[SCXML] Proposal to move to Java 8 minimum and drop/replace XML/XPath support with JSON

classic Classic list List threaded Threaded
7 messages Options
Reply | Threaded
Open this post in threaded view
|

[SCXML] Proposal to move to Java 8 minimum and drop/replace XML/XPath support with JSON

Ate Douma
Since early this year the progress and development of Commons SCXML 2.0 has
severely declined because of two major technical hurdles, and thereafter of
both motivation and lack of time:

- The SCXML XML/XPath datamodel support has been dropped from the final
W3C SCXML 1.0 specification [1], because of too many functional and semantic
complications and limitation, as well as lack of interest for implementing it.

The implementation of the XML/XPath datamodel in Commons SCXML has been
problematic for precisely the same reasons.
And not being able to provide such implementation properly by us (Commons
SCXML) actually has been one (final) argument for dropping it from the
specification...

- The implementation of the Javascript datamodel support based on the
old/outdated Rhino Javascript engine in Java 7 and below, turned out to be
quite difficult. While it turns out to be much easier and reliable, but
different, with the new Nashorn Javascript engine in Java 8+.

After bringing this first up on the user@ list earlier this week, I now want to
propose the following major changes to revive the further development towards
Commons SCXML 2.0:
- drop the support for XML/XPath based datamodel, and instead introduce a much
   easier to implement and support JSON datamodel as alternative, for all current
   Commons SCXML support 'languages': JEXL, Groovy and Javascript.
- bump the minimum Java version to 8 so we can leverage and only need to support
   the Nashorn Javascript engine

The only user response so far on user@ is fully in favor of these changes,
and both myself and Woonsan Ko are motivated to continue developing and
completing the goals for Commons SCXML 2.0 based on these changes.

If nobody here has strong arguments against the above proposal (and assuming
lazy consensus otherwise), we would like to start on these changes shortly,
before the end of the year.

Kind regards,
Ate Douma
Woonsan Ko

[1] http://www.w3.org/TR/2015/REC-scxml-20150901/

---------------------------------------------------------------------
To unsubscribe, e-mail: [hidden email]
For additional commands, e-mail: [hidden email]

Reply | Threaded
Open this post in threaded view
|

Re: [SCXML] Proposal to move to Java 8 minimum and drop/replace XML/XPath support with JSON

Juan Antonio Breña Moral
Good morning,

If you need some help in testing or development process, I could help
with some hours per month.

I was using the first version.

Juan Antonio

El 2015-12-09 10:15, Ate Douma escribió:

> Since early this year the progress and development of Commons SCXML 2.0
> has
> severely declined because of two major technical hurdles, and
> thereafter of
> both motivation and lack of time:
>
> - The SCXML XML/XPath datamodel support has been dropped from the final
> W3C SCXML 1.0 specification [1], because of too many functional and
> semantic
> complications and limitation, as well as lack of interest for
> implementing it.
>
> The implementation of the XML/XPath datamodel in Commons SCXML has been
> problematic for precisely the same reasons.
> And not being able to provide such implementation properly by us
> (Commons
> SCXML) actually has been one (final) argument for dropping it from the
> specification...
>
> - The implementation of the Javascript datamodel support based on the
> old/outdated Rhino Javascript engine in Java 7 and below, turned out to
> be
> quite difficult. While it turns out to be much easier and reliable, but
> different, with the new Nashorn Javascript engine in Java 8+.
>
> After bringing this first up on the user@ list earlier this week, I now
> want to
> propose the following major changes to revive the further development
> towards
> Commons SCXML 2.0:
> - drop the support for XML/XPath based datamodel, and instead introduce
> a much
>   easier to implement and support JSON datamodel as alternative, for
> all current
>   Commons SCXML support 'languages': JEXL, Groovy and Javascript.
> - bump the minimum Java version to 8 so we can leverage and only need
> to support
>   the Nashorn Javascript engine
>
> The only user response so far on user@ is fully in favor of these
> changes,
> and both myself and Woonsan Ko are motivated to continue developing and
> completing the goals for Commons SCXML 2.0 based on these changes.
>
> If nobody here has strong arguments against the above proposal (and
> assuming
> lazy consensus otherwise), we would like to start on these changes
> shortly,
> before the end of the year.
>
> Kind regards,
> Ate Douma
> Woonsan Ko
>
> [1] http://www.w3.org/TR/2015/REC-scxml-20150901/
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: [hidden email]
> For additional commands, e-mail: [hidden email]


---------------------------------------------------------------------
To unsubscribe, e-mail: [hidden email]
For additional commands, e-mail: [hidden email]

Reply | Threaded
Open this post in threaded view
|

