[math] should version 2.0 be targeted to Java 5 ?

[Luc Maisonobe]

Mauro Talevi recently proposed a new package for general linear
regression (https://issues.apache.org/jira/browse/MATH-203). This patch
needs Java 5, mainly for annotations.

Mauro suggested to take the opportunity of the next [math] major version
to switch to Java 5. A major version seems appropriate for such a
change, but do we want to do it now ?

My personal opinion is that sticking to Java 1.3 is really obsolete and
difficult. When I upgraded my Linux box recently, I had to search old
backups to reinstall a JDK manually. Dropping this could simplify some
codes (exceptions for example) and fix some errors (there is a known
issue with unit tests since Java 1.3 does not compute trigonometric
functions as it should).

If we decide to change minimal Java version, I would choose to target
1.5. It is widely adopted and deployed now and has many features which
would be useful for a mathematical library:
     - new Math functions (log10, cbrt, ulp, signum, cosh, sinh, tanh,
hypot, expm1, log1p)
     - autoboxing
     - MathContext, RoundingMode
In addition, there are the many features that are interesting for any
type of Java development (enums, generics, annotations).

Java 6 brings even more Math functions (copysign, getExponent,
nextAfter, nextUp, scalb), some of which we needed to add ourselves in
MathUtils. However, I'm not sure it is as widely deployed than Java5.

Perhaps Java 7 would bring even more functions (asinh, acosh and atanh
are still missing ...)

What do you think ?

Luc


---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@...
For additional commands, e-mail: dev-help@...

[Thorbjørn Ravn Andersen]

Luc Maisonobe skrev  den 11-05-2008 18:27:
> My personal opinion is that sticking to Java 1.3 is really obsolete
> and difficult. When I upgraded my Linux box recently, I had to search
> old backups to reinstall a JDK manually. Dropping this could simplify
> some codes (exceptions for example) and fix some errors (there is a
> known issue with unit tests since Java 1.3 does not compute
> trigonometric functions as it should).
>
See http://java.sun.com/javase/downloads/previous.jsp for getting pre-6
releases.

Notably, look at http://java.sun.com/products/archive/ for Java 1.1,
1.2, 1.3.

It is a click-through license and a tar file to unpack.
--
  Thorbjørn

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@...
For additional commands, e-mail: dev-help@...

[Oliver Heger-3]

Luc Maisonobe wrote:

> Mauro Talevi recently proposed a new package for general linear
> regression (https://issues.apache.org/jira/browse/MATH-203). This patch
> needs Java 5, mainly for annotations.
>
> Mauro suggested to take the opportunity of the next [math] major version
> to switch to Java 5. A major version seems appropriate for such a
> change, but do we want to do it now ?
>
> My personal opinion is that sticking to Java 1.3 is really obsolete and
> difficult. When I upgraded my Linux box recently, I had to search old
> backups to reinstall a JDK manually. Dropping this could simplify some
> codes (exceptions for example) and fix some errors (there is a known
> issue with unit tests since Java 1.3 does not compute trigonometric
> functions as it should).
>
> If we decide to change minimal Java version, I would choose to target
> 1.5. It is widely adopted and deployed now and has many features which
> would be useful for a mathematical library:
>     - new Math functions (log10, cbrt, ulp, signum, cosh, sinh, tanh,
> hypot, expm1, log1p)
>     - autoboxing
>     - MathContext, RoundingMode
> In addition, there are the many features that are interesting for any
> type of Java development (enums, generics, annotations).
>
> Java 6 brings even more Math functions (copysign, getExponent,
> nextAfter, nextUp, scalb), some of which we needed to add ourselves in
> MathUtils. However, I'm not sure it is as widely deployed than Java5.
>
> Perhaps Java 7 would bring even more functions (asinh, acosh and atanh
> are still missing ...)
>
> What do you think ?
>
> Luc
>

IMHO the time is right now for Java 1.5. I am not sure about the
adoption of higher versions, so with 1.5 you are probably on the safe side.

Oliver

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@...
For additional commands, e-mail: dev-help@...

[Rahul Akolkar]

As a general comment, its time to go to higher JDKs where it makes
sense -- or atleast where there is developer interest in doing so
(such as the post below :-). I have a JDK 1.6 branch for Commons
SCXML, which I hope to release in a few months.

-Rahul


On Sun, May 11, 2008 at 12:27 PM, Luc Maisonobe <Luc.Maisonobe@...> wrote:

> Mauro Talevi recently proposed a new package for general linear regression
> (https://issues.apache.org/jira/browse/MATH-203). This patch needs Java 5,
> mainly for annotations.
>
> Mauro suggested to take the opportunity of the next [math] major version to
> switch to Java 5. A major version seems appropriate for such a change, but
> do we want to do it now ?
>
> My personal opinion is that sticking to Java 1.3 is really obsolete and
> difficult. When I upgraded my Linux box recently, I had to search old
> backups to reinstall a JDK manually. Dropping this could simplify some codes
> (exceptions for example) and fix some errors (there is a known issue with
> unit tests since Java 1.3 does not compute trigonometric functions as it
> should).
>
> If we decide to change minimal Java version, I would choose to target 1.5.
> It is widely adopted and deployed now and has many features which would be
> useful for a mathematical library:
>    - new Math functions (log10, cbrt, ulp, signum, cosh, sinh, tanh, hypot,
> expm1, log1p)
>    - autoboxing
>    - MathContext, RoundingMode
> In addition, there are the many features that are interesting for any type
> of Java development (enums, generics, annotations).
>
> Java 6 brings even more Math functions (copysign, getExponent, nextAfter,
> nextUp, scalb), some of which we needed to add ourselves in MathUtils.
> However, I'm not sure it is as widely deployed than Java5.
>
> Perhaps Java 7 would bring even more functions (asinh, acosh and atanh are
> still missing ...)
>
> What do you think ?
>
> Luc
>

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@...
For additional commands, e-mail: dev-help@...

[Phil Steitz]

On Sun, May 11, 2008 at 9:27 AM, Luc Maisonobe <Luc.Maisonobe@...> wrote:

> Mauro Talevi recently proposed a new package for general linear regression
> (https://issues.apache.org/jira/browse/MATH-203). This patch needs Java 5,
> mainly for annotations.
>
> Mauro suggested to take the opportunity of the next [math] major version to
> switch to Java 5. A major version seems appropriate for such a change, but
> do we want to do it now ?
>
> My personal opinion is that sticking to Java 1.3 is really obsolete and
> difficult. When I upgraded my Linux box recently, I had to search old
> backups to reinstall a JDK manually. Dropping this could simplify some codes
> (exceptions for example) and fix some errors (there is a known issue with
> unit tests since Java 1.3 does not compute trigonometric functions as it
> should).
>
> If we decide to change minimal Java version, I would choose to target 1.5.
> It is widely adopted and deployed now and has many features which would be
> useful for a mathematical library:
>    - new Math functions (log10, cbrt, ulp, signum, cosh, sinh, tanh, hypot,
> expm1, log1p)
>    - autoboxing
>    - MathContext, RoundingMode
> In addition, there are the many features that are interesting for any type
> of Java development (enums, generics, annotations).
>
> Java 6 brings even more Math functions (copysign, getExponent, nextAfter,
> nextUp, scalb), some of which we needed to add ourselves in MathUtils.
> However, I'm not sure it is as widely deployed than Java5.
>
> Perhaps Java 7 would bring even more functions (asinh, acosh and atanh are
> still missing ...)
>
> What do you think ?

I agree that moving to 1.5 minimum in 2.0 would be OK.  The only thing
that bugs me is that there is a fair amount of (mostly Mantissa) stuff
queued up for 2.0 that does not require 1.5.  I wonder how many users
of the new stuff will still be on < 1.5.  Probably not many, so I am
+1 for requiring 1.5+ for 2.0.

Phil

>
> Luc
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@...
> For additional commands, e-mail: dev-help@...
>
>

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@...
For additional commands, e-mail: dev-help@...

[jwcarman]

Would it be better to make it Math 2.0?  With a language level change
like that, it should probably be a new major version.  You should also
consider putting the stuff in org.apache.commons.math2 packages to
avoid "jar hell" issues.

On Wed, May 14, 2008 at 6:55 PM, Phil Steitz <phil.steitz@...> wrote:

> On Sun, May 11, 2008 at 9:27 AM, Luc Maisonobe <Luc.Maisonobe@...> wrote:
>> Mauro Talevi recently proposed a new package for general linear regression
>> (https://issues.apache.org/jira/browse/MATH-203). This patch needs Java 5,
>> mainly for annotations.
>>
>> Mauro suggested to take the opportunity of the next [math] major version to
>> switch to Java 5. A major version seems appropriate for such a change, but
>> do we want to do it now ?
>>
>> My personal opinion is that sticking to Java 1.3 is really obsolete and
>> difficult. When I upgraded my Linux box recently, I had to search old
>> backups to reinstall a JDK manually. Dropping this could simplify some codes
>> (exceptions for example) and fix some errors (there is a known issue with
>> unit tests since Java 1.3 does not compute trigonometric functions as it
>> should).
>>
>> If we decide to change minimal Java version, I would choose to target 1.5.
>> It is widely adopted and deployed now and has many features which would be
>> useful for a mathematical library:
>>    - new Math functions (log10, cbrt, ulp, signum, cosh, sinh, tanh, hypot,
>> expm1, log1p)
>>    - autoboxing
>>    - MathContext, RoundingMode
>> In addition, there are the many features that are interesting for any type
>> of Java development (enums, generics, annotations).
>>
>> Java 6 brings even more Math functions (copysign, getExponent, nextAfter,
>> nextUp, scalb), some of which we needed to add ourselves in MathUtils.
>> However, I'm not sure it is as widely deployed than Java5.
>>
>> Perhaps Java 7 would bring even more functions (asinh, acosh and atanh are
>> still missing ...)
>>
>> What do you think ?
>
> I agree that moving to 1.5 minimum in 2.0 would be OK.  The only thing
> that bugs me is that there is a fair amount of (mostly Mantissa) stuff
> queued up for 2.0 that does not require 1.5.  I wonder how many users
> of the new stuff will still be on < 1.5.  Probably not many, so I am
> +1 for requiring 1.5+ for 2.0.
>
> Phil
>
>>
>> Luc
>>
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: dev-unsubscribe@...
>> For additional commands, e-mail: dev-help@...
>>
>>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@...
> For additional commands, e-mail: dev-help@...
>
>

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@...
For additional commands, e-mail: dev-help@...

[ebourg]

James Carman a écrit :
> Would it be better to make it Math 2.0?  With a language level change
> like that, it should probably be a new major version.  You should also
> consider putting the stuff in org.apache.commons.math2 packages to
> avoid "jar hell" issues.

And if you do so, you'll have to change the Maven identification of the
jar. That's the right time to release Commons Math as
org.apache.commons:commons-math instead of commons-math:commons-math.

Java 5 is the right target IMHO, Java 6 is still young on some platforms
(OS X to name it).

Emmanuel Bourg


---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@...
For additional commands, e-mail: dev-help@...

[Phil Steitz]

On Thu, May 15, 2008 at 1:55 AM, Emmanuel Bourg <ebourg@...> wrote:

> James Carman a écrit :
>>
>> Would it be better to make it Math 2.0?  With a language level change
>> like that, it should probably be a new major version.  You should also
>> consider putting the stuff in org.apache.commons.math2 packages to
>> avoid "jar hell" issues.
>
> And if you do so, you'll have to change the Maven identification of the jar.
> That's the right time to release Commons Math as
> org.apache.commons:commons-math instead of commons-math:commons-math.
>

Both good points.  Lets get the maven namespace fixed in 2.0.  Thanks
in advance for help making sure we don't screw that up.

Regarding package renaming, there are very few backward incompatible
changes lined up for 2.0, and all of the proposed 1.5-dependent stuff
is new, so I am hesistant to do a wholesale change.  What would be the
problem with renaming only packages that contain classes with
incompatible changes?

Phil

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@...
For additional commands, e-mail: dev-help@...

[ebourg]

Phil Steitz a écrit :

> Regarding package renaming, there are very few backward incompatible
> changes lined up for 2.0, and all of the proposed 1.5-dependent stuff
> is new, so I am hesistant to do a wholesale change.  What would be the
> problem with renaming only packages that contain classes with
> incompatible changes?

On the other hand, a new package may not be needed at all. I checked on
mvnrepository.com the number of open source projects depending on
Commons Math, and besides a beta version of JET from Codehaus, there is
none. That means slight incompatible changes in the 2.0 API are unlikely
to cause a dependency havoc across hundred of projects.

Emmanuel Bourg

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@...
For additional commands, e-mail: dev-help@...

[sebb-2-2]

On 15/05/2008, Emmanuel Bourg <ebourg@...> wrote:

> Phil Steitz a écrit :
>
>
> > Regarding package renaming, there are very few backward incompatible
> > changes lined up for 2.0, and all of the proposed 1.5-dependent stuff
> > is new, so I am hesistant to do a wholesale change.  What would be the
> > problem with renaming only packages that contain classes with
> > incompatible changes?
> >
>
>  On the other hand, a new package may not be needed at all. I checked on
> mvnrepository.com the number of open source projects depending on Commons
> Math, and besides a beta version of JET from Codehaus, there is none. That
> means slight incompatible changes in the 2.0 API are unlikely to cause a
> dependency havoc across hundred of projects.
>

There must be many projects that use Commons Math that aren't
published in the Maven repository.

Indeed if not, why was Commons Math created? There must be some
projects using it!

>  Emmanuel Bourg
>
>
> ---------------------------------------------------------------------
>  To unsubscribe, e-mail: dev-unsubscribe@...
>  For additional commands, e-mail: dev-help@...
>
>

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@...
For additional commands, e-mail: dev-help@...

[jwcarman]

On Thu, May 15, 2008 at 1:04 PM, sebb <sebbaz@...> wrote:
> There must be many projects that use Commons Math that aren't
> published in the Maven repository.
>
> Indeed if not, why was Commons Math created? There must be some
> projects using it!

I think the point was that we aren't very likely to get into the "jar
hell" situation, where two different projects depend on two different
versions of commons-math and my project depends on both of those
projects.  I just think that the JDK5 jump merits jumping major
versions.  And, if you're going to jump versions, you should jump your
package name to match.  Again, that's just my opinion.  I would just
like to see Commons do things in a somewhat consistent manner when it
comes to this kind of thing.

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@...
For additional commands, e-mail: dev-help@...

[sebb-2-2]

On 15/05/2008, James Carman <james@...> wrote:

> On Thu, May 15, 2008 at 1:04 PM, sebb <sebbaz@...> wrote:
>  > There must be many projects that use Commons Math that aren't
>  > published in the Maven repository.
>  >
>  > Indeed if not, why was Commons Math created? There must be some
>  > projects using it!
>
>
> I think the point was that we aren't very likely to get into the "jar
>  hell" situation, where two different projects depend on two different
>  versions of commons-math and my project depends on both of those
>  projects.

Sorry, I misread the posting.

However AFAICS "jar hell" could still apply to those unknown projects,
and needs to be avoided if at all possible.

>  I just think that the JDK5 jump merits jumping major
>  versions.  And, if you're going to jump versions, you should jump your
>  package name to match.  Again, that's just my opinion.  I would just
>  like to see Commons do things in a somewhat consistent manner when it
>  comes to this kind of thing.
>
>  ---------------------------------------------------------------------
>  To unsubscribe, e-mail: dev-unsubscribe@...
>  For additional commands, e-mail: dev-help@...
>
>

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@...
For additional commands, e-mail: dev-help@...

[ebourg]

James Carman a écrit :

> And, if you're going to jump versions, you should jump your
> package name to match.  Again, that's just my opinion.  I would just
> like to see Commons do things in a somewhat consistent manner when it
> comes to this kind of thing.

I agree to have a consistent policy when dealing with common issues,
changing the package name is the right solution to avoid conflicts
between incompatible releases.

However it's a bit late to require a package change just for jumping to
a new major version. Among the components that changed their major
revision number (collections, lang, cli, modeler, attributes), only CLI
changed its package, and it was justified by a complete incompatible
refactoring of the API.

Emmanuel Bourg


---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@...
For additional commands, e-mail: dev-help@...

[Luc Maisonobe]

Phil Steitz a écrit :

> On Thu, May 15, 2008 at 1:55 AM, Emmanuel Bourg <ebourg@...> wrote:
>> James Carman a écrit :
>>> Would it be better to make it Math 2.0?  With a language level change
>>> like that, it should probably be a new major version.  You should also
>>> consider putting the stuff in org.apache.commons.math2 packages to
>>> avoid "jar hell" issues.
>> And if you do so, you'll have to change the Maven identification of the jar.
>> That's the right time to release Commons Math as
>> org.apache.commons:commons-math instead of commons-math:commons-math.
>>
>
> Both good points.  Lets get the maven namespace fixed in 2.0.  Thanks
> in advance for help making sure we don't screw that up.
>
> Regarding package renaming, there are very few backward incompatible
> changes lined up for 2.0, and all of the proposed 1.5-dependent stuff
> is new, so I am hesistant to do a wholesale change.  What would be the
> problem with renaming only packages that contain classes with
> incompatible changes?

I see three problems with a mixed approach like this.

  - it is inconsistent and therefore difficult to understand to end-users
  - it prevents using simple search/replace to switch from 1.x to 2.x
  - it doesn't help when the two jars are in classpath and a class
    with no incompatible change (i.e still in a .math.something
    package) calls a class with an incompatible change

I'm also quite reluctant to packages names change, but it is only a
personal taste and therefore not important. I agree this is the safer
solution as it handles things properly.

Here is my proposal, summarizing what has been discussed so far in this
thread and adding my own bias:

  - commons-math 2.0 will target Java 1.5 as the minimal version
  - the maven groupId will be changed from commons-math to
    org.apache.commons (the artifactID is unchanged)
  - all packages will be relocated under org.apache.commons.math2

If nobody complains (mainly about the third point), I am going to
perform these changes in branch 2.0 on Sunday.

Luc

>
> Phil
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@...
> For additional commands, e-mail: dev-help@...
>



---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@...
For additional commands, e-mail: dev-help@...

[Phil Steitz]

On Thu, May 15, 2008 at 12:00 PM, Luc Maisonobe <Luc.Maisonobe@...> wrote:

> Phil Steitz a écrit :
>>
>> On Thu, May 15, 2008 at 1:55 AM, Emmanuel Bourg <ebourg@...> wrote:
>>>
>>> James Carman a écrit :
>>>>
>>>> Would it be better to make it Math 2.0?  With a language level change
>>>> like that, it should probably be a new major version.  You should also
>>>> consider putting the stuff in org.apache.commons.math2 packages to
>>>> avoid "jar hell" issues.
>>>
>>> And if you do so, you'll have to change the Maven identification of the
>>> jar.
>>> That's the right time to release Commons Math as
>>> org.apache.commons:commons-math instead of commons-math:commons-math.
>>>
>>
>> Both good points.  Lets get the maven namespace fixed in 2.0.  Thanks
>> in advance for help making sure we don't screw that up.
>>
>> Regarding package renaming, there are very few backward incompatible
>> changes lined up for 2.0, and all of the proposed 1.5-dependent stuff
>> is new, so I am hesistant to do a wholesale change.  What would be the
>> problem with renaming only packages that contain classes with
>> incompatible changes?
>
> I see three problems with a mixed approach like this.
>
>  - it is inconsistent and therefore difficult to understand to end-users
>  - it prevents using simple search/replace to switch from 1.x to 2.x
>  - it doesn't help when the two jars are in classpath and a class
>   with no incompatible change (i.e still in a .math.something
>   package) calls a class with an incompatible change

Assumiing that happens, which I guess we can't rule out, so point taken.

>
> I'm also quite reluctant to packages names change, but it is only a personal
> taste and therefore not important. I agree this is the safer solution as it
> handles things properly.
>
> Here is my proposal, summarizing what has been discussed so far in this
> thread and adding my own bias:
>
>  - commons-math 2.0 will target Java 1.5 as the minimal version
>  - the maven groupId will be changed from commons-math to
>   org.apache.commons (the artifactID is unchanged)
>  - all packages will be relocated under org.apache.commons.math2
>
> If nobody complains (mainly about the third point), I am going to perform
> these changes in branch 2.0 on Sunday.

I guess the third point gives me heartburn. Given the relatively small
number of incompatible changes, I do not see the need to make a
wholesale change to the package name and force all users to make
source-level changes to upgrade.  I am +1 on fixing the maven groupID,
though and upping the required JDK level to 1.5.

Phil

>
> Luc
>
>>
>> Phil
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: dev-unsubscribe@...
>> For additional commands, e-mail: dev-help@...
>>
>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@...
> For additional commands, e-mail: dev-help@...
>
>

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@...
For additional commands, e-mail: dev-help@...

[Rory Winston]

Just my 2c, but I think package renaming for major releases is ugly and
unecessary.

Phil Steitz wrote:

> On Thu, May 15, 2008 at 12:00 PM, Luc Maisonobe <Luc.Maisonobe@...> wrote:
>  
>> Phil Steitz a écrit :
>>    
>>> On Thu, May 15, 2008 at 1:55 AM, Emmanuel Bourg <ebourg@...> wrote:
>>>      
>>>> James Carman a écrit :
>>>>        
>>>>> Would it be better to make it Math 2.0?  With a language level change
>>>>> like that, it should probably be a new major version.  You should also
>>>>> consider putting the stuff in org.apache.commons.math2 packages to
>>>>> avoid "jar hell" issues.
>>>>>          
>>>> And if you do so, you'll have to change the Maven identification of the
>>>> jar.
>>>> That's the right time to release Commons Math as
>>>> org.apache.commons:commons-math instead of commons-math:commons-math.
>>>>
>>>>        
>>> Both good points.  Lets get the maven namespace fixed in 2.0.  Thanks
>>> in advance for help making sure we don't screw that up.
>>>
>>> Regarding package renaming, there are very few backward incompatible
>>> changes lined up for 2.0, and all of the proposed 1.5-dependent stuff
>>> is new, so I am hesistant to do a wholesale change.  What would be the
>>> problem with renaming only packages that contain classes with
>>> incompatible changes?
>>>      
>> I see three problems with a mixed approach like this.
>>
>>  - it is inconsistent and therefore difficult to understand to end-users
>>  - it prevents using simple search/replace to switch from 1.x to 2.x
>>  - it doesn't help when the two jars are in classpath and a class
>>   with no incompatible change (i.e still in a .math.something
>>   package) calls a class with an incompatible change
>>    
>
> Assumiing that happens, which I guess we can't rule out, so point taken.
>
>  
>> I'm also quite reluctant to packages names change, but it is only a personal
>> taste and therefore not important. I agree this is the safer solution as it
>> handles things properly.
>>
>> Here is my proposal, summarizing what has been discussed so far in this
>> thread and adding my own bias:
>>
>>  - commons-math 2.0 will target Java 1.5 as the minimal version
>>  - the maven groupId will be changed from commons-math to
>>   org.apache.commons (the artifactID is unchanged)
>>  - all packages will be relocated under org.apache.commons.math2
>>
>> If nobody complains (mainly about the third point), I am going to perform
>> these changes in branch 2.0 on Sunday.
>>    
>
> I guess the third point gives me heartburn. Given the relatively small
> number of incompatible changes, I do not see the need to make a
> wholesale change to the package name and force all users to make
> source-level changes to upgrade.  I am +1 on fixing the maven groupID,
> though and upping the required JDK level to 1.5.
>
> Phil
>  
>> Luc
>>
>>    
>>> Phil
>>>
>>> ---------------------------------------------------------------------
>>> To unsubscribe, e-mail: dev-unsubscribe@...
>>> For additional commands, e-mail: dev-help@...
>>>
>>>      
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: dev-unsubscribe@...
>> For additional commands, e-mail: dev-help@...
>>
>>
>>    
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@...
> For additional commands, e-mail: