Commons IO 1.4 release candidate 1 (RC1) is available for review. The
artifacts are here:
http://people.apache.org/~niallp/io-1.4-RC1/
SVN Tag:
http://svn.apache.org/viewvc/commons/proper/io/tags/commons-io-1.4-RC1/
Site:
http://people.apache.org/~niallp/io-1.4-RC1/site/
(note m2 generates relati
On Jan 12, 2008 11:44 PM, Phil Steitz <[EMAIL PROTECTED]> wrote:
> This is a vote to release commons pool 1.4.
>
> The signed source distributions (what we are voting on) are here:
> http://people.apache.org/~psteitz/pool-1.4-RC3/distributions/commons-pool-1.4-src.tar.gz
> http://people.apache.org/
Ugh. Yes. Release notes are here:
http://people.apache.org/~psteitz/pool-1.4-RC3/RELEASE-NOTES.txt
On Jan 12, 2008 4:55 PM, Gary Gregory <[EMAIL PROTECTED]> wrote:
> You must have meant:
>
> Release Notes:
> http://people.apache.org/~psteitz/pool-1.4-RC3/RELEASE-NOTES.txt
>
> instead of the RC2.
On Jan 12, 2008 3:37 PM, Rahul Akolkar <[EMAIL PROTECTED]> wrote:
> On 1/12/08, Jochen Wiedmann <[EMAIL PROTECTED]> wrote:
> > On Jan 12, 2008 3:25 PM, simon <[EMAIL PROTECTED]> wrote:
> >
> > > I don't see the point of that at all. Commons-xxx projects do not exist
> > > for the purposes of testin
You must have meant:
Release Notes:
http://people.apache.org/~psteitz/pool-1.4-RC3/RELEASE-NOTES.txt
instead of the RC2.
Thank you,
Gary
> -Original Message-
> From: Phil Steitz [mailto:[EMAIL PROTECTED]
> Sent: Saturday, January 12, 2008 3:44 PM
> To: Commons Developers List
> Subject:
+1
Phil
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
On Jan 12, 2008 3:45 PM, Rahul Akolkar <[EMAIL PROTECTED]> wrote:
> On 1/12/08, Luc Maisonobe <[EMAIL PROTECTED]> wrote:
> > One comment about this change: this would break compatibility with
> > version 1.1 and the clirr plugin flags this as an error.
>
>
> That was my initial reaction as well wh
This is a vote to release commons pool 1.4.
The signed source distributions (what we are voting on) are here:
http://people.apache.org/~psteitz/pool-1.4-RC3/distributions/commons-pool-1.4-src.tar.gz
http://people.apache.org/~psteitz/pool-1.4-RC3/distributions/commons-pool-1.4-src.zip
Site:
http:/
On 1/12/08, Luc Maisonobe <[EMAIL PROTECTED]> wrote:
> One comment about this change: this would break compatibility with
> version 1.1 and the clirr plugin flags this as an error.
That was my initial reaction as well when I read your first note
(below). In general, we try to avoid incompatible c
On 1/12/08, Niall Pemberton <[EMAIL PROTECTED]> wrote:
>
> [X] +1
> [ ] =0
> [ ] -1
-Rahul
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
On 1/12/08, Jochen Wiedmann <[EMAIL PROTECTED]> wrote:
> On Jan 12, 2008 3:25 PM, simon <[EMAIL PROTECTED]> wrote:
>
> > I don't see the point of that at all. Commons-xxx projects do not exist
> > for the purposes of testing maven plugins. If commons-xxx can build
> > successfully with version N of
+1
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
On 1/11/08, Dennis Lundberg <[EMAIL PROTECTED]> wrote:
> Rahul Akolkar wrote:
> > On 1/11/08, Niall Pemberton <[EMAIL PROTECTED]> wrote:
> >> On Jan 11, 2008 10:06 AM, Jochen Wiedmann <[EMAIL PROTECTED]> wrote:
> >>> On Jan 11, 2008 10:57 AM, Niall Pemberton <[EMAIL PROTECTED]> wrote:
> >>>
>
One comment about this change: this would break compatibility with
version 1.1 and the clirr plugin flags this as an error. However we
already have clirr errors in the report since the 2 protected fields eDA
and windowSize have been removed from the now deprecated
DescriptiveStatisticsImpl clas
I am performing a new pass on removing findbugs warnings.
One warning occurs in both BigMatrixImpl and RealMatrixImpl, it is about
the protected field TOO_SMALL that according to findbugs should be
final. I agree with it. This field is also protected whereas I would
prefer it to be private. It
Niall Pemberton wrote:
Vote is open for 72 hours
+1
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
Hi,
Seems like discussion has concluded so trying again...
The changes since the the last release of version 6 in summary:
Changes to the pom.xml:
- Configure NOTICE.txt and LICENSE.txt resources
- add *hack* to put NOTICE/LICENSE in the -javadoc.jar
- Change the order of the mail archives
-
On Jan 12, 2008 3:35 PM, Dennis Lundberg <[EMAIL PROTECTED]> wrote:
> I thought that the release of parent-7 was a preparation for the release
> of IO 1.4...
It was and perhaps may happen - but I didn't want to loose momentum on
Commons IO because of commons-parent. I'm just sorting out IO last fe
simon wrote:
On Sat, 2008-01-12 at 14:38 +0100, Dennis Lundberg wrote:
simon wrote:
On Sat, 2008-01-12 at 00:20 +, Niall Pemberton wrote:
On Jan 11, 2008 11:29 PM, Dennis Lundberg <[EMAIL PROTECTED]> wrote:
Jochen Wiedmann wrote:
On Jan 11, 2008 10:57 AM, Niall Pemberton <[EMAIL PROTECTE
Niall Pemberton wrote:
I just made some more changes to commons-parent:
http://svn.apache.org/viewvc?view=rev&revision=611126
This includes the "hack" to put the NOTICE/LICENSE files in the
javadoc jar (which Dennis was -1 to, but three people agreed). See
http://tinyurl.com/2zueu5 for all cha
I thought that the release of parent-7 was a preparation for the release
of IO 1.4...
Niall Pemberton wrote:
I'd rather not depend on the SNAPSHOT pom because IO 1.4 could well be
released before commons-parent.
Niall
On Jan 12, 2008 2:13 PM, <[EMAIL PROTECTED]> wrote:
Author: dennisl
Date:
I'd rather not depend on the SNAPSHOT pom because IO 1.4 could well be
released before commons-parent.
Niall
On Jan 12, 2008 2:13 PM, <[EMAIL PROTECTED]> wrote:
> Author: dennisl
> Date: Sat Jan 12 06:13:49 2008
> New Revision: 611418
>
> URL: http://svn.apache.org/viewvc?rev=611418&view=rev
> L
On Jan 12, 2008 3:25 PM, simon <[EMAIL PROTECTED]> wrote:
> I don't see the point of that at all. Commons-xxx projects do not exist
> for the purposes of testing maven plugins. If commons-xxx can build
> successfully with version N of a plugin, then there is no reason to ever
> use any other versi
On Jan 12, 2008 2:33 PM, Dennis Lundberg <[EMAIL PROTECTED]> wrote:
> Niall Pemberton wrote:
> > This is not quite the case - reproducability is the reason for
> > specifying the version, but not the reason for specifying the version
> > in the parent pom. The reason for specifying version numbers
On Sat, 2008-01-12 at 14:38 +0100, Dennis Lundberg wrote:
> simon wrote:
> > On Sat, 2008-01-12 at 00:20 +, Niall Pemberton wrote:
> >> On Jan 11, 2008 11:29 PM, Dennis Lundberg <[EMAIL PROTECTED]> wrote:
> >>> Jochen Wiedmann wrote:
> On Jan 11, 2008 10:57 AM, Niall Pemberton <[EMAIL PRO
Jochen Wiedmann wrote:
On Jan 12, 2008 12:29 AM, Dennis Lundberg <[EMAIL PROTECTED]> wrote:
The reason is to have reproducible builds. It makes sure that, no matter
who is building component A, the end result will always be the same.
Specifying versions for all plugins is considered a best pra
simon wrote:
On Sat, 2008-01-12 at 00:20 +, Niall Pemberton wrote:
On Jan 11, 2008 11:29 PM, Dennis Lundberg <[EMAIL PROTECTED]> wrote:
Jochen Wiedmann wrote:
On Jan 11, 2008 10:57 AM, Niall Pemberton <[EMAIL PROTECTED]> wrote:
Theres also the issue of specifying the "version" of the
rem
Niall Pemberton wrote:
On Jan 11, 2008 11:29 PM, Dennis Lundberg <[EMAIL PROTECTED]> wrote:
Jochen Wiedmann wrote:
On Jan 11, 2008 10:57 AM, Niall Pemberton <[EMAIL PROTECTED]> wrote:
Theres also the issue of specifying the "version" of the
remote-resources-plugin - which in previous discussi
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 [EMAIL PROTECTED]
Project commons-jelly-tags-jaxme has an issue affecting its community
integration.
This
On Sat, 2008-01-12 at 00:20 +, Niall Pemberton wrote:
> On Jan 11, 2008 11:29 PM, Dennis Lundberg <[EMAIL PROTECTED]> wrote:
> > Jochen Wiedmann wrote:
> > > On Jan 11, 2008 10:57 AM, Niall Pemberton <[EMAIL PROTECTED]> wrote:
> > >
> > >> Theres also the issue of specifying the "version" of t
30 matches
Mail list logo
