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
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
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
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...
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...
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
-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
+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
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
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
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
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:
{
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
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
+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.
-
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
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
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
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
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
(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
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
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
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,
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 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
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
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.
--
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
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
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
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
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
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
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.
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
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.
---
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
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
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.
---
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
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
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
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
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
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
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
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
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
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
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
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
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
+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
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
-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
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
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
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
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
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
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-
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
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-
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
>
>
>> 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
; 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
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
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
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
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
+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
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
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
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
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 ?
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
+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
+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
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
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
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
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.
There are probably too many things I dont know to be able to act as a proper
and efficient RM; I can help though if told what to do (besides bug fixing)
or, if no one else is candidate as RM, I would really appreciate some help
and being 'shown the way'. Reading the procedure is one thing, doing
Rahul Akolkar wrote:
>
>
> Right, its non-trivial (and sometimes multiple votes are needed and
> that requires a lot of patience) but its not all that daunting either.
>
> When I was getting started, I found it best to observe the process
> when someone else more experienced was RM'ing. ATM,
ure what
else I should expect from the tool considering how much has been refactored,
renamed or re-scoped...
3/ On a different note, it would be nice to move Apache Commons on the new
Nabble2
(http://n2.nabble.com/Migrating-forums-from-Nabble1-to-Nabble2-tp3791390p3791390.html)
Regards,
Henrib
--
Vi
ure what
else I should expect from the tool considering how much has been refactored,
renamed or re-scoped...
3/ On a different note, it would be nice to move Apache Commons on the new
Nabble2
(http://n2.nabble.com/Migrating-forums-from-Nabble1-to-Nabble2-tp3791390p3791390.html)
Regards,
Henrib
--
Vi
er) strong concerns
about what has been done so far, please tell me now.
sebb-2-2 wrote:
>
> On 12/11/2009, hen...@apache.org wrote:
>> Author: henrib
>> Date: Thu Nov 12 17:22:06 2009
>> New Revision: 835458
>>
>> URL: http://svn.apache.org/viewvc?rev=
n 12; with
commons-parent version 11, it gets further but stops at:
[ERROR] BUILD FAILURE
...
svn: Commit failed (details follow):
svn: File
'/repos/asf/commons/proper/jexl/tags/JEXL_2_0_RC1/src/main/assembly/src.xml'
already exists
Any hint/advice/help ?
Thanks
Henrib
(PS: for info, Java 5 r
Thanks for the info; not sure how to perform step 5 though...
Trying to cut a release is a tad stressfull for a newbie. :-)
Niall Pemberton-2 wrote:
>
> ...
> 5) Upload the artifacts for review
> ...
>
--
View this message in context:
http://old.nabble.com/Help-cutting-JEXL-2.0-RC1-needed-tp
are a few project that are just going /
went through that process (commons-exec for instance) . Is there anyone
involved willing to share their successful publishing process ?
Many thanks.
Henrib
Phil Steitz wrote:
>
> ...
> I always just tar up the files from /target and ~/.m2/reposi
Good info; will try that.
Thanks
Rahul Akolkar wrote:
>
>
> Perhaps a hint is that the error message seems similar to the one at
> the end of this page (scroll all the way down, see first message in
> "Trouble Shooting"):
>
> http://maven.apache.org/developers/release/apache-release.html
> .
Thanks for the offer; how should/can we proceed so we can capture this info
for the next project release? I'd hate to come back for help again and bug
you all when the release vote goes thru. :-)
Siegfried Goeschl wrote:
>
> Hi Henrib,
>
> if needed I can lend you a hand and
r/jexl/tags/JEXL_2_0_RC1
The source & destination of the svn copy are the same...
I suspect the pom.xml should carry somewhere the 'trunk' information; may be
the should mention the trunk rather than RC1 ?
Hints welcome.
Henrib
--
View this message in context:
http://old.nabble
Using the trunk in the tag and -Dpassword allowed to successfully
prepare!
The release:perform is getting stuck in the deploy:deploy...
Christian Grobmeier wrote:
>
> I think you hould mention the trunk instead of RC1 in the tag - but
> thats just a guess. I had the same idea before a few d
plied the
fix but had also provide the username / password to get it to work.
In the parent pom.xml, I did:
>
> org.apache.maven.plugins
> maven-release-plugin
> 2.0-beta-9
>
> henrib
> mypa
it because...
Thanks to all in advance,
Henrib
--
View this message in context:
http://old.nabble.com/-VOTE--Release-JEXL-2.0-based-on-RC1-tp26362771p26362771.html
Sent from the Commons - Dev mailing list archive at Nabble.com.
-
To u
I'm now able to publish releases but...
'mvn site' locally generates a different version than the one that ends up
being published; the local version does generate the reports menu & seems to
be styled correctly but the published version lacks the reports and styling
is non-existent...
Anyone with
Thanks for the comments.
> Looks like the commons skin is not applied to the above site -- its
> LnF should be similar to the site on c.a.o.
>
I've tried to address the issue and refreshed RC1 but the published site is
not the same as the one I get by generating locally through 'mvn site'.
> Tag looks mainly OK, contents agree with source archive apart from
> doap and STATUS which are in SVN only. PROPOSAL file could probably be
> dropped from source archive too.
>
Paraphrasing, doap and STATUS are not in the source archive; any pointers on
how do I add them ?
> Some of the CSS
1 - 100 of 209 matches
Mail list logo