Re: [SCXML] Proposal to move to Java 8 minimum and drop/replace XML/XPath support with JSON

Benedikt Ritter-4
In reply to this post by Ate Douma
Hello Ate,

2015-12-09 10:15 GMT+01:00 Ate Douma <[hidden email]>:

> Since early this year the progress and development of Commons SCXML 2.0 has
> severely declined because of two major technical hurdles, and thereafter of
> both motivation and lack of time:
>
> - The SCXML XML/XPath datamodel support has been dropped from the final
> W3C SCXML 1.0 specification [1], because of too many functional and
> semantic
> complications and limitation, as well as lack of interest for implementing
> it.
>
> The implementation of the XML/XPath datamodel in Commons SCXML has been
> problematic for precisely the same reasons.
> And not being able to provide such implementation properly by us (Commons
> SCXML) actually has been one (final) argument for dropping it from the
> specification...
>
> - The implementation of the Javascript datamodel support based on the
> old/outdated Rhino Javascript engine in Java 7 and below, turned out to be
> quite difficult. While it turns out to be much easier and reliable, but
> different, with the new Nashorn Javascript engine in Java 8+.
>
> After bringing this first up on the user@ list earlier this week, I now
> want to
> propose the following major changes to revive the further development
> towards
> Commons SCXML 2.0:
> - drop the support for XML/XPath based datamodel, and instead introduce a
> much
>   easier to implement and support JSON datamodel as alternative, for all
> current
>   Commons SCXML support 'languages': JEXL, Groovy and Javascript.
> - bump the minimum Java version to 8 so we can leverage and only need to
> support
>   the Nashorn Javascript engine
>
> The only user response so far on user@ is fully in favor of these changes,
> and both myself and Woonsan Ko are motivated to continue developing and
> completing the goals for Commons SCXML 2.0 based on these changes.
>
> If nobody here has strong arguments against the above proposal (and
> assuming
> lazy consensus otherwise), we would like to start on these changes shortly,
> before the end of the year.
>

I'm all for upgrading to Java 8 if it eases the development of Commons
SCXML. Go for it.

Regards,
Benedikt


>
> Kind regards,
> Ate Douma
> Woonsan Ko
>
> [1] http://www.w3.org/TR/2015/REC-scxml-20150901/
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: [hidden email]
> For additional commands, e-mail: [hidden email]
>
>


--
http://people.apache.org/~britter/
http://www.systemoutprintln.de/
http://twitter.com/BenediktRitter
http://github.com/britter
Reply | Threaded
Open this post in threaded view
|

Re: [SCXML] Proposal to move to Java 8 minimum and drop/replace XML/XPath support with JSON

Ate Douma
In reply to this post by Ate Douma
We'll now make a start with executing on the below proposal, moving to Java 8
first and then introducing JSON datamodel support to replace and drop XML/XPath
datamodel thereafter.

Regards, Ate

On 2015-12-09 10:15, Ate Douma wrote:

> Since early this year the progress and development of Commons SCXML 2.0 has
> severely declined because of two major technical hurdles, and thereafter of
> both motivation and lack of time:
>
> - The SCXML XML/XPath datamodel support has been dropped from the final
> W3C SCXML 1.0 specification [1], because of too many functional and semantic
> complications and limitation, as well as lack of interest for implementing it.
>
> The implementation of the XML/XPath datamodel in Commons SCXML has been
> problematic for precisely the same reasons.
> And not being able to provide such implementation properly by us (Commons
> SCXML) actually has been one (final) argument for dropping it from the
> specification...
>
> - The implementation of the Javascript datamodel support based on the
> old/outdated Rhino Javascript engine in Java 7 and below, turned out to be
> quite difficult. While it turns out to be much easier and reliable, but
> different, with the new Nashorn Javascript engine in Java 8+.
>
> After bringing this first up on the user@ list earlier this week, I now want to
> propose the following major changes to revive the further development towards
> Commons SCXML 2.0:
> - drop the support for XML/XPath based datamodel, and instead introduce a much
>    easier to implement and support JSON datamodel as alternative, for all current
>    Commons SCXML support 'languages': JEXL, Groovy and Javascript.
> - bump the minimum Java version to 8 so we can leverage and only need to support
>    the Nashorn Javascript engine
>
> The only user response so far on user@ is fully in favor of these changes,
> and both myself and Woonsan Ko are motivated to continue developing and
> completing the goals for Commons SCXML 2.0 based on these changes.
>
> If nobody here has strong arguments against the above proposal (and assuming
> lazy consensus otherwise), we would like to start on these changes shortly,
> before the end of the year.
>
> Kind regards,
> Ate Douma
> Woonsan Ko
>
> [1] http://www.w3.org/TR/2015/REC-scxml-20150901/


