Re: [ JEXL] Java 6 ?
Thanks for your inputs: consensus is java 8 is the way to go; reopened JEXL-249, will fix momentarily. -- Sent from: http://apache-commons.680414.n4.nabble.com/Commons-Dev-f680415.html - To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org For additional commands, e-mail: dev-h...@commons.apache.org
[ JEXL] Java 6 ?
Quick poll before attempting to release JEXL 3.1; Should we still release with support for Java 6 or should we move ahead with at least Java 8 ? Seems to me Java 6 is old enough to be dropped. One could still build from source with java 6 if needed. What do you think ? Cheers -- Sent from: http://apache-commons.680414.n4.nabble.com/Commons-Dev-f680415.html - To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org For additional commands, e-mail: dev-h...@commons.apache.org
Re: [commons-jexl] branch master updated: JEXL-307: tidy API (made JexlOptions a concrete non derivable class), try to ensure lexical interpretation on lexical feature, allow runtime options to be con
JexlOptions is introduced in 3.2, this class has not been released yet. I understand your reaction but I believe it is not warranted in this case. I also believe 'internal' classes are clearly out of the API contract - they are documented as such. If you believe there are already showstoppers that warrant a package change, aka jexl4, I should not even try releasing 3.2; please let me know. Cheers -- Sent from: http://apache-commons.680414.n4.nabble.com/Commons-Dev-f680415.html - To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org For additional commands, e-mail: dev-h...@commons.apache.org
[JEXL] GitHub/GitBox integration is out of whack
fyi https://issues.apache.org/jira/browse/INFRA-19344 Henrib -- Sent from: http://apache-commons.680414.n4.nabble.com/Commons-Dev-f680415.html - To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org For additional commands, e-mail: dev-h...@commons.apache.org
Re: [jexl] Migration to Git
No complaints nor remarks, just a simple "thank you" note. (ps: rebelling against considering positive reinforcement as clutter :-D ) -- Sent from: http://apache-commons.680414.n4.nabble.com/Commons-Dev-f680415.html - To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org For additional commands, e-mail: dev-h...@commons.apache.org
Re: [GitHub][JEXL] Svn trunk no longer reflected in Git ?
Opened INFRA-15611 (syncing to GitHub) & INFRA-15612 (creating a writeable GitHub repo). -- Sent from: http://apache-commons.680414.n4.nabble.com/Commons-Dev-f680415.html - To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org For additional commands, e-mail: dev-h...@commons.apache.org
[GitHub][JEXL] Svn trunk no longer reflected in Git ?
It seems the trunk for Commons JEXL (committed through svn) is no longer reflected in git, at least not for the past 14 days. Any idea what can/should be done to restart the sync ? Incidentally, I can't find the URL for committers in RW for this project through Git; what am I missing ? Thanks -- Sent from: http://apache-commons.680414.n4.nabble.com/Commons-Dev-f680415.html - To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org For additional commands, e-mail: dev-h...@commons.apache.org
Re: [VOTE] Release JEXL 3.1 based on RC1
+1 (non binding). Thanks Emmanuel :-) -- View this message in context: http://apache-commons.680414.n4.nabble.com/VOTE-Release-JEXL-3-1-based-on-RC1-tp4697204p4697339.html Sent from the Commons - Dev mailing list archive at Nabble.com. - To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org For additional commands, e-mail: dev-h...@commons.apache.org
Re: [jexl] 3.1 release review
The interface modifications are fixes to user enhancement requests: JEXL-211: Add callable method to JexlExpression interface JEXL-198: JxltEngine Template deos not expose pragmas JEXL-201: Allow Interpreter to use live values from JexlEngine.Option interface implemented by JexlContext Note again that these interfaces are *not* expected to be implemented by user code. The likelihood of any user implementing those and not filling enhancements requests or even asking questions in the Apache mailing lists (or Stackoverflow) seems very small... Choice is please (the few) users using the library or stay true to a rule that protects no real usage in this case. I wish this was seen as an easy choice for the community. Cheers -- View this message in context: http://apache-commons.680414.n4.nabble.com/jexl-3-1-release-review-tp4691513p4696492.html Sent from the Commons - Dev mailing list archive at Nabble.com. - To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org For additional commands, e-mail: dev-h...@commons.apache.org
Re: [jexl] 3.1 release review
I've reworded the warning about the source compatibility break in the release notes: If this source compatibility break is not 'permitted' despite its improbability, what option should we take: - move to another (jexl31) package ? - add 'extended' interfaces (Options31, JexlExpression31, Template31) ? - add a utility helper class (Jexl31Helper?) to put the 3 methods as functions ( boolean isCancellable(JExlEngine.Options opt) ? Comments welcome, Thanks -- View this message in context: http://apache-commons.680414.n4.nabble.com/jexl-3-1-release-review-tp4691513p4696416.html Sent from the Commons - Dev mailing list archive at Nabble.com. - To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org For additional commands, e-mail: dev-h...@commons.apache.org
Re: [jexl] 3.1 release review
Resurrecting the thread...Hopefully Emmanuel has a few spare cycles. :-)
I've commented JEXL-220 with the 3 Clirr errors that correspond to adding
methods to interfaces that only Jexl is supposed to implement.
I've also added a very clear statements as a waning in the release-notes; it
reads as:
{code}
Warning:
This release does break compatibility by adding methods to interfaces; these
interfaces are not expected to be
implemented by code external to the Jexl project and this compatibility
break should remain hypothetical.
It is however possible and we are sorry if it causes problems to any of you.
To mitigate this issue, besides continue using JEXL 3.0, you are likely
delegating to JEXL3 objects and you
shall be able to continue doing so with these new methods. The 3 interfaces
& methods are:
1 - 'public java.lang.Boolean isCancellable()' in interface
org.apache.commons.jexl3.JexlEngine$Options
2 - 'public java.util.concurrent.Callable
callable(org.apache.commons.jexl3.JexlContext)'in interface
org.apache.commons.jexl3.JexlExpression
3 - 'public java.util.Map getPragmas()'in interface
org.apache.commons.jexl3.JxltEngine$Template
{code}
Is this acceptable ?
--
View this message in context:
http://apache-commons.680414.n4.nabble.com/jexl-3-1-release-review-tp4691513p4696356.html
Sent from the Commons - Dev mailing list archive at Nabble.com.
-
To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
For additional commands, e-mail: dev-h...@commons.apache.org
Re: Jexl Array
Hi; As mentioned in https://commons.apache.org/proper/commons-jexl/reference/syntax.html#Operators , the 'in' aka '~=' operator works with array (and collections). The syntax is thus: x ~= [10, 20, 30] Cheers -- View this message in context: http://apache-commons.680414.n4.nabble.com/Jexl-Array-tp4683460p4683476.html Sent from the Commons - Dev mailing list archive at Nabble.com. - To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org For additional commands, e-mail: dev-h...@commons.apache.org
Re: [VOTE] Release JEXL 3.0 based on RC2
+1 Thank you Emmanuel !! -- View this message in context: http://apache-commons.680414.n4.nabble.com/VOTE-Release-JEXL-3-0-based-on-RC2-tp4681229p4681272.html Sent from the Commons - Dev mailing list archive at Nabble.com. - To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org For additional commands, e-mail: dev-h...@commons.apache.org
[JEXL] Any Release Manager for JEXL 3.0 ?
Hi; I was wondering if any community member would be ready to serve as Release Manager for JEXL 3.0? That 3.0 trunk/fork has been used in production for the past 3 years so it can be considered fairly mature stable. Besides, no-one seems interested in maintaining 2.x. To be honest, no-one seems eager to use 3.0 either... :-) The pom, code, changes and reports seem ok. I dont know how hard and how necessary it would be to keep links to previous versions for javadoc/downlads, i.e. 1.0 and 2.x. Just in case one of you had some free-cycles to spare... Regards, Henrib -- View this message in context: http://apache-commons.680414.n4.nabble.com/JEXL-Any-Release-Manager-for-JEXL-3-0-tp4673602.html Sent from the Commons - Dev mailing list archive at Nabble.com. - To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org For additional commands, e-mail: dev-h...@commons.apache.org
Re: [OGNL] Make use of logging?
Would you share why ? I'm sure it would be beneficial to others (including the commons logging community). -- View this message in context: http://apache-commons.680414.n4.nabble.com/OGNL-Make-use-of-logging-tp4653577p4656667.html Sent from the Commons - Dev mailing list archive at Nabble.com. - To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org For additional commands, e-mail: dev-h...@commons.apache.org
RE: [OGNL] Make use of logging?
IMHO, commons logging is the best choice for this kinds of lib; it does not force the choice of the implementation library. Henrib -- View this message in context: http://apache-commons.680414.n4.nabble.com/OGNL-Make-use-of-logging-tp4653577p4656625.html Sent from the Commons - Dev mailing list archive at Nabble.com. - To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org For additional commands, e-mail: dev-h...@commons.apache.org
Re: svn commit: r1370208 - in /commons/proper/jexl/branches/2.0: RELEASE-NOTES.txt pom.xml src/site/xdoc/changes.xml
Just trying to ensure that I will not generate a public jexl2 release compiled against a jdk6. Since most (if not all) JEXL users can't even use published snapshots, the likelihood of anyone attempting to compile jexl2 and not being able to comment the toolchain plugin in the pom seems very low... Anyhow, you can revert the modification and you are more than welcome to release jexl-2.1.2 if you want to. :-) -- View this message in context: http://apache-commons.680414.n4.nabble.com/Re-svn-commit-r1370208-in-commons-proper-jexl-branches-2-0-RELEASE-NOTES-txt-pom-xml-src-site-xdoc-cl-tp4637751p4637754.html Sent from the Commons - Dev mailing list archive at Nabble.com.
Re: svn commit: r1370208 - in /commons/proper/jexl/branches/2.0: RELEASE-NOTES.txt pom.xml src/site/xdoc/changes.xml
I corrected the toolchain configuration (thanks for pointing it out the error) and commented out its usage from the pom. Jexl 2.1.2 is all yours now. -- View this message in context: http://apache-commons.680414.n4.nabble.com/Re-svn-commit-r1370208-in-commons-proper-jexl-branches-2-0-RELEASE-NOTES-txt-pom-xml-src-site-xdoc-cl-tp4637751p4637757.html Sent from the Commons - Dev mailing list archive at Nabble.com. - To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org For additional commands, e-mail: dev-h...@commons.apache.org
Re: [jexl] using map as script parameter or local variable
Bug reproduced, thanks for the report. Tracked as https://issues.apache.org/jira/browse/JEXL-135 . Cheers, Henrib -- View this message in context: http://apache-commons.680414.n4.nabble.com/jexl-using-map-as-script-parameter-or-local-variable-tp4635832p4635864.html Sent from the Commons - Dev mailing list archive at Nabble.com. - To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org For additional commands, e-mail: dev-h...@commons.apache.org
Re: [Math] How to select a specific JDK ?
Hello Gilles; Not sure this will fit your purpose but *toolchains* can be used to direct which JDK is used by Maven. You'd have to declare the various JDKs accessible in toolchains.xml (in $user.home/.m2) and configure the plugin in your pom.xml. By specifying the toolchains JDK vendor/version as properties in different profiles, it seems it should be possible to switch the JDK by running mvn with a -P flag. Cheers, Henrib -- View this message in context: http://apache-commons.680414.n4.nabble.com/Math-How-to-select-a-specific-JDK-tp4634995p4635099.html Sent from the Commons - Dev mailing list archive at Nabble.com. - To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org For additional commands, e-mail: dev-h...@commons.apache.org
Re: [all] Java 5 vs. 6
We actually did vote on this matter :-) Can the next version major version of a project require Java6? (i.e. drop Java 1.5) Result was yes. http://apache-commons.680414.n4.nabble.com/RESULT-VOTE-Can-the-next-version-major-version-of-a-project-require-Java6-i-e-drop-Java-1-5-tt4176593.html Cheers, Henrib -- View this message in context: http://apache-commons.680414.n4.nabble.com/all-Java-5-vs-6-tp4376289p4378518.html Sent from the Commons - Dev mailing list archive at Nabble.com. - To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org For additional commands, e-mail: dev-h...@commons.apache.org
Re: [ALL][VOTE] Rename Commons Sanselan to Commons Image
Commons Image, +1 Henrib -- View this message in context: http://apache-commons.680414.n4.nabble.com/ALL-VOTE-Rename-Commons-Sanselan-to-Commons-Image-tp4214365p4217696.html Sent from the Commons - Dev mailing list archive at Nabble.com. - To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org For additional commands, e-mail: dev-h...@commons.apache.org
Re: svn commit: r1215050 - in /commons/proper/jexl/tags/COMMONS_JEXL_2_1-RC3/src: main/java/org/apache/commons/jexl2/internal/MethodExecutor.java test/java/org/apache/commons/jexl2/IssuesTest.java
Sorry Sebb, busier w.e. than expected. Thanks for pushing the release. -- View this message in context: http://apache-commons.680414.n4.nabble.com/Re-svn-commit-r1215050-in-commons-proper-jexl-tags-COMMONS-JEXL-2-1-RC3-src-main-java-org-apache-coma-tp4204034p4215680.html Sent from the Commons - Dev mailing list archive at Nabble.com. - To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org For additional commands, e-mail: dev-h...@commons.apache.org
Re: [VOTE] graduate [graph] as a proper component
+1 for graduating graph, go Simo, go! Phil Steitz wrote We have too many one man shows and walking dead in Commons proper now to make more. Can't you propose a clear list of what you believe should go to the attic and/or votes? -- View this message in context: http://apache-commons.680414.n4.nabble.com/VOTE-graduate-graph-as-a-proper-component-tp4211850p4215730.html Sent from the Commons - Dev mailing list archive at Nabble.com. - To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org For additional commands, e-mail: dev-h...@commons.apache.org
Re: [VOTE] Release JEXL 2.1.1 based on RC1
+1 (Thanks again Sebb) -- View this message in context: http://apache-commons.680414.n4.nabble.com/VOTE-Release-JEXL-2-1-1-based-on-RC1-tp4215081p4215744.html Sent from the Commons - Dev mailing list archive at Nabble.com. - To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org For additional commands, e-mail: dev-h...@commons.apache.org
Re: [VOTE] graduate [graph] as a proper component
Sorry, finally caught up on the attic discussion thread... We Commoners could try to find a way to at least let users see some metric on the stability/maturity/activity on projects so they can evaluate the risk they are taking using it. -- View this message in context: http://apache-commons.680414.n4.nabble.com/VOTE-graduate-graph-as-a-proper-component-tp4211850p4215918.html Sent from the Commons - Dev mailing list archive at Nabble.com. - To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org For additional commands, e-mail: dev-h...@commons.apache.org
Re: svn commit: r1215050 - in /commons/proper/jexl/tags/COMMONS_JEXL_2_1-RC3/src: main/java/org/apache/commons/jexl2/internal/MethodExecutor.java test/java/org/apache/commons/jexl2/IssuesTest.java
I probably used manual editing, otherwise it would be properly reverted... If you have the svn command on top of your head to revert to the initial RC3 version, please send it; I'd rather not f...up again - even better, apply it if you still can. :-) Thanks PS: What about 2.1.1, do you or do I ? -- View this message in context: http://apache-commons.680414.n4.nabble.com/Re-svn-commit-r1215050-in-commons-proper-jexl-tags-COMMONS-JEXL-2-1-RC3-src-main-java-org-apache-coma-tp4204034p4204379.html Sent from the Commons - Dev mailing list archive at Nabble.com. - To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org For additional commands, e-mail: dev-h...@commons.apache.org
Re: svn commit: r1214986 - in /commons/proper/jexl/tags/COMMONS_JEXL_2_1-RC3/src: main/java/org/apache/commons/jexl2/internal/MethodExecutor.java test/java/org/apache/commons/jexl2/IssuesTest.java
Should not commit that late... Reverted RC3, applied fix on 2.0 branch. Thanks for catching this! -- View this message in context: http://apache-commons.680414.n4.nabble.com/Re-svn-commit-r1214986-in-commons-proper-jexl-tags-COMMONS-JEXL-2-1-RC3-src-main-java-org-apache-coma-tp4202553p4203622.html Sent from the Commons - Dev mailing list archive at Nabble.com. - To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org For additional commands, e-mail: dev-h...@commons.apache.org
Re: [jira] [Commented] (JEXL-124) Array parameters to methods don't work anymore
I'd say 2.1.1 asap since some JEXL users will not use anything but release builds. And if another issue pops up, then a 2.1.2 will be needed (keeping my fingers crossed)... Do you or do I publish it ? -- View this message in context: http://apache-commons.680414.n4.nabble.com/Re-jira-Commented-JEXL-124-Array-parameters-to-methods-don-t-work-anymore-tp4202532p4203635.html Sent from the Commons - Dev mailing list archive at Nabble.com. - To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org For additional commands, e-mail: dev-h...@commons.apache.org
Re: [VOTE] Release JEXL 2.1 based on RC3
+1 The tag is actually https://svn.apache.org/repos/asf/commons/proper/jexl/tags/COMMONS_JEXL_2_1-RC3/ . There is one minor error in the Javadoc (interpreter visit FloatLiteral / IntegerLiteral) but since these are deprecated, it has no importance. Otherwise, everything looks good to me. Thanks Sebb for your hardwork. -- View this message in context: http://apache-commons.680414.n4.nabble.com/VOTE-Release-JEXL-2-1-based-on-RC3-tp4174001p4182455.html Sent from the Commons - Dev mailing list archive at Nabble.com. - To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org For additional commands, e-mail: dev-h...@commons.apache.org
Re: [VOTE] Release JEXL 2.1 based on RC3
On checkstyle, 3 of them are empty statements that are known - been there for long - and the other are Javadoc on deprecated methods introduced to ensure binary compatibility. On PMD, I've never tried to configure it correctly; there was already a lot of clutter in 1.1... A lot of the issues come from number of methods - but there is no choice since we derive/implement either Javacc generated code or List (at least for 3/4) and in the former case, a lot of import (one per type of ASTNode). Another lot are the x != y conditions; PMD says bad style, I tend to like it to avoid long imbricated if chains and a fail early workflow. The use of == on object references instead of equals is another bad habit I tend to use for special cases / constant values. For instance, trying to make a difference between an empty but modifiable list/map and the empty non-modifiable instance; this avoids null checking later on (iteration, access, etc). And the last bunch is parameter reuse which again, is convenient when using 'null' as marker for default value. When you factor those out, there is not much left (cyclomatic complexity...). Anyway, those are not new. May be I tend to focus too much on checkstyle, find bugs and cobertura to give me a quality assessment. I'll try to see if anything can be either better configured or styled better in v3. Cheers, Henrib -- View this message in context: http://apache-commons.680414.n4.nabble.com/VOTE-Release-JEXL-2-1-based-on-RC3-tp4174001p4183636.html Sent from the Commons - Dev mailing list archive at Nabble.com. - To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org For additional commands, e-mail: dev-h...@commons.apache.org
[RESULT][VOTE] Can the next version major version of a project require Java6? (i.e. drop Java 1.5)
Question for vote was Can the next version major version of a project require Java6? (i.e. drop Java 1.5) Results on binding votes: Christian Grobmeier +1 Gary Gregory +1 Henri Biestro +1 James Carman +1 Jorg Shaible +1 Luc Maisonobe +1 Simone Tripodi +1 Ralph Goers +1 No -1 or 0. Thanks you all for your time, Best regards Henrib -- View this message in context: http://apache-commons.680414.n4.nabble.com/RESULT-VOTE-Can-the-next-version-major-version-of-a-project-require-Java6-i-e-drop-Java-1-5-tp4176593p4176593.html Sent from the Commons - Dev mailing list archive at Nabble.com. - To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org For additional commands, e-mail: dev-h...@commons.apache.org
Re: [VOTE] Can the next version major version of a project require Java6? (i.e. drop Java 1.5)
I guess your +1 does not apply to the vote. :-) And to be honest, javax.script is implemented by org.apache.bsf 3.1 which runs on Java 1.5... Nevertheless, the fair point that has been made by Matt later in this thread is that Commons is a do-ocracy; if someone badly needs a component in Java 1.5, nothing prevents him from contributing that backport from Java6 code. Accepting this and respecting the will of many would be quite a step forward since it means Commons would cease forcing people to contribute new projects/major-versions on an EOLed platform - for which they have rightfully no interest for. IMHO, the Java 1.5 release rule, besides forcing the installation/maintenance cost of the dev platform for contributors, nurtures the perception that Commons is just an unattractive set of obsolete components. And besides, nothing in the Commons charter states that components must support 2 major versions old JDKs; stability and quality should not equate to obsolescence. Cheers, Henrib -- View this message in context: http://apache-commons.680414.n4.nabble.com/VOTE-Can-the-next-version-major-version-of-a-project-require-Java6-i-e-drop-Java-1-5-tp4160635p4168607.html Sent from the Commons - Dev mailing list archive at Nabble.com. - To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org For additional commands, e-mail: dev-h...@commons.apache.org
Re: [VOTE] Can the next version major version of a project require Java6? (i.e. drop Java 1.5)
I respect your point of view but it is really hard to attract new contributors when we first state they MUST code with JDK 1.5. And again, if the need for a Java 1.5 backport is proven - rather than imposed by default - , it's always possible to people interested in it to contribute (and/or ask). Plus I really suspect that for edge projects, there is absolutely no audience widening in supporting Java 1.5. Regards, Henrib PS: it would be pretty interesting to know which JDK is actually deployed within enterprises by segment/size. All customers we see - mostly Oracle customers as well - now run Java6. -- View this message in context: http://apache-commons.680414.n4.nabble.com/VOTE-Can-the-next-version-major-version-of-a-project-require-Java6-i-e-drop-Java-1-5-tp4160635p4169631.html Sent from the Commons - Dev mailing list archive at Nabble.com. - To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org For additional commands, e-mail: dev-h...@commons.apache.org
Re: [VOTE] Can the next version major version of a project require Java6? (i.e. drop Java 1.5)
Matt Benson-2 wrote Maybe the right approach is to start with Java 6, then whoever likes to can investigate how much work it would take to restore Java 5 compatibility. Seems like a reasonable proposal to me; it means Java 1.5 is a nice to have feature - not a must have - feature as it currently stands. If someone needs a Java 1.5 backport, he can contribute to the project by doing so. Do-ocracy at work. Fair enough? Cheers Henrib PS: may be at the process/Commons level, we could introduce another category for of our projects. Instead of the current 3 Proper, Sandbox, Dormant, something like Stable (1.5-able), Proper, Sandox, Dormant or Modern, Proper (1.5 able), Sandbox, Dormant. So new versions can go modern till the need arise a contribution is made for a stable version. Just a thought... -- View this message in context: http://apache-commons.680414.n4.nabble.com/VOTE-Can-the-next-version-major-version-of-a-project-require-Java6-i-e-drop-Java-1-5-tp4160635p4164066.html Sent from the Commons - Dev mailing list archive at Nabble.com. - To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org For additional commands, e-mail: dev-h...@commons.apache.org
Re: [RELEASE PROCESS] Stability versus usability
Hi Jörg; I've amended the idea based on feedback to *internal* package and @internal annotation (for pragmatic reasons: a good rule is one which is easy to follow and enforce). The naming convention or the annotation would allow clear but also explicit boundary; documentation is necessary but not sufficient IMHO. It should be possible to determine automatically whether public code unintentionally exposes or uses an @internal class by transitivity. I agree that packaging should be the preferred way but sometimes, it may be too hard/long/costly to refactor the project; sprinkling annotations would not be ideal but would still allow control over the API stability. Cheers, Henrib PS: We might need @experimental or @beta for APIs intended for public use but not stable enough to make a hard cast-in-stone stable contract. -- View this message in context: http://apache-commons.680414.n4.nabble.com/RELEASE-PROCESS-Stability-versus-usability-tp4150322p4164209.html Sent from the Commons - Dev mailing list archive at Nabble.com. - To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org For additional commands, e-mail: dev-h...@commons.apache.org
Re: [jira] [Created] (JEXL-123) Redesign API for stability
Sebb; Lets not return the pb; Java6 is not downwards compatible with Java 1.5. There is a cost in maintaining 2 JDKs on 3 boxes, a cost in remembering that @Override can not be used on interfaces implementation, that addAll is not there, a cost in switching environments before using mvn and publishing, etc. All these little things that accumulated make it a pain in the a But, again, the main point is just that it is not useful to maintain Java 1.5 which is eol; JEXL3 is a new project API intended for active/new projects and thus will be used and deployed on Java 6. Besides, there is always JEXL 2.1 - soon to be released I hope - which will cover the Java 1.5 aficionados needs. Why do you want to impose an unnecessary compatibility ? Is there anything in the Commons charter that states that obsolete platforms need to be deployment targets? And IMHO, it is a disservice to the Java community to let them run new APIs on Java 1.5 when Java7 is out. Finally, do you really need to challenge any change or evolution even when not related to stability or quality ? Will we have to call votes for everything and anything ? And then we wonder why people seem to be fed up; re-read Simo, JamesC, GaryG recent message in the [JEXL] Jexl 2.1 thread... Regards, Henrib -- View this message in context: http://apache-commons.680414.n4.nabble.com/Re-jira-Created-JEXL-123-Redesign-API-for-stability-tp4157779p4159821.html Sent from the Commons - Dev mailing list archive at Nabble.com. - To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org For additional commands, e-mail: dev-h...@commons.apache.org
Re: [jira] [Created] (JEXL-123) Redesign API for stability
Up-coming technical needs requiring Java 6: JSR-269 (apt/annotation processing), JSR-199 (compiler API). -- View this message in context: http://apache-commons.680414.n4.nabble.com/Re-jira-Created-JEXL-123-Redesign-API-for-stability-tp4157779p4160017.html Sent from the Commons - Dev mailing list archive at Nabble.com. - To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org For additional commands, e-mail: dev-h...@commons.apache.org
Re: [jira] [Created] (JEXL-123) Redesign API for stability
JSR-269: custom annotation processing hooks are available in Java6; say someones wants to develop an IDE plugin that checks whether usage of a class/field/method annotated by @internal is made from the same package and issue a warning in that case... JSR-199: convert a script / or part of a script as a compiled class; instead of going through ASM et al libraries, generate the Java code - Jexl templates - and compile it. The real question is whether a project that seeks (5 years old) novelty has a place within Commons; is there a way to move JEXL (at least from v3 up) somewhere else within Apache where the 1984-release-police is not tempted to rule the world ? -- View this message in context: http://apache-commons.680414.n4.nabble.com/Re-jira-Created-JEXL-123-Redesign-API-for-stability-tp4157779p4160457.html Sent from the Commons - Dev mailing list archive at Nabble.com. - To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org For additional commands, e-mail: dev-h...@commons.apache.org
[VOTE] Can the next version major version of a project require Java6? (i.e. drop Java 1.5)
Sorry to bug everyone again, I'm hopelessly trying to make Commons move a little forward... Since a 2-person opposition never breaks the tie, a vote is in order to decide whether JEXL3 (aka the next major version after 2.1, see JEXL-123) can actually break loose of Java 1.5 compatibility. (sic) JEXL3 is intended to be a next major release of JEXL that cleans up the API, making sure the internal/public contract is crystal clear. Since it is a major revamp of the API, JEXL3 is intended to be used by new/active projects that will be deployed on Java6 / Java7. To avoid some development cost, I've blatantly crossed another rule without much thinking by requiring Java6 for JEXL3 (instead of Java5 which is EOL). Since JEXL2.1 - aka the next imminent version of jexl2 - already targets Java 1.5, I did not think it would start yet another fight with the release police. Was I wrong... Why can't you supporting a EOL-ed platform for a new version of the project?. (Because it's not a freebie for me but no matter). So, here we are again for some bickering and vote: [+1] Yes, you may release the next major release of JEXL3 with a Java6 requirement [-1] No, this is an important case/issue/matter/rule that we continue supporting Java 1.5 [0] Don't care Many thanks to those who will vote for their time and patience; Henrib PS: Is there a process to formally move a project from Commons to elsewhere within Apache? -- View this message in context: http://apache-commons.680414.n4.nabble.com/VOTE-Can-the-next-version-major-version-of-a-project-require-Java6-i-e-drop-Java-1-5-tp4160635p4160635.html Sent from the Commons - Dev mailing list archive at Nabble.com. - To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org For additional commands, e-mail: dev-h...@commons.apache.org
Re: [VOTE] Can the next version major version of a project require Java6? (i.e. drop Java 1.5)
Forgot to add the vote will close in 72 hours, as per-usual rules. -- View this message in context: http://apache-commons.680414.n4.nabble.com/VOTE-Can-the-next-version-major-version-of-a-project-require-Java6-i-e-drop-Java-1-5-tp4160635p4161054.html Sent from the Commons - Dev mailing list archive at Nabble.com. - To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org For additional commands, e-mail: dev-h...@commons.apache.org
Re: [RELEASE PROCESS] Stability versus usability
About the *internal* and @internal (package annotation); Of course if we could come up with a binding convention on the source layout and package name for all projects, it would be really nice (i.e. the *internal* package convention). (Oh, a common pom where only the source/test/site would be specific and allow automated reports and release vote publication... just dreaming out loud) But as a pragmatist, I'd rather have the @internal annotation that can serve as an intermediate, easy to use way to determine stability (both for the dev and the user) than nothing that slows down release cycles to a crawl; forcing projects to align on a source layout convention is likely bound to fail or at least a very (very very) long path. One of the goal is to allow at least easier - if not faster - release cycles; as devs, we'd be made easily aware that we are tinkering with the API contract and for release voting, it gets easier to control that we've not unintentionally screwed it up. Oh, and I do agree on the immutability / thread safety doc. :-) Cheers, Henrib -- View this message in context: http://apache-commons.680414.n4.nabble.com/RELEASE-PROCESS-Stability-versus-usability-tp4150322p4161225.html Sent from the Commons - Dev mailing list archive at Nabble.com. - To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org For additional commands, e-mail: dev-h...@commons.apache.org
Re: [VOTE] Can the next version major version of a project require Java6? (i.e. drop Java 1.5)
You summed it up pretty well; Can we participate in moving forward - Java6 is not really the bleeding edge... - or are we bound to remain on obsolete platforms with Commons ? -- View this message in context: http://apache-commons.680414.n4.nabble.com/VOTE-Can-the-next-version-major-version-of-a-project-require-Java6-i-e-drop-Java-1-5-tp4160635p4161262.html Sent from the Commons - Dev mailing list archive at Nabble.com. - To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org For additional commands, e-mail: dev-h...@commons.apache.org
Re: [VOTE] Can the next version major version of a project require Java6? (i.e. drop Java 1.5)
sebb-2-2 wrote My view is that while there is still a need for software to be able to run on Java 1.5, we should not insist on requiring a minimum of 1.6.*unless* there is good technical reason for doing so. But you don't consider a good (technical) reason the fact that the contributor can not/does not want to incur the cost of maintaining a JDK 1.5 on its dev platforms to be able to contribute to newer versions... And no-one is stating that Java 1.5 is not in used in production somewhere; but IMHO, these are not the ones that will be JEXL3 users, especially since they have 2.1 (soon). Anyway and beyond the point, my advice to 1.5 users is that before trying to use new versions of libraries, migrating away from an unsupported/EOLed platform should be their priority. -- View this message in context: http://apache-commons.680414.n4.nabble.com/VOTE-Can-the-next-version-major-version-of-a-project-require-Java6-i-e-drop-Java-1-5-tp4160635p4161571.html Sent from the Commons - Dev mailing list archive at Nabble.com. - To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org For additional commands, e-mail: dev-h...@commons.apache.org
Re: [VOTE] Can the next version major version of a project require Java6? (i.e. drop Java 1.5)
sebb-2-2 wrote Indeed, ideally everyone would now be using Java 6 and Windows users should all upgrade to Windows 7 etc. But even if it were the case, you'd still argue for us to continue using IE6... -- View this message in context: http://apache-commons.680414.n4.nabble.com/VOTE-Can-the-next-version-major-version-of-a-project-require-Java6-i-e-drop-Java-1-5-tp4160635p4161736.html Sent from the Commons - Dev mailing list archive at Nabble.com. - To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org For additional commands, e-mail: dev-h...@commons.apache.org
Re: [VOTE] Can the next version major version of a project require Java6? (i.e. drop Java 1.5)
Matt Benson-2 wrote ... maybe it's worth that tiny bit of extra pain to reach that slightly larger audience... It is not a tiny bit when you accumulate it; and JEXL3 would not reach a larger audience because it allows deployment on Java 1.5. This is a wrongly imposed cost with no benefit. -- View this message in context: http://apache-commons.680414.n4.nabble.com/VOTE-Can-the-next-version-major-version-of-a-project-require-Java6-i-e-drop-Java-1-5-tp4160635p4161848.html Sent from the Commons - Dev mailing list archive at Nabble.com. - To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org For additional commands, e-mail: dev-h...@commons.apache.org
Re: [VOTE] Can the next version major version of a project require Java6? (i.e. drop Java 1.5)
sebb-2-2 wrote But even if it were the case, you'd still argue for us to continue using IE6... No, I would not; that's an end-user product. I see it as the worst web app client platform... Even on that, we can't agree! (sorry, couldn't resist :-)...) -- View this message in context: http://apache-commons.680414.n4.nabble.com/VOTE-Can-the-next-version-major-version-of-a-project-require-Java6-i-e-drop-Java-1-5-tp4160635p4161935.html Sent from the Commons - Dev mailing list archive at Nabble.com. - To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org For additional commands, e-mail: dev-h...@commons.apache.org
Re: [RELEASE PROCESS] Stability versus usability
Stefan Bodewig wrote Would you have known at the point when JEXL 2.0.1 has been released which APIs you'd mark up as @stable or @usable? Yes for most and in doubt, I could have marked them @usable (or @internal which may be a better term). -- View this message in context: http://apache-commons.680414.n4.nabble.com/RELEASE-PROCESS-Stability-versus-usability-tp4150322p4156394.html Sent from the Commons - Dev mailing list archive at Nabble.com. - To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org For additional commands, e-mail: dev-h...@commons.apache.org
Re: [RELEASE PROCESS] Stability versus usability
ralph.goers @dslextreme.com wrote The part I'm struggling with is that if these are annotations vs just javadoc tags then I would expect some kind of either compile time or runtime behavior (or both). It seems that you are proposing javadoc tags instead? If not what behavior would the annotations cause? I'm not versed enough in Javadoc but I believe annotation carry more processing power. The information can remain in the executable and allow post build analysis. To feed a clirr report, it seems we'd need to introspect the classes/methods to find those @internal. One could even dream of a -your favorite IDE here- plugin that warns you when using one of those. If there is an easy / easier practical solution that could serve the same purpose, I'm all for it! -- View this message in context: http://apache-commons.680414.n4.nabble.com/RELEASE-PROCESS-Stability-versus-usability-tp4150322p4156415.html Sent from the Commons - Dev mailing list archive at Nabble.com. - To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org For additional commands, e-mail: dev-h...@commons.apache.org
Re: [RELEASE PROCESS] Stability versus usability
Keeping track as it evolves based on feedback; Goal is to allow easy definition, usage and check of stable APIs. An annotation and a package naming convention allow the project developer to clearly state when a class/method/field is not part of the stable contract despite a public/protected declaration but only of the internal part of the project. @internal annotated class/method or *internal* package mean use this at your own maintenance cost; those are not part of the public API. They can be used and extended but are subject to change between versions without @deprecated annotations. Those annotations and conventions should allow feeding a clirr report with the proper information to allow detection of unintended API breakage and may even allow creating IDE plugins to warn about usage. -- View this message in context: http://apache-commons.680414.n4.nabble.com/RELEASE-PROCESS-Stability-versus-usability-tp4150322p4156552.html Sent from the Commons - Dev mailing list archive at Nabble.com. - To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org For additional commands, e-mail: dev-h...@commons.apache.org
Re: [JEXL] Are users likely to implement the Script interface?
sebb-2-2 wrote Don't know if this is an indication that the unit tests are incomplete or that there is not really a use case for implementing the interface, (other than the implementations which are already supplied.) I don't think anyone would implement the Script interface without deriving / delegating to an ExpressionImpl which is internal (by transitivity from the protected ASTJexlScript member); so it'b be someone trying to extend Jexl capabilities. Jexl being usually featured and used as a glue / joint, JEXL Scripts are usually used as classes members thus implementing Script is very unlikely. I've been working on a redesign of the API for a potential V3 - a fresh and clean API made to be stable but breaking free from the ancient Velocity ties - and moved the ExpressionImpl equivalent to an internal package; I'll commit soon in the trunk, tests ok, Checkstyle stuff remains mainly. Cheers, Henrib -- View this message in context: http://apache-commons.680414.n4.nabble.com/JEXL-Are-users-likely-to-implement-the-Script-interface-tp4157600p4157664.html Sent from the Commons - Dev mailing list archive at Nabble.com. - To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org For additional commands, e-mail: dev-h...@commons.apache.org
Re: [JEXL] [PreVOTE] OK to release Jexl with some Clirr errors but no package/id change?
+1 :-) I honestly believe it is safe and that we are not making a dis-service to the Jexl community. Thanks again for your hard efforts in keeping the package name as-is on their behalf. Best regards, Henrib -- View this message in context: http://apache-commons.680414.n4.nabble.com/JEXL-PreVOTE-OK-to-release-Jexl-with-some-Clirr-errors-but-no-package-id-change-tp4157709p4157751.html Sent from the Commons - Dev mailing list archive at Nabble.com. - To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org For additional commands, e-mail: dev-h...@commons.apache.org
Re: [jira] [Created] (JEXL-123) Redesign API for stability
sebb-2-2 wrote Since it is targeted at new projects or at least very active ones, the deployment will require at least Java 1.6. Now if 1.6 is absolutely required to support certain new features, that is a different matter. I should have said that 'not useful' too. I believe it is not useful to incur the cost of maintaining knowledge about 1.5 and 1.6 differences in this case. I also think that if you want to use new stuff, it is better to avoid putting it on top of unsupported ones (1.5 is eol afaik); instead of adapting some code to Jexl3, someone would be doing a better job at migrating towards Java 6. Henrib -- View this message in context: http://apache-commons.680414.n4.nabble.com/Re-jira-Created-JEXL-123-Redesign-API-for-stability-tp4157779p4157896.html Sent from the Commons - Dev mailing list archive at Nabble.com. - To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org For additional commands, e-mail: dev-h...@commons.apache.org
Re: [JEXL] remaining binary incompatibilities in 2.1
If the last hurdle to binary compatibility is replacing DebugInfo by JexlInfo, by all means, replace it! Nice analysis and great result. Thanks for your efforts, Cheers Henrib Ps any comment on the difference between stability and usability and possible solutions, cd release process post? -- View this message in context: http://apache-commons.680414.n4.nabble.com/JEXL-remaining-binary-incompatibilities-in-2-1-tp4153028p4153537.html Sent from the Commons - Dev mailing list archive at Nabble.com. - To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org For additional commands, e-mail: dev-h...@commons.apache.org
Re: [RELEASE PROCESS] Stability versus usability
Since it may need clarification; The idea would be to allow a clirr report to give accurate analysis of whether the external / stable API has been modified. Methods or classes annotated as @stable, could not change from one version to another before they are @deprecated. Methods or classes annotated as @unstable (rather than @usable) could change between versions. The net result would be a good sense of whether the actual stable API is broken by a version and avoid lengthy discussions like the one we just had... Wouldn't this be possible to add to our toolbox as a clirr plugin of some kind? -- View this message in context: http://apache-commons.680414.n4.nabble.com/RELEASE-PROCESS-Stability-versus-usability-tp4150322p4154703.html Sent from the Commons - Dev mailing list archive at Nabble.com. - To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org For additional commands, e-mail: dev-h...@commons.apache.org
Re: [RELEASE PROCESS] Stability versus usability
Phil Steitz wrote In practical terms, it might be hard to decide what to put where. Can you provide some examples based on recent RCs? When trying to release JEXL 2.1, the API was disrupted and the clirr report was outputing lots of clutter. As the dev, it became very hard to understand whether the change was actually breaking the intended stable API or just some internal methods or class. Then a lot of effort - thanks to sebb - had to be spent just to check and amend the code to restore the contract. The findbugs, cobertura, chekstyle reports mostly allow to assess quality, a usable clirr report would give us a good view of stability. Phil Steitz wrote An easy baby step that I could personally get behind - and actually need in [math] - is adopting the .internal package name convention For new packages or during major code overhaul, it definitely does the job. But it might be unpractical and requires lots of code moving around; I'm currently trying to achieve this with JEXL3 and it is a major refactor. Plus it requires creating interfaces or abstract classes to clearly delineate the API; it tilts the balance of effort towards stability and hinders the ability to add features (in the same timeframe) thus slows down innovation. The annotation would be convenient to (re)decorate code since it is very lightweight, easy to use and control. Instead of @unstable / @usable, may be an @internal annotation would carry the proper information and would follow the same idea as the package name. @internal annotated class/method or *internal* package mean use this at your own maintenance cost; it still allows users to code using them, does not forcibly close extensibility thus preserve innovative contributions and provides a clearer view of the stable contract. Seems like a win-win. Best regards, Henrib -- View this message in context: http://apache-commons.680414.n4.nabble.com/RELEASE-PROCESS-Stability-versus-usability-tp4150322p4156330.html Sent from the Commons - Dev mailing list archive at Nabble.com. - To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org For additional commands, e-mail: dev-h...@commons.apache.org
[JEXL] Jexl 2.1?
Just a simple question to Sebb; Do you intend to pursue and release 2.1 or just leave it as is? Regards, Henrib -- View this message in context: http://apache-commons.680414.n4.nabble.com/JEXL-Jexl-2-1-tp4147180p4147180.html Sent from the Commons - Dev mailing list archive at Nabble.com. - To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org For additional commands, e-mail: dev-h...@commons.apache.org
Re: [JEXL] Jexl 2.1?
Of course I am frustrated; I'm old enough to know it will pass... More importantly, I now need to re-evaluate whether JEXL as an Apache Commons project is a library I can continue to use and recommend for professional usage; it has a shallow community, only had one committer for the past 3-4 years and a stringent release police that make extensibility, bug fix and RFE availability impossible to expect and even less to predict. Ergo, the simple question I needed to ask. :-) Cheers, Henrib -- View this message in context: http://apache-commons.680414.n4.nabble.com/JEXL-Jexl-2-1-tp4147180p4147799.html Sent from the Commons - Dev mailing list archive at Nabble.com. - To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org For additional commands, e-mail: dev-h...@commons.apache.org
Re: [JEXL] Jexl 2.1?
I'll try to follow-up the discussion about the Clirr errors when it starts. I hope you'll be able to serve as an RM. Thanks for your answer, Henrib -- View this message in context: http://apache-commons.680414.n4.nabble.com/JEXL-Jexl-2-1-tp4147180p4147829.html Sent from the Commons - Dev mailing list archive at Nabble.com. - To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org For additional commands, e-mail: dev-h...@commons.apache.org
Re: [JEXL] Jexl 2.1?
I've done the same thing and been pushing JEXL snapshots for sometime to avoid the unpleasant moment, so unpleasant that I've procrastinated enough to now have to consider alternatives. I find disturbing that committers fear to release and that goodwill to share features and code is killed by the process that should help publish them - not oppose them! I agree that a release early, release often scheme would help but I've no idea how to achieve this without a release faster mean. However, I ultimately suspect that the vested interest of some in promoting a hard, difficult and lengthy process relates to how their bills get payed and by whom; there is a huge difference in those of us doing this as a goodwill hobby - so to speak - because we feel it is good ethics to contribute back and those who make a living from it. Can't blame them for making sure their fees stay high by ensuring hobbyists don't get too efficient! (just kidding :-)) Cheers, Henrib -- View this message in context: http://apache-commons.680414.n4.nabble.com/JEXL-Jexl-2-1-tp4147180p4148135.html Sent from the Commons - Dev mailing list archive at Nabble.com. - To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org For additional commands, e-mail: dev-h...@commons.apache.org
[RELEASE PROCESS] Stability versus usability
It seems to me we have a hard time allowing both stability and usability. Stability of APIs does not contradict usability of the library, at least should not. Some of us are looking for very long term/stable/high-quality solutions because they need to aggregate lost of components, the stability users. Others are looking for best-of-breed/narrow scope/malleable libraries a with a guaranteed quality, the usability users. Thus the importance of clearly stating in our libraries what is 'stable' and what is 'usable'. The expressiveness in the language itself is not enough to properly describe the contract made regarding each party; i.e. sometimes things have to be public but should not be considered part of the API that follow the major,minor - deprecation. I believe we can come up with a set of agreeable rules to please both camps be through some naming convention in packages and annotations. As an kickstart proposal, may be something as simple as 2 annotations actually could be enough: @stable, @usable. @stable meaning the contract this API represents will not change without being first @deprecated @usable meaning this API is valid for this major version but may change in each minor with no warning We might also use a clear 'internal' sub-package name as a frontier delimiter on the same rule. Thoughts ? Best regards, Henri -- View this message in context: http://apache-commons.680414.n4.nabble.com/RELEASE-PROCESS-Stability-versus-usability-tp4150322p4150322.html Sent from the Commons - Dev mailing list archive at Nabble.com. - To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org For additional commands, e-mail: dev-h...@commons.apache.org
Re: [JEXL] Jexl 2.1?
Just to bump your attention on the [RELEASE PROCESS] discussion that probably could ensue at this point. Best regards, Henrib -- View this message in context: http://apache-commons.680414.n4.nabble.com/JEXL-Jexl-2-1-tp4147180p4151203.html Sent from the Commons - Dev mailing list archive at Nabble.com. - To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org For additional commands, e-mail: dev-h...@commons.apache.org
Re: [JEXL] New non-private mutable fields
Both 'parameters' and 'cancelled' are protected so they can be used by derived classes easily; having a private field + protected setter and getter is clutter in this specific case. Parameters holds the register 'names' which proves useful when debugging; the 2 arrays are parallel. -- View this message in context: http://apache-commons.680414.n4.nabble.com/JEXL-New-non-private-mutable-fields-tp4127864p4128191.html Sent from the Commons - Dev mailing list archive at Nabble.com. - To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org For additional commands, e-mail: dev-h...@commons.apache.org
Re: [JEXL] New non-private mutable fields
Fair enough; do you make the change or do I make the change ? -- View this message in context: http://apache-commons.680414.n4.nabble.com/JEXL-New-non-private-mutable-fields-tp4127864p4128334.html Sent from the Commons - Dev mailing list archive at Nabble.com. - To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org For additional commands, e-mail: dev-h...@commons.apache.org
Re: [JEXL] New non-private mutable fields
I don't think the JexlEngine mutable fields should be made volatile. Same as JexlArithmetic btw. The intent is not to change them but just to allow configuration of the behavior after the ctor but before usage. In the future, those should also be made final and/or use feature ala JexlThreadeArithmetic. This would probably require a JexlEngineBuilder of some sort since the list of options/parameters is pretty long... I'd rather see these setters documented the same (previous) way as in: This method is emnot/em thread safe; it should be called as an optional step of the JexlEngine initialization code before expression creation amp; evaluation. And may be add: Changing them after initialization may result in undefined behavior. -- View this message in context: http://apache-commons.680414.n4.nabble.com/JEXL-New-non-private-mutable-fields-tp4127864p4128517.html Sent from the Commons - Dev mailing list archive at Nabble.com. - To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org For additional commands, e-mail: dev-h...@commons.apache.org
Re: [JEXL] New non-private mutable fields
After more thoughts on the matter, I tried to be attractive to pragmatic coder with JEXL which is antagonist to the more rigorous approach you want to impose. As a user of some other libraries, I find bothersome not being able to derive classes because all methods/fields are private and/or final when there is no obvious reason. Which also means I accept the price of this freedom which is to follow releases / maintain my code when necessary. Thus, my tendency to privilege 'protected' fields or methods. My goal with JEXL was allowing a playground of some sort for scripting; I will definitely loose interest in it if it has to become a closed library. Your call. -- View this message in context: http://apache-commons.680414.n4.nabble.com/JEXL-New-non-private-mutable-fields-tp4127864p4128789.html Sent from the Commons - Dev mailing list archive at Nabble.com. - To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org For additional commands, e-mail: dev-h...@commons.apache.org
Re: [JEXL] New non-private mutable fields
Do as you wish, I will no longer bug you. -- View this message in context: http://apache-commons.680414.n4.nabble.com/JEXL-New-non-private-mutable-fields-tp4127864p4128952.html Sent from the Commons - Dev mailing list archive at Nabble.com. - To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org For additional commands, e-mail: dev-h...@commons.apache.org
Re: [JEXL] binary compatibility
About Test org.apache.commons.jexl2.UnifiedJEXLTest that failed, the code had bugs and was fixed. 1187458 Fri Oct 21 18:40:17 CEST 2011 henrib Added getVariables method (similar to JexlEngine) to extract all references variables from an UJEXL expression; Fixed issue where preparing a deferred expression would not always return an immediate expression; Updated test accordingly About Test org.apache.commons.jexl2.IssuesTest FAILED - test73, some changes were made on error reporting and the 2.0.1 test was weakly checking the exception message: 1182807 Thu Oct 13 14:38:05 CEST 2011 henrib Added JexlException.Property exception to more accurately report errors due to unknown or inaccessible object properties About Test org.apache.commons.jexl2.ArithmeticTest FAILED, these fail against 2.1 due to JEXL-83 fix which needs a JexlThreadedArithmetic instance to change the strict mode through the engine. -- View this message in context: http://apache-commons.680414.n4.nabble.com/JEXL-binary-compatibility-tp4114818p4123418.html Sent from the Commons - Dev mailing list archive at Nabble.com. - To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org For additional commands, e-mail: dev-h...@commons.apache.org
Re: [JEXL] binary compatibility
About Was: Dear #{p} Doe; Now: Dear ${p} Doe;
As stated, the issue was that preparing a deferred expression must always
return an immediate (even composite) expression. When preparing Dear #{p}
${name}; , the immediate ${name} will be evaluated - 'name' is the set of
variables - and the preparation of the inner-deferred #{p} leads to another
immediate ${p} thus the expression Dear ${p} Doe; - where the set of
variables is 'p'.
Since asString() must return the stringified form of the expression, it's
pretty essential that this behavior remains as is which is correct.
About JEXL-83 - which is an issue you reported - and its fix which lead to
the JexlThreadedArithmetic, the behavior is documented in the Javadoc @
setLenient():
* pThis method is emnot/em thread safe; it should be called as an
optional step of the JexlEngine initialization code before expression
creation amp; evaluation./p
* pAs of 2.1, you need a JexlThreadedArithmetic instance for this
call to also modify the JexlArithmetic
* leniency behavior./p
The rationale is pretty well documented in the issue itself.
I'd vote for throwing an UnsupportedOperationException with the same message
(or log an error if silent?) and document the change explicitly in the
release notes.
--
View this message in context:
http://apache-commons.680414.n4.nabble.com/JEXL-binary-compatibility-tp4114818p4123859.html
Sent from the Commons - Dev mailing list archive at Nabble.com.
-
To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
For additional commands, e-mail: dev-h...@commons.apache.org
Re: [JEXL] binary compatibility
If we go back to pre JEXL-83 fix (protected non final strict field + setter) and deprecate those, we can attempt releasing as 2.1 ? -- View this message in context: http://apache-commons.680414.n4.nabble.com/JEXL-binary-compatibility-tp4114818p4125129.html Sent from the Commons - Dev mailing list archive at Nabble.com. - To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org For additional commands, e-mail: dev-h...@commons.apache.org
Re: [JEXL] binary compatibility
I've committed the fix on the 2.0 branch - tests are OK - and if 2.1 is ever released, this will be needed. -- View this message in context: http://apache-commons.680414.n4.nabble.com/JEXL-binary-compatibility-tp4114818p4125259.html Sent from the Commons - Dev mailing list archive at Nabble.com. - To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org For additional commands, e-mail: dev-h...@commons.apache.org
Re: svn commit: r1207946 - /commons/proper/jexl/tags/COMMONS_JEXL_3_0/
Missed... I'll copy the tag with RC1. -- View this message in context: http://apache-commons.680414.n4.nabble.com/Re-svn-commit-r1207946-commons-proper-jexl-tags-COMMONS-JEXL-3-0-tp4119802p4119911.html Sent from the Commons - Dev mailing list archive at Nabble.com. - To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org For additional commands, e-mail: dev-h...@commons.apache.org
Re: svn commit: r1207946 - /commons/proper/jexl/tags/COMMONS_JEXL_3_0/
Done. https://svn.apache.org/repos/asf/commons/proper/jexl/tags/COMMONS_JEXL_3_0-RC1/ -- View this message in context: http://apache-commons.680414.n4.nabble.com/Re-svn-commit-r1207946-commons-proper-jexl-tags-COMMONS-JEXL-3-0-tp4119802p4119930.html Sent from the Commons - Dev mailing list archive at Nabble.com. - To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org For additional commands, e-mail: dev-h...@commons.apache.org
Re: Release JEXL 3.0 based on RC1
I dont understand what is expected anymore... There are some new features and fixes that break the API at the binary and source level; I'm merely applying the best practice recommendations - and previous 2.1 rejection basis. This version has been 18 months in the making, fixes quite a few bugs and adds what could be considered major functionalities; making it a new major version does not seem stupid. Besides, the very scarce JEXL's community is expecting these changes and no other Apache component really uses JEXL 2. Besides, anyone using a scripting engine in a binary safe way will (should) use it through JSR-223... What is the danger here, besides scaring off anyone trying to use JEXL ? Even if the next version is again a major one after 18 months (on average), would it be so bad ? I'm really puzzled and can't understand the motivation to reject (besides the artifactId). And if you feel disappointed, how would you feel if your work and time was only considered low quality or a waste by people who aren't actually using it? After all, may be OGNL is the way to go and JEXL moved to the attic... Sorry for the rant and thanks for another lesson in humility. Henrib -- View this message in context: http://apache-commons.680414.n4.nabble.com/Release-JEXL-3-0-based-on-RC1-tp4119894p4120071.html Sent from the Commons - Dev mailing list archive at Nabble.com. - To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org For additional commands, e-mail: dev-h...@commons.apache.org
Re: svn commit: r1207974 - /commons/proper/jexl/tags/COMMONS_JEXL_3_0-RC1/
Removed the tag. And don't understand why the artifactId must change with the version. -- View this message in context: http://apache-commons.680414.n4.nabble.com/Re-svn-commit-r1207974-commons-proper-jexl-tags-COMMONS-JEXL-3-0-RC1-tp4120017p4120114.html Sent from the Commons - Dev mailing list archive at Nabble.com. - To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org For additional commands, e-mail: dev-h...@commons.apache.org
Re: [CANCELLED][VOTE] Release JEXL 2.1 based on RC1
One might argue that JEXL does not have that many users so jar hell is very (very) unlikely - no Apache project depends on jexl2 afaik - and that forcing up to date/snapshot users to switch to a new package when they're already used to recompile against the latest JEXL version is adding burden on their side (i.e. replace all o.a.c.jexl2 imports with o.a.c.jexl3, update maven dependencies, etc.) with no practical benefit. However, following the commons best practice being the wisest route to release, I'll re-attempt an RC after migration to o.a.c.jexl3. Regards, Henrib -- View this message in context: http://apache-commons.680414.n4.nabble.com/CANCELLED-VOTE-Release-JEXL-2-1-based-on-RC1-tp4114443p4115226.html Sent from the Commons - Dev mailing list archive at Nabble.com. - To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org For additional commands, e-mail: dev-h...@commons.apache.org
Re: [VOTE] Release JEXL 2.1 based on RC1
Thanks for tidying up my mess. About org.apache.commons.jexl2.UnifiedJEXL$Expression, its subclasses are private because only that base class is supposed to be usable by end-users; one declares 'UnifiedJEXL.Expression expr' and the engine manages the rest. org.apache.commons.jexl2.internal is definitely internal (sic :-)). org.apache.commons.jexl2.introspection is intended to be used as a base to customization so should be considered public (albeit most likely never used by anyone); Uberspect.getConstructor was not carrying the proper signature in 2.0.x. The amount of work to try to make the release binary compatible seems unfortunately much greater than switching to a new package name... Thanks again for your help, Henrib -- View this message in context: http://apache-commons.680414.n4.nabble.com/VOTE-Release-JEXL-2-1-based-on-RC1-tp4113403p4115331.html Sent from the Commons - Dev mailing list archive at Nabble.com. - To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org For additional commands, e-mail: dev-h...@commons.apache.org
Re: [JEXL] binary compatibility
@since, will do. On the Script interface, I suspect anyone implementing it derives ExpressionImpl which does carry default implementations... On the new Script methods (getVariables etc), I'd like to keep the API simple and avoid multiplying interfaces (esp for 2/3 methods at a time). Thanks for the review Henrib -- View this message in context: http://apache-commons.680414.n4.nabble.com/JEXL-binary-compatibility-tp4114818p4115380.html Sent from the Commons - Dev mailing list archive at Nabble.com. - To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org For additional commands, e-mail: dev-h...@commons.apache.org
Re: [VOTE] Release JEXL 2.1 based on RC1
Cancelled vote. Henrib -- View this message in context: http://apache-commons.680414.n4.nabble.com/VOTE-Release-JEXL-2-1-based-on-RC1-tp4113403p4114453.html Sent from the Commons - Dev mailing list archive at Nabble.com. - To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org For additional commands, e-mail: dev-h...@commons.apache.org
Re: [ognl] internal cache performance improvement
Hi Simo; You might want to take a look at jexl in the org.apache.commons.jexl2.internal.introspection and org.apache.commons.jexl2.internal packages for ideas, more specifically at IntrospectorBase. Jexl caching is roughly a hashmap keyed by classes whose values are (essentially) hashmap keyed on method signatures pointing to methods. Cache access is synchronized and the whole cache is soft-refed so it can be evicted on memory pressure (or class loader change). To further reduce contention, the jexl interpreter caches method references in AST nodes through a volatile member; after the first execution, the script/statement retries to call the cached method. It will only go back to the class cache if the call is unsuccessful. At a higher level but I'm not sure it is practical, the org.apache.commons.jexl2.introspection package could be (re)used; it abstracts the whole introspection parts caching included. Hope this can help, Cheers Henrib -- View this message in context: http://apache-commons.680414.n4.nabble.com/ognl-internal-cache-performance-improvement-tp3576227p3578976.html Sent from the Commons - Dev mailing list archive at Nabble.com. - To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org For additional commands, e-mail: dev-h...@commons.apache.org
Re: OGNL as a part of Commons
Howdy; I looked at OGNL a while ago and can't fully remember why I ended up using JEXL (probably because it seemed simpler). Anyway, OGNL seems very powerful and expressive. What about trying to merge OGNL JEXL2 (instead of BeanUtils)? I'm pretty sure the core JEXL2 features (introspector - method /static / ctor calls, arithmetic) could be leveraged easily. The main differences would be in the upper parts I guess (syntax, constructs). It probably could help define a better scripting engine and language in the future rather than overlapping ones. Thoughts ? Henrib -- View this message in context: http://apache-commons.680414.n4.nabble.com/OGNL-as-a-part-of-Commons-tp3085026p3330241.html Sent from the Commons - Dev mailing list archive at Nabble.com. - To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org For additional commands, e-mail: dev-h...@commons.apache.org
Re: [jexl] Short description in commit messages (was: svn commit: r1072000)
Sorry about that; will do. Got it reversed between what I write in Jira and in the svn log. Regards, Henrib -- View this message in context: http://apache-commons.680414.n4.nabble.com/Re-jexl-Short-description-in-commit-messages-was-svn-commit-r1072000-tp3312834p3313182.html Sent from the Commons - Dev mailing list archive at Nabble.com. - To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org For additional commands, e-mail: dev-h...@commons.apache.org
Re: [VOTE] Release Commons IO 2.0 based on RC5
Checked trunk build on WinXP Mac OS / jdk 1.6; mvn site ok (besides javadoc link). +1 Henrib -- View this message in context: http://apache-commons.680414.n4.nabble.com/VOTE-Release-Commons-IO-2-0-based-on-RC5-tp2996424p2998344.html Sent from the Commons - Dev mailing list archive at Nabble.com. - To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org For additional commands, e-mail: dev-h...@commons.apache.org
Re: [VOTE] Release commons-exec-1.1 based on RC1
Looks good to me; checked trunk build on WinXP / Mac OS X - jdk1.6. +1 Henrib -- View this message in context: http://apache-commons.680414.n4.nabble.com/VOTE-Release-commons-exec-1-1-based-on-RC1-tp2970579p2998397.html Sent from the Commons - Dev mailing list archive at Nabble.com. - To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org For additional commands, e-mail: dev-h...@commons.apache.org
Re: [VOTE] Release Commons Parent POM version 17
+1 Henrib -- View this message in context: http://apache-commons.680414.n4.nabble.com/VOTE-Release-Commons-Parent-POM-version-17-tp2285989p2286989.html Sent from the Commons - Dev mailing list archive at Nabble.com. - To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org For additional commands, e-mail: dev-h...@commons.apache.org
Re: [JEXL] Problem Integrating JEXL 1.x Branch and Cocoon 2.2.x
Hi Stefan, I've had a quick look at the jexl-1.x source; the VelPropertyGet.isAlive method is not called anywhere in jexl's code or tests. Commenting it out from the interface does the trick. The real problem lies in changing this public interface which could be harmful to other projects that may depend on it. The easiest (obvious) route would be for you to use a locally modified / built jexl-1.x snapshot. We could also create a specific 'gump' branch with that modification but this would be really odd process-wise... A cleaner more future-proof alternative might be to use jexl-2 and the jexl-1 compatibility layer which is part of the distribution as source only ( http://svn.apache.org/viewvc/commons/proper/jexl/trunk/jexl2-compat/src/main/java/org/apache/commons/jexl/ ); I might help/check feasibility if needed. Cheers Henrib -- View this message in context: http://apache-commons.680414.n4.nabble.com/JEXL-Problem-Integrating-JEXL-1-x-Branch-and-Cocoon-2-2-x-tp2274718p2274885.html Sent from the Commons - Dev mailing list archive at Nabble.com. - To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org For additional commands, e-mail: dev-h...@commons.apache.org
[RESULT] Release Jexl 2.0.1
The following people voted on Jexl 2.0.1 release based on RC3: Rahul Akolkar: +1 Seb Bazley : +1 Oliver Heger: +1 Luc Maisonobe: +1 Jorg Schaible: +1 Thanks to all for your support and patience. I'll publish the 2.0.1 release momentarily. Cheers; Henrib -- View this message in context: http://n4.nabble.com/RESULT-Release-Jexl-2-0-1-tp1752861p1752861.html Sent from the Commons - Dev mailing list archive at Nabble.com. - To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org For additional commands, e-mail: dev-h...@commons.apache.org
Re: [VOTE] Release Jexl 2.0.1
Thank you for the review and the corrective actions. Generating RC2. -- View this message in context: http://n4.nabble.com/VOTE-Release-Jexl-2-0-1-tp1707491p1746534.html Sent from the Commons - Dev mailing list archive at Nabble.com. - To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org For additional commands, e-mail: dev-h...@commons.apache.org
Re: [VOTE] Release Jexl 2.0.1
RC1 was voted out due to packaging errors, RC2 out. JEXL 2.0.1 is a hotfix release correcting a blocker issue. Tag: https://svn.apache.org/repos/asf/commons/proper/jexl/tags/COMMONS_JEXL_2_0_1-RC2 Site: http://people.apache.org/~henrib/jexl-2.0.1-RC2/site/index.html Binaries: http://people.apache.org/~henrib/jexl-2.0.1-RC2/staged [ ] +1 release it [ ] +0 go ahead I don't care [ ] -1 no, do not release it because Votes will close on Tuesday 2010-04-06T22:00+2. Thanks Henrib -- View this message in context: http://n4.nabble.com/VOTE-Release-Jexl-2-0-1-tp1707491p1746540.html Sent from the Commons - Dev mailing list archive at Nabble.com. - To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org For additional commands, e-mail: dev-h...@commons.apache.org
Re: svn commit: r929437 - in /commons/proper/jexl/trunk: pom.xml src/main/config/findbugs-exclude-filter.xml
Should have documented this, my bad. I've added the 'henrib' profile to upload the RC site through 'mvn -Phenrib site:deploy' in my home directory as http://...henrib/jexl-2.0.1-RC2/site. The 'rc' profile would do so in the http://.../builds/commons/jexl/2.0.1/RC2/site. Since most projects are staged in the home dir, I just tried to do the same in a reproducible manner ( especially given my inane ability to screw-up the release process ). -- View this message in context: http://n4.nabble.com/Re-svn-commit-r929437-in-commons-proper-jexl-trunk-pom-xml-src-main-config-findbugs-exclude-filter-xl-tp1746587p1746604.html Sent from the Commons - Dev mailing list archive at Nabble.com. - To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org For additional commands, e-mail: dev-h...@commons.apache.org
Re: svn commit: r929437 - in /commons/proper/jexl/trunk: pom.xml src/main/config/findbugs-exclude-filter.xml
I still think the profile does not belong in the project pom.
Just add it to your settings.xml instead.
I cant define the distributionManagement .../ in my settings. How/where
can I put the staging site dir so it persists ?
s/inane/innate/ ?
I meant 'innane' (as in Lacking sense or meaning - often implying, to the
point of boredom or annoyance :-) ). I just wish I g{e,o}t faster to the
point where you would not have to catch all these inept errors I'm making.
Thanks again.
--
View this message in context:
http://n4.nabble.com/Re-svn-commit-r929437-in-commons-proper-jexl-trunk-pom-xml-src-main-config-findbugs-exclude-filter-xl-tp1746587p1746874.html
Sent from the Commons - Dev mailing list archive at Nabble.com.
-
To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
For additional commands, e-mail: dev-h...@commons.apache.org
Re: svn commit: r929437 - in /commons/proper/jexl/trunk: pom.xml src/main/config/findbugs-exclude-filter.xml
Or I can just do 'zip -r site site' and upload like the artefacts... Guess I'll have to update the pom (just the pom, nothing else) and try a manual RC3 upload. Third is a charm... -- View this message in context: http://n4.nabble.com/Re-svn-commit-r929437-in-commons-proper-jexl-trunk-pom-xml-src-main-config-findbugs-exclude-filter-xl-tp1746587p1747110.html Sent from the Commons - Dev mailing list archive at Nabble.com. - To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org For additional commands, e-mail: dev-h...@commons.apache.org
Re: svn commit: r929437 - in /commons/proper/jexl/trunk: pom.xml src/main/config/findbugs-exclude-filter.xml
Ooops, too late, RC3 out... With a bit of luck, I'll get your +1 vote. :-) -- View this message in context: http://n4.nabble.com/Re-svn-commit-r929437-in-commons-proper-jexl-trunk-pom-xml-src-main-config-findbugs-exclude-filter-xl-tp1746587p1747181.html Sent from the Commons - Dev mailing list archive at Nabble.com. - To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org For additional commands, e-mail: dev-h...@commons.apache.org
Re: [VOTE] Release Jexl 2.0.1
RC1 was voted out due to packaging errors, RC2 was using a non-standard pom, RC3 is out. JEXL 2.0.1 is a hotfix release correcting a blocker issue. Tag: https://svn.apache.org/repos/asf/commons/proper/jexl/tags/COMMONS_JEXL_2_0_1-RC3 Site: http://people.apache.org/~henrib/jexl-2.0.1-RC3/site/index.html Binaries: http://people.apache.org/~henrib/jexl-2.0.1-RC3/staged [ ] +1 release it [ ] +0 go ahead I don't care [ ] -1 no, do not release it because Votes will close on Tuesday 2010-04-06T22:00+2. Thanks Henrib -- View this message in context: http://n4.nabble.com/VOTE-Release-Jexl-2-0-1-tp1707491p1747185.html Sent from the Commons - Dev mailing list archive at Nabble.com. - To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org For additional commands, e-mail: dev-h...@commons.apache.org
Staging/publishing procedure and tools
I've used the http://wiki.apache.org/commons/CreatingReleases procedure to
release JEXL-2.0 (from Windows, not working on Unix/Mac) and I'm trying to
reuse it for JEXL-2.0.1.
It appears 'mvn -Prc release:perform...' no longer generates the expected
artefacts.
'mvn -Prc release:prepare' happily builds commons-jexl-2.0.1-RC1.jar and
tags COMMONS_JEXL_2_0_1-RC1.
'mvn -Prc release:perform...' insists on creating commons-jexl-2.0.jar
instead of commons-jexl-2.0.1-RC1.jar .
The assembly/{bin,src}.xml seem normal, the pom.xml specifies
commons.release.version2.0.1/commons.release.version and
commons.rc.versionRC1/commons.rc.version.
Tried on WinXP OS X on a fresh m2 repository, same result, no success.
Am I missing an obvious step / doc / procedure ?
Could this be an undetected regression (may be through commons-parent-14)
?
IMHO, our community would benefit from finishing the (designed to be)
automated and reliable publishing process described in the Wiki. Especially
since the manual procedures (
http://commons.apache.org/releases/prepare.html and
http://commons.apache.org/releases/release.html ) are complex and appear to
focus on ant / maven-1 projects. This likely would allow faster/smaller
release cycles and more lively projects.
Anyone else also interested by the topic? I'm no maven plugin expert but
will try to help, test and learn if shown the way.
Best regards,
Henrib
--
View this message in context:
http://n4.nabble.com/Staging-publishing-procedure-and-tools-tp1695256p1695256.html
Sent from the Commons - Dev mailing list archive at Nabble.com.
-
To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
For additional commands, e-mail: dev-h...@commons.apache.org
Re: Staging/publishing procedure and tools
Thank you Rahul; I was able to generate and upload JEXL-2.0.1-RC1. It means the Wiki procedure *does* work on Windows; unfortunately, it also still doesn't on Unix (http://jira.codehaus.org/browse/PLXUTILS-116 ?). I guess that till this is fixed and (doxia-1.1.2?) released, the Wiki procedure will remain 'beta'? -- View this message in context: http://n4.nabble.com/Staging-publishing-procedure-and-tools-tp1695256p1695365.html Sent from the Commons - Dev mailing list archive at Nabble.com. - To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org For additional commands, e-mail: dev-h...@commons.apache.org
[VOTE] Release Jexl 2.0.1
Tag: https://svn.apache.org/repos/asf/commons/proper/jexl/tags/COMMONS_JEXL_2_0_1-RC1 Site: http://people.apache.org/~henrib/jexl-2.0.1-RC1/site/index.html Binaries: http://people.apache.org/~henrib/jexl-2.0.1-RC1/staged [ ] +1 release it [ ] +0 go ahead I don't care [ ] -1 no, do not release it because Votes will close on Friday 2010-04-02T22:00+2. Thanks Henrib -- View this message in context: http://n4.nabble.com/VOTE-Release-Jexl-2-0-1-tp1707491p1707491.html Sent from the Commons - Dev mailing list archive at Nabble.com. - To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org For additional commands, e-mail: dev-h...@commons.apache.org
Is the release process for micro/hotfix releases the same as major ones?
I'm considering releasing JEXL-2.0.1 which corrects 2 bugs; do I have to publish an RC and call vote or is there any expedite process that can be used? Sorry if this is a silly question. Regards, Henrib -- View this message in context: http://n4.nabble.com/Is-the-release-process-for-micro-hotfix-releases-the-same-as-major-ones-tp1694143p1694143.html Sent from the Commons - Dev mailing list archive at Nabble.com. - To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org For additional commands, e-mail: dev-h...@commons.apache.org
Re: svn commit: r927953 - in /commons/proper/jexl/trunk/src/main/java/org/apache/commons/jexl2/parser: ASTIntegerLiteral.java ASTStringLiteral.java
The ctor is called by javacc generated code and I cant think of a way to make it pass the proper argument. -- View this message in context: http://n4.nabble.com/Re-svn-commit-r927953-in-commons-proper-jexl-trunk-src-main-java-org-apache-commons-jexl2-parser-ASTa-tp1692511p1692580.html Sent from the Commons - Dev mailing list archive at Nabble.com. - To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org For additional commands, e-mail: dev-h...@commons.apache.org
Re: [VOTE] Release Jexl 2.0
The result was declared ( http://n4.nabble.com/RESULT-Release-Jexl-2-0-tt1460048.html#a1460048 ) and I attempted to announce the release ( http://n4.nabble.com/ANNOUNCEMENT-Jexl-2-0-released-tt1470182.html#a1470501 ). I've not been able to solve all the noted items yet - in particular the 'Releases and build' link in the web site that reappears when navigating - and still need to rewrite/reformat the announcement. -- View this message in context: http://n4.nabble.com/VOTE-Release-Jexl-2-0-tp1016004p1562863.html Sent from the Commons - Dev mailing list archive at Nabble.com. - To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org For additional commands, e-mail: dev-h...@commons.apache.org
