date:20111205

Hi Claudio,
what a pleasant surprise! :) I was hoping commons-graph would have
caught the interest of researchers on that field, I'm really happy you
would like to contribute!

I agree with your observations, please fill new issues on JIRA[1] and
feel free to provide patches, I'll process them ASAP :)

Moreover, I start having the feeling the {{WeightedGraph}} is a
useless interface: it is enough marking the vertices/edges as weighted
depending on the problem... or not? At the end of the day,
{{WeightedGraph}} does nothing than having the the edges marked as
weighted, so Dijkstra signature changed as:

V extends Vertex, WE extends WeightedEdge, G extends DirectedGraphV,
WE WeightedPathV, WE findShortestPath( G graph,  V source, V
target )

still define well the input type, a graph wich relations are directed
edges and edges are weighted... WDYT?

Looking forward for your contributions, can't wait for them! :)
Simo

[1] https://issues.apache.org/jira/browse/SANDBOX

http://people.apache.org/~simonetripodi/
http://simonetripodi.livejournal.com/
http://twitter.com/simonetripodi
http://www.99soft.org/



On Mon, Dec 5, 2011 at 2:00 AM, James Carman ja...@carmanconsulting.com wrote:
 Welcome!  Contributions (and the contributor) are always welcome.  In my
 past life, I did quite a bit of graph programming to solve business
 problems.  We used yfiles, though.  I hope to get around to playing with
 [graph] someday too.  Please do submit a patch!
 On Dec 4, 2011 6:43 PM, Claudio Squarcella squar...@dia.uniroma3.it
 wrote:

 Hello,

 I have been reading the source in the past days and I found that the
 concept of weight (e.g. weighted edge, graph, etc) could benefit from a
 bit of abstraction.

 The basic idea would be to have an interface called Weighted with an
 obvious method getWeight(). Changes in the code would easily derive from
 that. As a side effect it would be easy to implement new stuff like
 weighted vertices: not as glorious as weighted edges, but still needed in
 some problems (e.g. all-pairs bottleneck paths) and therefore desirable for
 a general purpose graph API.

 One step further. A weight is not necessarily a double: in some cases not
 even a number, but rather a comparable of some sort. So I would suggest
 to make use of generics in some way, possibly the smartest. Suggestions are
 welcome :-)

 If my thoughts meet some interest I will work on a patch.

 Ciao,
 Claudio


 P.S.
 I am a first-timer here, so what follows is a short introduction.
 I am doing a PhD in Graph Drawing and Information Visualization. I always
 looked for a standard, unified way to represent and handle graphs when
 developing prototypes. So my interest in this project is quite natural, and
 I am willing to help and see it become a robust project.

 --
 Claudio Squarcella
 PhD student at Roma Tre University
 E-mail address: squar...@dia.uniroma3.it
 Phone: +39-06-57333215
 Fax: +39-06-57333612
 http://www.dia.uniroma3.it/~**squarcelhttp://www.dia.uniroma3.it/~squarcel


 --**--**-
 To unsubscribe, e-mail: 
 dev-unsubscribe@commons.**apache.orgdev-unsubscr...@commons.apache.org
 For additional commands, e-mail: dev-h...@commons.apache.org



-
To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
For additional commands, e-mail: dev-h...@commons.apache.org

Re: [math] Inconsistencies (bugs) in PascalDistribution?

2011-12-05 Thread Mikkel Meyer Andersen

2011/12/5 Sébastien Brisard sebastien.bris...@m4x.org:
 Hi Mikkel,

 No, you are more than welcome to do the patch and I'll review it :-). Thanks!

 Cheers, Mikkel.

 I've committed a correction (r1210359). Could you please review it and
 post your comments on the JIRA ticket (MATH-715).
 Thanks a lot!
 Sébastien

Dear Sébastien,

It seems like only the test was changed in r1210359 (svn diff -r
1210359). This does _not_ correspond to the log (svn log -r 1210359).
It seems like the changes was done in r1210358. Is that true? svn log
is empty for r1210358. This is not to bash, but merely to try to
stress the importance of keeping a stringent svn history.

Cheers, Mikkel.

-
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

On 5 December 2011 09:34, henrib hen...@apache.org wrote:
 Sebb;
 Lets not return the pb; Java6 is not downwards compatible with Java 1.5.

Of course not; that's the point.

 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

That is partly why we have CI systems such as Continuum.

 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 ?

Why do you wish to impose a potentially unnecessary compatibily?

 Is there anything
 in the Commons charter that states that obsolete platforms need to be
 deployment targets?

No, but Commons does strive for compatibility as far as possible.

 And IMHO, it is a disservice to the Java community to
 let them run new APIs on Java 1.5 when Java7 is out.

Irrelevant; they can still run any Commons component that targets 1.4
or 1.5 on Java7.

 Finally, do you really need to challenge any change or evolution even when
 not related to stability or quality ?

No, but I think it's necessary to explain why the change in JVM is
necessary for end-users.

The change between 1.4 and 1.5 was much easier to justify, as there
were huge improvements; not least in the memory model.

There are of course improvements in Java 1.6, but they are not of the
same order.

So unless there is a feature in Java 1.6 that is essential for JEXL 3,
then I don't think it's necessary to make Java 1.6 a requirement.

 Will we have to call votes for everything and anything ?

No, but I think it's necessary to justify the change in JVM.

I have yet to see a technical argument why 1.6 is necessary.

 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...

Also see response from Joerg Schaible.

In Commons particularly, it is important to strive for compatibilty.


 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


-
To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
For additional commands, e-mail: dev-h...@commons.apache.org

Re: [math] Inconsistencies (bugs) in PascalDistribution?

2011-12-05 Thread Sébastien Brisard

Hi Mikkel,

 This is not to bash, but merely to try to
 stress the importance of keeping a stringent svn history.

 Cheers, Mikkel.

Thanks for pointing that out. I have run into numerous problems with
SVN this morning, and, although I'm sure I've committed with a log
(it's actually still recorded in eclipse), I would not be surprised if
this log had gone. I will correct that immediately. Thanks again,
Sébastien


-
To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
For additional commands, e-mail: dev-h...@commons.apache.org

Re: [math] Inconsistencies (bugs) in PascalDistribution?

2011-12-05 Thread Sébastien Brisard

Hi Mikkel,
 It seems like only the test was changed in r1210359 (svn diff -r
 1210359). This does _not_ correspond to the log (svn log -r 1210359).

Here is an excerpt of the email sent automatically when I committed
revision 1210359

==BEGIN EXCERPT==
Author: celestin
Date: Mon Dec  5 08:15:38 2011
New Revision: 1210359

URL: http://svn.apache.org/viewvc?rev=1210359view=rev
Log:
- Corrected expressions for mean and variance in
distribution.PascalDistribution (MATH-715).
- Made javadoc more explicit
- Restored SVN properties to various files in package distribution.



Modified: 
commons/proper/math/trunk/src/main/java/org/apache/commons/math/distribution/PascalDistribution.java
URL: 
http://svn.apache.org/viewvc/commons/proper/math/trunk/src/main/java/org/apache/commons/math/distribution/PascalDistribution.java?rev=1210359r1=1210358r2=1210359view=diff
==
--- 
commons/proper/math/trunk/src/main/java/org/apache/commons/math/distribution/PascalDistribution.java
(original)
+++ 
commons/proper/math/trunk/src/main/java/org/apache/commons/math/distribution/PascalDistribution.java
Mon Dec  5 08:15:38 2011
@@ -31,10 +31,25 @@ import org.apache.commons.math.util.Fast
 * /p
 * p
 * There are various ways to express the probability mass and distribution
- * functions for the Pascal distribution.  The convention employed by the
- * library is to express these functions in terms of the number of failures in
- * a Bernoulli experiment
- * (see a 
href=http://en.wikipedia.org/wiki/Negative_binomial_distribution#Waiting_time_in_a_Bernoulli_process;Waiting
Time in a Bernoulli Process/a).
+ * functions for the Pascal distribution. The present implementation represents
+ * the distribution of the number of failures before {@code r} successes occur.
+ * This is the convention adopted in e.g.
+ * a 
href=http://mathworld.wolfram.com/NegativeBinomialDistribution.html;MathWorld/a,
+ * but emnot/em in
+ * a 
href=http://en.wikipedia.org/wiki/Negative_binomial_distribution;Wikipedia/a.
+ * /p
+ * p
+ * For a random variable {@code X} whose values are distributed
according to this
+ * distribution, the probability mass function is given bybr/
+ * {@code P(X = k) = C(k + r - 1, r - 1) * p^r * (1 - p)^k,}br/
+ * where {@code r} is the number of successes, {@code p} is the probability of
+ * success, and {@code X} is the total number of failures. {@code C(n, k)} is
+ * the binomial coefficient ({@code n} choose {@code k}). The mean and variance
+ * of {@code X} arebr/
+ * {@code E(X) = (1 - p) * r / p, var(X) = (1 - p) * r / p^2.}br/
+ * Finally, the cumulative distribution function is given bybr/
+ * {@code P(X = k) = I(p, r, k + 1)},
+ * where I is the regularized incomplete Beta function.
 * /p
 *
 * @see a href=http://en.wikipedia.org/wiki/Negative_binomial_distribution;
@@ -159,25 +174,24 @@ public class PascalDistribution extends
 * {@inheritDoc}
 *
 * For number of successes {@code r} and probability of success {@code p},
- * the mean is {@code (r * p) / (1 - p)}.
+ * the mean is {@code r * (1 - p) / p}.
 */
public double getNumericalMean() {
final double p = getProbabilityOfSuccess();
final double r = getNumberOfSuccesses();
-return (r * p) / (1 - p);
+return (r * (1 - p)) / p;
}

/**
 * {@inheritDoc}
 *
 * For number of successes {@code r} and probability of success {@code p},
- * the variance is {@code (r * p) / (1 - p)^2}.
+ * the variance is {@code r * (1 - p) / p^2}.
 */
public double getNumericalVariance() {
final double p = getProbabilityOfSuccess();
final double r = getNumberOfSuccesses();
-final double pInv = 1 - p;
-return (r * p) / (pInv * pInv);
+return r * (1 - p) / (p * p);
}

==END EXCERPT==

It seems to me that everything (?) is OK?


 It seems like the changes was done in r1210358. Is that true?

I don't think so (see extract below).

==BEGIN EXCERPT==

Author: sgoeschl
Date: Mon Dec  5 08:02:46 2011
New Revision: 1210358

URL: http://svn.apache.org/viewvc?rev=1210358view=rev
Log:
[maven-release-plugin] prepare for next development iteration

Modified:
   commons/proper/email/trunk/pom.xml

==END EXCERPT==

I don't really understand what is happening. I hope I didn't mess up
anything this morning. Please keep me posted.
Sébastien


-
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

On 5 December 2011 10:50, henrib hen...@apache.org wrote:
 Up-coming technical needs requiring Java 6: JSR-269 (apt/annotation
 processing),

JUnit4 relies on annotations, but does not require Java 1.6

 JSR-199 (compiler API).

I think we need a bit more info than that.

What are the new features that will require 1.6?

I'm not saying that the move to 1.6 should not be made; but I'm not
yet convinced that it is strictly necessary.

-
To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
For additional commands, e-mail: dev-h...@commons.apache.org

Re: [Graph] Weighted as an interface

2011-12-05 Thread Claudio Squarcella


Hi,

thanks to both for your words! Please find comments below.

On 05/12/2011 10:01, Simone Tripodi wrote:

Hi Claudio,
what a pleasant surprise! :) I was hoping commons-graph would have
caught the interest of researchers on that field, I'm really happy you
would like to contribute!