---------------------------------------------------------------------
To unsubscribe, e-mail: [hidden email]
For additional commands, e-mail: [hidden email]

Reply | Threaded
Open this post in threaded view
|

Re: [SCXML] Proposal to move to Java 8 minimum and drop/replace XML/XPath support with JSON

garydgregory
Go to town! ;-)

G

On Wed, Dec 23, 2015 at 4:00 AM, Ate Douma <[hidden email]> wrote:

> We'll now make a start with executing on the below proposal, moving to
> Java 8 first and then introducing JSON datamodel support to replace and
> drop XML/XPath datamodel thereafter.
>
> Regards, Ate
>
>
> On 2015-12-09 10:15, Ate Douma wrote:
>
>> Since early this year the progress and development of Commons SCXML 2.0
>> has
>> severely declined because of two major technical hurdles, and thereafter
>> of
>> both motivation and lack of time:
>>
>> - The SCXML XML/XPath datamodel support has been dropped from the final
>> W3C SCXML 1.0 specification [1], because of too many functional and
>> semantic
>> complications and limitation, as well as lack of interest for
>> implementing it.
>>
>> The implementation of the XML/XPath datamodel in Commons SCXML has been
>> problematic for precisely the same reasons.
>> And not being able to provide such implementation properly by us (Commons
>> SCXML) actually has been one (final) argument for dropping it from the
>> specification...
>>
>> - The implementation of the Javascript datamodel support based on the
>> old/outdated Rhino Javascript engine in Java 7 and below, turned out to be
>> quite difficult. While it turns out to be much easier and reliable, but
>> different, with the new Nashorn Javascript engine in Java 8+.
>>
>> After bringing this first up on the user@ list earlier this week, I now
>> want to
>> propose the following major changes to revive the further development
>> towards
>> Commons SCXML 2.0:
>> - drop the support for XML/XPath based datamodel, and instead introduce a
>> much
>>    easier to implement and support JSON datamodel as alternative, for all
>> current
>>    Commons SCXML support 'languages': JEXL, Groovy and Javascript.
>> - bump the minimum Java version to 8 so we can leverage and only need to
>> support
>>    the Nashorn Javascript engine
>>
>> The only user response so far on user@ is fully in favor of these
>> changes,
>> and both myself and Woonsan Ko are motivated to continue developing and
>> completing the goals for Commons SCXML 2.0 based on these changes.
>>
>> If nobody here has strong arguments against the above proposal (and
>> assuming
>> lazy consensus otherwise), we would like to start on these changes
>> shortly,
>> before the end of the year.
>>
>> Kind regards,
>> Ate Douma
>> Woonsan Ko
>>
>> [1] http://www.w3.org/TR/2015/REC-scxml-20150901/
>>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: [hidden email]
> For additional commands, e-mail: [hidden email]
>
>


--
E-Mail: [hidden email] | [hidden email]
Java Persistence with Hibernate, Second Edition
<http://www.manning.com/bauer3/>
JUnit in Action, Second Edition <http://www.manning.com/tahchiev/>
Spring Batch in Action <http://www.manning.com/templier/>
Blog: http://garygregory.wordpress.com
Home: http://garygregory.com/
Tweet! http://twitter.com/GaryGregory
Reply | Threaded
Open this post in threaded view
|

Re: [SCXML] Proposal to move to Java 8 minimum and drop/replace XML/XPath support with JSON

Woonsan Ko-4
In reply to this post by Ate Douma
Hi Ate,

Can we create jira tickets for each story in the proposal as a next step?

Regards,

Woonsan (Sent from my iPhone)

