Briefly looking at
http://svn.apache.org/repos/asf/lucene/mahout/trunk/math/src/main/java/org/apache/mahout/math/
- it looks like this is more along the lines of the Collections as new
data structures/algorithms rather than Collections as JDK enhancer?
Ignoring the edge case overlaps with Math
If by 'jdk enhancer' you mean 'provide newer functionality to older
jdks', I completely agree.
On Sat, Jan 2, 2010 at 3:31 AM, Henri Yandell flame...@gmail.com wrote:
Briefly looking at
http://svn.apache.org/repos/asf/lucene/mahout/trunk/math/src/main/java/org/apache/mahout/math/
- it looks
Henri Yandell wrote:
Overlap between Lang and Collections is starting to increase a bit.
Requested items for ArrayUtils (LANG-238, LANG-470) are better
implemented imo as an ArraySet class. An easy add to Collections.
ComparableComparator made its way (privately) over for the new Range
I do not like the divide between Lang and Collections. I think it's a
superficial divide that can never really be complete, and the forces
of logic naturally pulls us back together in some regards. It's
consternation to keep these projects separate. Why must we keep
trying?
I'd like to propose
On Sat, Jan 2, 2010 at 9:11 AM, Phil Steitz phil.ste...@gmail.com wrote:
Henri Yandell wrote:
Overlap between Lang and Collections is starting to increase a bit.
Requested items for ArrayUtils (LANG-238, LANG-470) are better
implemented imo as an ArraySet class. An easy add to Collections.
On Sat, Jan 2, 2010 at 10:02 AM, Henri Yandell flame...@gmail.com wrote:
On Sat, Jan 2, 2010 at 9:11 AM, Phil Steitz phil.ste...@gmail.com wrote:
One final comment is that a logical alternative is to just split
[collections] internally into multiple pieces with separate release
cycles.
Henri Yandell wrote:
On Sat, Jan 2, 2010 at 9:11 AM, Phil Steitz phil.ste...@gmail.com wrote:
Henri Yandell wrote:
Overlap between Lang and Collections is starting to increase a bit.
Requested items for ArrayUtils (LANG-238, LANG-470) are better
implemented imo as an ArraySet class. An easy
Online report :
http://vmbuild.apache.org/continuum/buildResult.action?buildId=264829projectId=171
Build statistics:
State: Failed
Previous State: Ok
Started at: Thu 31 Dec 2009 18:13:06 -0800
Finished at: Thu 31 Dec 2009 18:13:28 -0800
Total time: 22s
Build Trigger: Schedule
Build
In order to change the minimum required JDK to 1.4 I modified pom.xml. I
was hoping to get rid of all the XML-related dependencies, but obviously
this is not so easy.
When dropping the Xerces-dependency I get a bunch of test failures:
- Many of them are caused by tests for
Each if you split Collections into Maven children, you would still
wouldn't want to release them independently. That would be a gigantic
administrative error. Struts was thinking about doing the same thing
with its libraries, but we turned away from it -- THANKFULLY. How
would you explain to users
On Sat, Jan 2, 2010 at 10:45 AM, Phil Steitz phil.ste...@gmail.com wrote:
Henri Yandell wrote:
I was thinking more that a smaller [collections] might have room for
the functor code again - not that [lang] would :) Agreed that it's
better out than in though.
That is instructive, but sort of
On Sat, Jan 2, 2010 at 12:36 PM, Paul Benedict pbened...@apache.org wrote:
Each if you split Collections into Maven children, you would still
wouldn't want to release them independently. That would be a gigantic
administrative error. Struts was thinking about doing the same thing
with its
What would a dependency of 1.5 mean with regards to the Xerces dependency?
You depend on Lang/Collections, and both are 1.5 dependent for their
next version.
Hen
On Sat, Jan 2, 2010 at 12:22 PM, Oliver Heger
oliver.he...@oliver-heger.de wrote:
In order to change the minimum required JDK to 1.4
Henri,
Lang's math.NumberUtils and math.Fraction for example. MathUtils and a
little bit of StatUtils do look to be similar in scope.
I have voiced booting the whole math package from Commons Lang.
Anytime another project inches its way into another, that's my signal
its poorly placed. I still
Henri,
I would be tempted to schedule major upgrade cycles, while having
minor ones run independently. Still tricky to do, and hurts
innovation. Then again - having a scheduled 'v4.0 of all Commons
components will now be available to be worked on' time might make
innovation happen more
On 01/01/2010, Phil Steitz phil.ste...@gmail.com wrote:
Phil Steitz wrote:
sebb wrote:
On 31/12/2009, Phil Steitz phil.ste...@gmail.com wrote:
Comments have not changed sebb's -1, so I am going to consider this
a failed VOTE and roll another RC with documentation fixes already
This is how I believe the commons.lang.math package can be eliminated.
Based on the current 3.0-SNAPSHOT API, there are only three classes
left:
Fraction
IEEE754rUtils
NumberUtils
1) Fraction should leave; it is completely inappropriate for this
library. It has nothing to do with the JDK or
Online report :
http://vmbuild.apache.org/continuum/buildResult.action?buildId=264868projectId=161
Build statistics:
State: Failed
Previous State: Ok
Started at: Thu 31 Dec 2009 20:25:19 -0800
Finished at: Thu 31 Dec 2009 20:28:36 -0800
Total time: 3m 16s
Build Trigger: Schedule
sebb wrote:
On 01/01/2010, Phil Steitz phil.ste...@gmail.com wrote:
Phil Steitz wrote:
sebb wrote:
On 31/12/2009, Phil Steitz phil.ste...@gmail.com wrote:
Comments have not changed sebb's -1, so I am going to consider this
a failed VOTE and roll another RC with documentation fixes
On Sat, Jan 2, 2010 at 1:34 PM, Paul Benedict pbened...@apache.org wrote:
Henri,
I would be tempted to schedule major upgrade cycles, while having
minor ones run independently. Still tricky to do, and hurts
innovation. Then again - having a scheduled 'v4.0 of all Commons
components will now
On Sat, Jan 2, 2010 at 1:57 PM, Paul Benedict pbened...@apache.org wrote:
This is how I believe the commons.lang.math package can be eliminated.
Based on the current 3.0-SNAPSHOT API, there are only three classes
left:
Fraction
IEEE754rUtils
NumberUtils
1) Fraction should leave; it is
On 02/01/2010, Phil Steitz phil.ste...@gmail.com wrote:
sebb wrote:
On 01/01/2010, Phil Steitz phil.ste...@gmail.com wrote:
Phil Steitz wrote:
sebb wrote:
On 31/12/2009, Phil Steitz phil.ste...@gmail.com wrote:
Comments have not changed sebb's -1, so I am going to consider
To whom it may engage...
This is an automated request, but not an unsolicited one. For
more information please visit http://gump.apache.org/nagged.html,
and/or contact the folk at gene...@gump.apache.org.
Project commons-vfs has an issue affecting its community integration.
This issue
On 03/01/2010, sebb seb...@gmail.com wrote:
On 02/01/2010, Phil Steitz phil.ste...@gmail.com wrote:
sebb wrote:
On 01/01/2010, Phil Steitz phil.ste...@gmail.com wrote:
Phil Steitz wrote:
sebb wrote:
On 31/12/2009, Phil Steitz phil.ste...@gmail.com wrote:
Comments
Online report :
http://vmbuild.apache.org/continuum/buildResult.action?buildId=264954projectId=114
Build statistics:
State: Failed
Previous State: Ok
Started at: Fri 1 Jan 2010 01:22:04 -0800
Finished at: Fri 1 Jan 2010 01:22:50 -0800
Total time: 45s
Build Trigger: Schedule
Build
sebb wrote:
On 02/01/2010, Phil Steitz phil.ste...@gmail.com wrote:
sebb wrote:
On 01/01/2010, Phil Steitz phil.ste...@gmail.com wrote:
Phil Steitz wrote:
sebb wrote:
On 31/12/2009, Phil Steitz phil.ste...@gmail.com wrote:
Comments have not changed sebb's -1, so I am going
sebb wrote:
On 03/01/2010, sebb seb...@gmail.com wrote:
On 02/01/2010, Phil Steitz phil.ste...@gmail.com wrote:
sebb wrote:
On 01/01/2010, Phil Steitz phil.ste...@gmail.com wrote:
Phil Steitz wrote:
sebb wrote:
On 31/12/2009, Phil Steitz phil.ste...@gmail.com wrote:
Online report :
http://vmbuild.apache.org/continuum/buildResult.action?buildId=264992projectId=114
Build statistics:
State: Ok
Previous State: Failed
Started at: Fri 1 Jan 2010 03:53:47 -0800
Finished at: Fri 1 Jan 2010 03:55:31 -0800
Total time: 1m 43s
Build Trigger: Schedule
28 matches
Mail list logo