I agree with your observations, please fill new issues on JIRA[1] and
feel free to provide patches, I'll process them ASAP :)


Alright, I'll find time later this week.

As for my suggestion on types, should I go for {{WeightedN extends 
Number}}?
Note that I am also concerned about domain-specific requirements (e.g. 
all weights must be positive) that I would like to see implemented as 
statically as possible in the code. {{Number}} should give us quite 
enough freedom in that direction (e.g. one could later extend it with 
something like {{PositiveInteger}}).


A more platonic alternative would be to have an abstract type of weight 
which 1. is comparable and 2. can be aggregated in some way (e.g. the 
weight of a path is the sum of weights of its edges). But I am probably 
going too far...




Moreover, I start having the feeling the {{WeightedGraph}} is a
useless interface: it is enough marking the vertices/edges as weighted
depending on the problem... or not? At the end of the day,
{{WeightedGraph}} does nothing than having the the edges marked as
weighted, so Dijkstra signature changed as:

V extends Vertex, WE extends WeightedEdge, G extends DirectedGraphV,
WE  WeightedPathV, WE  findShortestPath( G graph,  V source, V
target )

still define well the input type, a graph wich relations are directed
edges and edges are weighted... WDYT?


I agree, as long as there are no specific features of the graph that are 
independent on its vertices and edges. Another advantage: I won't bother 
later to add more speficic interfaces like {{EdgeWeightedGraph}} or 
{{VertexWeightedGraph}} ;-)


Ciao,
Claudio



Looking forward for your contributions, can't wait for them! :)
Simo

[1] https://issues.apache.org/jira/browse/SANDBOX

http://people.apache.org/~simonetripodi/
http://simonetripodi.livejournal.com/
http://twitter.com/simonetripodi
http://www.99soft.org/



On Mon, Dec 5, 2011 at 2:00 AM, James Carmanja...@carmanconsulting.com  wrote:

Welcome!  Contributions (and the contributor) are always welcome.  In my
past life, I did quite a bit of graph programming to solve business
problems.  We used yfiles, though.  I hope to get around to playing with
[graph] someday too.  Please do submit a patch!
On Dec 4, 2011 6:43 PM, Claudio Squarcellasquar...@dia.uniroma3.it
wrote:


Hello,

I have been reading the source in the past days and I found that the
concept of weight (e.g. weighted edge, graph, etc) could benefit from a
bit of abstraction.

The basic idea would be to have an interface called Weighted with an
obvious method getWeight(). Changes in the code would easily derive from
that. As a side effect it would be easy to implement new stuff like
weighted vertices: not as glorious as weighted edges, but still needed in
some problems (e.g. all-pairs bottleneck paths) and therefore desirable for
a general purpose graph API.

One step further. A weight is not necessarily a double: in some cases not
even a number, but rather a comparable of some sort. So I would suggest
to make use of generics in some way, possibly the smartest. Suggestions are
welcome :-)

If my thoughts meet some interest I will work on a patch.

Ciao,
Claudio


P.S.
I am a first-timer here, so what follows is a short introduction.
I am doing a PhD in Graph Drawing and Information Visualization. I always
looked for a standard, unified way to represent and handle graphs when
developing prototypes. So my interest in this project is quite natural, and
I am willing to help and see it become a robust project.

--
Claudio Squarcella
PhD student at Roma Tre University
E-mail address: squar...@dia.uniroma3.it
Phone: +39-06-57333215
Fax: +39-06-57333612
http://www.dia.uniroma3.it/~**squarcelhttp://www.dia.uniroma3.it/~squarcel


--**--**-
To unsubscribe, e-mail: 
dev-unsubscribe@commons.**apache.orgdev-unsubscr...@commons.apache.org
For additional commands, e-mail: dev-h...@commons.apache.org



-
To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
For additional commands, e-mail: dev-h...@commons.apache.org



--
Claudio Squarcella
PhD student at Roma Tre University
E-mail address: squar...@dia.uniroma3.it
Phone: +39-06-57333215
Fax: +39-06-57333612
http://www.dia.uniroma3.it/~squarcel


-
To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
For additional commands, e-mail: dev-h...@commons.apache.org

Re: [Graph] Weighted as an interface

Hi Claudio,
so nice to see you are already deep in the spirit of the project! :)

 As for my suggestion on types, should I go for {{WeightedN extends
 Number}}?
 Note that I am also concerned about domain-specific requirements (e.g. all
 weights must be positive) that I would like to see implemented as
 statically as possible in the code. {{Number}} should give us quite enough
 freedom in that direction (e.g. one could later extend it with something
 like {{PositiveInteger}}).

 A more platonic alternative would be to have an abstract type of weight
 which 1. is comparable and 2. can be aggregated in some way (e.g. the weight
 of a path is the sum of weights of its edges). But I am probably going too
 far...



I think that is a valid idea, please don't stop and explore more! ;)


 Moreover, I start having the feeling the {{WeightedGraph}} is a
 useless interface: it is enough marking the vertices/edges as weighted
 depending on the problem... or not? At the end of the day,
 {{WeightedGraph}} does nothing than having the the edges marked as
 weighted, so Dijkstra signature changed as:

 V extends Vertex, WE extends WeightedEdge, G extends DirectedGraphV,
 WE  WeightedPathV, WE  findShortestPath( G graph,  V source, V
 target )

 still define well the input type, a graph wich relations are directed
 edges and edges are weighted... WDYT?


 I agree, as long as there are no specific features of the graph that are
 independent on its vertices and edges. Another advantage: I won't bother
 later to add more speficic interfaces like {{EdgeWeightedGraph}} or
 {{VertexWeightedGraph}} ;-)


+1, please include that in a separate issue!
All the best, have a nice day!
Simo

 Ciao,
 Claudio

http://people.apache.org/~simonetripodi/
http://simonetripodi.livejournal.com/
http://twitter.com/simonetripodi
http://www.99soft.org/

-
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

Re: [jira] [Created] (JEXL-123) Redesign API for stability

On 5 December 2011 13:34, henrib hen...@apache.org wrote:
 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...

In that case, surely the plugin can target Java 1.6?

 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.

Is that going to be part of JEXL itself?
Again, if it is an add-on, that can require 1.6.

-
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)

Salut Henri,

if you need the Java6 APIs to provide a fresh new set of APIs to JEXL
users, I would be +1.
We recently accepted Java6 in Apache Cocoon since Oracle announced
Java 5 SE EOL (End Of Life) since 2009.

Anyway I would to point you to a message in the ASF Tika ML[1] where
describing the pros and cons about moving to Java6 - I wonder how many
users would still require Java4/5 to run JEXL.

Break a leg, all the best,
Simo

[1] http://lucene.472066.n3.nabble.com/support-of-Java-5-td3039517.html

http://people.apache.org/~simonetripodi/
http://simonetripodi.livejournal.com/
http://twitter.com/simonetripodi
http://www.99soft.org/



On Mon, Dec 5, 2011 at 3:17 PM, henrib hen...@apache.org wrote:
 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


-
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)

 [+1] Yes, you may release the next major release of JEXL3 with a Java6
 requirement

I think the maintainers of a component can decide on their own which
jdk they want to support. If you want to support a newer Java with the
next big major version of JEXL I give you my +1. For me a major
version is allowed to break old rules and create new ones.

 PS: Is there a process to formally move a project from Commons to elsewhere
 within Apache?

What exactly do you mean? Make JEXL a top level project or move JEXL
to another toplevel project? Or something completley different?

To move JEXL out of here, i think you should make up a (good) proposal
and vote on this list. I can imagine it would go to the incubator to
build up an community. Anyway I tend to think a component should have
a pretty good size to stand on its own.

Cheers
Christian








 --
 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




-- 
http://www.grobmeier.de
https://www.timeandbill.de

-
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

Henri,

I would love to see this as a Commons recommendation on the Wiki.
As Stefan mentioned, in Compress we have @experimental annons (I
actually added them).
I like the idea to make up a public, rarely to break interface api and
some not so public sometimes to break implementation. Maybe we should
even consider to create an interface jar and an implementation jar of
different versions. On the other hand this makes things complex - but
anyway

Cheers
Christian

On Sun, Dec 4, 2011 at 11:41 AM, henrib hen...@apache.org wrote:
 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




-- 
http://www.grobmeier.de
https://www.timeandbill.de

-
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

+1 Christian this is a nice idea - maybe RetentionPolicy.SOURCE
annotations? (so we don't have to bring the dependency in each
component for runtime...)
Simo

http://people.apache.org/~simonetripodi/
http://simonetripodi.livejournal.com/
http://twitter.com/simonetripodi
http://www.99soft.org/



On Mon, Dec 5, 2011 at 4:21 PM, Christian Grobmeier grobme...@gmail.com wrote:
 Henri,

 I would love to see this as a Commons recommendation on the Wiki.
 As Stefan mentioned, in Compress we have @experimental annons (I
 actually added them).
 I like the idea to make up a public, rarely to break interface api and
 some not so public sometimes to break implementation. Maybe we should
 even consider to create an interface jar and an implementation jar of
 different versions. On the other hand this makes things complex - but
 anyway

 Cheers
 Christian

 On Sun, Dec 4, 2011 at 11:41 AM, henrib hen...@apache.org wrote:
 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




 --
 http://www.grobmeier.de
 https://www.timeandbill.de

 -
 To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
 For additional commands, e-mail: dev-h...@commons.apache.org


-
To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
For additional commands, e-mail: dev-h...@commons.apache.org

Re: [VOTE] Can the next version major version of a project require Java6? (i.e. drop Java 1.5)

Easy one: +1.

Gary

On Mon, Dec 5, 2011 at 10:14 AM, Christian Grobmeier grobme...@gmail.comwrote:

[+1] Yes, you may release the next major release of JEXL3 with a Java6
requirement

I think the maintainers of a component can decide on their own which
jdk they want to support. If you want to support a newer Java with the
next big major version of JEXL I give you my +1. For me a major
version is allowed to break old rules and create new ones.

PS: Is there a process to formally move a project from Commons to
elsewhere
within Apache?

What exactly do you mean? Make JEXL a top level project or move JEXL
to another toplevel project? Or something completley different?

To move JEXL out of here, i think you should make up a (good) proposal
and vote on this list. I can imagine it would go to the incubator to
build up an community. Anyway I tend to think a component should have
a pretty good size to stand on its own.

Cheers
Christian

-
To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
For additional commands, e-mail: dev-h...@commons.apache.org

--
http://www.grobmeier.de
https://www.timeandbill.de

-
To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
For additional commands, e-mail: dev-h...@commons.apache.org

--
E-Mail: garydgreg...@gmail.com | ggreg...@apache.org
JUnit in Action, 2nd Ed: http://goog_1249600977http://bit.ly/ECvg0
Spring Batch in Action: http://s.apache.org/HOqhttp://bit.ly/bqpbCK
Blog: http://garygregory.wordpress.com
Home: http://garygregory.com/
Tweet! http://twitter.com/GaryGregory

Re: [VOTE] Can the next version major version of a project require Java6? (i.e. drop Java 1.5)

On Mon, Dec 5, 2011 at 10:14 AM, Christian Grobmeier grobme...@gmail.comwrote:

[+1] Yes, you may release the next major release of JEXL3 with a Java6
requirement

I agree.

Gary

PS: Is there a process to formally move a project from Commons to
elsewhere
within Apache?

