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...
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
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
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
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 unsubs
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
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
+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.
-
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 agai
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, Templ
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:
{
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-Arr
+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.
-
T
-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
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.
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
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-N
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...
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
on 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 ma
a-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 unsu
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
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.6
+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
+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-commo
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 - D
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 ?
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-JE
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.htm
exity...).
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
+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 S
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
r 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
nents 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
ct; "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:
htt
; 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.
Ins
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
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
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-
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
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-
ng 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-PROCE
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 arch
ement
[-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 th
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
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
-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 a
f
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
+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
mmit 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 th
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 declar
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
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://apach
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-tp4150322p415633
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 annotat
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
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
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 u
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.ht
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 - D
t 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-Jex
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
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.
---
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 wh
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 JexlThreadeAri
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.
---
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
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.
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
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 prepara
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
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 a
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 hum
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 archiv
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.
--
ase.
I'm pretty sure that no active JEXL user would really be bothered by the 2.1
API modifications - and even less so by the binary incompatibility - but I
don't see how the case can be made...
Any hint/advice/idea ?
I've got a migrated-to jexl3 code base ready just in case jexl2 is a
d
s 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 unsubscri
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 t
s 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,
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
ction 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 Nabbl
(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 t
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
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
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 archiv
+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
+1
Thanks for pushing this Sebb, it should make releasing easier.
--
View this message in context:
http://apache-commons.680414.n4.nabble.com/VOTE-Commons-Parent-POM-version-16-tp2278175p2280714.html
Sent from the Commons - Dev mailing list archive at Nabble.com.
--
o 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 con
Thanks for the update; I've been using it to publish JEXL 2.0.1 and things
look good so far - besides my own wrong doings. (I know I'll have to triple
check things though...).
One small thing, when we publish the site, to verify it from Europe, the
proxy IP 209.237.227.195 does not work. (Ping fai
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 co
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
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
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
>> I still think the profile does not belong in the project pom.
>> Just add it to your settings.xml instead.
I cant define the 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,
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
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
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.
-
this future is discussed?
Thanks again,
Henrib
--
View this message in context:
http://n4.nabble.com/Staging-publishing-procedure-and-tools-tp1695256p1745102.html
Sent from the Commons - Dev mailing list archive at Nabble.com.
-
To
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 re
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 wil
1 - 100 of 209 matches
Mail list logo