> On Dec 23, 2015, at 7:00 AM, Ate Douma <[hidden email]> wrote:
>
> We'll now make a start with executing on the below proposal, moving to Java 8 first and then introducing JSON datamodel support to replace and drop XML/XPath datamodel thereafter.
>
> Regards, Ate
>
>> On 2015-12-09 10:15, Ate Douma wrote:
>> Since early this year the progress and development of Commons SCXML 2.0 has
>> severely declined because of two major technical hurdles, and thereafter of
>> both motivation and lack of time:
>>
>> - The SCXML XML/XPath datamodel support has been dropped from the final
>> W3C SCXML 1.0 specification [1], because of too many functional and semantic
>> complications and limitation, as well as lack of interest for implementing it.
>>
>> The implementation of the XML/XPath datamodel in Commons SCXML has been
>> problematic for precisely the same reasons.
>> And not being able to provide such implementation properly by us (Commons
>> SCXML) actually has been one (final) argument for dropping it from the
>> specification...
>>
>> - The implementation of the Javascript datamodel support based on the
>> old/outdated Rhino Javascript engine in Java 7 and below, turned out to be
>> quite difficult. While it turns out to be much easier and reliable, but
>> different, with the new Nashorn Javascript engine in Java 8+.
>>
>> After bringing this first up on the user@ list earlier this week, I now want to
>> propose the following major changes to revive the further development towards
>> Commons SCXML 2.0:
>> - drop the support for XML/XPath based datamodel, and instead introduce a much
>>   easier to implement and support JSON datamodel as alternative, for all current
>>   Commons SCXML support 'languages': JEXL, Groovy and Javascript.
>> - bump the minimum Java version to 8 so we can leverage and only need to support
>>   the Nashorn Javascript engine
>>
>> The only user response so far on user@ is fully in favor of these changes,
>> and both myself and Woonsan Ko are motivated to continue developing and
>> completing the goals for Commons SCXML 2.0 based on these changes.
>>
>> If nobody here has strong arguments against the above proposal (and assuming
>> lazy consensus otherwise), we would like to start on these changes shortly,
>> before the end of the year.
>>
>> Kind regards,
>> Ate Douma
>> Woonsan Ko
>>
>> [1] http://www.w3.org/TR/2015/REC-scxml-20150901/
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: [hidden email]
> For additional commands, e-mail: [hidden email]
>
Reply | Threaded
Open this post in threaded view
|

Re: [SCXML] Proposal to move to Java 8 minimum and drop/replace XML/XPath support with JSON

Woonsan Ko-3
In reply to this post by Ate Douma
I've just created JIRA tickets for the proposal:
- https://issues.apache.org/jira/browse/SCXML-249 (Moving to Java 8 in 2.0)
- https://issues.apache.org/jira/browse/SCXML-250 (Drop XML/XPath
based data model in 2.0)

Replacing Rhino JS evaluator by Nashorn was already done with
SCXML-245, so there are only two items regarding this proposal.
SCXML-250 could probably take more time to replace existing tests
though.

Regards,

Woonsan


On Wed, Dec 23, 2015 at 7:00 AM, Ate Douma <[hidden email]> wrote:

> We'll now make a start with executing on the below proposal, moving to Java
> 8 first and then introducing JSON datamodel support to replace and drop
> XML/XPath datamodel thereafter.
>
> Regards, Ate
>
>
> On 2015-12-09 10:15, Ate Douma wrote:
>>
>> Since early this year the progress and development of Commons SCXML 2.0
>> has
>> severely declined because of two major technical hurdles, and thereafter
>> of
>> both motivation and lack of time:
>>
>> - The SCXML XML/XPath datamodel support has been dropped from the final
>> W3C SCXML 1.0 specification [1], because of too many functional and
>> semantic
>> complications and limitation, as well as lack of interest for implementing
>> it.
>>
>> The implementation of the XML/XPath datamodel in Commons SCXML has been
>> problematic for precisely the same reasons.
>> And not being able to provide such implementation properly by us (Commons
>> SCXML) actually has been one (final) argument for dropping it from the
>> specification...
>>
>> - The implementation of the Javascript datamodel support based on the
>> old/outdated Rhino Javascript engine in Java 7 and below, turned out to be
>> quite difficult. While it turns out to be much easier and reliable, but
>> different, with the new Nashorn Javascript engine in Java 8+.
>>
>> After bringing this first up on the user@ list earlier this week, I now
>> want to
>> propose the following major changes to revive the further development
>> towards
>> Commons SCXML 2.0:
>> - drop the support for XML/XPath based datamodel, and instead introduce a
>> much
>>    easier to implement and support JSON datamodel as alternative, for all
>> current
>>    Commons SCXML support 'languages': JEXL, Groovy and Javascript.
>> - bump the minimum Java version to 8 so we can leverage and only need to
>> support
>>    the Nashorn Javascript engine
>>
>> The only user response so far on user@ is fully in favor of these changes,
>> and both myself and Woonsan Ko are motivated to continue developing and
>> completing the goals for Commons SCXML 2.0 based on these changes.
>>
>> If nobody here has strong arguments against the above proposal (and
>> assuming
>> lazy consensus otherwise), we would like to start on these changes
>> shortly,
>> before the end of the year.
>>
>> Kind regards,
>> Ate Douma
>> Woonsan Ko
>>
>> [1] http://www.w3.org/TR/2015/REC-scxml-20150901/
>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: [hidden email]
> For additional commands, e-mail: [hidden email]
>

---------------------------------------------------------------------
To unsubscribe, e-mail: [hidden email]
For additional commands, e-mail: [hidden email]