What exactly do you mean? Make JEXL a top level project or move JEXL
to another toplevel project? Or something completley different?

Cheers
Christian

-
To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
For additional commands, e-mail: dev-h...@commons.apache.org

--
http://www.grobmeier.de
https://www.timeandbill.de

-
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

Personally, I do not like annotations to describe the stability of an API.

If it's public I can use it. The next release is binary and/or source
compatible, just document how to migrate. No one is forcing me to upgrade.
If I upgrade, I am using a new pile of code and I must deal with that.

Using .internal packages is an interesting way to go.

But I do like documentation of some kind for things like immutability and
thread-safety.

We've started going down the path of what I call extreme versioning when
we create new packages for new incompatible releases.

Right now, binary incompatible - new package (I'm even going to include
Maven artifact ID noise here).

But what about a change in behavior that is not compatible? Should that not
lead to a new package?

Commons is a 'special' project because it includes so many components. It
would be nice if all components played by the same rules. Strictly
speaking, I think we are bound to do so.

Gary

On Mon, Dec 5, 2011 at 10:21 AM, Christian Grobmeier grobme...@gmail.comwrote:

 Henri,

 I would love to see this as a Commons recommendation on the Wiki.
 As Stefan mentioned, in Compress we have @experimental annons (I
 actually added them).
 I like the idea to make up a public, rarely to break interface api and
 some not so public sometimes to break implementation. Maybe we should
 even consider to create an interface jar and an implementation jar of
 different versions. On the other hand this makes things complex - but
 anyway

 Cheers
 Christian

 On Sun, Dec 4, 2011 at 11:41 AM, henrib hen...@apache.org wrote:
  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
 



 --
 http://www.grobmeier.de
 https://www.timeandbill.de

 -
 To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
 For additional commands, e-mail: dev-h...@commons.apache.org




-- 
E-Mail: garydgreg...@gmail.com | ggreg...@apache.org
JUnit in Action, 2nd Ed: http://goog_1249600977http://bit.ly/ECvg0
Spring Batch in Action: http://s.apache.org/HOqhttp://bit.ly/bqpbCK
Blog: http://garygregory.wordpress.com
Home: http://garygregory.com/
Tweet! http://twitter.com/GaryGregory

Re: [VOTE] Can the next version major version of a project require Java6? (i.e. drop Java 1.5)

On 5 December 2011 15:06, Simone Tripodi simonetrip...@apache.org wrote:
 Salut Henri,

 if you need the Java6 APIs to provide a fresh new set of APIs to JEXL
 users, I would be +1.
 We recently accepted Java6 in Apache Cocoon since Oracle announced
 Java 5 SE EOL (End Of Life) since 2009.

Cocoon is a slightly different case, as it's probably not embedded in
other components as much as Commons components are.

 Anyway I would to point you to a message in the ASF Tika ML[1] where
 describing the pros and cons about moving to Java6 - I wonder how many
 users would still require Java4/5 to run JEXL.

Exactly - but I'm not sure we'll find that out by asking on the
developer list, where one would expect people to install the new
versions of Java as they come out.

If the argument is that Jexl users don't need it to run on Java 1.5,
then a better place to ask the question might be the user list.


 Break a leg, all the best,
 Simo

 [1] http://lucene.472066.n3.nabble.com/support-of-Java-5-td3039517.html

 http://people.apache.org/~simonetripodi/
 http://simonetripodi.livejournal.com/
 http://twitter.com/simonetripodi
 http://www.99soft.org/



 On Mon, Dec 5, 2011 at 3:17 PM, henrib hen...@apache.org wrote:
 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


 -
 To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
 For additional commands, e-mail: dev-h...@commons.apache.org


-
To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
For additional commands, e-mail: dev-h...@commons.apache.org

Re: [VOTE] Can the next version major version of a project require Java6? (i.e. drop Java 1.5)

On Mon, Dec 5, 2011 at 4:31 PM, Gary Gregory garydgreg...@gmail.com wrote:
 On Mon, Dec 5, 2011 at 10:14 AM, Christian Grobmeier 
 grobme...@gmail.comwrote:

  [+1] Yes, you may release the next major release of JEXL3 with a Java6
  requirement

 I think the maintainers of a component can decide on their own which
 jdk they want to support. If you want to support a newer Java with the
 next big major version of JEXL I give you my +1. For me a major
 version is allowed to break old rules and create new ones.


 I agree.

 Gary


me too, that's why I started working on Digester3

-
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)

On Mon, Dec 5, 2011 at 4:43 PM, sebb seb...@gmail.com wrote:
On 5 December 2011 15:06, Simone Tripodi simonetrip...@apache.org wrote:
Salut Henri,

if you need the Java6 APIs to provide a fresh new set of APIs to JEXL
users, I would be +1.
We recently accepted Java6 in Apache Cocoon since Oracle announced
Java 5 SE EOL (End Of Life) since 2009.

Cocoon is a slightly different case, as it's probably not embedded in
other components as much as Commons components are.

Java 5 EOL 2009? Thats 2 years. I mean, we can still make releases of
JEXL 2.x and fix bugs, while the new JEXL 3.x line supports a newer
Java and creates new features. I think this is how most software
vendors do it. Make the old line bugfix only and concentrate on the
new line with current platform.

Anyway I would to point you to a message in the ASF Tika ML[1] where
describing the pros and cons about moving to Java6 - I wonder how many
users would still require Java4/5 to run JEXL.

Exactly - but I'm not sure we'll find that out by asking on the
developer list, where one would expect people to install the new
versions of Java as they come out.

If the argument is that Jexl users don't need it to run on Java 1.5,
then a better place to ask the question might be the user list.

Jexl users in need of 1.5 can still use the 2.x line. Where is the problem?
If we always ask about every of our steps we will never go forward.

Cheers

Break a leg, all the best,
Simo

[1] http://lucene.472066.n3.nabble.com/support-of-Java-5-td3039517.html

http://people.apache.org/~simonetripodi/
http://simonetripodi.livejournal.com/
http://twitter.com/simonetripodi
http://www.99soft.org/

On Mon, Dec 5, 2011 at 3:17 PM, henrib hen...@apache.org wrote:
Sorry to bug everyone again, I'm hopelessly trying to make Commons move a
little forward...

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?

-
To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
For additional commands, e-mail: dev-h...@commons.apache.org

--
http://www.grobmeier.de
https://www.timeandbill.de

-
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: [VOTE] Can the next version major version of a project require Java6? (i.e. drop Java 1.5)

http://people.apache.org/~simonetripodi/
http://simonetripodi.livejournal.com/
http://twitter.com/simonetripodi
http://www.99soft.org/



On Mon, Dec 5, 2011 at 4:43 PM, sebb seb...@gmail.com wrote:
 On 5 December 2011 15:06, Simone Tripodi simonetrip...@apache.org wrote:
 Salut Henri,

 if you need the Java6 APIs to provide a fresh new set of APIs to JEXL
 users, I would be +1.
 We recently accepted Java6 in Apache Cocoon since Oracle announced
 Java 5 SE EOL (End Of Life) since 2009.

 Cocoon is a slightly different case, as it's probably not embedded in
 other components as much as Commons components are.


nope, new Cocoon3 has small commons components as well that allow
users embed it in a commons-xxx style, take a look at Christian's
experience on his blog post[1]

 Anyway I would to point you to a message in the ASF Tika ML[1] where
 describing the pros and cons about moving to Java6 - I wonder how many
 users would still require Java4/5 to run JEXL.

 Exactly - but I'm not sure we'll find that out by asking on the
 developer list, where one would expect people to install the new
 versions of Java as they come out.

 If the argument is that Jexl users don't need it to run on Java 1.5,
 then a better place to ask the question might be the user list.


agreed, but I guess HenriB concern is on dev side as well, the
implicit question sounds clear to me: is there any objection in the
dev community?

-Simo

[1] http://www.grobmeier.de/create-pdf-cocoon-3-struts-2-15112011.html

-
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 Gary!

On Mon, Dec 5, 2011 at 4:42 PM, Gary Gregory garydgreg...@gmail.com wrote:
 Personally, I do not like annotations to describe the stability of an API.

 If it's public I can use it. The next release is binary and/or source
 compatible, just document how to migrate. No one is forcing me to upgrade.
 If I upgrade, I am using a new pile of code and I must deal with that.

 Using .internal packages is an interesting way to go.


interesting stuff as well - I learnt a trick from Google Guice team
that developed internal stuff only[1] and then obfuscate[2] them in
the way most ides won't recognize for code completion, so users cannot
rely on internal APIs :P
I personally think that is a valid approach, just my 0.02 cents,
-Simo

[1] http://s.apache.org/dt7
[2] http://s.apache.org/yC

http://people.apache.org/~simonetripodi/
http://simonetripodi.livejournal.com/
http://twitter.com/simonetripodi
http://www.99soft.org/

-
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

On 5 December 2011 15:42, Gary Gregory garydgreg...@gmail.com wrote:
 Personally, I do not like annotations to describe the stability of an API.

 If it's public I can use it. The next release is binary and/or source
 compatible, just document how to migrate. No one is forcing me to upgrade.

If your component is part of a larger application that may not be
true, see below.

 If I upgrade, I am using a new pile of code and I must deal with that.

That's OK if your code is stand-alone at the end of the food chain,
and you have control over it.

Commons components often are deeply embedded.

 Using .internal packages is an interesting way to go.

 But I do like documentation of some kind for things like immutability and
 thread-safety.

 We've started going down the path of what I call extreme versioning when
 we create new packages for new incompatible releases.

 Right now, binary incompatible - new package (I'm even going to include
 Maven artifact ID noise here).

See below for the reason why that is generally necessary.

 But what about a change in behavior that is not compatible? Should that not
 lead to a new package?

Depends why the behaviour changed. Is it a bug fix?

 Commons is a 'special' project because it includes so many components. It
 would be nice if all components played by the same rules. Strictly
 speaking, I think we are bound to do so.

I would say the Commons components are special because they are likely
to be deeply nested in applications, with many other components
depending on them.

It may not be possible to upgrade the other components all at once.
Some may be impossible to replace.
If two components in the same classpath need incompatible versions, it
will in general be impossible to update unless the two versions can
coexist.

That is why we have the rules on package/Maven id changes, so there
can be multiple versions of a Commons component on the same classpath,
if the need arises.

Because package changes are expensive to end users, we try to avoid
them if at all possible.

That is why it's worth striving for binary compatibility.

 Gary

 On Mon, Dec 5, 2011 at 10:21 AM, Christian Grobmeier 
 grobme...@gmail.comwrote:

 Henri,

 I would love to see this as a Commons recommendation on the Wiki.
 As Stefan mentioned, in Compress we have @experimental annons (I
 actually added them).
 I like the idea to make up a public, rarely to break interface api and
 some not so public sometimes to break implementation. Maybe we should
 even consider to create an interface jar and an implementation jar of
 different versions. On the other hand this makes things complex - but
 anyway

 Cheers
 Christian

 On Sun, Dec 4, 2011 at 11:41 AM, henrib hen...@apache.org wrote:
  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
 



 --
 http://www.grobmeier.de
 https://www.timeandbill.de

 -
 To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
 For additional commands, e-mail: dev-h...@commons.apache.org




 --
 E-Mail: garydgreg...@gmail.com | ggreg...@apache.org
 JUnit in Action, 2nd Ed: http://goog_1249600977http://bit.ly/ECvg0
 Spring Batch in Action: http://s.apache.org/HOqhttp://bit.ly/bqpbCK
 Blog: http://garygregory.wordpress.com
 Home: http://garygregory.com/
 Tweet! http://twitter.com/GaryGregory

