Re: status and release of commons-scxml-2.0?
Hi Jake,
On 19/04/2019 16.15, Jacob Beard wrote:
Hi Ate,
Thanks for your reply. I think I could help with these issues, and close the
gap for full compliance of the js language model.
That would be great and definitely appreciated.
But that said: I'm still worried if it actually is worth the effort.
Because: who is looking for or (still) waiting for js language
support in commons-scxml?
Community wise, there have been no concrete questions or requests
concerning the js language for many years.
And with the Nashorn engine now deprecated, the current implementation
is besides being incomplete, not sustainable in the long run anyway.
Of course we could consider adding support for GraalVM instead, but is
anyone really asking or waiting for that either?
We currently have pretty solid and SCXML compliant language support with
jexl and groovy, which might be good enough in practice for many, if not
all, of the community.
What I really dislike is further delaying the 2.0 release just because
of the incomplete js language support, and with a unclear idea if it
ever can/will be completed.
Although I personally would still vote +1 to remove js language support,
I also can agree to keep it for a while longer to allow others like you
to chime in and try completing.
But pending that uncertain outcome, I rather proceed with the 2.0
release ASAP anyway, explicitly stating the js language support is not
finished and to be considered alpha or beta.
I was wondering, did you have a timeline in mind for the 2.0 release? I should
start to free up in June/July.
I may be able to spend some cycles the coming month (May) to proceed
with the above idea and work towards a 2.0 release, independent of the
js language support status.
Once we have a 2.0 release out, we can (more) easily roll out newer
minor/patch releases thereafter for improved js language support if and
when we get that incorporated.
Regards,
Ate
Let me know what you think. Thank you,
Jake
On Apr 18, 2019, at 3:46 PM, Ate Douma wrote:
On 18/04/2019 18.00, Jacob Beard wrote:
Hi Ate,
On Apr 18, 2019, at 11:23 AM, Ate Douma wrote:
Only for the javascript language (using Java 8 Nashorn, now deprecated
since Java 11...) there are still 3/188 W3C IRP tests failing.
And those 3 test failures are really, really difficult to fix, because
of limitations/quirks in the Nashorn engine itself.
Could you please provide more information on this? Which tests are failing, and
what are the limitations and quirks of Nashorn that cause this?
Sure.
Regarding 'quirks': see issue SCXML-273 [1] which concerns the problem
that the Nashorn engine by default doesn't fail on referencing a missing
property. Which is tested by W3C IRP test 307.
Regarding limitations: there are two W3C IRP ecma test, 557 and 561,
which make use of XML DOM APIs in a condition, like:
cond="var1.getElementsByTagName('book')[0].getAttribute('title') == 'title1'"
However Nashorn doesn't provide default/native XML DOM support, and
adding that would be (at least from my perspective) quite an effort, if
even properly doable.
That doesn't feel like worth the effort, with little added value/ROI.
[1] https://issues.apache.org/jira/browse/SCXML-273
Thank you,
Jake
-
To unsubscribe, e-mail: user-unsubscr...@commons.apache.org
For additional commands, e-mail: user-h...@commons.apache.org
-
To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
For additional commands, e-mail: dev-h...@commons.apache.org
Re: status and release of commons-scxml-2.0?
On 18/04/2019 18.00, Jacob Beard wrote:
Hi Ate,
On Apr 18, 2019, at 11:23 AM, Ate Douma wrote:
Only for the javascript language (using Java 8 Nashorn, now deprecated
since Java 11...) there are still 3/188 W3C IRP tests failing.
And those 3 test failures are really, really difficult to fix, because
of limitations/quirks in the Nashorn engine itself.
Could you please provide more information on this? Which tests are failing, and
what are the limitations and quirks of Nashorn that cause this?
Sure.
Regarding 'quirks': see issue SCXML-273 [1] which concerns the problem
that the Nashorn engine by default doesn't fail on referencing a missing
property. Which is tested by W3C IRP test 307.
Regarding limitations: there are two W3C IRP ecma test, 557 and 561,
which make use of XML DOM APIs in a condition, like:
cond="var1.getElementsByTagName('book')[0].getAttribute('title') ==
'title1'"
However Nashorn doesn't provide default/native XML DOM support, and
adding that would be (at least from my perspective) quite an effort, if
even properly doable.
That doesn't feel like worth the effort, with little added value/ROI.
[1] https://issues.apache.org/jira/browse/SCXML-273
Thank you,
Jake
-
To unsubscribe, e-mail: user-unsubscr...@commons.apache.org
For additional commands, e-mail: user-h...@commons.apache.org
-
To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
For additional commands, e-mail: dev-h...@commons.apache.org
status and release of commons-scxml-2.0?
Hi developers/community, I've received an out-of-band request about the current status of commons-scxml-2.0 and its release schedule. As there might be more (hopefully at least a few) people interested in this, and I don't like answering out-of-band questions, I'm giving a heads-up here for the whole community. To be absolutely clear upfront: I've dropped the ball on this (again) since my last burst of changes early 2018. I simply didn't, and still don't, have the cycles and priority to work on this beyond maybe minimally answering a few questions now and then. Now, there have been only very few questions in the last several years, and luckily Woonsan (who is a remote colleague of mine in our d2d job) stepped in to help with those as well. So practically, there hasn't been much demand or pressure to wrap-up the work and finish the 2.0 release. And neither from my d2d job (we're still happily using the 2.0-M1 release without problems so far). But technically, the current master branch towards the 2.0 release *is* practically done and ready to be tagged and released. If/when a few remaining cleanup and polishing tasks are completed... The current master branch *is* already fully compliant with the W3C SCXML 1.0 specification, including passing all the W3C (IRP) tests for it. At least, when using the jexl or groovy script languages. And the Common SCXML 2.0 engine IMO is pretty cool and convenient to use, for those who like/need a formalized statemachine engine. Only for the javascript language (using Java 8 Nashorn, now deprecated since Java 11...) there are still 3/188 W3C IRP tests failing. And those 3 test failures are really, really difficult to fix, because of limitations/quirks in the Nashorn engine itself. So that is where I got 'stuck'. I honestly lost interest and desire to try fix this, given that Nashorn now is deprecated in Java 11 anyway, I don't think anyone is actually using/waiting for the javascript language support to begin with, and so I rather just/simply rip out the whole javascript language support and be done with it. And then, there is the remaining work to: a) Fix/remove/replace existing documentation, which is still mostly based upon the last 0.9 release from more than a decade ago. To do this properly is/would be a major effort in itself, as the commons-scxml-2.0 API is really, really different now. b) Fix/configure the site generation itself (I'm actually clueless) c) Check/adjust current checkstyle and other build/release reports to be more in line with the common practices for Apache Commons projects? For task a) I assume I'd have to take first responsibility, possible/hopefully with some help from Woonsan, because 80+% of the code and API changes were made by me, the rest by Woonsan. However I honestly don't have the cycles to do this properly right now. But if it is acceptable to only do the bare minimum, and at least remove the out-of-date examples and just have a basic/minimal 'getting started' page, I could pull that off in a few weeks time. For task b) I assume other devs may be able to help out a bit: I just needs some explanation and clarification how this (now) is supposed to work. Lastly, for task c) I don't know what the current/common policy is or should be: the only thing I realized is that the current reporting configuration is extremely old (10+ years) and might need adjusting. I guess this is also something other Commons devs might be able to explain or even help out with? Looking forward to further input, and hopefully some offered help, because I really would like to wrap this up, sometime soon. Regards, Ate - To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org For additional commands, e-mail: dev-h...@commons.apache.org
Re: [Math] Technical objection (Was: [math] [POLL] new TLP name)
On 2016-02-02 12:43, Gilles wrote: On Mon, 1 Feb 2016 10:06:40 -0700, Phil Steitz wrote: Please select your top choice among the following suggested names for the new [math]-based TLP. All are welcome and encouraged to respond. This POLL will be open for 72 hours, at which time two tallies will be presented: one among those who have volunteered for the new PMC and a second among all respondents. Hopefully, one name will emerge as consensus winner. If not, I will kick off another runoff poll among the top choices. Please respond with your top choice for the name. AjaMa Epsilon Erdos Euclid Euler Gauss JAML This choice: Math can potentially lead to legal and/or technical problems: * name of the JAR will basically be "math.jar", easily clashing with local toolboxes (also named without much imagination) apache-math-x.y.z.jar will fix the name clashing trivially. * name of the project will obviously be impossible to protect MathBlocks MathComponents (or Math Components) Mathelactica MathModules Megginson modMath Nash Newton Pythagoras The second objection of course holds for many names in the list. We'd better follow Bertrand's suggestion. Gilles - To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org For additional commands, e-mail: dev-h...@commons.apache.org - To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org For additional commands, e-mail: dev-h...@commons.apache.org
Re: [VOTE] Form a separate TLP based on [math]
+1 Ate On 2016-01-16 16:18, Phil Steitz wrote: The discussion has thus far been generally favorable. I would like therefore to put the proposal to split [math] out into a separate TLP to a VOTE. Assuming a favorable vote, we can discuss how to go about doing it. Votes, please. All are welcome to vote. [ ] +1 I am in favor of this action [ ] +0 I am OK with this [ ] -0 OK, but... [ ] -1 I oppose this action because... This VOTE will run a little longer than usual - closing at 20 Jan 13:00 UTC. Thanks! Phil - To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org For additional commands, e-mail: dev-h...@commons.apache.org - To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org For additional commands, e-mail: dev-h...@commons.apache.org
Re: [SCXML] Proposal to move to Java 8 minimum and drop/replace XML/XPath support with JSON
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: dev-unsubscr...@commons.apache.org For additional commands, e-mail: dev-h...@commons.apache.org
[SCXML] Proposal to move to Java 8 minimum and drop/replace XML/XPath support with JSON
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: dev-unsubscr...@commons.apache.org For additional commands, e-mail: dev-h...@commons.apache.org
Re: [VOTE][LAZY] Migrate Commons SCXML to Git
Sorry for the too late response, but I would have voted +1 too :) Ate On 2015-07-08 20:27, Woonsan Ko wrote: Apache Commons Developers, This VOTE has passed with the following votes: +1 Dave Brosius +1 James Carman (PMC) +1 Gary Gregory (PMC) +1 Woonsan Ko Thank you all for voting! I will create an INFRA ticket soon and keep you updated about the progress and availabilities. Regards, Woonsan Ko On Wed, Jul 1, 2015 at 9:50 PM, Woonsan Ko wrote: Hi there, I think the experiences in Commons Math and Commons Lang using git as primary VCS have been successful. Also, we received requests from some new people about using git instead (through mailing list and JIRA tickets). So, I'd like to call a vote to migrate Commons SCXML to git, assuming most Commons SCXML developers feel comfortable with switching to git. (Please see [1] for summarized info about using git in Apache Commons project.) This vote by lazy consensus will close no sooner than 72 hours from now, i.e. after 2015-07-07 18:00 EDT. [ ] +1 go for it [ ] +0 OK, but... [ ] -0 Not happy about this, because... [ ] -1 We should not do this Thanks! Woonsan [1] https://wiki.apache.org/commons/UsingGIT - To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org For additional commands, e-mail: dev-h...@commons.apache.org - To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org For additional commands, e-mail: dev-h...@commons.apache.org
Re: svn commit: r1602784 - /commons/proper/scxml/trunk/src/main/java/org/apache/commons/scxml2/model/Action.java
Dave,
Thanks for detecting and fixing the potential NPE below, much appreciated!
But your fix had a potential functional side-effect, which I now fixed in
http://svn.apache.org/r1621831
Maybe it would be good if you (or whoever) applies such micro fixes to also send
a heads-up to the dev@ list so we'd notice these earlier and are better aware of
the need to review them...
Thanks, Ate
On 16-06-14 02:57, dbros...@apache.org wrote:
Author: dbrosius
Date: Mon Jun 16 00:57:57 2014
New Revision: 1602784
URL: http://svn.apache.org/r1602784
Log:
guard against npes
Modified:
commons/proper/scxml/trunk/src/main/java/org/apache/commons/scxml2/model/Action.java
Modified:
commons/proper/scxml/trunk/src/main/java/org/apache/commons/scxml2/model/Action.java
URL:
http://svn.apache.org/viewvc/commons/proper/scxml/trunk/src/main/java/org/apache/commons/scxml2/model/Action.java?rev=1602784&r1=1602783&r2=1602784&view=diff
==
---
commons/proper/scxml/trunk/src/main/java/org/apache/commons/scxml2/model/Action.java
(original)
+++
commons/proper/scxml/trunk/src/main/java/org/apache/commons/scxml2/model/Action.java
Mon Jun 16 00:57:57 2014
@@ -98,7 +98,7 @@ public abstract class Action implements
*/
public final EnterableState getParentEnterableState()
throws ModelException {
-if (parent == null && this instanceof Script &&
((Script)this).isGlobalScript()) {
+if (parent == null || (this instanceof Script &&
((Script)this).isGlobalScript())) {
// global script doesn't have a EnterableState
return null;
}
-
To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
For additional commands, e-mail: dev-h...@commons.apache.org
Re: Apache Commons & ApacheCon Europe 2014
Hi all, Sorry for chiming in this late but I definitely think it would be cool, and very useful, to organize a dedicated Commons track at the ApacheCon, and promote this project as a whole. Siegfried and I discussed this a bit in Denver, and I also talked about it with Rich Bowen if a special Commons track would be feasible for the next ApacheCon. Rich said he definitely liked the idea and if we come up with a good proposal it has much chance of being accepted. I think there is plenty of activity here in several Commons components to talk about. Not all might need a separate full track: combining 2 or 3 smaller presentations into one full track slot IMO should be feasible AND actually more interesting for the audience. And if we can come up with some 5, 6 or even more of such short tracks, we can combine them together into a proper Apache Commons track. I think it is important to note that, at least IMO, such presentations not necessarily need to cover a formal released component version, but very well may (also or alone) present the current state of development, roadmap plans, etc. The goal and purpose of such presentations need not just be 'tutorial' or 'explanatory' style, but also can (and should!) target community building and giving potential users some ideas what is or might be in stock in the future. Anyone seriously scratching an itch here at Commons IMO might have something useful to talk about, and hopefully also is interested in talking about it with interested peers and community members! Now, if the upcoming ApacheCon at Budapest in November is feasible for you all or not, I cannot say. Even I cannot make a promise for that already this early. But it would be great to hear who *might* be interested in participating in such a Apache Commons track, about what topic/component you'd like to talk about, etc. Just to determine if this might be a feasible setup, already next ApacheCon or maybe sometimes later. I definitely would like to present again on the SCXML component, its possible 2.0 release by that time, and/or give an overview of its current status and roadmap like I did in Denver. Doing so in only 15-20 min. would be fine to me, especially if its part of a larger Commons track. So, who else here is potentially interested in doing something similar? Thanks, Ate On 18-04-14 20:47, Siegfried Goeschl wrote: Hi folks, so judging from the conversation we have volunteers for Apache Commons VFS :-) Reclaiming the message thread - who else would like to present his/her pet component? Thanks in advance Siegfried Goeschl On 17 Apr 2014, at 17:28, Schalk Cronjé wrote: On 17/04/2014 23:45, Mark Fortner wrote: Schalk, It's my understanding that new providers in NIO2 are simply added using the ServiceLoader. Cheers, Mark Hi Mark, Maybe I should have explained better, In Apache VFS one can either add custom providers via a META-INF/vfs-providers.xml file (behaviour of StandardFileSystemManager). This means just compiling a JAR accordingly and have it available on the classpath. Let's call this Approach A. Alternatively one can call addProvider (on DefaultFileSystemManager) directly. This is quite useful in certain circumstances to do this programmatically. This is Approach B. With NIO2 loading occurs by providing a META-INF/services/java.nio.file.spi.FileSystemProvider file and ServiceLoader should take care of it. This is effectively the NIO2 way of Approach A. What I am saying is that I would like to have an Approach B for NIO2 as well, except that I have seen no clear way of accomplishing it. It could just be a lack of knowledge on my side. On Thu, Apr 17, 2014 at 3:31 PM, Schalk Cronj é wrote: On 17/04/2014 22:38, Bernd Eckenfels wrote: But theoretically both is possible: consume FileSystems as a provider or implement an adapter which makes a VFS filesystem(manager) to provide the FileSystem SPI. I have been playing with that and it looks possible, but it is far from trivial. The meagre documentation or even lack of published success in writing NIO2 providers shows that this is a road less travelled. I have looked at the supplied ZIP example that comes with the JDK and IMHO still very much prototype code. I think VFS has some things going for it that I could not see in NIO2 - even something as simple as having two schemes for one provider. In addition, adding providers on the fly is easy in VFS, by just calling addProvider on FilesystemManager. From my initial investigation I could not see a clear way of doing the equivalent in NIO2. There will be more things like these, I am sure. I am very interesting in where this is going in future and the maintainer of Groovy VFS, I have a vested interest. I might be interested to go to Budapest in November if this gets discussed. -- Schalk W. Cronjé @ysb33r - To unsubscribe, e-mail: dev-unsubscr...@
[SCXML] developer heads-up: Commons SCXML 2.0-M1 (milestone 1) tag now available - please test
SCXML developers, I've just created the second Commons SCXML 2.0-M1 milestone tag on the roadmap towards Commons SCXML 2.0 [1]. This milestone incorporates some major (and drastic) changes, and completely replaces the old SCXMLSemantics with a new implementation which now is fully compliant to the current SCXML specification [2],[3]. Actually, its even a little bit ahead of the specification right now, as I discovered a few edge-case issues in the specification, which I reported and discussed with the specification group [4], and which have been solved already in the Apache Commons SCXML implementation :) Also important to note is that the internal structure of many of the controlling parts of the engine has been refactored, towards a much cleaner separation of concern [5]. Finally, most of the core SCXML Document model has been updated to be now fully compliant with the SCXML specification as well [6]. There are certainly still several hurdles to take and additional features to be implemented, which will be the subject of the next milestone(s) ahead. Please check out the roadmap overview [1] for further details. It would be great if you can test this new milestone and report anything which doesn't work as expected, besides the already planned fixes and improvements of course. To get an overview of all the issues resolved for version 2.0 since the previous milestone 0 (2014-03-11) up to today you can use the JIRA query in [7]. To be able to test drive this tag, you'll first have to checkout the code using: $ svn co https://svn.apache.org/repos/asf/commons/proper/scxml/tags/commons-scxml2-2.0-M1 build and install to your local Maven repository: $ cd commons-scxml2-2.0-M1 & mvn install and then in your Maven project add the following dependency configuration: org.apache.commons commons-scxml2 2.0-M1 Note (again) also the change of both the groupId and artifactId from commons-scxml:commons-scxml to org.apache.commons:commons-scmxl2. Subsequent milestone tags will provide new and changed functionalities as indicated on the roadmap. Regards, Ate [1] http://commons.apache.org/proper/commons-scxml/roadmap.html [2] http://www.w3.org/TR/2014/CR-scxml-20140313/#AlgorithmforSCXMLInterpretation [3] https://issues.apache.org/jira/browse/SCXML-196 [4] http://lists.w3.org/Archives/Public/www-voice/ [5] https://issues.apache.org/jira/browse/SCXML-197 [6] https://issues.apache.org/jira/browse/SCXML-200 [7] https://issues.apache.org/jira/browse/SCXML-201?jql=fixVersion%20%3D%202.0%20AND%20project%20%3D%20SCXML%20AND%20resolved%20%3C%20%222014%2F04%2F04%22%20and%20resolved%20%3E%20%222014%2F03%2F11%22%20ORDER%20BY%20key%20DESC - To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org For additional commands, e-mail: dev-h...@commons.apache.org
Re: svn commit: r1580369 [1/5] - in /commons/proper/scxml/trunk/src: main/java/org/apache/commons/scxml2/ main/java/org/apache/commons/scxml2/env/ main/java/org/apache/commons/scxml2/env/groovy/ main/
Darn. Thanks for spotting this Matt. I actually did have a commit message prepared but must have either forgotten to paste it in or something else went wrong there. I'll update the revision log right away. Thanks again, Ate On 23-03-14 05:34, Matt Benson wrote: Ate, It would probably be nice if you'd rewrite the log message from this large commit to include the description of the JIRA issue as well as its ID, for future usability. Matt On Mar 22, 2014 6:35 PM, wrote: Author: ate Date: Sat Mar 22 23:34:20 2014 New Revision: 1580369 URL: http://svn.apache.org/r1580369 Log: SCXML-200: - To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org For additional commands, e-mail: dev-h...@commons.apache.org
[SCXML] developer heads-up: Commons SCXML 2.0-M0 (milestone 0) tag now available - please test
SCXML developers, I've just created a first Commons SCXML 2.0-M0 milestone tag as baseline for the roadmap [1] towards Commons SCXML 2.0. Please read the roadmap for further details. It would be great if you can test this first baseline to validate everything is still working as expected, for the features still supported :) Note that this first milestone did remove a lot of old/outdated features, see [2]. Also, as a next major release, the base Java package name changed from org.apache.commons.scxml.* to org.apache.commons.scxml2.* To get an overview of all the issues resolved for version 2.0 up to today you can use the JIRA query in [2]. To be able to test drive this tag, you'll first have to checkout the code using: $ svn co https://svn.apache.org/repos/asf/commons/proper/scxml/tags/commons-scxml2-2.0-M0 build and install to your local Maven repository: $ cd commons-scxml2-2.0-M0 & mvn install and then in your Maven project add the following dependency configuration: org.apache.commons commons-scxml2 2.0-M0 Note also the change of both the groupId and artifactId from commons-scxml:commons-scxml to org.apache.commons:commons-scmxl2. Subsequent milestone tags will provide new and changed functionalities as indicated on the roadmap. Regards, Ate [1] http://commons.apache.org/proper/commons-scxml/roadmap.html [2] https://issues.apache.org/jira/browse/SCXML-194 [3] https://issues.apache.org/jira/browse/SCXML-195?jql=fixVersion%20%3D%202.0%20AND%20project%20%3D%20SCXML%20AND%20resolved%20%3C%20%222014%2F03%2F11%22%20ORDER%20BY%20key%20DESC - To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org For additional commands, e-mail: dev-h...@commons.apache.org
Re: [SCXML] roadmap plan published - question about procedure for milestone tagging
On 11-03-14 12:24, sebb wrote: On 11 March 2014 09:11, Ate Douma wrote: On 11-03-14 01:00, Gary Gregory wrote: IMO, if you make artifacts available through MC, then it is a "release", whatever you label it, alpha, beta, milestone, and so on, which requires a VOTE. Right. Although in my book at the ASF we only formally VOTE on source releases, never on binary artifacts. Also note that providing (only) such convenience binaries, without need for voting, should be allowed, as specified on [1]: "During the process of developing software and preparing a release, various packages are made available to the developer community for testing purposes. Do not include any links on the project website that might encourage non-developers to download and use nightly builds, snapshots, release candidates, or any other similar package." However, also critical is the following sentence: "If you find that the general public are downloading such test packages, then remove them." So, it seems like it would be OK if I would provide pre-build milestone artifacts on a server managed through Apache so I can easily again remove these, while deploying them to Maven Central would make that rather difficult. The whole point of having these on Maven Central is only as a convenience (being a Maven repository) to testers. Putting binary artifacts 'standalone' in like my ASF people ~ folder, would defeat the purpose. Those developers willing to test drive these milestone builds then just as easily, even more so, can checkout the tag and do a local maven install. Anyway, I'll agree deploying to Maven Central is not an option without having a formal voted release first. There is an ASF snapshot repo. By default Continuum uploads there if the build&test succeeeds. And a manual deploy of a snapshot build should also upload the jars to that repo. So you could point developers (only) at the ASF snapshot repo. But remember that the snapshot repo contents can be updated/dropped at any time. Make sure developers are aware that the contents have not been formally released. Sure, I know about the ASF snapshot repo, and we already use that (too). My intend for the milestone builds is to provide a more stable (even if temporarily available) artifact to be used for testers. I already concurred that this cannot be done through Maven Central, which isn't a big deal really. The only extra step testers now need to do is check out the milestone tag themselves and deploy into their own local repository. Regards, Ate p.s. I've just created the first milestone 0 tag and will send out a separate heads-up to this list shortly. I'll update the roadmap plan description accordingly. If you do not make it available through MC, then you can use an SVN revision # or a tag for a more developer oriented milestone marker. Gary On Mon, Mar 10, 2014 at 6:52 PM, Ate Douma wrote: Hi, I just published a high-level roadmap plan towards SCXML 2.0 [1] Part of that plan, which consists of working through a set of milestone targets, is also tagging these milestones "as is", see [2]. As I also described there, these milestone tags will "not represent a formal release and they are only intended and targeted to be used by the Commons SCXML developers, not end users." I would however like to have these milestone tags be deployed and made available through Maven Central. My question is: is this OK for the Commons PMC and can I just create and deploy these tags (using maven release) without need to go through formal voting and validation? Again: these do not represent formal releases, nor will I provide download links or send out announcements, other than a developers heads-up here on dev@. Thanks, Ate p.s. Any feedback on the roadmap plan itself of course also is welcome :) [1] http://commons.apache.org/proper/commons-scxml/roadmap.html [2] http://commons.apache.org/proper/commons-scxml/roadmap. html#Milestone_tags - To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org For additional commands, e-mail: dev-h...@commons.apache.org - To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org For additional commands, e-mail: dev-h...@commons.apache.org - To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org For additional commands, e-mail: dev-h...@commons.apache.org - To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org For additional commands, e-mail: dev-h...@commons.apache.org
Re: [SCXML] roadmap plan published - question about procedure for milestone tagging
On 11-03-14 10:11, Ate Douma wrote: On 11-03-14 01:00, Gary Gregory wrote: IMO, if you make artifacts available through MC, then it is a "release", whatever you label it, alpha, beta, milestone, and so on, which requires a VOTE. Right. Although in my book at the ASF we only formally VOTE on source releases, never on binary artifacts. Also note that providing (only) such convenience binaries, without need for voting, should be allowed, as specified on [1]: I always forget to provide links :) Here is the one for [1] above, and specifically concerning the second paragraph: http://www.apache.org/dev/release.html#what "During the process of developing software and preparing a release, various packages are made available to the developer community for testing purposes. Do not include any links on the project website that might encourage non-developers to download and use nightly builds, snapshots, release candidates, or any other similar package." However, also critical is the following sentence: "If you find that the general public are downloading such test packages, then remove them." So, it seems like it would be OK if I would provide pre-build milestone artifacts on a server managed through Apache so I can easily again remove these, while deploying them to Maven Central would make that rather difficult. The whole point of having these on Maven Central is only as a convenience (being a Maven repository) to testers. Putting binary artifacts 'standalone' in like my ASF people ~ folder, would defeat the purpose. Those developers willing to test drive these milestone builds then just as easily, even more so, can checkout the tag and do a local maven install. Anyway, I'll agree deploying to Maven Central is not an option without having a formal voted release first. I'll update the roadmap plan description accordingly. Which I now have done and published. If you do not make it available through MC, then you can use an SVN revision # or a tag for a more developer oriented milestone marker. Gary On Mon, Mar 10, 2014 at 6:52 PM, Ate Douma wrote: Hi, I just published a high-level roadmap plan towards SCXML 2.0 [1] Part of that plan, which consists of working through a set of milestone targets, is also tagging these milestones "as is", see [2]. As I also described there, these milestone tags will "not represent a formal release and they are only intended and targeted to be used by the Commons SCXML developers, not end users." I would however like to have these milestone tags be deployed and made available through Maven Central. My question is: is this OK for the Commons PMC and can I just create and deploy these tags (using maven release) without need to go through formal voting and validation? Again: these do not represent formal releases, nor will I provide download links or send out announcements, other than a developers heads-up here on dev@. Thanks, Ate p.s. Any feedback on the roadmap plan itself of course also is welcome :) [1] http://commons.apache.org/proper/commons-scxml/roadmap.html [2] http://commons.apache.org/proper/commons-scxml/roadmap. html#Milestone_tags - To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org For additional commands, e-mail: dev-h...@commons.apache.org - To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org For additional commands, e-mail: dev-h...@commons.apache.org
Re: [SCXML] roadmap plan published - question about procedure for milestone tagging
On 11-03-14 01:00, Gary Gregory wrote: IMO, if you make artifacts available through MC, then it is a "release", whatever you label it, alpha, beta, milestone, and so on, which requires a VOTE. Right. Although in my book at the ASF we only formally VOTE on source releases, never on binary artifacts. Also note that providing (only) such convenience binaries, without need for voting, should be allowed, as specified on [1]: "During the process of developing software and preparing a release, various packages are made available to the developer community for testing purposes. Do not include any links on the project website that might encourage non-developers to download and use nightly builds, snapshots, release candidates, or any other similar package." However, also critical is the following sentence: "If you find that the general public are downloading such test packages, then remove them." So, it seems like it would be OK if I would provide pre-build milestone artifacts on a server managed through Apache so I can easily again remove these, while deploying them to Maven Central would make that rather difficult. The whole point of having these on Maven Central is only as a convenience (being a Maven repository) to testers. Putting binary artifacts 'standalone' in like my ASF people ~ folder, would defeat the purpose. Those developers willing to test drive these milestone builds then just as easily, even more so, can checkout the tag and do a local maven install. Anyway, I'll agree deploying to Maven Central is not an option without having a formal voted release first. I'll update the roadmap plan description accordingly. If you do not make it available through MC, then you can use an SVN revision # or a tag for a more developer oriented milestone marker. Gary On Mon, Mar 10, 2014 at 6:52 PM, Ate Douma wrote: Hi, I just published a high-level roadmap plan towards SCXML 2.0 [1] Part of that plan, which consists of working through a set of milestone targets, is also tagging these milestones "as is", see [2]. As I also described there, these milestone tags will "not represent a formal release and they are only intended and targeted to be used by the Commons SCXML developers, not end users." I would however like to have these milestone tags be deployed and made available through Maven Central. My question is: is this OK for the Commons PMC and can I just create and deploy these tags (using maven release) without need to go through formal voting and validation? Again: these do not represent formal releases, nor will I provide download links or send out announcements, other than a developers heads-up here on dev@. Thanks, Ate p.s. Any feedback on the roadmap plan itself of course also is welcome :) [1] http://commons.apache.org/proper/commons-scxml/roadmap.html [2] http://commons.apache.org/proper/commons-scxml/roadmap. html#Milestone_tags - To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org For additional commands, e-mail: dev-h...@commons.apache.org - To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org For additional commands, e-mail: dev-h...@commons.apache.org
[SCXML] roadmap plan published - question about procedure for milestone tagging
Hi, I just published a high-level roadmap plan towards SCXML 2.0 [1] Part of that plan, which consists of working through a set of milestone targets, is also tagging these milestones "as is", see [2]. As I also described there, these milestone tags will "not represent a formal release and they are only intended and targeted to be used by the Commons SCXML developers, not end users." I would however like to have these milestone tags be deployed and made available through Maven Central. My question is: is this OK for the Commons PMC and can I just create and deploy these tags (using maven release) without need to go through formal voting and validation? Again: these do not represent formal releases, nor will I provide download links or send out announcements, other than a developers heads-up here on dev@. Thanks, Ate p.s. Any feedback on the roadmap plan itself of course also is welcome :) [1] http://commons.apache.org/proper/commons-scxml/roadmap.html [2] http://commons.apache.org/proper/commons-scxml/roadmap.html#Milestone_tags - To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org For additional commands, e-mail: dev-h...@commons.apache.org
Re: [SCXML][DISCUSS] Towards specification compliance - roadmap and next steps
Thanks for the positive and supportive feedback Matt and Benedikt! I'll now also assume lazy consensus from the others here and start with executing according to my proposal. You can expect some major cleanup and removal of outdated features, including documentation, for SCXML shortly... Regards, Ate On 27-02-14 14:46, Matt Benson wrote: On Feb 27, 2014 4:35 AM, "Ate Douma" wrote: On 27-02-14 11:30, Benedikt Ritter wrote: Hello Ate, without knowing SCXML or the specs here are my thought about your proposals (just from a apache commons point of view ;-): 2014-02-27 0:48 GMT+01:00 Ate Douma : Hi SCXML and other community members/developers, After working on the new Commons SCXML 2.0 code base for a few months, doing some cleaning up and providing minor fixes and improvements, I think we now need some more serious and drastic changes... The goal (as it always has been) for Commons SCXML 2.0 is to reach specification [1] compliance. But after thoroughly reviewing the current implementation, this IMO won't be possible without some major changes. The top 'issues' I've identified are: a) The SCXML model itself: there are several model elements not (properly) supported right now, or in a way incompatible with the current specification, or in a way the specification provides/requires an alternative solution for. b) SCXML datamodel: the (XPath/XML) datamodel currently implemented in Commons SCXML is considerably out-of-sync and incompatible with what the specification requires. Most importantly: the local/nested 'scope' of datamodel definitions (and contexts) in Commons SCXML, while very flexible and great in theory, is in conflict with the current specification requirements. And actually making things *much* more difficult and complicated than what the specification asks for... c) Event processing: the current internal event processing is in violation with the current specification. Like for example all internal events on the queue are processed together (one micro step) while the specification requires these to be processed in sequence. This affects the behavior and semantics of SCXML processing, and as such I consider this as one of the most problematic issues right now. d) A bunch of other specification requirements currently not at all supported or only badly so. Examples are (supposed read-only) system variables, session support, external communications. e) Optional features, like adding ECMAScript+JSON datamodel support, possibly HTTP Event I/O Processor support. All of the above (except e) should be solved and done to reach a reasonable level of compliance with the specification. Which is *a lot* of work :) To give this a reasonable chance of success, I have the following proposal: 1) Accept serious changes in the implementation, including breaking changes (with regard to the outdated 0.9 version). Also: ignore/forget about deprecation support if practically unfeasible or too complicated. Sounds good to me, as long as the requirements for breaking BC are met (changing package names and maven coords) Sure, and already taken care of. When we started on the new SCXML 2.0 trunk, we changed both the package and the maven coordinates accordingly, so we're all set for this. It is nice to try and preserve backward compatibility wherever possible but once packaging, etc. has been changed it is not essential. The other points of your proposal sound similarly reasonable. Matt 2) drop and remove, at least *for now*, support for many/most of the outdated/incomplete 'integration' features, like Apache Shale (which is in the attic) and JSF, Servlet/JSP, Android, Rhino/E4X (ECMAScript for XML, outdated/unsupported spec.). This also includes deleting all the outdated and incomplete/broken documentation around them. We *can* add support back for (some of) these later, after we reached reasonable compliance *and* there is actual interest (and help) for re-implementing and testing them. Makes sense. 3) Start working on the first 4 top 'issues' of the list above, a) to d). Technically I think this most effectively can be done in the following order: c, b, a and then d. And while doing this, the requirements for optional features like e) should be kept in mind as well. go for it! :-) Thanks! But most important are steps 1) and 2), otherwise step 3) will IMO practically impossible to achieve. Any feedback to the above is very welcome. I'd like to start cranking on this ASAP, also with regards to my presentation on Commons SCXML 2.0 at the ApacheCon in Denver coming April [2] :) So I hope I also can assume lazy consensus with little or no feedback ;) The only thing we are crazy about is making sure users won't get into jar hell when using our libs. So we're trying to make sure incompatible classes can never end up in the same class path by
Re: svn commit: r899664 [1/13] - in /websites/production/commons/content/proper/commons-scxml
On 02-03-14 00:02, a...@apache.org wrote: Author: ate Date: Sat Mar 1 23:02:28 2014 New Revision: 899664 Log: Site checkin for project Apache Commons SCXML This turned out to be an unexpected large site checkin ... I only fixed a few menu items, so I expected a minor update. Turned out, the previous site was generated with a "de" language, while I have "en" as default language, and the generated javadocs all get this language encoded in their element. So all apidocs pages where updated like this: - + Now, I can imagine this will hit us many times over in the future if we don't somehow either remove or suppress the lang attribute or else set it to a fixed value... Anyone an idea how to improve this? Thanks, Ate - To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org For additional commands, e-mail: dev-h...@commons.apache.org
Re: [SCXML] Update of website
On 27-02-14 15:53, Benedikt Ritter wrote: Should be working now :-) Yes it does. Thanks! 2014-02-27 14:22 GMT+01:00 Bruno P. Kinoshita : I think [imaging] had similar problem days ago [1] Maybe looking at the commits sent to [imaging] could be of some help. Just my 0.02 cents :) HTH Bruno [1] http://markmail.org/thread/lxdlwp35vdlwousi - Original Message - From: Benedikt Ritter To: Commons Developers List Cc: Sent: Thursday, February 27, 2014 10:05 AM Subject: Re: [SCXML] Update of website 2014-02-27 13:57 GMT+01:00 Benedikt Ritter : 2014-02-27 13:52 GMT+01:00 Ate Douma : On 27-02-14 13:36, Benedikt Ritter wrote: Hi, I've worked on the website today. It uses the new design now. I've fixed some broken links also. If you find anything that's not working, just drop me a message. Wow, many thanks! It looks great and 'refreshed' :) After only a quick check I see the Download link is broken. I can try find out how to fix that myself, but don't really have much time for it until this weekend. I'll take care of it. Well, I get a 403 when accessing http://commons.apache.org/proper/commons-scxml/download_scxml.cgi Not sure if this is a problem of the site deploy. Can anybody help? Benedikt Ate Benedikt - To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org For additional commands, e-mail: dev-h...@commons.apache.org -- http://people.apache.org/~britter/ http://www.systemoutprintln.de/ http://twitter.com/BenediktRitter http://github.com/britter -- http://people.apache.org/~britter/ http://www.systemoutprintln.de/ http://twitter.com/BenediktRitter http://github.com/britter - To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org For additional commands, e-mail: dev-h...@commons.apache.org - To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org For additional commands, e-mail: dev-h...@commons.apache.org
Re: [SCXML] Update of website
On 27-02-14 13:36, Benedikt Ritter wrote: Hi, I've worked on the website today. It uses the new design now. I've fixed some broken links also. If you find anything that's not working, just drop me a message. Wow, many thanks! It looks great and 'refreshed' :) After only a quick check I see the Download link is broken. I can try find out how to fix that myself, but don't really have much time for it until this weekend. Ate Benedikt - To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org For additional commands, e-mail: dev-h...@commons.apache.org
Re: [SCXML][DISCUSS] Towards specification compliance - roadmap and next steps
On 27-02-14 11:30, Benedikt Ritter wrote: Hello Ate, without knowing SCXML or the specs here are my thought about your proposals (just from a apache commons point of view ;-): 2014-02-27 0:48 GMT+01:00 Ate Douma : Hi SCXML and other community members/developers, After working on the new Commons SCXML 2.0 code base for a few months, doing some cleaning up and providing minor fixes and improvements, I think we now need some more serious and drastic changes... The goal (as it always has been) for Commons SCXML 2.0 is to reach specification [1] compliance. But after thoroughly reviewing the current implementation, this IMO won't be possible without some major changes. The top 'issues' I've identified are: a) The SCXML model itself: there are several model elements not (properly) supported right now, or in a way incompatible with the current specification, or in a way the specification provides/requires an alternative solution for. b) SCXML datamodel: the (XPath/XML) datamodel currently implemented in Commons SCXML is considerably out-of-sync and incompatible with what the specification requires. Most importantly: the local/nested 'scope' of datamodel definitions (and contexts) in Commons SCXML, while very flexible and great in theory, is in conflict with the current specification requirements. And actually making things *much* more difficult and complicated than what the specification asks for... c) Event processing: the current internal event processing is in violation with the current specification. Like for example all internal events on the queue are processed together (one micro step) while the specification requires these to be processed in sequence. This affects the behavior and semantics of SCXML processing, and as such I consider this as one of the most problematic issues right now. d) A bunch of other specification requirements currently not at all supported or only badly so. Examples are (supposed read-only) system variables, session support, external communications. e) Optional features, like adding ECMAScript+JSON datamodel support, possibly HTTP Event I/O Processor support. All of the above (except e) should be solved and done to reach a reasonable level of compliance with the specification. Which is *a lot* of work :) To give this a reasonable chance of success, I have the following proposal: 1) Accept serious changes in the implementation, including breaking changes (with regard to the outdated 0.9 version). Also: ignore/forget about deprecation support if practically unfeasible or too complicated. Sounds good to me, as long as the requirements for breaking BC are met (changing package names and maven coords) Sure, and already taken care of. When we started on the new SCXML 2.0 trunk, we changed both the package and the maven coordinates accordingly, so we're all set for this. 2) drop and remove, at least *for now*, support for many/most of the outdated/incomplete 'integration' features, like Apache Shale (which is in the attic) and JSF, Servlet/JSP, Android, Rhino/E4X (ECMAScript for XML, outdated/unsupported spec.). This also includes deleting all the outdated and incomplete/broken documentation around them. We *can* add support back for (some of) these later, after we reached reasonable compliance *and* there is actual interest (and help) for re-implementing and testing them. Makes sense. 3) Start working on the first 4 top 'issues' of the list above, a) to d). Technically I think this most effectively can be done in the following order: c, b, a and then d. And while doing this, the requirements for optional features like e) should be kept in mind as well. go for it! :-) Thanks! But most important are steps 1) and 2), otherwise step 3) will IMO practically impossible to achieve. Any feedback to the above is very welcome. I'd like to start cranking on this ASAP, also with regards to my presentation on Commons SCXML 2.0 at the ApacheCon in Denver coming April [2] :) So I hope I also can assume lazy consensus with little or no feedback ;) The only thing we are crazy about is making sure users won't get into jar hell when using our libs. So we're trying to make sure incompatible classes can never end up in the same class path by changing the package name. Since we already have commons-scxml in maven central [1] we need to change the package name. Yup, see above. Keep up the good work! Benedikt Thanks for the positive feedback. Much appreciated! Ate [1] http://search.maven.org/#artifactdetails%7Ccommons-scxml%7Ccommons-scxml%7C0.9%7Cjar With kind regards, Ate [1] http://www.w3.org/TR/scxml/ [2] http://sched.co/1dlTw2L - To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org For additional commands, e-mail: dev-h...@commons.apache.org
[SCXML][DISCUSS] Towards specification compliance - roadmap and next steps
Hi SCXML and other community members/developers, After working on the new Commons SCXML 2.0 code base for a few months, doing some cleaning up and providing minor fixes and improvements, I think we now need some more serious and drastic changes... The goal (as it always has been) for Commons SCXML 2.0 is to reach specification [1] compliance. But after thoroughly reviewing the current implementation, this IMO won't be possible without some major changes. The top 'issues' I've identified are: a) The SCXML model itself: there are several model elements not (properly) supported right now, or in a way incompatible with the current specification, or in a way the specification provides/requires an alternative solution for. b) SCXML datamodel: the (XPath/XML) datamodel currently implemented in Commons SCXML is considerably out-of-sync and incompatible with what the specification requires. Most importantly: the local/nested 'scope' of datamodel definitions (and contexts) in Commons SCXML, while very flexible and great in theory, is in conflict with the current specification requirements. And actually making things *much* more difficult and complicated than what the specification asks for... c) Event processing: the current internal event processing is in violation with the current specification. Like for example all internal events on the queue are processed together (one micro step) while the specification requires these to be processed in sequence. This affects the behavior and semantics of SCXML processing, and as such I consider this as one of the most problematic issues right now. d) A bunch of other specification requirements currently not at all supported or only badly so. Examples are (supposed read-only) system variables, session support, external communications. e) Optional features, like adding ECMAScript+JSON datamodel support, possibly HTTP Event I/O Processor support. All of the above (except e) should be solved and done to reach a reasonable level of compliance with the specification. Which is *a lot* of work :) To give this a reasonable chance of success, I have the following proposal: 1) Accept serious changes in the implementation, including breaking changes (with regard to the outdated 0.9 version). Also: ignore/forget about deprecation support if practically unfeasible or too complicated. 2) drop and remove, at least *for now*, support for many/most of the outdated/incomplete 'integration' features, like Apache Shale (which is in the attic) and JSF, Servlet/JSP, Android, Rhino/E4X (ECMAScript for XML, outdated/unsupported spec.). This also includes deleting all the outdated and incomplete/broken documentation around them. We *can* add support back for (some of) these later, after we reached reasonable compliance *and* there is actual interest (and help) for re-implementing and testing them. 3) Start working on the first 4 top 'issues' of the list above, a) to d). Technically I think this most effectively can be done in the following order: c, b, a and then d. And while doing this, the requirements for optional features like e) should be kept in mind as well. But most important are steps 1) and 2), otherwise step 3) will IMO practically impossible to achieve. Any feedback to the above is very welcome. I'd like to start cranking on this ASAP, also with regards to my presentation on Commons SCXML 2.0 at the ApacheCon in Denver coming April [2] :) So I hope I also can assume lazy consensus with little or no feedback ;) With kind regards, Ate [1] http://www.w3.org/TR/scxml/ [2] http://sched.co/1dlTw2L - To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org For additional commands, e-mail: dev-h...@commons.apache.org
Re: [ANNOUNCE] Welcome Duncan Jones, committer
On 01/24/2014 04:20 PM, Gary Gregory wrote: Hi All, Please give a warm welcome to Duncan Jones, our latest committer. Welcome aboard Duncan! Welcome Duncan! Regards, Ate Gary - To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org For additional commands, e-mail: dev-h...@commons.apache.org
Fwd: [jira] [Created] (SCXML-188) OpenJDK 1.6 Rhino ScriptEngine error causes JSEvaluationTest to fail
We turn out to have an issue with running SCXML on OpenJDK 1.6 when using the Mozilla Rhino script engine. IMO we cannot 'fix' the OpenJDK bug, and I'm inclined to simply state that using SCXML on OpenJDK isn't support, *if* using the Rhine script engine. But the annoying fact is that Continuum is building the project against OpenJDK 1.6, causing it to fail continuously :( Has anyone an idea how we should 'solve' this with respect to maybe conditional testing? Otherwise maybe we should disable building SCXML on Continuum with OpenJDK 1.6. Thanks, Ate p.s: I've no idea who manages the Continuum build configurations for Commons. Original Message Subject: [jira] [Created] (SCXML-188) OpenJDK 1.6 Rhino ScriptEngine error causes JSEvaluationTest to fail Date: Mon, 20 Jan 2014 16:04:22 + (UTC) From: Ate Douma (JIRA) Reply-To: iss...@commons.apache.org To: iss...@commons.apache.org Ate Douma created SCXML-188: --- Summary: OpenJDK 1.6 Rhino ScriptEngine error causes JSEvaluationTest to fail Key: SCXML-188 URL: https://issues.apache.org/jira/browse/SCXML-188 Project: Commons SCXML Issue Type: Bug Affects Versions: 2.0 Environment: continuum-ci.apache.org, OpenJDK 1.6.2 (6b27-1.12.6-1ubuntu0.12.04, amd64) Reporter: Ate Douma On OpenJDK 1.7 and Sun/Oracle java 6 and 7 the following JS expression "1 + 1 + 2 + 3 + 5" returns a Double value (12.0) On OpenJDK 1.6 the returned value is an Integer (12), causing the JSEvaluatorTest to fail. Seems like the OpenJDK Mozilla Rhino implementation/embedding is broken, and until a newer version of OpenJDK 1.6 comes out which fixes this (unlikely any time soon?) we might want to exclude support for OpenJDK 1.6 when using the Rhino Javscript ScriptEngine. The question is though: (how) can we handle this conditionally in the test? -- This message was sent by Atlassian JIRA (v6.1.5#6160) - To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org For additional commands, e-mail: dev-h...@commons.apache.org
Re: [SCXML] Deprecated 'src' attributes in state, parallel and assign
On 12/05/2013 11:26 PM, Woonsan Ko wrote: Hi, The current code is taking care of 'src' attribute for state, parallel, assign and invoke element. Invoke element should still accept 'src' attribute, but it seems to have been removed for the other elements in the current specification. The src atttribute for state and parallel was removed from the specification several years ago, May 2010, with the suggestion to use the xinclude standard instead. See: http://www.w3.org/TR/2010/WD-scxml-20100513/#files Do we need to deprecate (and remove later) the current behavior for those elements except of invoke element? Or is there still any good reason to keep the feature for some reason (e.g, overriding something from the 'src' for state/parallel element as a commons-scxml feature) ? Deprecate seems the reasonable thing to do as the xinclude solution is said to provide a superior version of the same functionality. But that should be validated and properly tested first before dropping the current implementation. But that shouldn't happen anyway until the next major release for SCXML, after the 2.0 release. Side note: the and
Re: [SCXML] What's the SCXML spec draft(s) supported in the current commons-scxml?
Woonsan, Bernd, To be able to edit the wiki, you'll need to provide your Wiki username. A Wiki username should be a *wiki* name, e.g. 'Woonsan Ko' AFAIK isn't a qualified one, but something like WoonsanKo would. Then, someone with the right permissions (someone on the AdminGroup) can add you to the wiki ContributorsGroup (which I cannot). Ate On 11/15/2013 09:53 PM, Woonsan Ko wrote: Hi Bernd, I think I can correct it and the other outdated information in the page. Could you give me proper access to edit? My wiki name is 'Woonsan Ko'. Cheers, Woonsan On Friday, November 15, 2013 3:08 PM, Bernd Eckenfels wrote: The "Stopwatch" usecase link on that wiki page is broken. Can somebody please remove the /sandbox/ part? (And I would be happy if somebody tells me what can I do to get some more permissions in the Wiki) Gruss Bernd Am 15.11.2013, 20:58 Uhr, schrieb Woonsan Ko : [1] http://wiki.apache.org/commons/SCXML/FrequentlyAskedQuestions - To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org For additional commands, e-mail: dev-h...@commons.apache.org - To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org For additional commands, e-mail: dev-h...@commons.apache.org
Re: svn commit: r1534254 - /commons/proper/scxml/trunk/pom.xml
Sebb, Was the bump to commons-el 1.0.1-SNAPSHOT intentional, and if so can you explain why? In general I prefer not depending on external SNAPSHOT dependencies if not absolutely needed. And in this case it actually caused the tests to fail. For now I've reverted back to commons-el 1.0. Regards, Ate On 10/21/2013 06:00 PM, s...@apache.org wrote: Author: sebb Date: Mon Oct 21 16:00:20 2013 New Revision: 1534254 URL: http://svn.apache.org/r1534254 Log: ASF Branding Modified: commons/proper/scxml/trunk/pom.xml Modified: commons/proper/scxml/trunk/pom.xml URL: http://svn.apache.org/viewvc/commons/proper/scxml/trunk/pom.xml?rev=1534254&r1=1534253&r2=1534254&view=diff == --- commons/proper/scxml/trunk/pom.xml (original) +++ commons/proper/scxml/trunk/pom.xml Mon Oct 21 16:00:20 2013 @@ -24,7 +24,7 @@ 4.0.0 - Commons SCXML + Apache Commons SCXML commons-scxml2 2.0-SNAPSHOT @@ -151,7 +151,7 @@ commons-el commons-el - 1.0 + 1.0.1-SNAPSHOT provided true - To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org For additional commands, e-mail: dev-h...@commons.apache.org
Re: [Commons Wiki] Update of "ContributorsGroup" by JörgSchaible
On 10/16/2013 09:36 AM, Jörg Schaible wrote: Hi Ate, Ate Douma wrote: On 10/16/2013 08:54 AM, Jörg Schaible wrote: It seems it is unnecessary for committers to be added here, otherwise I would not have been able to add myself. I don't think so. AFAIK the moinmoin security is not wired into the ASF LDAP security system, except maybe for (root) admins. The moinmoin security is also wiki specific, only managed/configured through the ContributorsGroup and AdminGroup pages. So if you could do this yourself already, my guess is you already are on the AdminGroup (which for instance I'm not allowed to view). Neither am I ... Oh, then something strange is going on with the wiki security. While I already was given commit karma for Commons, I still could not edit this (or any) page, until Sebb added my account name. - Jörg - To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org For additional commands, e-mail: dev-h...@commons.apache.org - To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org For additional commands, e-mail: dev-h...@commons.apache.org
Re: [Commons Wiki] Update of "ContributorsGroup" by JörgSchaible
On 10/16/2013 08:54 AM, Jörg Schaible wrote: It seems it is unnecessary for committers to be added here, otherwise I would not have been able to add myself. I don't think so. AFAIK the moinmoin security is not wired into the ASF LDAP security system, except maybe for (root) admins. The moinmoin security is also wiki specific, only managed/configured through the ContributorsGroup and AdminGroup pages. So if you could do this yourself already, my guess is you already are on the AdminGroup (which for instance I'm not allowed to view). Apache Wiki wrote: Dear Wiki user, You have subscribed to a wiki page or wiki category on "Commons Wiki" for change notification. The "ContributorsGroup" page has been changed by JörgSchaible: https://wiki.apache.org/commons/ContributorsGroup?action=diff&rev1=5&rev2=6 Comment: Added myself * DennisLundberg * EmmanuelBourg * GillesSadowski + * JörgSchaible * KonstantinKolinko * MattBenson * NiallPemberton - To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org For additional commands, e-mail: dev-h...@commons.apache.org - To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org For additional commands, e-mail: dev-h...@commons.apache.org
Re: [CHALLENGE] Move All of Commons to the Dormant
On 10/15/2013 10:31 AM, Torsten Curdt wrote: I monitor commits, rarely check JIRA, follow and sometimes answer mails and close to never develop code for that component anymore - maybe once or twice a year when I go through JIRAs. Now what? I appreciate the initiative but don't see this working too well for me. If this was all just one repo and dormant was just a "not actively developed" flag this would be a little easier. While Henri suggested in his initial email that non-active components should be 'moved' to Attic/Dormant, he already indicated later that no decision or even conclusion should be drawn yet. Lets first build up some data on the current status, which I think is a very sensible thing to do (regularly even). If and how 'dormant' components should be flagged IMO should be a separate discussion once we have clearer view which components would fall in such category. I myself would agree to just 'flag' such components, recorded in some status file somewhere and probably should (automatically?) get a warning banner up on their site so the *end users* are aware of this status. Moving a component in svn under /dormant (if its not there already) seems to me a change not really needed to get the point across. Again: the primary target here IMO are the *end users*, not temporarily MIA developers. And moving a component into the the Attic is something completely different all together. Maybe feasible as well for some 'forever dormant' components, but not to be decided lightly for sure. Even better if there was a script that regularly checks different conditions and updates the flag on the website accordingly. That would work for me as well. Not sure though how easy such script can be made, which criteria to check and how to quantify them (svn, release tags, JIRA, mailing lists, etc.) Ate cheers, Torsten - To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org For additional commands, e-mail: dev-h...@commons.apache.org
[SCXML] Proposal - drop Ant build support
Hi SCXML community, I'd like to propose dropping Ant build support for the next major SCXML version 1.0, which development now has been reactivated on trunk. Both Woonsan and myself are 'Maven' adepts, and have no use nor interest in maintaining and updating/fixing the already outdated Ant build configuration. If someone in the community prefers us to keep and maintain the Ant build, then please chime in and provide some help (patches) to update and maintain the Ant build configuration. Unless someone chimes in, I'm going to assume lazy consensus on this proposal, and drop the Ant build support by the end of this week. And of course, we can always restore the Ant build support, if so requested. Thanks, Ate - To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org For additional commands, e-mail: dev-h...@commons.apache.org
Re: [JIRA] Request to be given Commons committer karma in JIRA
On 10/14/2013 09:33 PM, Mark Thomas wrote: On 14/10/2013 20:27, Ate Douma wrote: On 10/14/2013 09:23 PM, Ate Douma wrote: Hi Commons team, Can someone grant me, and likewise for Woonsan, committer karma in JIRA for at least Commons SCXML so we can start picking up and assigning issues? Forgot to mention my ASF JIRA handle is: adouma and for Woonsan: woon_san Done. Thanks! I just created and assigned myself issue SCXML-169, so it works :) Ate Mark - To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org For additional commands, e-mail: dev-h...@commons.apache.org - To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org For additional commands, e-mail: dev-h...@commons.apache.org
Re: [JIRA] Request to be given Commons committer karma in JIRA
On 10/14/2013 09:23 PM, Ate Douma wrote: Hi Commons team, Can someone grant me, and likewise for Woonsan, committer karma in JIRA for at least Commons SCXML so we can start picking up and assigning issues? Forgot to mention my ASF JIRA handle is: adouma and for Woonsan: woon_san Thanks, Ate - To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org For additional commands, e-mail: dev-h...@commons.apache.org
[JIRA] Request to be given Commons committer karma in JIRA
Hi Commons team, Can someone grant me, and likewise for Woonsan, committer karma in JIRA for at least Commons SCXML so we can start picking up and assigning issues? Thanks, Ate - To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org For additional commands, e-mail: dev-h...@commons.apache.org
[WIKI] Request to be added to the wiki Contributors Group
Can someone add my wiki name (AteDouma) to the Contributors Group page [1]? Thanks, Ate [1] https://wiki.apache.org/commons/ContributorsGroup - To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org For additional commands, e-mail: dev-h...@commons.apache.org
Re: New committers: Ate Douma and Woonsan Ko
Thank you all for the trust and the warm welcome! Regards, Ate On 10/14/2013 07:51 PM, Luc Maisonobe wrote: Hi all, Please welcome Ate Douma and Woonsan Ko as a new committers of the Apache Commons project. The Commons PMC has voted to grant committership to them and they accepted. Both accounts have already been set up and they can begin working on the Commons components. Ate and Woonsan, welcome to the team ! Luc Maisonobe, on behalf of Apache Commons PMC - To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org For additional commands, e-mail: dev-h...@commons.apache.org - To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org For additional commands, e-mail: dev-h...@commons.apache.org
Re: [SCXML] Next major version number required package rename needed?
On 10/11/2013 02:54 AM, James Carman wrote: It wouldn't look so funky that way. I'm cool with that. I'm leaning to this solution as well, going for scxml2 with version 2.0(-xx). While this would 'skip' the 1.0 range, I think not only doesn't it look so funky (scxml1) but also better indicate align with the current versioning rules which state that a first version should start with 1.0 to begin with. SCXML clearly was started long before this became practice, hence its current 0.x range. But as we're about to 'restart' the component, using version 2.0 probably is a beter indication of this 'second major version' for SCXML. If nobody further objects to this, I'll assume lazy consensus on this. Thank you all for the feedback, Ate On Thursday, October 10, 2013, Niall Pemberton wrote: I would bump to version 2.0 because I dont think its clear that going from 0.9 to 1.0 is a major version change - in my mind 0.9 seems to imply "we haven't quite completed everything we want to for 1.0" Niall On Fri, Oct 11, 2013 at 12:52 AM, James Carman >wrote: Now, this case is a bit weird, since we have released code in a < 1.0 version number. So, the artifact/package will have to be scxml1, which looks funky IMHO. I guess that follows the pattern, though. On Thu, Oct 10, 2013 at 7:49 PM, Ate Douma wrote: On 10/11/2013 01:41 AM, James Carman wrote: If you are breaking backward compatibility then you need to do the renames (package, and artifactId). That was my impression already. And I have no real issue with doing so. But again, when has this been decided and has it ever been formalized (written down) somewhere? I don't know if we ever landed on a "rule" about the new JDK level scenario, though. Okay, maybe that was just an incorrect assumption. And it doesn't really matter as there will be breaking API changes needed for the next version of SCXML, so we'll have to bump the major version anyway. On Thursday, October 10, 2013, Ate Douma wrote: On 10/11/2013 01:16 AM, Emmanuel Bourg wrote: Commons SCXML has only one reverse dependency in Maven Central, flexistate, so I wouldn't bother with the binary compatibility and just keep the package as is. Hmm. That might be the only reverse dependency of artifacts also deployed to Maven Central, but I'm pretty sure SCXML 0.9 is used in plenty of projects which might be impacted still. I would expect stronger arguments to decide yes/no if a package rename is required or not. This would seem a bit (too) arbitrary to me. Mind you, I'd prefer not having to do a package rename, but I got the impression there are more explicit 'rules' when to do so. So I'd still would like to hear more explicitly if such a rule is defined, and if so how it is worded and where. But of course if there is none, fine by me :) Thanks, Ate http://mvnrepository.com/**artifact/commons-scxml/**commons-scxml/0.9 <http://mvnrepository.com/artifact/commons-scxml/commons-scxml/0.9> Emmanuel Bourg --**--**- To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org For additional commands, e-mail: dev-h...@commons.apache.org --**--**- To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org For additional commands, e-mail: dev-h...@commons.apache.org - To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org For additional commands, e- - To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org For additional commands, e-mail: dev-h...@commons.apache.org
Re: [DISCUSS] Allow unstable 0.x OR -Milestone releases [Was: [DISCUSS] Putting several unmaintained components to dormant]
On 10/10/2013 03:31 PM, James Carman wrote: We definitely need to make sure our naming scheme will work with maven properly. Hopefully commons-foo:1.0 would supercede commons-foo:1.0-M1. Again, I really don't care what we call it, as long as we manage expectations and don't dork up maven. Since Maven 3+ there is now a reasonable and predictable handling of such versioning, including doing 'the right thing' for the commons-foo:1.0-M1 example. See [1] (which is an old wiki proposal which since has been implemented) and [2] for the exact rules, which I'm copying below for convenience. From [2]: Features: - mixing of '-' (dash) and '.' (dot) separators, - transition between characters and digits also constitutes a separator: 1.0alpha1 => [1, 0, alpha, 1] - unlimited number of version components, - version components in the text can be digits or strings, - strings are checked for well-known qualifiers and the qualifier ordering is used for version ordering. Well-known qualifiers (case insensitive) are: - snapshot - alpha or a - beta or b - milestone or m - rc or cr - (the empty string) or ga or final - sp Unknown qualifiers are considered after known qualifiers, with lexical order (always case insensitive), - a dash usually precedes a qualifier, and is always less important than something preceded with a dot. [1] https://cwiki.apache.org/confluence/display/MAVENOLD/Versioning [2] http://maven.apache.org/ref/3.0.4/maven-artifact/apidocs/org/apache/maven/artifact/versioning/ComparableVersion.html On Thu, Oct 10, 2013 at 9:25 AM, Ate Douma wrote: On 10/10/2013 03:00 PM, James Carman wrote: On Thu, Oct 10, 2013 at 8:35 AM, Gary Gregory wrote: I think "milestone" releases works if you have a clear development plan and schedule. I've never seen it be the case in Commons. Calling "releases" to Maven and dist, Alphas and Betas make more sense for us IMO. I don't care what we call it. They key is that we set up the expectation with our users. If you use this release, do NOT use it in production code. It is not "supported", meaning we aren't going to fix bugs in that alpha version if we have already released its subsequent full release version (or a subsequent alpha). Indeed and agreed. I also don't care if its called milestone or alpha or whatever. But we already have explicit wording for milestone releases [1], also clearly stating such releases are not supported. So I'm actually only asking *confirmation* to use already established rules. [1] http://commons.apache.org/releases/versioning.html#Milestone_Releases - To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org For additional commands, e-mail: dev-h...@commons.apache.org - To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org For additional commands, e-mail: dev-h...@commons.apache.org - To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org For additional commands, e-mail: dev-h...@commons.apache.org - To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org For additional commands, e-mail: dev-h...@commons.apache.org
Re: [SCXML] Next major version number required package rename needed?
On 10/11/2013 01:41 AM, James Carman wrote: If you are breaking backward compatibility then you need to do the renames (package, and artifactId). That was my impression already. And I have no real issue with doing so. But again, when has this been decided and has it ever been formalized (written down) somewhere? I don't know if we ever landed on a "rule" about the new JDK level scenario, though. Okay, maybe that was just an incorrect assumption. And it doesn't really matter as there will be breaking API changes needed for the next version of SCXML, so we'll have to bump the major version anyway. On Thursday, October 10, 2013, Ate Douma wrote: On 10/11/2013 01:16 AM, Emmanuel Bourg wrote: Commons SCXML has only one reverse dependency in Maven Central, flexistate, so I wouldn't bother with the binary compatibility and just keep the package as is. Hmm. That might be the only reverse dependency of artifacts also deployed to Maven Central, but I'm pretty sure SCXML 0.9 is used in plenty of projects which might be impacted still. I would expect stronger arguments to decide yes/no if a package rename is required or not. This would seem a bit (too) arbitrary to me. Mind you, I'd prefer not having to do a package rename, but I got the impression there are more explicit 'rules' when to do so. So I'd still would like to hear more explicitly if such a rule is defined, and if so how it is worded and where. But of course if there is none, fine by me :) Thanks, Ate http://mvnrepository.com/**artifact/commons-scxml/**commons-scxml/0.9<http://mvnrepository.com/artifact/commons-scxml/commons-scxml/0.9> Emmanuel Bourg --**--**- To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org For additional commands, e-mail: dev-h...@commons.apache.org --**--**- To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org For additional commands, e-mail: dev-h...@commons.apache.org - To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org For additional commands, e-mail: dev-h...@commons.apache.org
Re: [SCXML] Next major version number required package rename needed?
On 10/11/2013 01:16 AM, Emmanuel Bourg wrote: Commons SCXML has only one reverse dependency in Maven Central, flexistate, so I wouldn't bother with the binary compatibility and just keep the package as is. Hmm. That might be the only reverse dependency of artifacts also deployed to Maven Central, but I'm pretty sure SCXML 0.9 is used in plenty of projects which might be impacted still. I would expect stronger arguments to decide yes/no if a package rename is required or not. This would seem a bit (too) arbitrary to me. Mind you, I'd prefer not having to do a package rename, but I got the impression there are more explicit 'rules' when to do so. So I'd still would like to hear more explicitly if such a rule is defined, and if so how it is worded and where. But of course if there is none, fine by me :) Thanks, Ate http://mvnrepository.com/artifact/commons-scxml/commons-scxml/0.9 Emmanuel Bourg - To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org For additional commands, e-mail: dev-h...@commons.apache.org - To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org For additional commands, e-mail: dev-h...@commons.apache.org
[SCXML] Next major version number required package rename needed?
On 10/10/2013 09:39 PM, Rahul Akolkar wrote: On Thu, Oct 10, 2013 at 7:26 AM, Ate Douma wrote: Case in point: SCXML If we are allowed to start working on this component shortly, we intend to, and HAVE to switch to a 1.0 version first, as there already is a 0.9 version release out, while we will need to move to newer JDK and incompatible API changes anyway. At the same time, getting a final/stabalized 1.0 release out most certainly will take several iterations. Release version comparisons being what the are, we could go to v0.10, as in below (greater than sign implies more recent release version): 0.11 > 0.10 > 0.9 For the intended promotion of the SCXML J6 branch to trunk, I don't think that would align with the Commons versioning scheme. The SCXML J6 branch (which currently already uses version 1.0-SNAPSHOT) imposes API breaking changes from the 0.9 release, as well as targets a newer JDK (1.6+). AFAIK this will require a major version bump, hence should target version 1.0. I thus intend to roll out a first intermediate release of this new trunk as version 1.0-alpha-1 (as discussed earlier today in a separate thread). What however is still unclear to me is if this also requires a package rename, e.g. move from org.apache.commons.scxml.* -> org.apache.commons.scxml1.* ? I got the impression from other discussions as well as from looking at other components recent major versions, that this now also is a rule or policy within Commons. But I can't find any specific writing about such 'policy'. At least the online Versioning document doesn't say anything about it, or I must be blindly overlooking it. So my question is: is such package rename now a required rule, or more of a convention? And if this was established as a formal requirement, can someone point me out the documentation (or maybe VOTE thread) for it? Thanks, Ate Not very different than, say the following, which may appear more intuitive for release versions (agree 0.x line is trickier): 2.11 > 2.10 > 2.9 Overall, I think it's OK to go the 0.10 route, if you want to save a 1.0 major release for later at a point it's really needed. In hindsight, the first Commons SCXML release could've been 0.1 (rather than 0.5) to give more room for 4 more releases before getting to this point :-) -Rahul - To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org For additional commands, e-mail: dev-h...@commons.apache.org
Re: [DISCUSS] Allow unstable 0.x OR -Milestone releases
On 10/10/2013 04:31 PM, James Carman wrote: On Thu, Oct 10, 2013 at 10:19 AM, Ate Douma wrote: I'm a bit unfamiliar yet with the 'rules' within Commons concerning such changes. I'm willing to create an issue for this and draft up a documentation patch for it, but maybe this needs formal voting by the PMC first? I'd suggest a vote. This way we have documentation that a decision was made to move in this direction and we don't have to re-hash the discussion every time someone wants to do an alpha release or break BC between alpha releases. We should probably vote before establishing such "policy" changes. This doesn't mean components *have* to do alphas if they don't want, but we're merely establishing that it's an acceptable practice within Commons to do so and more importantly to establish the expectations when the situation arises. Great! If OK, I'm willing to draft up a proposal for such a VOTE, with text ready to be incorporated in the Versioning documentation once accepted. Ate Hopefully once we get our release process streamlined we can do these releases much more frequently and get our cool code in our users' hands quickly! Great discussions, folks. I'm glad to see us thinking like this. - To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org For additional commands, e-mail: dev-h...@commons.apache.org - To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org For additional commands, e-mail: dev-h...@commons.apache.org
Re: [DISCUSS] Allow unstable 0.x OR -Milestone releases
On 10/10/2013 04:13 PM, James Carman wrote: Well, alphas still shouldn't break backward compatibility with a prior *full* release within a major version number. If they do, then it's a bug we need to address it. So, it's not really "anything goes." At least, that's how I'd think about it. Any new APIs are considered "volatile" and subject to change before the next full release. Yes, that is a good refinement. "Anything goes" indeed isn't needed nor asked for. So... as we seem to get to an understanding here with respect to the meaning and usage of 'alpha' releases, how about adding this to the Versioning documentation? Currently there is wording for milestones, but not yet alpha releases. I'm a bit unfamiliar yet with the 'rules' within Commons concerning such changes. I'm willing to create an issue for this and draft up a documentation patch for it, but maybe this needs formal voting by the PMC first? Thanks, Ate On Thu, Oct 10, 2013 at 10:06 AM, Gary Gregory wrote: On Thu, Oct 10, 2013 at 9:55 AM, Ate Douma wrote: On 10/10/2013 03:47 PM, Gary Gregory wrote: On Thu, Oct 10, 2013 at 9:06 AM, James Carman wrote: On Thu, Oct 10, 2013 at 8:25 AM, Emmanuel Bourg wrote: I'm afraid this is more than a perceived issue, the plexus-container example given by Jörg is a very good one. Pushing drastically incompatible versions to Maven Central is not a good service for the users. I think my suggestion is a good compromise, otherwise the die-hard compatibility defenders here will never agree to publish incompatible artifacts to Maven Central. This gets back to my earlier comments on another thread. We can't try to stupid-proof our code. If our users want to do something stupid, we can't protect them from themselves. If they want to "release" code which points to milestone/alpha/rc/SNAPSHOT/whatever, then that's on them. I agree this is annoying, but this has to be balanced with the annoyance of dealing with incompatible dependencies (for example, components depending on different versions of BouncyCastle). It's easy to rename an import in your code compared to fixing a jar hell situation. If a third-party library releases a version which points at one of our alpha releases and relies upon an API that they've been told may not be stable, then they need to fix it. Again, we can boil the ocean trying to think up all the stupid things people can do with our software and try to code/process around it, but at the end of the day, you can't fix stupid. Indeed, developers and users will forever find creative and painful ways to shoot themselves in the foot and other appendages. Conversely, we should not hand out defective weaponry by breaking Binary Compatibility (this relates to a discussion on another thread: I claim it is never OK to break BC, you release a new (Java) package to do the equivalent). I state that an alpha release (which I gather you prefer above calling it milestones), by definition, cannot have a 'Compatibility' claim to begin with, hence cannot break one either. So, are you OK with alpha releases, which do NOT claim any stability nor compatibility? Yes, an alpha is an anything goes release. Whether or not it is in a special package is a different story :) Gary Gary - To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org For additional commands, e-mail: dev-h...@commons.apache.org - To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org For additional commands, e-mail: dev-h...@commons.apache.org -- E-Mail: garydgreg...@gmail.com | ggreg...@apache.org Java Persistence with Hibernate, Second Edition JUnit in Action, Second Edition Spring Batch in Action Blog: http://garygregory.wordpress.com Home: http://garygregory.com/ Tweet! http://twitter.com/GaryGregory - To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org For additional commands, e-mail: dev-h...@commons.apache.org - To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org For additional commands, e-mail: dev-h...@commons.apache.org - To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org For additional commands, e-mail: dev-h...@commons.apache.org
Re: [DISCUSS] Allow unstable 0.x OR -Milestone releases
On 10/10/2013 04:06 PM, Gary Gregory wrote: On Thu, Oct 10, 2013 at 9:55 AM, Ate Douma wrote: On 10/10/2013 03:47 PM, Gary Gregory wrote: On Thu, Oct 10, 2013 at 9:06 AM, James Carman wrote: On Thu, Oct 10, 2013 at 8:25 AM, Emmanuel Bourg wrote: I'm afraid this is more than a perceived issue, the plexus-container example given by Jörg is a very good one. Pushing drastically incompatible versions to Maven Central is not a good service for the users. I think my suggestion is a good compromise, otherwise the die-hard compatibility defenders here will never agree to publish incompatible artifacts to Maven Central. This gets back to my earlier comments on another thread. We can't try to stupid-proof our code. If our users want to do something stupid, we can't protect them from themselves. If they want to "release" code which points to milestone/alpha/rc/SNAPSHOT/whatever, then that's on them. I agree this is annoying, but this has to be balanced with the annoyance of dealing with incompatible dependencies (for example, components depending on different versions of BouncyCastle). It's easy to rename an import in your code compared to fixing a jar hell situation. If a third-party library releases a version which points at one of our alpha releases and relies upon an API that they've been told may not be stable, then they need to fix it. Again, we can boil the ocean trying to think up all the stupid things people can do with our software and try to code/process around it, but at the end of the day, you can't fix stupid. Indeed, developers and users will forever find creative and painful ways to shoot themselves in the foot and other appendages. Conversely, we should not hand out defective weaponry by breaking Binary Compatibility (this relates to a discussion on another thread: I claim it is never OK to break BC, you release a new (Java) package to do the equivalent). I state that an alpha release (which I gather you prefer above calling it milestones), by definition, cannot have a 'Compatibility' claim to begin with, hence cannot break one either. So, are you OK with alpha releases, which do NOT claim any stability nor compatibility? Yes, an alpha is an anything goes release. Thanks, that's all I needed to hear :) Whether or not it is in a special package is a different story :) But because it is an 'anything goes release', it doesn't really matter, is up to the developer(s), and at any rate CANNOT be a restriction on a release. Ate Gary Gary - To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org For additional commands, e-mail: dev-h...@commons.apache.org - To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org For additional commands, e-mail: dev-h...@commons.apache.org - To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org For additional commands, e-mail: dev-h...@commons.apache.org
Re: [DISCUSS] Allow unstable 0.x OR -Milestone releases
On 10/10/2013 03:47 PM, Gary Gregory wrote: On Thu, Oct 10, 2013 at 9:06 AM, James Carman wrote: On Thu, Oct 10, 2013 at 8:25 AM, Emmanuel Bourg wrote: I'm afraid this is more than a perceived issue, the plexus-container example given by Jörg is a very good one. Pushing drastically incompatible versions to Maven Central is not a good service for the users. I think my suggestion is a good compromise, otherwise the die-hard compatibility defenders here will never agree to publish incompatible artifacts to Maven Central. This gets back to my earlier comments on another thread. We can't try to stupid-proof our code. If our users want to do something stupid, we can't protect them from themselves. If they want to "release" code which points to milestone/alpha/rc/SNAPSHOT/whatever, then that's on them. I agree this is annoying, but this has to be balanced with the annoyance of dealing with incompatible dependencies (for example, components depending on different versions of BouncyCastle). It's easy to rename an import in your code compared to fixing a jar hell situation. If a third-party library releases a version which points at one of our alpha releases and relies upon an API that they've been told may not be stable, then they need to fix it. Again, we can boil the ocean trying to think up all the stupid things people can do with our software and try to code/process around it, but at the end of the day, you can't fix stupid. Indeed, developers and users will forever find creative and painful ways to shoot themselves in the foot and other appendages. Conversely, we should not hand out defective weaponry by breaking Binary Compatibility (this relates to a discussion on another thread: I claim it is never OK to break BC, you release a new (Java) package to do the equivalent). I state that an alpha release (which I gather you prefer above calling it milestones), by definition, cannot have a 'Compatibility' claim to begin with, hence cannot break one either. So, are you OK with alpha releases, which do NOT claim any stability nor compatibility? Gary - To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org For additional commands, e-mail: dev-h...@commons.apache.org - To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org For additional commands, e-mail: dev-h...@commons.apache.org
Re: [DISCUSS] Allow unstable 0.x OR -Milestone releases [Was: [DISCUSS] Putting several unmaintained components to dormant]
On 10/10/2013 03:00 PM, James Carman wrote: On Thu, Oct 10, 2013 at 8:35 AM, Gary Gregory wrote: I think "milestone" releases works if you have a clear development plan and schedule. I've never seen it be the case in Commons. Calling "releases" to Maven and dist, Alphas and Betas make more sense for us IMO. I don't care what we call it. They key is that we set up the expectation with our users. If you use this release, do NOT use it in production code. It is not "supported", meaning we aren't going to fix bugs in that alpha version if we have already released its subsequent full release version (or a subsequent alpha). Indeed and agreed. I also don't care if its called milestone or alpha or whatever. But we already have explicit wording for milestone releases [1], also clearly stating such releases are not supported. So I'm actually only asking *confirmation* to use already established rules. [1] http://commons.apache.org/releases/versioning.html#Milestone_Releases - To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org For additional commands, e-mail: dev-h...@commons.apache.org - To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org For additional commands, e-mail: dev-h...@commons.apache.org
Re: [DISCUSS] Allow unstable 0.x OR -Milestone releases
On 10/10/2013 03:06 PM, James Carman wrote: On Thu, Oct 10, 2013 at 8:25 AM, Emmanuel Bourg wrote: I'm afraid this is more than a perceived issue, the plexus-container example given by Jörg is a very good one. Pushing drastically incompatible versions to Maven Central is not a good service for the users. I think my suggestion is a good compromise, otherwise the die-hard compatibility defenders here will never agree to publish incompatible artifacts to Maven Central. This gets back to my earlier comments on another thread. We can't try to stupid-proof our code. If our users want to do something stupid, we can't protect them from themselves. If they want to "release" code which points to milestone/alpha/rc/SNAPSHOT/whatever, then that's on them. I agree this is annoying, but this has to be balanced with the annoyance of dealing with incompatible dependencies (for example, components depending on different versions of BouncyCastle). It's easy to rename an import in your code compared to fixing a jar hell situation. If a third-party library releases a version which points at one of our alpha releases and relies upon an API that they've been told may not be stable, then they need to fix it. Again, we can boil the ocean trying to think up all the stupid things people can do with our software and try to code/process around it, but at the end of the day, you can't fix stupid. Amen to that - To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org For additional commands, e-mail: dev-h...@commons.apache.org - To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org For additional commands, e-mail: dev-h...@commons.apache.org
Re: [DISCUSS] Allow unstable 0.x OR -Milestone releases
On 10/10/2013 01:36 PM, Emmanuel Bourg wrote: Le 10/10/2013 13:26, Ate Douma a écrit : Thoughts? A solution could be to change the package for every preview release. Something like: org.apache.commons.experimental. So, for CSV we could release a 0.8 and 0.9 version under the packages: org.apache.commons.experimental.csv8 org.apache.commons.experimental.csv9 The package translation could probably be automated by the shade plugin, such that we keep developing with the org.apache.commons.csv package. While doing this might be somewhat automated, sure, I still would not favor this. I think it tries to solve more of a perceived than an actual problem. And it is not convenient for the experimental end-users either, because they most definitely will HAVE to modify their code (manually). Emmanuel Bourg - To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org For additional commands, e-mail: dev-h...@commons.apache.org - To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org For additional commands, e-mail: dev-h...@commons.apache.org
Re: [DISCUSS] Allow unstable 0.x OR -Milestone releases
Sigh, typical mistake of forgetting to provide the link referenced further below: [1] http://commons.apache.org/releases/versioning.html#Milestone_Releases On 10/10/2013 01:26 PM, Ate Douma wrote: I've move this into a separate [DISCUSS] thread as I think it needs separate discussion. Jörg gave some objections below about using Milestone releases, as I proposed earlier to support releasing intermediate versions of a not-yet-stabalized component. While I understand his problems with unstable versions potentially getting 'stuck' for long time, where end-users *might* start expecting them to remain stable, I don't agree this is, or should be, the common case. Or at least not an argument to hold against using such 0.x or -Milestone releases. Instead, the whole point is to get project/component development moving *faster* by allowing *experimental* end-users to provide feedback, and more flexibility and convenience for the developers of such project/component. The idea to have to 'switch' to a next major version for any incompatibile change, as Jörg proposes, requiring package changes, whatnot, while a project clearly is not ready to stabalize, really puts way too much hurdles up for both the developers *and* such experimental end-users, as they would HAVE to change all of their code to be able to provide AND leaverage such new 0.x or Milestone version. Case in point: SCXML If we are allowed to start working on this component shortly, we intend to, and HAVE to switch to a 1.0 version first, as there already is a 0.9 version release out, while we will need to move to newer JDK and incompatible API changes anyway. At the same time, getting a final/stabalized 1.0 release out most certainly will take several iterations. I don't want to have to wait doing an intermediate release, nor rapidly having to switch to a 2.x/3.x/4.x/etc. versions, just because Milestone releases are acceptable for this purpose. Of course I inteded to say 'just because Milestone releases are NOT acceptable for this purpose'. Where would Milestone releases [1] be useful for otherwise, anyway? I think a real problem might arise IF other components (or 3rd party libraries) would start depending directly on such Milestone releases, potentially introducing unexpected instabilities for end-users. And maybe it is worthwhile to make such usages, at least for Commons, prohibited. That would make sense to me. But for components like SCXML, javaflow, or csv, this I don't think would be a real issue. Those end-users making use of these experimental components are, or should be very well aware, of the added responsibility they take depending on a not-yet-stabilized version, as clearly is also indicated by the version, as well as SHOULD be prominently documented in the release notes, readme, etc. Thoughts? Ate On 10/10/2013 12:45 PM, Benedikt Ritter wrote: I like the idea of releasing 0.x versions. A good example is [csv]. I would have no problem with releasing the current trunk as 0.9. At the moment [csv] is just another component we don't releaese because we want to come up with a perfect API (and I take responsibility for that :-) Benedikt Send from my mobile device Am 10.10.2013 um 12:15 schrieb Jörg Schaible : Hi, Ate Douma wrote: On 10/10/2013 12:24 AM, Torsten Curdt wrote: Every now and then I keep getting requests via private mail asking to release javaflow as it seems to be working for people. Yet I know there is still so much essential stuff to fix for a 1.0 release. Crossing over to the other thread: I know on github I would made a 0.x release already ages ago but knowing I won't have time to work on it anymore I keep pushing this out at commons. Wouldn't this be a case to allow and use intermediate milestone releases? Using a 1.0-Mxx version would make still clear to the users things haven't settled yet (API wise), so should not limit or restrict making API changes before a final 1.0 release, but would help both the community and the project moving. More likely to incite further involvement and contributions, etc. Being 'stuck' on getting a (final) 1.0 release out because everything should be settled and 'frozen' (API wise) first doesn't make sense to me at all. We should not be so afraid to switch to 2.x if the 1.x API turns out to be cumbersome in some cases. Typically you may also increase Java level in the meantime and therefore eventually even have a benefit of new possibilities. "Release early and often" really is what keeps open source projects moving forward, *any* policy which blocks that is plain wrong and should be fixed. Note: I'm not saying I'm against the strict versioning rules, but those should NOT block getting to a 1.0 release easily. And I don't think they do. Isn't this where Milestone releases are meant for? I am not a big fan of milestones unless we really h
[DISCUSS] Allow unstable 0.x OR -Milestone releases [Was: [DISCUSS] Putting several unmaintained components to dormant]
I've move this into a separate [DISCUSS] thread as I think it needs separate discussion. Jörg gave some objections below about using Milestone releases, as I proposed earlier to support releasing intermediate versions of a not-yet-stabalized component. While I understand his problems with unstable versions potentially getting 'stuck' for long time, where end-users *might* start expecting them to remain stable, I don't agree this is, or should be, the common case. Or at least not an argument to hold against using such 0.x or -Milestone releases. Instead, the whole point is to get project/component development moving *faster* by allowing *experimental* end-users to provide feedback, and more flexibility and convenience for the developers of such project/component. The idea to have to 'switch' to a next major version for any incompatibile change, as Jörg proposes, requiring package changes, whatnot, while a project clearly is not ready to stabalize, really puts way too much hurdles up for both the developers *and* such experimental end-users, as they would HAVE to change all of their code to be able to provide AND leaverage such new 0.x or Milestone version. Case in point: SCXML If we are allowed to start working on this component shortly, we intend to, and HAVE to switch to a 1.0 version first, as there already is a 0.9 version release out, while we will need to move to newer JDK and incompatible API changes anyway. At the same time, getting a final/stabalized 1.0 release out most certainly will take several iterations. I don't want to have to wait doing an intermediate release, nor rapidly having to switch to a 2.x/3.x/4.x/etc. versions, just because Milestone releases are acceptable for this purpose. Where would Milestone releases [1] be useful for otherwise, anyway? I think a real problem might arise IF other components (or 3rd party libraries) would start depending directly on such Milestone releases, potentially introducing unexpected instabilities for end-users. And maybe it is worthwhile to make such usages, at least for Commons, prohibited. That would make sense to me. But for components like SCXML, javaflow, or csv, this I don't think would be a real issue. Those end-users making use of these experimental components are, or should be very well aware, of the added responsibility they take depending on a not-yet-stabilized version, as clearly is also indicated by the version, as well as SHOULD be prominently documented in the release notes, readme, etc. Thoughts? Ate On 10/10/2013 12:45 PM, Benedikt Ritter wrote: I like the idea of releasing 0.x versions. A good example is [csv]. I would have no problem with releasing the current trunk as 0.9. At the moment [csv] is just another component we don't releaese because we want to come up with a perfect API (and I take responsibility for that :-) Benedikt Send from my mobile device Am 10.10.2013 um 12:15 schrieb Jörg Schaible : Hi, Ate Douma wrote: On 10/10/2013 12:24 AM, Torsten Curdt wrote: Every now and then I keep getting requests via private mail asking to release javaflow as it seems to be working for people. Yet I know there is still so much essential stuff to fix for a 1.0 release. Crossing over to the other thread: I know on github I would made a 0.x release already ages ago but knowing I won't have time to work on it anymore I keep pushing this out at commons. Wouldn't this be a case to allow and use intermediate milestone releases? Using a 1.0-Mxx version would make still clear to the users things haven't settled yet (API wise), so should not limit or restrict making API changes before a final 1.0 release, but would help both the community and the project moving. More likely to incite further involvement and contributions, etc. Being 'stuck' on getting a (final) 1.0 release out because everything should be settled and 'frozen' (API wise) first doesn't make sense to me at all. We should not be so afraid to switch to 2.x if the 1.x API turns out to be cumbersome in some cases. Typically you may also increase Java level in the meantime and therefore eventually even have a benefit of new possibilities. "Release early and often" really is what keeps open source projects moving forward, *any* policy which blocks that is plain wrong and should be fixed. Note: I'm not saying I'm against the strict versioning rules, but those should NOT block getting to a 1.0 release easily. And I don't think they do. Isn't this where Milestone releases are meant for? I am not a big fan of milestones unless we really have a forced schedule for the final release. If we get into the situation that the milestone is the latest release for months, we get into jar hell again, because that milestone is then *used* like any proper release. You cannot prevent this. There is a reason why I hav
Re: [DISCUSS] Putting several unmaintained components to dormant
On 10/10/2013 12:24 AM, Torsten Curdt wrote: Every now and then I keep getting requests via private mail asking to release javaflow as it seems to be working for people. Yet I know there is still so much essential stuff to fix for a 1.0 release. Crossing over to the other thread: I know on github I would made a 0.x release already ages ago but knowing I won't have time to work on it anymore I keep pushing this out at commons. Wouldn't this be a case to allow and use intermediate milestone releases? Using a 1.0-Mxx version would make still clear to the users things haven't settled yet (API wise), so should not limit or restrict making API changes before a final 1.0 release, but would help both the community and the project moving. More likely to incite further involvement and contributions, etc. Being 'stuck' on getting a (final) 1.0 release out because everything should be settled and 'frozen' (API wise) first doesn't make sense to me at all. "Release early and often" really is what keeps open source projects moving forward, *any* policy which blocks that is plain wrong and should be fixed. Note: I'm not saying I'm against the strict versioning rules, but those should NOT block getting to a 1.0 release easily. And I don't think they do. Isn't this where Milestone releases are meant for? Ate Release and put into dormant? It's a strange situation. cheers, Torsten - To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org For additional commands, e-mail: dev-h...@commons.apache.org
Re: [SCXML] knock knock?
On 10/08/2013 02:18 PM, Rahul Akolkar wrote: Who's there :-) Agree with all your Commons SCXML related comments below.I've been out of time for this for a while; you're welcome to have at it. Being ASF committers helps as discussed down-thread. I'll continue to lurk, but likely won't be active in the immediate future. Welcome to Commons, -Rahul Thanks for the welcome Rahul. Its great to hear you agree to the proposal, and welcoming us to go ahead. Too bad you won't be able to participate directly, but we'll make sure to properly discuss and propose important changes first, so you still be able to chime in any time you feel like it. And knowing you'll still be lurking is cool: we'll assume no feedback as a good sign then :) Thanks and regards, Ate On Mon, Oct 7, 2013 at 10:40 AM, Ate Douma wrote: Hi SCXML developers/community, We are trying to figure out what the status and activity of SCXML development is, and and/or who in the community might be interested in re-activating it. From the mailing lists and JIRA activity we gather not much has been happening here for a very long time: the last release 0.9 dates back to December 2008 and the last serious code commits to June 2011... Looking back through the history of SCXML, Rahul Akolkar was and pretty much still is the only maintainer of the code but seemingly no longer able or willing to contribute much anymore. So, what to do with Commons SCXML? To put it bluntly, we would very much like to revive the development of SCXML again. We are working for Hippo (Open Source CMS vendor) and intend to start using SCXML as state machine engine in our product shortly. As the latest release is so old, and based on only Java 1.4, we're looking into using the Java 6 (J6) branch instead. But this branch is still 'work in progress' without any release (but targeted at next major version 1.0). This J6/1.0 branch AFAIK is intended to cover the final SCXML specification [1], but already running quite a bit behind the latest draft of that specification. However, this being a W3C specification, having to wait for it to become final before releasing a next major version of Commons SCXML seems very counter-productive to me... Both myself and Woonsan are Apache committers on several other ASF projects for quite some time, so we know 'how it works'. We would like to get out hands dirty, start contributing on Commons SCXML, and help move it forward towards a more current release. But the question is: is there still anyone out here willing to pick up and review contributions, discuss stuff, etc. Hopefully Rahul can chime in (if still listening) and let us know what his ideas and plans are, or else maybe other active members of the Commons community? As a minimum we would like to get a Java 6+ compatible version released soon, maybe as a first milestone release towards 1.0, and incrementally add (more) compliance to the current SCXML specification. For this we propose to 'archive' the current stalled trunk (move it to a 0.xx branch or something), promote the current J6 branch to trunk, and then take it from there. Website and documentation fixes would be next to pick up and straighten out and updating the current Maven build. Possibly drop the outdated Ant build as well if nobody really is using or dependening on it anyway. As said, we're willing to step up here, but as non committers for Apache Commons we do need a 'handle' to get stuff moving again. Thanks, Ate & Woonsan [1] http://www.w3.org/TR/scxml/ - To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org For additional commands, e-mail: dev-h...@commons.apache.org - To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org For additional commands, e-mail: dev-h...@commons.apache.org
Re: [SCXML] knock knock?
On 10/07/2013 11:59 PM, Phil Steitz wrote: On Oct 7, 2013, at 2:15 PM, Emmanuel Bourg wrote: Le 07/10/2013 20:30, Phil Steitz a écrit : Great. We give sandbox commit to any ASF committer. Reply with your availIds and we can get that done immediately. Commit to commons proper requires a little more process, but we can get that done easily assuming you want to join us as committers. As veteran ASF committers I trust them to work directly on proper. +1 we just need nominations / votes on private@ You are quick :) We would definitely appreciate it and are willing to take this on, if the PMC accepts and trust us to do so. Or otherwise willing to start slower and build up the trust in the sandbox first. It would be good though if Rahul also could chime in. After all, he created and maintained the SCXML component for many years, practically all on his own. So if possible we'd like his input and hopefully support as well... Thanks, Ate & Woonsan Emmanuel Bourg - To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org For additional commands, e-mail: dev-h...@commons.apache.org - To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org For additional commands, e-mail: dev-h...@commons.apache.org
Re: [SCXML] knock knock?
On 10/07/2013 10:40 PM, Juan Antonio Breña Moral wrote: Hi, I am working with SCXML for HFSM with EV3 Robots. https://github.com/jabrena/liverobots Very nice! I would like to collaborate. Any ideas you have floating, bring them on! All help is appreciated. Now, Apache Commons SCXML is running in a ARM9 with good performance. Great to hear it runs fine on ARM9! Our use-case concerns a high level of concurrent processes: many users executing and interacting with a state machine at the same time, constantly modifying, publishing etc. large amounts of content all in different states. We definitely will need good performance too, with the least possible overhead. I'm looking forward to work on this together. Regards, Ate Cheers On 10/07/2013 10:23 PM, Ate Douma wrote: On 10/07/2013 09:52 PM, Juan Antonio Breña Moral wrote: Hi Great Idea. In my case I could test software and contribute a bit. Great to hear! Are you currently active user of SCXML? I'd love to hear in what context, what version, etc. I surely welcome your offer to test and contribute! Thanks, Ate Juan Antonio On 10/07/2013 08:30 PM, Phil Steitz wrote: On 10/7/13 7:40 AM, Ate Douma wrote: Hi SCXML developers/community, We are trying to figure out what the status and activity of SCXML development is, and and/or who in the community might be interested in re-activating it. From the mailing lists and JIRA activity we gather not much has been happening here for a very long time: the last release 0.9 dates back to December 2008 and the last serious code commits to June 2011... Looking back through the history of SCXML, Rahul Akolkar was and pretty much still is the only maintainer of the code but seemingly no longer able or willing to contribute much anymore. So, what to do with Commons SCXML? To put it bluntly, we would very much like to revive the development of SCXML again. Great. We are working for Hippo (Open Source CMS vendor) and intend to start using SCXML as state machine engine in our product shortly. As the latest release is so old, and based on only Java 1.4, we're looking into using the Java 6 (J6) branch instead. But this branch is still 'work in progress' without any release (but targeted at next major version 1.0). This J6/1.0 branch AFAIK is intended to cover the final SCXML specification [1], but already running quite a bit behind the latest draft of that specification. However, this being a W3C specification, having to wait for it to become final before releasing a next major version of Commons SCXML seems very counter-productive to me... Both myself and Woonsan are Apache committers on several other ASF projects for quite some time, so we know 'how it works'. We would like to get out hands dirty, start contributing on Commons SCXML, and help move it forward towards a more current release. Great. We give sandbox commit to any ASF committer. Reply with your availIds and we can get that done immediately. Commit to commons proper requires a little more process, but we can get that done easily assuming you want to join us as committers. But the question is: is there still anyone out here willing to pick up and review contributions, discuss stuff, etc. Hopefully Rahul can chime in (if still listening) and let us know what his ideas and plans are, or else maybe other active members of the Commons community? Would be ideal if Rahul is still available / listening; otherwise what you can count on is some random help / comments and help with the release and build process. As a minimum we would like to get a Java 6+ compatible version released soon, maybe as a first milestone release towards 1.0, and incrementally add (more) compliance to the current SCXML specification. For this we propose to 'archive' the current stalled trunk (move it to a 0.xx branch or something), promote the current J6 branch to trunk, and then take it from there. Website and documentation fixes would be next to pick up and straighten out and updating the current Maven build. Possibly drop the outdated Ant build as well if nobody really is using or dependening on it anyway. Sounds reasonable. As said, we're willing to step up here, but as non committers for Apache Commons we do need a 'handle' to get stuff moving again. Welcome to commons! Phil Thanks, Ate & Woonsan [1] http://www.w3.org/TR/scxml/ - To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org For additional commands, e-mail: dev-h...@commons.apache.org - To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org For additional commands, e-mail: dev-h...@commons.apache.org - To unsubscribe, e-mail: dev-unsubscr...@commons.apache.
Re: [DISCUSS] Mission Statement for Commons...
On 10/07/2013 08:14 PM, Benedikt Ritter wrote: Hi, since we have discussed a lot of different aspects, it may be time to sum things up a bit (please correct me or add things I've missed): Release Management - Releases take too long - Build is overly complex - dependencies to parent pom seem to be unclear - to few releases (more releases may attract more people) Technical/Coding Stuff - Commons feels legacy - Using old JDKs simply isn't fun - people are moving to alternative libs (for example guava) because commons feels like legacy code - switching to git (?!) Organisational Stuff - to few people work on to many components - Split up commons into several TLPs - Split up commons into bigger sub projects with individual MLs - decide what can be dormant and focus on core components Etiquette/Policies - we are a do-ocracy - discussions are started instead of fixing it yourself (specially in sandbox) - we don't have to be perfect (and we will never be ;-) - loosen API compatibility policy? I personally would like to at the point about commons public relations I've talked about a while back. Seriously: if you look at our website do you get the feeling that bleeding edge software is developed at commons? I intended to do something about the site but got caught up in the site build and then lost the motivation to dig deeper into the issue (which I'm a bit ashamed of, now that I've to spell it out loud ;-) The question is: how do we want to address these issues. I've seen endless discussions here with no result. That's another problem I see. When we get started with discussing, a lot of ideas come up, but little action is taken in the end. I've only been lurking here for a while, so I don't have yet first hand experience of these problems (here), and probably a bit naive because of that. But my experience in other ASF communities is that many of such endless discussions with no result can be prevented by allowing a more lazy consensus process, combined with more effective honoring a do-ocracy policy (those who do decide). People with an itch willing to scratch it should just propose to do so. And unless someone with a reasonable argument *and* alternative objects, be allowed to execute it. That should get stuff moving much faster *and* be motivating for others with an itch to start scratching as well. Objecting against a reasonable proposal without being able to step in yourself doesn't help any project or community forward. Nor does it align with the 'Apache way'. If you don't have the time or interest to chime in and help, step aside and make room for others who do. 'Community over code' really is key. For me at least that is the most important 'thing' making the ASF so great to be part of. Thanks, Ate Benedikt 2013/10/7 James Carman On Sun, Oct 6, 2013 at 3:44 PM, Christian Grobmeier wrote: We discuss magic strings in the sandbox. Why? We don't need to discuss that. Before we release we can simply check Sonar. Safe the time to discuss. Fix it or leave it to Sonar to report it. +1! This sort of behavior definitely has to stop. It frustrates our contributors. Nobody wants to get into lengthy discussions about this level of minutiae. I know some folks have given up, because they don't want to have to debate every little change they make. We vote people in because they have the technical chops and have proven themselves. They don't need a babysitter! Perhaps we should all watch this video: http://www.youtube.com/watch?v=Q52kFL8zVoM Don't get me wrong, I am glad to know that we have people so dedicated to the project that they are willing to monitor every single commit message that comes through (I don't have that kind of time), but perhaps that time would be better spent coding. If you see something you think needs more documentation, then go document it. If you think a refactoring is in order (like introducing a constant, extract method, etc.), then go do it. Don't spend more of your time (and theirs) writing up emails telling someone else to do it. Do it yourself! For me, if you *have* to document your code, then you've failed. Your code should be self-documenting. Comments eventually get out of sync with the code and then you've got one big mess on your hands. Write clear, elegant code and you don't have to worry about documentation. - To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org For additional commands, e-mail: dev-h...@commons.apache.org - To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org For additional commands, e-mail: dev-h...@commons.apache.org
Re: [SCXML] knock knock?
On 10/07/2013 09:52 PM, Juan Antonio Breña Moral wrote: Hi Great Idea. In my case I could test software and contribute a bit. Great to hear! Are you currently active user of SCXML? I'd love to hear in what context, what version, etc. I surely welcome your offer to test and contribute! Thanks, Ate Juan Antonio On 10/07/2013 08:30 PM, Phil Steitz wrote: On 10/7/13 7:40 AM, Ate Douma wrote: Hi SCXML developers/community, We are trying to figure out what the status and activity of SCXML development is, and and/or who in the community might be interested in re-activating it. From the mailing lists and JIRA activity we gather not much has been happening here for a very long time: the last release 0.9 dates back to December 2008 and the last serious code commits to June 2011... Looking back through the history of SCXML, Rahul Akolkar was and pretty much still is the only maintainer of the code but seemingly no longer able or willing to contribute much anymore. So, what to do with Commons SCXML? To put it bluntly, we would very much like to revive the development of SCXML again. Great. We are working for Hippo (Open Source CMS vendor) and intend to start using SCXML as state machine engine in our product shortly. As the latest release is so old, and based on only Java 1.4, we're looking into using the Java 6 (J6) branch instead. But this branch is still 'work in progress' without any release (but targeted at next major version 1.0). This J6/1.0 branch AFAIK is intended to cover the final SCXML specification [1], but already running quite a bit behind the latest draft of that specification. However, this being a W3C specification, having to wait for it to become final before releasing a next major version of Commons SCXML seems very counter-productive to me... Both myself and Woonsan are Apache committers on several other ASF projects for quite some time, so we know 'how it works'. We would like to get out hands dirty, start contributing on Commons SCXML, and help move it forward towards a more current release. Great. We give sandbox commit to any ASF committer. Reply with your availIds and we can get that done immediately. Commit to commons proper requires a little more process, but we can get that done easily assuming you want to join us as committers. But the question is: is there still anyone out here willing to pick up and review contributions, discuss stuff, etc. Hopefully Rahul can chime in (if still listening) and let us know what his ideas and plans are, or else maybe other active members of the Commons community? Would be ideal if Rahul is still available / listening; otherwise what you can count on is some random help / comments and help with the release and build process. As a minimum we would like to get a Java 6+ compatible version released soon, maybe as a first milestone release towards 1.0, and incrementally add (more) compliance to the current SCXML specification. For this we propose to 'archive' the current stalled trunk (move it to a 0.xx branch or something), promote the current J6 branch to trunk, and then take it from there. Website and documentation fixes would be next to pick up and straighten out and updating the current Maven build. Possibly drop the outdated Ant build as well if nobody really is using or dependening on it anyway. Sounds reasonable. As said, we're willing to step up here, but as non committers for Apache Commons we do need a 'handle' to get stuff moving again. Welcome to commons! Phil Thanks, Ate & Woonsan [1] http://www.w3.org/TR/scxml/ - To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org For additional commands, e-mail: dev-h...@commons.apache.org - To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org For additional commands, e-mail: dev-h...@commons.apache.org - To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org For additional commands, e-mail: dev-h...@commons.apache.org - To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org For additional commands, e-mail: dev-h...@commons.apache.org
Re: [SCXML] knock knock?
On 10/07/2013 08:30 PM, Phil Steitz wrote: On 10/7/13 7:40 AM, Ate Douma wrote: Hi SCXML developers/community, We are trying to figure out what the status and activity of SCXML development is, and and/or who in the community might be interested in re-activating it. From the mailing lists and JIRA activity we gather not much has been happening here for a very long time: the last release 0.9 dates back to December 2008 and the last serious code commits to June 2011... Looking back through the history of SCXML, Rahul Akolkar was and pretty much still is the only maintainer of the code but seemingly no longer able or willing to contribute much anymore. So, what to do with Commons SCXML? To put it bluntly, we would very much like to revive the development of SCXML again. Great. We are working for Hippo (Open Source CMS vendor) and intend to start using SCXML as state machine engine in our product shortly. As the latest release is so old, and based on only Java 1.4, we're looking into using the Java 6 (J6) branch instead. But this branch is still 'work in progress' without any release (but targeted at next major version 1.0). This J6/1.0 branch AFAIK is intended to cover the final SCXML specification [1], but already running quite a bit behind the latest draft of that specification. However, this being a W3C specification, having to wait for it to become final before releasing a next major version of Commons SCXML seems very counter-productive to me... Both myself and Woonsan are Apache committers on several other ASF projects for quite some time, so we know 'how it works'. We would like to get out hands dirty, start contributing on Commons SCXML, and help move it forward towards a more current release. Great. We give sandbox commit to any ASF committer. Reply with your availIds and we can get that done immediately. Great! For Woonsan and me that would be 'woonsan' and 'ate'. Commit to commons proper requires a little more process, but we can get that done easily assuming you want to join us as committers. We surely do. And of course we understand and know that becoming commons proper committers does require more. Which we're willing to provide :) Being committers to the Commons sandbox however won't help us much right now as SCXML already is in commons proper. So unless the current SCXML J6 branch is 'branched' into the sandbox (temporarily), we'll have to rely on others to review and commit our contributions. Maybe such a temporary SCXML 'branch' in commons sandbox would be a way to get started? But the question is: is there still anyone out here willing to pick up and review contributions, discuss stuff, etc. Hopefully Rahul can chime in (if still listening) and let us know what his ideas and plans are, or else maybe other active members of the Commons community? Would be ideal if Rahul is still available / listening; otherwise what you can count on is some random help / comments and help with the release and build process. That already would be great. I've been trying to digest the release and build process as well as updating the website (which for SCXML is seriously broken in some areas), which turns out to be non-trivial to say the least ;) I expect to come up with more detailed questions as well as patches soon. I already opened up a relatively trivial JIRA ticket (SCXML-168), with patch attached, last week but that hasn't seen a response yet. But then, neither has many other open tickets for SCXML in quite a while... As a minimum we would like to get a Java 6+ compatible version released soon, maybe as a first milestone release towards 1.0, and incrementally add (more) compliance to the current SCXML specification. For this we propose to 'archive' the current stalled trunk (move it to a 0.xx branch or something), promote the current J6 branch to trunk, and then take it from there. Website and documentation fixes would be next to pick up and straighten out and updating the current Maven build. Possibly drop the outdated Ant build as well if nobody really is using or dependening on it anyway. Sounds reasonable. Great! If nobody objects I can propose a more definitive and detailed plan in a few days through a JIRA tickets and if still considered reasonable, hopefully someone then can 'execute' it. As said, we're willing to step up here, but as non committers for Apache Commons we do need a 'handle' to get stuff moving again. Welcome to commons! Thanks! Phil Thanks, Ate & Woonsan [1] http://www.w3.org/TR/scxml/ - To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org For additional commands, e-mail: dev-h...@commons.apache.org
Re: [SCXML] knock knock?
Hi Benedikt, On 10/07/2013 07:44 PM, Benedikt Ritter wrote: Hello Ate, we are going through some discussions at the moment about how we want to organize development at commons in the future [1]. I'm aware of it as I've been subscribed to this list for several months. So far only lurking but now ready to step up :) We are always looking for people that want to contribute so I see no reason why you shouldn't dig right into the code. Great, and I like to start doing so. But as an 'outsider' still, I do hope to engage and collaborate with the existing SCXML community, or at least what is left of it. And if that only is Rahul, I hope he can chime in to help us get rolling. Otherwise it might be much more difficult, and would depend on others within Commons to chime in and step up until we would be ready and merited to act directly ourselves. Regarding the reviewing: I don't now the SCXML spec, so I may not be the best one to review this kind of contributions. But we'll find a way to push SCXML forward. Cool, and thanks for willing to help! Nice that you've joint us. Benedikt Thanks for welcoming us in! Kind regards, Ate [1] http://markmail.org/message/kvclice322ea45yh 2013/10/7 Ate Douma Hi SCXML developers/community, We are trying to figure out what the status and activity of SCXML development is, and and/or who in the community might be interested in re-activating it. From the mailing lists and JIRA activity we gather not much has been happening here for a very long time: the last release 0.9 dates back to December 2008 and the last serious code commits to June 2011... Looking back through the history of SCXML, Rahul Akolkar was and pretty much still is the only maintainer of the code but seemingly no longer able or willing to contribute much anymore. So, what to do with Commons SCXML? To put it bluntly, we would very much like to revive the development of SCXML again. We are working for Hippo (Open Source CMS vendor) and intend to start using SCXML as state machine engine in our product shortly. As the latest release is so old, and based on only Java 1.4, we're looking into using the Java 6 (J6) branch instead. But this branch is still 'work in progress' without any release (but targeted at next major version 1.0). This J6/1.0 branch AFAIK is intended to cover the final SCXML specification [1], but already running quite a bit behind the latest draft of that specification. However, this being a W3C specification, having to wait for it to become final before releasing a next major version of Commons SCXML seems very counter-productive to me... Both myself and Woonsan are Apache committers on several other ASF projects for quite some time, so we know 'how it works'. We would like to get out hands dirty, start contributing on Commons SCXML, and help move it forward towards a more current release. But the question is: is there still anyone out here willing to pick up and review contributions, discuss stuff, etc. Hopefully Rahul can chime in (if still listening) and let us know what his ideas and plans are, or else maybe other active members of the Commons community? As a minimum we would like to get a Java 6+ compatible version released soon, maybe as a first milestone release towards 1.0, and incrementally add (more) compliance to the current SCXML specification. For this we propose to 'archive' the current stalled trunk (move it to a 0.xx branch or something), promote the current J6 branch to trunk, and then take it from there. Website and documentation fixes would be next to pick up and straighten out and updating the current Maven build. Possibly drop the outdated Ant build as well if nobody really is using or dependening on it anyway. As said, we're willing to step up here, but as non committers for Apache Commons we do need a 'handle' to get stuff moving again. Thanks, Ate & Woonsan [1] http://www.w3.org/TR/scxml/ --**--**- To unsubscribe, e-mail: dev-unsubscribe@commons.**apache.org For additional commands, e-mail: dev-h...@commons.apache.org - To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org For additional commands, e-mail: dev-h...@commons.apache.org
[SCXML] knock knock?
Hi SCXML developers/community, We are trying to figure out what the status and activity of SCXML development is, and and/or who in the community might be interested in re-activating it. From the mailing lists and JIRA activity we gather not much has been happening here for a very long time: the last release 0.9 dates back to December 2008 and the last serious code commits to June 2011... Looking back through the history of SCXML, Rahul Akolkar was and pretty much still is the only maintainer of the code but seemingly no longer able or willing to contribute much anymore. So, what to do with Commons SCXML? To put it bluntly, we would very much like to revive the development of SCXML again. We are working for Hippo (Open Source CMS vendor) and intend to start using SCXML as state machine engine in our product shortly. As the latest release is so old, and based on only Java 1.4, we're looking into using the Java 6 (J6) branch instead. But this branch is still 'work in progress' without any release (but targeted at next major version 1.0). This J6/1.0 branch AFAIK is intended to cover the final SCXML specification [1], but already running quite a bit behind the latest draft of that specification. However, this being a W3C specification, having to wait for it to become final before releasing a next major version of Commons SCXML seems very counter-productive to me... Both myself and Woonsan are Apache committers on several other ASF projects for quite some time, so we know 'how it works'. We would like to get out hands dirty, start contributing on Commons SCXML, and help move it forward towards a more current release. But the question is: is there still anyone out here willing to pick up and review contributions, discuss stuff, etc. Hopefully Rahul can chime in (if still listening) and let us know what his ideas and plans are, or else maybe other active members of the Commons community? As a minimum we would like to get a Java 6+ compatible version released soon, maybe as a first milestone release towards 1.0, and incrementally add (more) compliance to the current SCXML specification. For this we propose to 'archive' the current stalled trunk (move it to a 0.xx branch or something), promote the current J6 branch to trunk, and then take it from there. Website and documentation fixes would be next to pick up and straighten out and updating the current Maven build. Possibly drop the outdated Ant build as well if nobody really is using or dependening on it anyway. As said, we're willing to step up here, but as non committers for Apache Commons we do need a 'handle' to get stuff moving again. Thanks, Ate & Woonsan [1] http://www.w3.org/TR/scxml/ - To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org For additional commands, e-mail: dev-h...@commons.apache.org
Re: Fwd: commons-logging unsuited for cross-context webapplication invocation usage - migrating to slf4j?
Mark Thomas wrote: Ate Douma wrote: Mark Thomas wrote: I have seen similar issues in Tomcat's internal logging with java.util.logging, log4j and commons-logging. Why will this be any different with slf4j? Because sfl4j does not use the ContextClassLoader to determine the logger instance but compile-time binding. Exactly the reason why CL doesn't work and slf4j does. I think using slf4j for Tomcat internal logging would solve this too. I still don't get how slf4j solves all of the web app container logging issues. I might have to download slf4j and try a few things out. In the meantime consider this: Two web applications both using slf4j with java.util.logging and both using a third party library that has a logger called "MyLogger". When web app one uses the library, slf4j will return - via a call to j.u.l.getLogger() - a new logger called MyLogger. When web app two uses the library it will get the same logger instance as web app one. This type of behaviour is often at the root of permgen memory leaks. If these libraries (slf4j + third party library) both are *separately* within the WEB-INF/lib of their own webapp as you replied in a later message, *and* the webcontainer uses PARENT_LAST classloading policy (as standard by Tomcat), effectively you'll end up with two separate instances of MyLogger (as being loaded by different classloaders) and all should be fine, at least when using log4j. How a global JUL configuration will work out in this case I don't know for sure because, to be honest, I always do my best to stay far away from using JUL. Remy had to write a new LogManager for j.u.l to work around this. If you use slf4j/log4j with your webapp you should not see this issue as the logger repository would be at the webapp level rather than globally as it is with j.u.l. Right :) That said, I'd still be worried about cross-context calls and webapps getting instances of loggers loaded by other webapps and would want to do some very careful testing. When using slf4j+log4j and PARENT_LAST webapp classloader policy as is the servlet spec recommendation (I won't say requirement because some people/companies disagree, but *I* think that is the only sensible configuration and interpretation of the spec), you should not need to worry. Regards, Ate I freely admit this stuff makes my head hurt every time I have to try and figure out one of these bugs. If slf4j solves all of these issues I'd really like to understand how. Mark - To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org For additional commands, e-mail: dev-h...@commons.apache.org - To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org For additional commands, e-mail: dev-h...@commons.apache.org
Re: Fwd: commons-logging unsuited for cross-context webapplication invocation usage - migrating to slf4j?
Hi John,
While your example proxy solution is nice enough by itself, imo its way too
much over-engineering for the issue at hand.
We're trying to get rid of the ContextClassLoader use for *only* the logging,
not add more overhead to it!
And, in practice this solution wouldn't work for us anyway as there are other cross-context invocation usages where we *need* the
ContextClassLoader of the caller, like when marshalling and unmarshalling complex PortletEvent payload (using JAXB) provided by the Portlet
Application to be dispatched across potentially even other Portlet Applications (all this managed and coordinated from the Portal/container
web app). The PortletContainer (we) know when to use the ContextClassLoader and when not. An all-encompassing proxy solution adds too much
unnecessary overhead and actually blocks the usage of the real ContextClassLoader when its needed.
We just needed the least intrusive and most straightforward solution available
and wrapping or patching CL simply doesn't fit that bill.
With kind regards,
Ate
John Bollinger wrote:
Mark Thomas wrote:
John Bollinger wrote:
See attached sample code for a class that would support this behavior.
Your attachment didn't make it through. Could you post it in-line?
Sure:
/*
* Licensed to the Apache Software Foundation (ASF) under one or more
* contributor license agreements. See the NOTICE file distributed with
* this work for additional information regarding copyright ownership.
* The ASF licenses this file to You under the Apache License, Version 2.0
* (the "License"); you may not use this file except in compliance with
* the License. You may obtain a copy of the License at
*
* http://www.apache.org/licenses/LICENSE-2.0
*
* Unless required by applicable law or agreed to in writing, software
* distributed under the License is distributed on an "AS IS" BASIS,
* WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied.
* See the License for the specific language governing permissions and
* limitations under the License.
*/
package example;
import java.lang.reflect.InvocationHandler;
import java.lang.reflect.Method;
import java.lang.reflect.Proxy;
/**
*
* A service class that assists in managing a "context" within an application or
* service. This version provides for creating dynamic proxies around objects
* belonging to a particular context to ensure that those objects' methods are
* invoked in that context.
*
* Instances may be created and held on a one-per-context basis, but currently
* there is no harm in having multiple managers for the same context.
* Alternatively, {...@code ContextManager}s are lightweight, so they may be
created
* at need and released freely. Model usage:
*
* ContextManager contextManager = ContextManager.forCurrentContext();
* ...
* void passRequestToForeignContext(RequestInterface request, ForeignContext
context) {
* context.handleRequest(
* contextManager.createProxy(request, RequestInterface.class)
* );
* }
*
*
*
* @author John C. Bollinger
*/
public class ContextManager {
/**
* The context ClassLoader for the context managed by this ContextManager
*/
private final ClassLoader contextClassLoader;
/**
* Initializes a new ContextManager managing the context defined by the
* specified context {...@code ClassLoader}
*
* @param contextClassLoader a {...@code ClassLoader} representing the
context
* to be managed by this {...@code ContextManager}
*/
public ContextManager(ClassLoader contextClassLoader) {
this.contextClassLoader = contextClassLoader;
}
/**
* Creates and returns a {...@code ContextManger} for the current context
*
* @return a {...@code ContextManger} for the current context
*/
public static ContextManager forCurrentContext() {
return new
ContextManager(Thread.currentThread().getContextClassLoader());
}
/**
* Creates a dynamic proxy object wrapping the provided object and ensuring
* that all methods of the wrapped object (when invoked via the proxy) see
* the appropriate context ClassLoader for the context managed by this
* {...@code ContextManager}. The proxy's class will implement the
specified
* interface(s) by delegating every method invocation to the wrapped object,
* setting the context ClassLoader before, and resetting it after.
*
* @param an interface type that the proxy object will implement
* @param object the object to be wrapped by the
* @param iface a Class representing one of the interfaces the proxy's class
* must implement, and defining the formal type of the return value and
* the {...@code object} argument
* @param additionalIfaces {...@code Class}es representing additional
interfaces
* the proxy's class must implement
*
* @return a p
Re: Fwd: commons-logging unsuited for cross-context webapplication invocation usage - migrating to slf4j?
Mark Thomas wrote: Ate Douma wrote: When Pluto needs to "aggregate" the content of this TestPortlet, it invokes it render(PortletRequest, PortletResponse) method using a "cross-context" call from the Pluto web application to the "test" web application. The TestPortlet.render method receives the PortletRequest object (as loaded from the Pluto WEB-INF/lib) and invokes its PortletRequest.getPortletPreferences() method. If the PortletPreferences class hasn't been accessed yet before, this will cause the ClassLoader of PortletRequest, being the Pluto webapp ClassLoader, to now load the PortletPreferences class. But, because the current ContextClassLoader is the "test" webapp ClassLoader, LogFactory will lookup the logger implementation from the "test" webapp... With as result that logging output for the PortletPreferences class will end up in the target as specified by the "test" webapp, not in the one (as expected) as configured for the Pluto webapp. I have seen similar issues in Tomcat's internal logging with java.util.logging, log4j and commons-logging. Why will this be any different with slf4j? Because sfl4j does not use the ContextClassLoader to determine the logger instance but compile-time binding. Exactly the reason why CL doesn't work and slf4j does. I think using slf4j for Tomcat internal logging would solve this too. The only possible workaround I could come up with was extending LogFactory itself and temporarily switching/enforcing the current ContextClassLoader to that of the class itself, but obviously we didn't even consider that as a real option. In Tomcat, the issue was (mainly) log objects for internal components being created and loaded by a web application class loader. This was a particular issue for Jasper, the JSP engine, as it interacts quite closely with web apps. We solved this by ensuring that the logs were created during Tomcat start. Sure, that will work *if* you manage to prime/pre-load all loggers upfront. For a webserver that might be doable (for its internal libraries), but for an embeddable component like a portletcontainer and definitely for a highly configurable and extendable portal like Jetspeed that would put too much runtime overhead and an indeterminable configuration nightmare for the end users/integrators. Would a similar solution not work for Pluto? Use a ServletContextListener to create your log instances when the portlet container web appilcation starts? And start scanning and preloading all classes from WEB-INF/classes and WEB-INF/lib? Replacing CL with slf4j is by far a more transparent and easier solution than that. Ate Mark - To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org For additional commands, e-mail: dev-h...@commons.apache.org - To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org For additional commands, e-mail: dev-h...@commons.apache.org
Re: Fwd: commons-logging unsuited for cross-context webapplication invocation usage - migrating to slf4j?
..@portals.apache.org Reply-To: pluto-...@portals.apache.org +1 to SLF4J several Jasig projects are also looking at it as an alternative to JCL. -Eric Ate Douma wrote: Pluto community, I'd like to ask your intention for issue PLUTO-553: http://issues.apache.org/jira/browse/PLUTO-553 Detailed information about this blocking issue can be found at above JIRA page. As I have described there, if nobody objects I intend to commit the migration to sfl4j soon. Any comments/feedback of further discussion is of course welcome. Regards, Ate - To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org For additional commands, e-mail: dev-h...@commons.apache.org