-
To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
For additional commands, e-mail: dev-h...@commons.apache.org

Re: [RELEASE PROCESS] Stability versus usability

On Mon, Dec 5, 2011 at 4:42 PM, Gary Gregory garydgreg...@gmail.com wrote:
 Personally, I do not like annotations to describe the stability of an API.

 If it's public I can use it. The next release is binary and/or source
 compatible, just document how to migrate. No one is forcing me to upgrade.
 If I upgrade, I am using a new pile of code and I must deal with that.

 Using .internal packages is an interesting way to go.

It is fine, using annotations is not really a must have for me. I
think similar stuff like .internal do the Cayenne developers.

 But I do like documentation of some kind for things like immutability and
 thread-safety.

+1

 We've started going down the path of what I call extreme versioning when
 we create new packages for new incompatible releases.

 Right now, binary incompatible - new package (I'm even going to include
 Maven artifact ID noise here).

 But what about a change in behavior that is not compatible? Should that not
 lead to a new package?

Honestly, no clue.

What do you think on making up some good interfaces for a components.
For example, a Compress interface set for version 1. If we decide to
change something, no problem - interfaces stay the same. When the
interfaces change, the version number changes and this will probably
lead to a packagename change.

I would hate to see o.a.c.compress_2_1.bla btw. ;-)

 Commons is a 'special' project because it includes so many components. It
 would be nice if all components played by the same rules. Strictly
 speaking, I think we are bound to do so.

Very much +1. There are so many differences. As a user I am totally
lost on all the different things people do.

Cheers


 Gary

 On Mon, Dec 5, 2011 at 10:21 AM, Christian Grobmeier 
 grobme...@gmail.comwrote:

 Henri,

 I would love to see this as a Commons recommendation on the Wiki.
 As Stefan mentioned, in Compress we have @experimental annons (I
 actually added them).
 I like the idea to make up a public, rarely to break interface api and
 some not so public sometimes to break implementation. Maybe we should
 even consider to create an interface jar and an implementation jar of
 different versions. On the other hand this makes things complex - but
 anyway

 Cheers
 Christian

 On Sun, Dec 4, 2011 at 11:41 AM, henrib hen...@apache.org wrote:
  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
 



 --
 http://www.grobmeier.de
 https://www.timeandbill.de

 -
 To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
 For additional commands, e-mail: dev-h...@commons.apache.org




 --
 E-Mail: garydgreg...@gmail.com | ggreg...@apache.org
 JUnit in Action, 2nd Ed: http://goog_1249600977http://bit.ly/ECvg0
 Spring Batch in Action: http://s.apache.org/HOqhttp://bit.ly/bqpbCK
 Blog: http://garygregory.wordpress.com
 Home: http://garygregory.com/
 Tweet! http://twitter.com/GaryGregory



-- 
http://www.grobmeier.de
https://www.timeandbill.de

-
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)

2011-12-05 Thread ralph.goers @dslextreme.com

+1 to the proposal.

As for moving out of commons I would expect that it would require a vote of
the Commons PMC with approval from the board. I don't know why it would
need to go through the incubator since it would have already performed
releases here, its IP would already be cleared and presumably we would only
make the proposal if it already had a community of its own.

Ralph

On Mon, Dec 5, 2011 at 6:17 AM, henrib hen...@apache.org wrote:

Sorry to bug everyone again, I'm hopelessly trying to make Commons move a
little forward...

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).

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?

-
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)

On 5 December 2011 16:46, henrib hen...@apache.org wrote:
 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 ?

That is not a question I can answer, because it's not a simple
dichotomy (if that's the correct word).

It's not my view that all Commons components have to remain on 1.5
until no-one else is using that release.
Nor is it my view that all Commons components should immediately be
able to switch to 1.6.

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.

I've yet to see that argument put forward; nor has anyone produced
evidence that Java 1.5 is not still being used in production across
the user base.



 --
 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


-
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)

On Mon, Dec 5, 2011 at 6:44 PM, ralph.goers @dslextreme.com
ralph.go...@dslextreme.com wrote:
+1 to the proposal.

I said it only because of the community building aspect. A new tld
would be required and a working PMC must be setup. If this is would be
clear from the beginning I agree. Actually if this step would be
required, I would try to avoid the incubator as much as I can

Ralph

On Mon, Dec 5, 2011 at 6:17 AM, henrib hen...@apache.org wrote:

Sorry to bug everyone again, I'm hopelessly trying to make Commons move a
little forward...

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).

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?

-
To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
For additional commands, e-mail: dev-h...@commons.apache.org

--
http://www.grobmeier.de
https://www.timeandbill.de

-
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)

On Mon, Dec 5, 2011 at 6:51 PM, sebb seb...@gmail.com wrote:
On 5 December 2011 16:46, henrib hen...@apache.org wrote:
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 ?

That is not a question I can answer, because it's not a simple
dichotomy (if that's the correct word).

It's not my view that all Commons components have to remain on 1.5
until no-one else is using that release.
Nor is it my view that all Commons components should immediately be
able to switch to 1.6.

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.

I've yet to see that argument put forward; nor has anyone produced
evidence that Java 1.5 is not still being used in production across
the user base.

Hey what is wrong with doing jexl3 with Java 6?
Why do we need to satisfy to use current technology (guess its already
j7 out there)?
I mean, the proposal is to upgrade the requirements with a version bump.

What is the problem with:
- Jexl 2 going maintenance and bugfix mode only, using j5
- Jexl 3 going to have j6 (to the joy of its developers) and doing all
the new fancy stuff

I do not think we have to clarify why we go to j6, we have to clarify
why we still stick to j5 when we do a major version bump.

Probably there is need for j5 software - these users can benefit from
jexl2. If maintenance mode is not enough I ask myself why we don't
still support Java 1.4. I mean, recently I saw it live (guess, at a
bank).

Imho Commons must not always be the most conservative place ever. We
should progress a little more or after all we have only the banks as
users, because the modern guys go with all that modern stuff.

Of course if you volunteer to migrate all the jexl3 things to jexl2,
please go ahead and do it. But this should not force Henri to develop
in j6. I mean one team, one dream, but how can you attract new
developers with java5 nowadays?

Cheers

--
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

--
http://www.grobmeier.de
https://www.timeandbill.de

-
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)

2011-12-05 Thread ralph.goers @dslextreme.com

FWIW, I have been planning on starting work on vfs3 when I finish up with
some other stuff. VFS3 will require Java 7 as Java 7 provides virtual file
support, so vfs3 will be slimmed down to just provide implementations.

Ralph

On Mon, Dec 5, 2011 at 9:51 AM, sebb seb...@gmail.com wrote:

On 5 December 2011 16:46, henrib hen...@apache.org wrote:
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 ?

That is not a question I can answer, because it's not a simple
dichotomy (if that's the correct word).

It's not my view that all Commons components have to remain on 1.5
until no-one else is using that release.
Nor is it my view that all Commons components should immediately be
able to switch to 1.6.

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.

I've yet to see that argument put forward; nor has anyone produced
evidence that Java 1.5 is not still being used in production across
the user base.

--
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)

On 5 December 2011 18:30, ralph.goers @dslextreme.com
ralph.go...@dslextreme.com wrote:
FWIW, I have been planning on starting work on vfs3 when I finish up with
some other stuff. VFS3 will require Java 7 as Java 7 provides virtual file
support, so vfs3 will be slimmed down to just provide implementations.

That's again a bit different.

VFS3 will effectively then be a different component, addressing a
completely different user base.

Ralph

On Mon, Dec 5, 2011 at 9:51 AM, sebb seb...@gmail.com wrote:

That is not a question I can answer, because it's not a simple
dichotomy (if that's the correct word).

It's not my view that all Commons components have to remain on 1.5
until no-one else is using that release.
Nor is it my view that all Commons components should immediately be
able to switch to 1.6.

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.

I've yet to see that argument put forward; nor has anyone produced
evidence that Java 1.5 is not still being used in production across
the user base.

--
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)

On 5 December 2011 18:10, henrib hen...@apache.org wrote:

 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...

No, I don't consider that a valid reason on its own.

 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.

Indeed, ideally everyone would now be using Java 6 and Windows users
should all upgrade to Windows 7 etc.

But that is a separate issue.

-
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)

On Mon, Dec 5, 2011 at 7:38 PM, sebb seb...@gmail.com wrote:
 On 5 December 2011 18:10, henrib hen...@apache.org wrote:
 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...

 No, I don't consider that a valid reason on its own.

Committing should be fun. If one does not want to support JDK 1.5 he
goes away. Henri seems as he does not want and would like to put
effort in a more modern environment. In addition, how many people can
you attract with a JDK 1.5 version to contribute? For me this is valid
reason.

 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.

 Indeed, ideally everyone would now be using Java 6 and Windows users
 should all upgrade to Windows 7 etc.

 But that is a separate issue.

No it is not.

It seems you ignore my idea on having jexl2 in maintenance mode, but
this is actually what MS did with Win XP. Now they don't support it. I
ask myself, why do we need to support outdated jdks until all
committers are gone away or the library is the outdated people get
some fresher stuff (Collections vs Guava)?

If Henri is the opinion that people should use jdk6 he should be
allowed to create such a version and call it Jexl3.
If you want to keep a jdk5 version, you are of course allowed to
support that one.

Cheers
Christian


 -
 To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
 For additional commands, e-mail: dev-h...@commons.apache.org




-- 
http://www.grobmeier.de
https://www.timeandbill.de

-
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 think all that Sebastian is saying is something like if you can
create your new, cool API and the only things you really miss from
Java 6 are @Override on interface implementation methods and
ServiceLoader, for example, maybe it's worth that tiny bit of extra
pain to reach that slightly larger audience.  We all feel frustrated
from time to time working in the community setting; I've been there
myself, but I don't think Seb is just trying to be a killjoy just for
the hell of it.

Matt

On Mon, Dec 5, 2011 at 1:13 PM, Christian Grobmeier grobme...@gmail.com wrote:
 On Mon, Dec 5, 2011 at 7:38 PM, sebb seb...@gmail.com wrote:
 On 5 December 2011 18:10, henrib hen...@apache.org wrote:
 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...

 No, I don't consider that a valid reason on its own.

 Committing should be fun. If one does not want to support JDK 1.5 he
 goes away. Henri seems as he does not want and would like to put
 effort in a more modern environment. In addition, how many people can
 you attract with a JDK 1.5 version to contribute? For me this is valid
 reason.

 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.

 Indeed, ideally everyone would now be using Java 6 and Windows users
 should all upgrade to Windows 7 etc.

 But that is a separate issue.

 No it is not.

 It seems you ignore my idea on having jexl2 in maintenance mode, but
 this is actually what MS did with Win XP. Now they don't support it. I
 ask myself, why do we need to support outdated jdks until all
 committers are gone away or the library is the outdated people get
 some fresher stuff (Collections vs Guava)?

 If Henri is the opinion that people should use jdk6 he should be
 allowed to create such a version and call it Jexl3.
 If you want to keep a jdk5 version, you are of course allowed to
 support that one.

 Cheers
 Christian


 -
 To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
 For additional commands, e-mail: dev-h...@commons.apache.org




 --
 http://www.grobmeier.de
 https://www.timeandbill.de

 -
 To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
 For additional commands, e-mail: dev-h...@commons.apache.org


-
To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
For additional commands, e-mail: dev-h...@commons.apache.org

Re: [VOTE] 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)

On Mon, Dec 5, 2011 at 8:22 PM, Matt Benson gudnabr...@gmail.com wrote:
 I think all that Sebastian is saying is something like if you can
 create your new, cool API and the only things you really miss from
 Java 6 are @Override on interface implementation methods and
 ServiceLoader, for example, maybe it's worth that tiny bit of extra
 pain to reach that slightly larger audience.  We all feel frustrated
 from time to time working in the community setting; I've been there
 myself, but I don't think Seb is just trying to be a killjoy just for
 the hell of it.

Yes, you might be right on this interpretation.

As long as there a volunteers for maintaining jexl2 on j5 setting, I
am fine with keeping j5 for it. To be clear, I am not saying we kill
jexl2 today or quit jdk5 support for jexl2.

But we should not make it a policy to start a new, major version with
the lowest JDK version possible when the actual maintainers would like
to use a current platform - this needs no discussion imho, they should
simply do as they please.

Cheers


 Matt

 On Mon, Dec 5, 2011 at 1:13 PM, Christian Grobmeier grobme...@gmail.com 
 wrote:
 On Mon, Dec 5, 2011 at 7:38 PM, sebb seb...@gmail.com wrote:
 On 5 December 2011 18:10, henrib hen...@apache.org wrote:
 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...

 No, I don't consider that a valid reason on its own.

 Committing should be fun. If one does not want to support JDK 1.5 he
 goes away. Henri seems as he does not want and would like to put
 effort in a more modern environment. In addition, how many people can
 you attract with a JDK 1.5 version to contribute? For me this is valid
 reason.

 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.

 Indeed, ideally everyone would now be using Java 6 and Windows users
 should all upgrade to Windows 7 etc.

 But that is a separate issue.

 No it is not.

 It seems you ignore my idea on having jexl2 in maintenance mode, but
 this is actually what MS did with Win XP. Now they don't support it. I
 ask myself, why do we need to support outdated jdks until all
 committers are gone away or the library is the outdated people get
 some fresher stuff (Collections vs Guava)?

 If Henri is the opinion that people should use jdk6 he should be
 allowed to create such a version and call it Jexl3.
 If you want to keep a jdk5 version, you are of course allowed to
 support that one.

 Cheers
 Christian


 -
 To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
 For additional commands, e-mail: dev-h...@commons.apache.org




 --
 http://www.grobmeier.de
 https://www.timeandbill.de

 -
 To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
 For additional commands, e-mail: dev-h...@commons.apache.org


 -
 To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
 For additional commands, e-mail: dev-h...@commons.apache.org




-- 
http://www.grobmeier.de
https://www.timeandbill.de

-
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)

On 5 December 2011 19:01, henrib hen...@apache.org wrote:

 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...

No, I would not; that's an end-user product.


 --
 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


-
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

[VOTE][email] Release Commons Email 1.3 based on RC2

2011-12-05 Thread Siegfried Goeschl


Hi folks,

I would like to call a vote to release commons-email-1.3 which contains 
the following bug fixes and improvements found here


http://people.apache.org/builds/commons/email/1.3/RC2/site/changes-report.html

Tag:

https://svn.apache.org/repos/asf/commons/proper/email/tags/EMAIL_1_3_RC2

Site:

http://people.apache.org/builds/commons/email/1.3/RC2/site/index.html

Binaries:

http://people.apache.org/builds/commons/email/1.3/RC2/staged/org/apache/commons/commons-email/1.3/

[ ] +1 release it
[ ] +0 go ahead I don't care
[ ] -1 no, do not release it because

Thanks in advance

Siegfried Goeschl

-
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)

On Mon, Dec 5, 2011 at 1:39 PM, Christian Grobmeier grobme...@gmail.com wrote:
 On Mon, Dec 5, 2011 at 8:22 PM, Matt Benson gudnabr...@gmail.com wrote:
 I think all that Sebastian is saying is something like if you can
 create your new, cool API and the only things you really miss from
 Java 6 are @Override on interface implementation methods and
 ServiceLoader, for example, maybe it's worth that tiny bit of extra
 pain to reach that slightly larger audience.  We all feel frustrated
 from time to time working in the community setting; I've been there
 myself, but I don't think Seb is just trying to be a killjoy just for
 the hell of it.

 Yes, you might be right on this interpretation.

 As long as there a volunteers for maintaining jexl2 on j5 setting, I
 am fine with keeping j5 for it. To be clear, I am not saying we kill
 jexl2 today or quit jdk5 support for jexl2.

 But we should not make it a policy to start a new, major version with
 the lowest JDK version possible when the actual maintainers would like
 to use a current platform - this needs no discussion imho, they should
 simply do as they please.

I agree that the developers of a component should do as they
[collectively] please.  However, in the case of [jexl] it appears that
Seb is interested in the development of this component.  He may
continue to be interested in the development of a v3.x of [jexl].  Now
we don't have as clear-cut a case of do-ocracy and henrib just doing
what he pleases anymore, because he has to do instead as near as he
can get to what he pleases while still functioning in a
consensus-based manner.  A possible sequence of events:

  - henrib proposes that [jexl] include feature X, using feature Y
from Java 6, thus justifying this minimum version.  Assuming the
community doesn't vote down the feature on its own merits, Java 6 it
is.
 - sebb can then come along say, hey, I know we agreed on feature X,
but I can put in 4 hours of work or create a new Commons component to
reimplement feature Y, and now Java 5 users can also benefit from
[jexl] 3!

Assuming someone else is willing to do the *actual* work required to
keep Java 5 compatibility, are you really going to spend time and
energy fighting for interface @Overrides?  Obviously there would
probably be some point at which Seb in this example would say, sure, I
could reimplement feature Y, but it's going to take ten hours, twenty
hours.  Not worth it; have your Java 6!

This is the way I see our community as having to function.

Matt


 Cheers


 Matt

 On Mon, Dec 5, 2011 at 1:13 PM, Christian Grobmeier grobme...@gmail.com 
 wrote:
 On Mon, Dec 5, 2011 at 7:38 PM, sebb seb...@gmail.com wrote:
 On 5 December 2011 18:10, henrib hen...@apache.org wrote:
 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...

 No, I don't consider that a valid reason on its own.

 Committing should be fun. If one does not want to support JDK 1.5 he
 goes away. Henri seems as he does not want and would like to put
 effort in a more modern environment. In addition, how many people can
 you attract with a JDK 1.5 version to contribute? For me this is valid
 reason.

 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.

 Indeed, ideally everyone would now be using Java 6 and Windows users
 should all upgrade to Windows 7 etc.

 But that is a separate issue.

 No it is not.

 It seems you ignore my idea on having jexl2 in maintenance mode, but
 this is actually what MS did with Win XP. Now they don't support it. I
 ask myself, why do we need to support outdated jdks until all
 committers are gone away or the library is the outdated people get
 some fresher stuff (Collections vs Guava)?

 If Henri is the opinion that people should use jdk6 he should be
 allowed to create such a version and call it Jexl3.
 If you want to keep a jdk5 version, you are of course allowed to
 support that one.

 Cheers
 Christian


 -
 To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
 For additional commands, e-mail: dev-h...@commons.apache.org




 --
 http://www.grobmeier.de
 https://www.timeandbill.de

 -
 To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
 For additional commands,

Re: [VOTE][Codec] Release Commons Codec 1.6-RC2 REDUX

On Sun, Dec 4, 2011 at 3:24 PM, Oliver Heger
oliver.he...@oliver-heger.dewrote:

 Am 03.12.2011 22:14, schrieb Gary Gregory:

 On Sat, Dec 3, 2011 at 3:14 PM, Oliver Heger
 oliver.he...@oliver-heger.de**wrote:

  Am 03.12.2011 17:18, schrieb Gary Gregory:

  On Sat, Dec 3, 2011 at 5:45 AM, Oliver Heger
 oliver.he...@oliver-heger.dewrote:


  When building I get a heap space error in testSpeedCheck(org.apache.**

 commons.codec.language.bm.**BeiderMorseEncoderTest), even when
 setting


 MAVEN_OPTS=-Xmx1024m. I remember there was discussion about this for
 the
 last RC. Which amount of memory is required?


  Try bumping up your MaxPermSize, for example:

 MAVEN_OPTS=-XX:MaxPermSize=256m -Xmx1024m


 No luck either. As the error message indicates, the problem really seems
 to be related to heap size (AFAIK you get a specific perm gen error
 message
 otherwise). I get the same error message up to 1400 MB heap space.
 Unfortunately, I cannot increase my heap size beyond this value because I
 reach the limit of my physical memory. For a unit test these seem to be
 tough requirements.


 If I turn /off/ MAVEN_OPTS (set MAVEN_OPTS=) it still works for me, so
 that's good. I tied the 'mvn test' and 'mvn site'.

 After running site, Maven reports:

 [INFO] Final Memory: 43M/143M


 Did some more testing: the build runs fine for me with Java 1.6, but the
 heap space error occurs on Java 1.5 (on Windows 7). Any idea what could be
 the source of this problem?


I am good on Java 5 and Windows 7, so I am not sure how to help here.

[INFO]

[INFO] BUILD SUCCESS
[INFO]

[INFO] Total time: 45.467s
[INFO] Finished at: Mon Dec 05 16:59:48 EST 2011
[INFO] Final Memory: 15M/65M
[INFO]

C:\temp\codecm3 -version
Apache Maven 3.0.3 (r1075438; 2011-02-28 12:31:09-0500)
Maven home: C:\Java\apache-maven-3.0.3\bin\..
Java version: 1.5.0_22, vendor: Sun Microsystems Inc.
Java home: C:\Program Files\Java\jdk1.5.0_22\jre
Default locale: en_US, platform encoding: Cp1252
OS name: windows 7, version: 6.1, arch: amd64, family: windows

Gary


 Oliver


 Gary



 Oliver


  Gary



  Otherwise, I did not find major problems. The site has two checkstyle
 links: one is clean, the other contains errors.

 Oliver

 Am 03.12.2011 04:06, schrieb Gary Gregory:

  Good day to you all:


 I have prepared Commons Codec 1.6-RC2, again, per Sebb's suggestion. I
 am
 not calling it RC3 because there are no changes in source files from
 the
 last RC. The only difference is that I built from a fresh checkout of
 the
 RC2 svn tag.

 The changes from RC1 are what Sebb found:
 - EOL in sources
 - Cruft from a dirty build, so I built this RC as I should have the
 first
 time around with:
 - mvn clean
 - mvn deploy -Prelease

 Tag:

 https://svn.apache.org/repos/**asf/commons/proper/codec/
 tags/**https://svn.apache.org/repos/asf/commons/proper/codec/**tags/**
 https://svn.apache.**org/repos/**asf/commons/**proper/codec/tags/**https://svn.apache.org/repos/**asf/commons/proper/codec/tags/**
 
 commons-codechttps://svn.**ap**ache.org/repos/asf/commons/**http://apache.org/repos/asf/commons/**
 proper/codec/tags/commons-codechttps://svn.apache.org/**
 repos/asf/commons/proper/**codec/tags/commons-codechttps://svn.apache.org/repos/asf/commons/proper/codec/tags/commons-codec
 


  -1.6-RC2

 Site:

 https://people.apache.org/**builds/commons/codec/1.6/RC2/https://people.apache.org/builds/commons/codec/1.6/RC2/
 **https://people.apache.org/builds/commons/codec/1.6/RC2/https://people.apache.org/**builds/commons/codec/1.6/RC2/
 
 **https://people.apache.org/builds/commons/codec/1.6/RC2/https://people.apache.org/**builds/commons/codec/1.6/RC2/
 **https://people.apache.org/**builds/commons/codec/1.6/RC2/https://people.apache.org/builds/commons/codec/1.6/RC2/
 



 Binaries:

 https://repository.apache.**org/content/repositories/**
 orgapachecommons-224/https://repository.apache.org/**content/**http://repository.apache.org/content/**
 repositories/orgapachecommons-224/https://repository.**
 apache.org/content/**repositories/orgapachecommons-**224/https://repository.apache.org/content/repositories/orgapachecommons-224/
 





  
 https://repository.apache.org/**content/repositories/**https://repository.apache.org/content/repositories/**
 ht**tps://repository.apache.org/content/repositories/**https://repository.apache.org/**content/repositories/**
 
 orgapachecommons-290/https://repository.apache.org/**content/**http://repository.apache.org/content/**
 repositories/orgapachecommons-290/https://repository.**
 apache.org/content/**repositories/orgapachecommons-**290/https://repository.apache.org/content/repositories/orgapachecommons-290/
 




 The link above includes checksum

Re: [VOTE][Codec] Release Commons Codec 1.6-RC2 REDUX

My +1.

Gary

On Fri, Dec 2, 2011 at 10:06 PM, Gary Gregory ggreg...@apache.org wrote:

 Good day to you all:

 I have prepared Commons Codec 1.6-RC2, again, per Sebb's suggestion. I am
 not calling it RC3 because there are no changes in source files from the
 last RC. The only difference is that I built from a fresh checkout of the
 RC2 svn tag.

 The changes from RC1 are what Sebb found:
 - EOL in sources
 - Cruft from a dirty build, so I built this RC as I should have the first
 time around with:
 - mvn clean
 - mvn deploy -Prelease

 Tag:

 https://svn.apache.org/repos/asf/commons/proper/codec/tags/commons-codec
 -1.6-RC2

 Site:

 https://people.apache.org/builds/commons/codec/1.6/RC2/

 Binaries:

 https://repository.apache.org/content/repositories/orgapachecommons-224/
 https://repository.apache.org/content/repositories/orgapachecommons-290/

 The link above includes checksum files.

 [ ] +1 release it
 [ ] +0 go ahead, I cannot take the time
 [ ] -1 no, do not release it because:

 This VOTE is open for 72 hours, until November 23 2011, 14:00 EST.

 Fixed Bugs:
 o Use standard Maven directory layout.  Issue: CODEC-129. Thanks to
 ggregory.
 o Documentation spelling fixes.  Issue: CODEC-128. Thanks 
 toville.sky...@iki.fi
 .
 o Fix various character encoding issues in comments and test cases.
 Issue: CODEC-127.
 o ColognePhonetic Javadoc should use HTML entities for special characters.
 Issue: CODEC-123.

 Changes:
 o Implement a Beider-Morse phonetic matching codec.  Issue: CODEC-125.
 Thanks to Matthew Pocock.
 o Migrate to Java 5.  Issue: CODEC-119.
 o Migrate to JUnit 4.  Issue: CODEC-120.

 Heads up: the Beider-Morse encoder tests take a long time to run (5
 minutes). The code has been optimized.

 Thank you,
 Gary

 --
 E-Mail: garydgreg...@gmail.com | ggreg...@apache.org
 JUnit in Action, 2nd Ed: http://bit.ly/ECvg0
 Spring Batch in Action: http://bit.ly/bqpbCK
 Blog: http://garygregory.wordpress.com
 Home: http://garygregory.com/
 Tweet! http://twitter.com/GaryGregory http://twitter.com/GaryGregory




-- 
E-Mail: garydgreg...@gmail.com | ggreg...@apache.org
JUnit in Action, 2nd Ed: http://goog_1249600977http://bit.ly/ECvg0
Spring Batch in Action: http://s.apache.org/HOqhttp://bit.ly/bqpbCK
Blog: http://garygregory.wordpress.com
Home: http://garygregory.com/
Tweet! http://twitter.com/GaryGregory

Re: [VOTE][email] Release Commons Email 1.3 based on RC2

Hi Siegfried:

Thank you for preparing the RC.

This /sounds/ worrisome from RAT:

Unapproved licenses:

  src/resources/META-INF/mime.types
  src/test/eml/attachment-only.eml
  src/test/eml/html-attachment.eml
  src/test/eml/multipart-report.eml
  src/test/eml/simple-reply.eml
  src/test/eml/simple.eml

Where is the 'src' zip I can build from?

Looks like there are three easy to fix checkstyle errors (not the missing
Javadocs.)

-1: Can you justify the 51 Clirr errors in a minor release?

Our current guideline is that such a change means a major version and new
package. I do not care which way we go but we should be mindful of binary
compatibility for minor release.

Thank you,
Gary

On Mon, Dec 5, 2011 at 4:31 PM, Siegfried Goeschl sgoes...@gmx.at wrote:

 Hi folks,

 I would like to call a vote to release commons-email-1.3 which contains
 the following bug fixes and improvements found here

 http://people.apache.org/**builds/commons/email/1.3/RC2/**
 site/changes-report.htmlhttp://people.apache.org/builds/commons/email/1.3/RC2/site/changes-report.html

 Tag:

 https://svn.apache.org/repos/**asf/commons/proper/email/tags/**
 EMAIL_1_3_RC2https://svn.apache.org/repos/asf/commons/proper/email/tags/EMAIL_1_3_RC2

 Site:

 http://people.apache.org/**builds/commons/email/1.3/RC2/**site/index.htmlhttp://people.apache.org/builds/commons/email/1.3/RC2/site/index.html

 Binaries:

 http://people.apache.org/**builds/commons/email/1.3/RC2/**
 staged/org/apache/commons/**commons-email/1.3/http://people.apache.org/builds/commons/email/1.3/RC2/staged/org/apache/commons/commons-email/1.3/

 [ ] +1 release it
 [ ] +0 go ahead I don't care
 [ ] -1 no, do not release it because

 Thanks in advance

 Siegfried Goeschl

 --**--**-
 To unsubscribe, e-mail: 
 dev-unsubscribe@commons.**apache.orgdev-unsubscr...@commons.apache.org
 For additional commands, e-mail: dev-h...@commons.apache.org




-- 
E-Mail: garydgreg...@gmail.com | ggreg...@apache.org
JUnit in Action, 2nd Ed: http://goog_1249600977http://bit.ly/ECvg0
Spring Batch in Action: http://s.apache.org/HOqhttp://bit.ly/bqpbCK
Blog: http://garygregory.wordpress.com
Home: http://garygregory.com/
Tweet! http://twitter.com/GaryGregory

Re: [VOTE] Can the next version major version of a project require Java6? (i.e. drop Java 1.5)

On Mon, Dec 5, 2011 at 10:37 PM, Matt Benson gudnabr...@gmail.com wrote:
 On Mon, Dec 5, 2011 at 1:39 PM, Christian Grobmeier grobme...@gmail.com 
 wrote:
 On Mon, Dec 5, 2011 at 8:22 PM, Matt Benson gudnabr...@gmail.com wrote:
 I think all that Sebastian is saying is something like if you can
 create your new, cool API and the only things you really miss from
 Java 6 are @Override on interface implementation methods and
 ServiceLoader, for example, maybe it's worth that tiny bit of extra
 pain to reach that slightly larger audience.  We all feel frustrated
 from time to time working in the community setting; I've been there
 myself, but I don't think Seb is just trying to be a killjoy just for
 the hell of it.

 Yes, you might be right on this interpretation.

 As long as there a volunteers for maintaining jexl2 on j5 setting, I
 am fine with keeping j5 for it. To be clear, I am not saying we kill
 jexl2 today or quit jdk5 support for jexl2.

 But we should not make it a policy to start a new, major version with
 the lowest JDK version possible when the actual maintainers would like
 to use a current platform - this needs no discussion imho, they should
 simply do as they please.

 I agree that the developers of a component should do as they
 [collectively] please.  However, in the case of [jexl] it appears that
 Seb is interested in the development of this component.  He may
 continue to be interested in the development of a v3.x of [jexl].  Now
 we don't have as clear-cut a case of do-ocracy and henrib just doing
 what he pleases anymore, because he has to do instead as near as he
 can get to what he pleases while still functioning in a
 consensus-based manner.  A possible sequence of events:

  - henrib proposes that [jexl] include feature X, using feature Y
 from Java 6, thus justifying this minimum version.  Assuming the
 community doesn't vote down the feature on its own merits, Java 6 it
 is.
  - sebb can then come along say, hey, I know we agreed on feature X,
 but I can put in 4 hours of work or create a new Commons component to
 reimplement feature Y, and now Java 5 users can also benefit from
 [jexl] 3!

 Assuming someone else is willing to do the *actual* work required to
 keep Java 5 compatibility, are you really going to spend time and
 energy fighting for interface @Overrides?  Obviously there would
 probably be some point at which Seb in this example would say, sure, I
 could reimplement feature Y, but it's going to take ten hours, twenty
 hours.  Not worth it; have your Java 6!

 This is the way I see our community as having to function.

With just 2 committers on a component, is not really easy to get an
consens when both have different opinions. What now?
Henri needs to wait until Sebb gives up java5.

...

Christian


 Matt


 Cheers


 Matt

 On Mon, Dec 5, 2011 at 1:13 PM, Christian Grobmeier grobme...@gmail.com 
 wrote:
 On Mon, Dec 5, 2011 at 7:38 PM, sebb seb...@gmail.com wrote:
 On 5 December 2011 18:10, henrib hen...@apache.org wrote:
 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...

 No, I don't consider that a valid reason on its own.

 Committing should be fun. If one does not want to support JDK 1.5 he
 goes away. Henri seems as he does not want and would like to put
 effort in a more modern environment. In addition, how many people can
 you attract with a JDK 1.5 version to contribute? For me this is valid
 reason.

 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.

 Indeed, ideally everyone would now be using Java 6 and Windows users
 should all upgrade to Windows 7 etc.

 But that is a separate issue.

 No it is not.

 It seems you ignore my idea on having jexl2 in maintenance mode, but
 this is actually what MS did with Win XP. Now they don't support it. I
 ask myself, why do we need to support outdated jdks until all
 committers are gone away or the library is the outdated people get
 some fresher stuff (Collections vs Guava)?

 If Henri is the opinion that people should use jdk6 he should be
 allowed to create such a version and call it Jexl3.
 If you want to keep a jdk5 version, you are of course allowed to
 support that one.

 Cheers
 Christian


 -
 To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org

Re: [RELEASE PROCESS] Stability versus usability

Hi Henri,

henrib wrote:

 
 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 ?

I don't see a real different between stable and usable. Either a user can 
rely on a functionality or not. If you want to improve a part of the API 
without breaking compatibility, you may always deprecate the part that 
should no longer be used, because it will vanish in the next major release. 
This is what we normally do for a new release. This is e.g. what we've done 
with commons-io (although we improved the interface for generics). If it is 
a real redesign of the API (like lang3), we make it possible to use old and 
new versions side-by-side with new package name and artifactId to avoid 
unresolvable dependency situations for our users.

I am all for 'internal' packages. IMHO it is not necessary to name a package 
as 'internal' as long as it is clearly documented, but it is definitely a 
better indication. It's definitely the right approach to exclude internal 
packages from clirr, personally I'd even exclude internal packages from 
Javadoc. The risc of usage must be clear to every user.

However, I don't believe that annotations will really help. I'd separate 
internal stiff on package boundary and anything else is part of the public 
API. If you start to mix different annotations within one package, all you 
get is confusion.

Cheers,
Jörg


-
To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
For additional commands, e-mail: dev-h...@commons.apache.org

Re: [VOTE][Codec] Release Commons Codec 1.6-RC2 REDUX

Gary Gregory wrote:

 Good day to you all:
 
 I have prepared Commons Codec 1.6-RC2, again, per Sebb's suggestion. I am
 not calling it RC3 because there are no changes in source files from the
 last RC. The only difference is that I built from a fresh checkout of the
 RC2 svn tag.
 
 The changes from RC1 are what Sebb found:
 - EOL in sources
 - Cruft from a dirty build, so I built this RC as I should have the first
 time around with:
 - mvn clean
 - mvn deploy -Prelease
 
 Tag:
 
 https://svn.apache.org/repos/asf/commons/proper/codec/tags/commons-codec
 -1.6-RC2
 
 Site:
 
 https://people.apache.org/builds/commons/codec/1.6/RC2/
 
 Binaries:
 
 https://repository.apache.org/content/repositories/orgapachecommons-224/
 https://repository.apache.org/content/repositories/orgapachecommons-290/
 
 The link above includes checksum files.
 
 [ ] +1 release it
 [ ] +0 go ahead, I cannot take the time
 [ ] -1 no, do not release it because:

+1

 This VOTE is open for 72 hours, until November 23 2011, 14:00 EST.

Change the history ... ?!? :)

Build went fine for my compiler zoo (apart from the well-known problem with 
IBM JDK 5) on Linux/amd64. I had none of Olivers problems with Java 5 
versions.

- Jörg


-
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?

Go for 2.1.

The problem of binary incompatibility only arise if you do *not* have access 
to the sources.

sebb wrote:

 The Jexl 2.0 branch now has only a few incompatibilities reported by
 Clirr (see below).
 
 Also the 2.0.1 JUnit tests now run (with minor essential changes)
 against both 2.0.1 and 2.1-SNAPSHOT.
 
 The remaining errors all relate to adding methods to interfaces.
 According to the JLS [1], adding methods to an interface does not
 break *binary* compatibility; however of course it will break source
 compatibility.
 I assume that Clirr has got this wrong; or is failing to distinguish
 source compatibility from binary compatibility.
 There is a test case to show this -
 ScriptTest.testScriptInterfaceBinaryCompat() - in the
 COMMONS_JEXL_2_0_1_TEST branch.
 
 I think it would be OK to release the code without changing package
 names / Maven id if other Commons developers agree.
 What do others think?
 
 Assuming that there are no objections, there is the question of what
 version to use.
 
 The changes clearly require at least a minor version bump, i.e. 2.1
 rather than 2.0.2.
 It is unlikely that any users will have implemented the Script
 interface directly; any that have done so will need to update their
 source before recompiling.
 Does such a source incompatibility require a major version bump to 3.0?
 [Note: this does *not* mean a package change is required; however a
 package change would require a major version bump]
 
 I think this discussion is best held separately from any release vote,
 as there are always plenty of other items to check in a release
 vote...
 
 =
 
 ERROR: 7012: org.apache.commons.jexl2.introspection.Uberspect: Method
 'public org.apache.commons.jexl2.introspection.JexlMethod
 getConstructorMethod(java.lang.Object, java.lang.Object[],
 org.apache.commons.jexl2.JexlInfo)' has been added to an interface
 ERROR: 7012: org.apache.commons.jexl2.JexlInfo: Method 'public
 org.apache.commons.jexl2.DebugInfo debugInfo()' has been added to an
 interface
 ERROR: 7012: org.apache.commons.jexl2.Script: Method 'public
 java.lang.Object execute(org.apache.commons.jexl2.JexlContext,
 java.lang.Object[])' has been added to an interface
 ERROR: 7012: org.apache.commons.jexl2.Script: Method 'public
 java.lang.String[] getLocalVariables()' has been added to an interface
 ERROR: 7012: org.apache.commons.jexl2.Script: Method 'public
 java.lang.String[] getParameters()' has been added to an interface
 ERROR: 7012: org.apache.commons.jexl2.Script: Method 'public
 java.util.concurrent.Callable
 callable(org.apache.commons.jexl2.JexlContext)' has been added to an
 interface
 ERROR: 7012: org.apache.commons.jexl2.Script: Method 'public
 java.util.concurrent.Callable
 callable(org.apache.commons.jexl2.JexlContext, java.lang.Object[])'
 has been added to an interface
 ERROR: 7012: org.apache.commons.jexl2.Script: Method 'public
 java.util.Set getVariables()' has been added to an interface
 
 [1]
 
[http://java.sun.com/docs/books/jls/second_edition/html/binaryComp.doc.html#45347



-
To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
For additional commands, e-mail: dev-h...@commons.apache.org

Re: svn commit: r1210678 - in /commons/proper/digester/trunk/src: main/java/org/apache/commons/digester3/binder/ test/resources/org/apache/commons/digester3/xmlrules/

Note that in the testcase XML you don't need @params if you're using
the (boolean, double) constructor.  The default constructor arguments
were needed to avoid the NPEs that were thrown due to the (Boolean,
Double) constructor calling { this( booleanProperty.booleanValue(),
doubleProperty.doubleValue() ); }

Matt

On Mon, Dec 5, 2011 at 4:27 PM,  simonetrip...@apache.org wrote:
 Author: simonetripodi
 Date: Mon Dec  5 22:27:50 2011
 New Revision: 1210678

 URL: http://svn.apache.org/viewvc?rev=1210678view=rev
 Log:
 [DIGESTER-154] The DigesterBinder is not able to load primitive classes by 
 name

 Added:
    
 commons/proper/digester/trunk/src/main/java/org/apache/commons/digester3/binder/BinderClassLoader.java
    (with props)
 Modified:
    
 commons/proper/digester/trunk/src/main/java/org/apache/commons/digester3/binder/DigesterLoader.java
    
 commons/proper/digester/trunk/src/main/java/org/apache/commons/digester3/binder/ObjectCreateBuilder.java
    
 commons/proper/digester/trunk/src/test/resources/org/apache/commons/digester3/xmlrules/constructor-testrules.xml

 Added: 
 commons/proper/digester/trunk/src/main/java/org/apache/commons/digester3/binder/BinderClassLoader.java
 URL: 
 http://svn.apache.org/viewvc/commons/proper/digester/trunk/src/main/java/org/apache/commons/digester3/binder/BinderClassLoader.java?rev=1210678view=auto
 ==
 --- 
 commons/proper/digester/trunk/src/main/java/org/apache/commons/digester3/binder/BinderClassLoader.java
  (added)
 +++ 
 commons/proper/digester/trunk/src/main/java/org/apache/commons/digester3/binder/BinderClassLoader.java
  Mon Dec  5 22:27:50 2011
 @@ -0,0 +1,71 @@
 +package org.apache.commons.digester3.binder;
 +
 +import java.util.Collections;
 +import java.util.HashMap;
 +import java.util.Map;
 +
 +/*
 + * Licensed to the Apache Software Foundation (ASF) under one
 + * or more contributor license agreements.  See the NOTICE file
 + * distributed with this work for additional information
 + * regarding copyright ownership.  The ASF licenses this file
 + * to you under the Apache License, Version 2.0 (the
 + * License); you may not use this file except in compliance
 + * with the License.  You may obtain a copy of the License at
 + *
 + *   http://www.apache.org/licenses/LICENSE-2.0
 + *
 + * Unless required by applicable law or agreed to in writing,
 + * software distributed under the License is distributed on an
 + * AS IS BASIS, WITHOUT WARRANTIES OR CONDITIONS OF ANY
 + * KIND, either express or implied.  See the License for the
 + * specific language governing permissions and limitations
 + * under the License.
 + */
 +
 +final class BinderClassLoader
 +    extends ClassLoader
 +{
 +
 +    private static final MapString, Class? PRIMITIVE_TYPES;
 +    static
 +    {
 +        HashMapString, Class? primitiveTypes = new HashMapString, 
 Class?();
 +        primitiveTypes.put( boolean, boolean.class );
 +        primitiveTypes.put( byte, byte.class );
 +        primitiveTypes.put( short, short.class );
 +        primitiveTypes.put( int, int.class );
 +        primitiveTypes.put( char, char.class );
 +        primitiveTypes.put( long, long.class );
 +        primitiveTypes.put( float, float.class );
 +        primitiveTypes.put( double, double.class );
 +        PRIMITIVE_TYPES = Collections.unmodifiableMap( primitiveTypes );
 +    }
 +
 +    private final ClassLoader adaptedClassLoader;
 +
 +    public BinderClassLoader( ClassLoader adaptedClassLoader )
 +    {
 +        this.adaptedClassLoader = adaptedClassLoader;
 +    }
 +
 +    public ClassLoader getAdaptedClassLoader()
 +    {
 +        return adaptedClassLoader;
 +    }
 +
 +    /**
 +     * {@inheritDoc}
 +     */
 +    @Override
 +    protected synchronized Class? loadClass( String name, boolean resolve )
 +        throws ClassNotFoundException
 +    {
 +        if ( PRIMITIVE_TYPES.containsKey( name ) )
 +        {
 +            return PRIMITIVE_TYPES.get( name );
 +        }
 +        return adaptedClassLoader.loadClass( name );
 +    }
 +
 +}

 Propchange: 
 commons/proper/digester/trunk/src/main/java/org/apache/commons/digester3/binder/BinderClassLoader.java
 --
    svn:eol-style = native

 Propchange: 
 commons/proper/digester/trunk/src/main/java/org/apache/commons/digester3/binder/BinderClassLoader.java
 --
    svn:keywords = Date Author Id Revision HeadURL

 Propchange: 
 commons/proper/digester/trunk/src/main/java/org/apache/commons/digester3/binder/BinderClassLoader.java
 --
    svn:mime-type = text/plain

 Modified: 
 commons/proper/digester/trunk/src/main/java/org/apache/commons/digester3/binder/DigesterLoader.java
 URL:

Re: [VOTE] Can the next version major version of a project require Java6? (i.e. drop Java 1.5)

Hi Henri,

henrib wrote:

 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).

As a rule of thumb: Do not drop binary compatibility without a really good 
reason. We were really glad when some of our major customers finally dropped 
Java 1.4 two years ago, long after its EOL. It is really not uncommon for 
big players to stay way behind especially in financial business. However ...

if you make a complete redesign of the API, that will break compatibility in 
large parts anyway, it is IMHO also fine to rely on the latest Java version. 
JEXL 2.x will not vanish and nobody is stopped from creating a maintenance 
release.

 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

+1

 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?

The problem of deep dependency conflicts will not suddenly vanish though ;-)

- Jörg


-
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)

henrib wrote:

 
 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 :-)...)

... and you know what? One of our major customers finally (!!!) did an 
upgrade *last month*. This *is* a typical situation in large companies, 
where a software upgrade means to roll out software to 100'000 computers.

- Jörg


-
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)

On Mon, Dec 5, 2011 at 5:13 PM, Christian Grobmeier grobme...@gmail.comwrote:

 On Mon, Dec 5, 2011 at 10:37 PM, Matt Benson gudnabr...@gmail.com wrote:
  On Mon, Dec 5, 2011 at 1:39 PM, Christian Grobmeier grobme...@gmail.com
 wrote:
  On Mon, Dec 5, 2011 at 8:22 PM, Matt Benson gudnabr...@gmail.com
 wrote:
  I think all that Sebastian is saying is something like if you can
  create your new, cool API and the only things you really miss from
  Java 6 are @Override on interface implementation methods and
  ServiceLoader, for example, maybe it's worth that tiny bit of extra
  pain to reach that slightly larger audience.  We all feel frustrated
  from time to time working in the community setting; I've been there
  myself, but I don't think Seb is just trying to be a killjoy just for
  the hell of it.
 
  Yes, you might be right on this interpretation.
 
  As long as there a volunteers for maintaining jexl2 on j5 setting, I
  am fine with keeping j5 for it. To be clear, I am not saying we kill
  jexl2 today or quit jdk5 support for jexl2.
 
  But we should not make it a policy to start a new, major version with
  the lowest JDK version possible when the actual maintainers would like
  to use a current platform - this needs no discussion imho, they should
  simply do as they please.
 
  I agree that the developers of a component should do as they
  [collectively] please.  However, in the case of [jexl] it appears that
  Seb is interested in the development of this component.  He may
  continue to be interested in the development of a v3.x of [jexl].  Now
  we don't have as clear-cut a case of do-ocracy and henrib just doing
  what he pleases anymore, because he has to do instead as near as he
  can get to what he pleases while still functioning in a
  consensus-based manner.  A possible sequence of events:
 
   - henrib proposes that [jexl] include feature X, using feature Y
  from Java 6, thus justifying this minimum version.  Assuming the
  community doesn't vote down the feature on its own merits, Java 6 it
  is.
   - sebb can then come along say, hey, I know we agreed on feature X,
  but I can put in 4 hours of work or create a new Commons component to
  reimplement feature Y, and now Java 5 users can also benefit from
  [jexl] 3!
 
  Assuming someone else is willing to do the *actual* work required to
  keep Java 5 compatibility, are you really going to spend time and
  energy fighting for interface @Overrides?  Obviously there would
  probably be some point at which Seb in this example would say, sure, I
  could reimplement feature Y, but it's going to take ten hours, twenty
  hours.  Not worth it; have your Java 6!
 
  This is the way I see our community as having to function.

 With just 2 committers on a component, is not really easy to get an
 consens when both have different opinions. What now?
 Henri needs to wait until Sebb gives up java5.


No one has veto power here. We're all reasonable folks. Well, I'd like to
think I am. Most of us are passionate and opinionated. That a good thing.

If you work towards a .jexl3 Java 6 release and get the votes to get an RC
out, I won't and can't stop you. Actually, I'm all for it :)

Gary


 ...

 Christian

 
  Matt
 
 
  Cheers
 
 
  Matt
 
  On Mon, Dec 5, 2011 at 1:13 PM, Christian Grobmeier 
 grobme...@gmail.com wrote:
  On Mon, Dec 5, 2011 at 7:38 PM, sebb seb...@gmail.com wrote:
  On 5 December 2011 18:10, henrib hen...@apache.org wrote:
  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...
 
  No, I don't consider that a valid reason on its own.
 
  Committing should be fun. If one does not want to support JDK 1.5 he
  goes away. Henri seems as he does not want and would like to put
  effort in a more modern environment. In addition, how many people can
  you attract with a JDK 1.5 version to contribute? For me this is valid
  reason.
 
  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.
 
  Indeed, ideally everyone would now be using Java 6 and Windows users
  should all upgrade to Windows 7 etc.
 
  But that is a separate issue.
 
  No it is not.
 
  It seems you ignore my idea on having jexl2 in maintenance mode, but
  this is actually what MS did with Win XP. Now they don't support it. I
  ask myself, why do we need to support outdated jdks until all

Re: [VOTE] Can the next version major version of a project require Java6? (i.e. drop Java 1.5)

On Mon, Dec 5, 2011 at 4:13 PM, Christian Grobmeier grobme...@gmail.com wrote:
 On Mon, Dec 5, 2011 at 10:37 PM, Matt Benson gudnabr...@gmail.com wrote:
 On Mon, Dec 5, 2011 at 1:39 PM, Christian Grobmeier grobme...@gmail.com 
 wrote:
 On Mon, Dec 5, 2011 at 8:22 PM, Matt Benson gudnabr...@gmail.com wrote:
 I think all that Sebastian is saying is something like if you can
 create your new, cool API and the only things you really miss from
 Java 6 are @Override on interface implementation methods and
 ServiceLoader, for example, maybe it's worth that tiny bit of extra
 pain to reach that slightly larger audience.  We all feel frustrated
 from time to time working in the community setting; I've been there
 myself, but I don't think Seb is just trying to be a killjoy just for
 the hell of it.

 Yes, you might be right on this interpretation.

 As long as there a volunteers for maintaining jexl2 on j5 setting, I
 am fine with keeping j5 for it. To be clear, I am not saying we kill
 jexl2 today or quit jdk5 support for jexl2.

 But we should not make it a policy to start a new, major version with
 the lowest JDK version possible when the actual maintainers would like
 to use a current platform - this needs no discussion imho, they should
 simply do as they please.

 I agree that the developers of a component should do as they
 [collectively] please.  However, in the case of [jexl] it appears that
 Seb is interested in the development of this component.  He may
 continue to be interested in the development of a v3.x of [jexl].  Now
 we don't have as clear-cut a case of do-ocracy and henrib just doing
 what he pleases anymore, because he has to do instead as near as he
 can get to what he pleases while still functioning in a
 consensus-based manner.  A possible sequence of events:

  - henrib proposes that [jexl] include feature X, using feature Y
 from Java 6, thus justifying this minimum version.  Assuming the
 community doesn't vote down the feature on its own merits, Java 6 it
 is.
  - sebb can then come along say, hey, I know we agreed on feature X,
 but I can put in 4 hours of work or create a new Commons component to
 reimplement feature Y, and now Java 5 users can also benefit from
 [jexl] 3!

 Assuming someone else is willing to do the *actual* work required to
 keep Java 5 compatibility, are you really going to spend time and
 energy fighting for interface @Overrides?  Obviously there would
 probably be some point at which Seb in this example would say, sure, I
 could reimplement feature Y, but it's going to take ten hours, twenty
 hours.  Not worth it; have your Java 6!

 This is the way I see our community as having to function.

 With just 2 committers on a component, is not really easy to get an
 consens when both have different opinions. What now?
 Henri needs to wait until Sebb gives up java5.


I don't know what to say.  Finding consensus is part of The Apache
Way.  I guess this means all concerned parties should try and be
reasonable and remember that this is a do-ocracy.  If Seb wants to
make the contributions that will keep [jexl] 3x compatible with 1.5, I
don't see that this should inconvenience Henri B. to the point that he
should rather work elsewhere.  Again, when the burden of maintaining
compatibility becomes too great, it will be obviously time to move to
Java 6.

On the other hand, how long will an API redesign take?  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.  This could even be done with multiple mvn modules.

Matt

 ...

 Christian


 Matt


 Cheers


 Matt

 On Mon, Dec 5, 2011 at 1:13 PM, Christian Grobmeier grobme...@gmail.com 
 wrote:
 On Mon, Dec 5, 2011 at 7:38 PM, sebb seb...@gmail.com wrote:
 On 5 December 2011 18:10, henrib hen...@apache.org wrote:
 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...

 No, I don't consider that a valid reason on its own.

 Committing should be fun. If one does not want to support JDK 1.5 he
 goes away. Henri seems as he does not want and would like to put
 effort in a more modern environment. In addition, how many people can
 you attract with a JDK 1.5 version to contribute? For me this is valid
 reason.

 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

Re: [VOTE][email] Release Commons Email 1.3 based on RC2

Hi Siegfried,

Siegfried Goeschl wrote:

 Hi folks,
 
 I would like to call a vote to release commons-email-1.3 which contains
 the following bug fixes and improvements found here
 
 http://people.apache.org/builds/commons/email/1.3/RC2/site/changes-
report.html
 
 Tag:
 
 https://svn.apache.org/repos/asf/commons/proper/email/tags/EMAIL_1_3_RC2
 
 Site:
 
 http://people.apache.org/builds/commons/email/1.3/RC2/site/index.html
 
 Binaries:
 
 
http://people.apache.org/builds/commons/email/1.3/RC2/staged/org/apache/commons/commons-
email/1.3/
 
 [ ] +1 release it
 [ ] +0 go ahead I don't care
 [ ] -1 no, do not release it because

-1

like Gary I miss the distribution .zip and .tar.gz files for binaries and 
source.

Cheers,
Jörg


-
To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
For additional commands, e-mail: dev-h...@commons.apache.org

Re: [VOTE][Codec] Release Commons Codec 1.6-RC2 REDUX

On Mon, Dec 5, 2011 at 5:19 PM, Jörg Schaible joerg.schai...@gmx.de wrote:

 Gary Gregory wrote:

  Good day to you all:
 
  I have prepared Commons Codec 1.6-RC2, again, per Sebb's suggestion. I am
  not calling it RC3 because there are no changes in source files from the
  last RC. The only difference is that I built from a fresh checkout of the
  RC2 svn tag.
 
  The changes from RC1 are what Sebb found:
  - EOL in sources
  - Cruft from a dirty build, so I built this RC as I should have the first
  time around with:
  - mvn clean
  - mvn deploy -Prelease
 
  Tag:
 
  https://svn.apache.org/repos/asf/commons/proper/codec/tags/commons-codec
  -1.6-RC2
 
  Site:
 
  https://people.apache.org/builds/commons/codec/1.6/RC2/
 
  Binaries:
 
  
 https://repository.apache.org/content/repositories/orgapachecommons-224/
  https://repository.apache.org/content/repositories/orgapachecommons-290/
 
  The link above includes checksum files.
 
  [ ] +1 release it
  [ ] +0 go ahead, I cannot take the time
  [ ] -1 no, do not release it because:

 +1

  This VOTE is open for 72 hours, until November 23 2011, 14:00 EST.

 Change the history ... ?!? :)


Ah, yes, we have different clocks here on planet Zeenar.

REDUX: This VOTE is open for 72 hours, until December 5 2011, 23:00 EST.

Good catch,
Gary


 Build went fine for my compiler zoo (apart from the well-known problem with
 IBM JDK 5) on Linux/amd64. I had none of Olivers problems with Java 5
 versions.

 - Jörg


 -
 To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
 For additional commands, e-mail: dev-h...@commons.apache.org




-- 
E-Mail: garydgreg...@gmail.com | ggreg...@apache.org
JUnit in Action, 2nd Ed: http://goog_1249600977http://bit.ly/ECvg0
Spring Batch in Action: http://s.apache.org/HOqhttp://bit.ly/bqpbCK
Blog: http://garygregory.wordpress.com
Home: http://garygregory.com/
Tweet! http://twitter.com/GaryGregory

Re: [VFS] next release

Hi Gary,

Gary Gregory wrote:

 Hi All:
 
 I've made several improvements to VFS over the last couple of months which
 feels ready for a release soon.
 
 One important internal change is that the builds runs almost all unit
 tests
 :) 

I saw your efforts and this is really a great improvement! Thanks!

 I've not found an easy way to embed a WebDAV server in the tests like
 JackRabbit, which would be nice to do.

Definitely :)

 I know Ralph just mentioned thoughts of a VFS3 on top of Java 7, which is
 great news indeed. This feels like it needs a new name instead of a
 version change though because the change is so radical (and nice.)
 
 Thoughts?

I'd keep the name, it's a brand here and if we name it VFS3 and document 
that it is based on Java 7 technology, so why change it?

- Jörg


-
To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
For additional commands, e-mail: dev-h...@commons.apache.org

Re: [VFS] next release