I think we're ready for another release candidate.
Does anyone know of any remaining items? JIRA is clean, and I don't
see anything in the email threads that implies more work needs to be
done.
Hen
-
To unsubscribe, e-mail: dev-
Is Pair now good (for a value of consensually agreed good)?
On Mon, Apr 11, 2011 at 7:00 AM, Gary Gregory wrote:
> Hi All:
>
> I added a test to verify the default Pair toString behavior.
>
> For me to replace our custom Pair class at work, I need to customize the to
> String behavior.
>
> Subcla
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-proxy-test has an issue affecting its community integration.
This
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-scxml-test has an issue affecting its community integration.
This
I have 2 classes that implement a good portion of the Jdbc stuff that
I have been using pretty heavily over the last year for various
projects.
The implementation is:
SsDbUtils - A set of Static Functions that implement the JDBC calls
* Integer queryForInt(Connection conn, String sql, Object[
There is also an iterative conjugate gradient solver that is about to go in
as well.
On Tue, Apr 19, 2011 at 1:16 PM, Ted Dunning wrote:
> I am about to check in an implementation of LSMR into Mahout. As always,
> Commons Math is entirely welcome to poach it or any aspect of it.
>
> That might
I am about to check in an implementation of LSMR into Mahout. As always,
Commons Math is entirely welcome to poach it or any aspect of it.
That might or might not be what you want.
2011/4/19 Sébastien Brisard
> Dear All,
> following a previous discussion where I got the impression that such
>
Dear All,
following a previous discussion where I got the impression that such solvers
would be useful in commons-math, I took the liberty to open a wiki page
discussing some design issues. I would really appreciate any feedback, so that
I can submit some code in adequate form.
I do not know if my
Dear Wiki user,
You have subscribed to a wiki page or wiki category on "Commons Wiki" for
change notification.
The "IterativeLinearSolvers" page has been changed by SebastienBrisard.
http://wiki.apache.org/commons/IterativeLinearSolvers?action=diff&rev1=1&rev2=2
Dear Wiki user,
You have subscribed to a wiki page or wiki category on "Commons Wiki" for
change notification.
The "IterativeLinearSolvers" page has been changed by SebastienBrisard.
http://wiki.apache.org/commons/IterativeLinearSolvers
--
New pa
Dear Wiki user,
You have subscribed to a wiki page or wiki category on "Commons Wiki" for
change notification.
The "MathWishList" page has been changed by SebastienBrisard.
http://wiki.apache.org/commons/MathWishList?action=diff&rev1=63&rev2=64
--
Dear Wiki user,
You have subscribed to a wiki page or wiki category on "Commons Wiki" for
change notification.
The "MathWishList" page has been changed by SebastienBrisard.
http://wiki.apache.org/commons/MathWishList?action=diff&rev1=62&rev2=63
--
Le 18/04/2011 21:36, Gary Gregory a écrit :
> Hi All:
>
> This is a VOTE to release commons-parent 21 based on version 21-RC3.
+1
Luc
>
> The VOTE is open until Thursday April 21 16:00 EDT = UTC Thursday, April 21,
> 2011 at 20:00.
>
> Changes:
>
> - Upgrade maven-gpg-plugin to 1.2 from 1.1.
On 04/19/2011 04:00 PM, Mark Thomas wrote:
On 18/04/2011 22:40, sebb wrote:
As suggested by Hen, we should be able to use lazy consensus voting
for Commons Parent pom releases.
[ ] +1 let's use lazy consensus voting for Commons Parent pom in future
[X] -1 why not?
It is a release and that req
On Tue, Apr 19, 2011 at 6:59 PM, sebb wrote:
> Note that Maven core is released to /dist, however AFAICT none of the
> plugins are released to /dist, nor is the Apache Parent Pom.
> So even if Commons uploads the parent pom, it won't be possible to use
> it without relying on Maven Central.
Agre
On 19 April 2011 15:00, Mark Thomas wrote:
> On 18/04/2011 22:40, sebb wrote:
>> As suggested by Hen, we should be able to use lazy consensus voting
>> for Commons Parent pom releases.
>>
>> [ ] +1 let's use lazy consensus voting for Commons Parent pom in future
>> [X] -1 why not?
>
> It is a rele
Sorry, 100% agreement with sebb. I read the attribution wrong :-)
On Tue, Apr 19, 2011 at 10:26 AM, Paul Benedict wrote:
> I carried my Effective Java 2nd Edition book in to work today.
>
> It's item #7. On Page 29 says, Josh says, "While there is no guarantee
> that the finalizer will be invoked
100% agreement with Torsten I carried my Effective Java 2nd Edition book
in to work today.
It's item #7. On Page 29 says, Josh says, "While there is no guarantee
that the finalizer will be invoked promptly, it may be better to free the
resource
late than never, in those (hopefully rare) cases
On 19 April 2011 16:00, Torsten Curdt wrote:
> I am really not comfortable doing all this stuff in finalize. Why use
> finalize at all?
> If someone forgot a close then he has to find and fix this in his code.
>
> Darn. Cannot find the reference I am thinking of why using "finalize"
> usually is r
No point continuing this thread any further.
On 19 April 2011 15:58, Paul Benedict wrote:
> Here is Apache's Release FAQ:
> http://www.apache.org/dev/release.html
>
> There is a line that says "Each PMC must obey the ASF requirements on
> approving any release" but then doesn't divulge those rule
I am really not comfortable doing all this stuff in finalize. Why use
finalize at all?
If someone forgot a close then he has to find and fix this in his code.
Darn. Cannot find the reference I am thinking of why using "finalize"
usually is really a bad idea. Was it from Bloch? Can't remember.
che
Here is Apache's Release FAQ:
http://www.apache.org/dev/release.html
There is a line that says "Each PMC must obey the ASF requirements on
approving any release" but then doesn't divulge those rules. I imagine the
+3 rules applies universally. If they don't, I am about to learn something
new.
Pau
On 19 April 2011 15:30, Stefan Bodewig wrote:
> On 2011-04-19, sebb wrote:
>
>> On 19 April 2011 06:35, wrote:
>
// this flag is only written here and read in finalize() which
// can never be run in parallel.
// no synchronization needed.
>
>> Are you sure?
>
On 4/18/11 2:40 PM, sebb wrote:
> As suggested by Hen, we should be able to use lazy consensus voting
> for Commons Parent pom releases.
>
> [ ] +1 let's use lazy consensus voting for Commons Parent pom in future
> [ ] -1 why not?
-1
Its either a release or its not. If it is, we have to VOTE. It
>> Why are you using the jars from the app server would be my question.
>
> * Because I wouldn't want to modify the installation?
> * Because I'd like to deliver my application to customers so that they
> can deploy in an unmodified environment?
> * Because it works fine that way with the current p
On 19 April 2011 15:27, Stefan Bodewig wrote:
> On 2011-04-19, sebb wrote:
>
>> On 19 April 2011 06:39, wrote:
>
>>> URL:
>>> http://svn.apache.org/viewvc/commons/proper/compress/trunk/src/main/java/org/apache/commons/compress/archivers/zip/ZipFile.java?rev=1094857&r1=1094856&r2=1094857&view=di
On 2011-04-19, sebb wrote:
> On 19 April 2011 06:35, wrote:
>>> // this flag is only written here and read in finalize() which
>>> // can never be run in parallel.
>>> // no synchronization needed.
> Are you sure?
At least as long as finalize is not called by anybody else
On 2011-04-19, sebb wrote:
> On 19 April 2011 06:39, wrote:
>> URL:
>> http://svn.apache.org/viewvc/commons/proper/compress/trunk/src/main/java/org/apache/commons/compress/archivers/zip/ZipFile.java?rev=1094857&r1=1094856&r2=1094857&view=diff
>>
On Tue, Apr 19, 2011 at 3:41 PM, Torsten Curdt wrote:
> Why are you using the jars from the app server would be my question.
* Because I wouldn't want to modify the installation?
* Because I'd like to deliver my application to customers so that they
can deploy in an unmodified environment?
* Bec
On 18/04/2011 22:40, sebb wrote:
> As suggested by Hen, we should be able to use lazy consensus voting
> for Commons Parent pom releases.
>
> [ ] +1 let's use lazy consensus voting for Commons Parent pom in future
> [X] -1 why not?
It is a release and that requires a positive action from the PMC
>>> * source compatibility for x.*.*
>>
>> Disagreed. I can quote numerous examples of application servers that
>> come with varying versions of commons-foo, even within my employers
>> house. Your proposal would mean that I had to create varying jar files
>> of the applications shared library, dep
It seems to me the process worked. It's a nice simple process, so starting
to add exceptions is not my first choice.
Gary
On Tue, Apr 19, 2011 at 3:58 AM, wrote:
> -1 I am not comfortable either with lazy consensus here.
> It is a release and furthermore it is a dependency for all our component
Hi Sebb,
On Mon, Apr 18, 2011 at 7:10 PM, sebb wrote:
> On 18 April 2011 13:48, Hiranya Jayathilaka wrote:
> > On Sat, Jan 29, 2011 at 9:10 PM, Ralph Goers >wrote:
> >
> >> Can you try with the latest source in subversion?
> >>
> >
> > I tried with a latest Commons VFS build and the problem st
On 19 April 2011 06:39, wrote:
> Author: bodewig
> Date: Tue Apr 19 05:39:38 2011
> New Revision: 1094857
>
> URL: http://svn.apache.org/viewvc?rev=1094857&view=rev
> Log:
> don't warn in finalize if the constructor throws an exception and the user
> can not call close at all - happens in Maven2
On 19 April 2011 06:35, wrote:
> Author: bodewig
> Date: Tue Apr 19 05:35:04 2011
> New Revision: 1094856
>
> URL: http://svn.apache.org/viewvc?rev=1094856&view=rev
> Log:
> print a warning if finalize closes the archive
>
> Modified:
>
> commons/proper/compress/trunk/src/main/java/org/apache
On 19 April 2011 06:07, Phil Steitz wrote:
> On 4/18/11 10:02 PM, Stefan Bodewig wrote:
>> On 2011-04-18, Phil Steitz wrote:
>>
>>> The problem is that without logging in to vmbuild, there does not
>>> appear to be a way to get to /target and see all the little
>>> surefire-reports files that mave
On 19 April 2011 08:58, wrote:
> -1 I am not comfortable either with lazy consensus here.
> It is a release and furthermore it is a dependency for all our components as
> what we release is really source code, so the build process is important.
It is a release, but each release is an optional d
On 19 April 2011 09:33, Jochen Wiedmann wrote:
> On Tue, Apr 19, 2011 at 10:16 AM, Torsten Curdt wrote:
>
>> * source compatibility for x.*.*
>
> Disagreed. I can quote numerous examples of application servers that
> come with varying versions of commons-foo, even within my employers
> house. You
Jochen Wiedmann wrote:
> On Tue, Apr 19, 2011 at 10:16 AM, Torsten Curdt wrote:
>
>> * source compatibility for x.*.*
>
> Disagreed. I can quote numerous examples of application servers that
> come with varying versions of commons-foo, even within my employers
> house. Your proposal would mean
What about using the Maven Ant Tasks to write a simple Ant wrapper that
delegates the real work to Maven ? That would ensure the consistency
between the two builds and provide an alternative for people reluctant
to install Maven.
Emmanuel Bourg
smime.p7s
Description: S/MIME Cryptographic Si
On Tue, Apr 19, 2011 at 10:16 AM, Torsten Curdt wrote:
> * source compatibility for x.*.*
Disagreed. I can quote numerous examples of application servers that
come with varying versions of commons-foo, even within my employers
house. Your proposal would mean that I had to create varying jar file
With a version of x.y.z I think it would be sane to expect...
* binary compatibility for x.y.*
* source compatibility for x.*.*
* no compatibility whatsoever for *.*.*
* but *.*.* releases should not clash
I don't think we should cater for any other kind of user stories. If
it's a user wants to u
-1 I am not comfortable either with lazy consensus here.
It is a release and furthermore it is a dependency for all our components as
what we release is really source code, so the build process is important.
We clearly failed with the previous vote, but Gary set up another one quickly.
Luc
Jochen Wiedmann wrote:
> Another topic: Are we, as a PMC, free to allow lazy consensus? After
> all, this is a release in the sense of the ASF (although a very small
> one). I think we should query the board or at least a skilled board
> member before going on. I find it likely that the "3 PMC mem
Another topic: Are we, as a PMC, free to allow lazy consensus? After
all, this is a release in the sense of the ASF (although a very small
one). I think we should query the board or at least a skilled board
member before going on. I find it likely that the "3 PMC members" is
something that we canno
+1
Allow me to disagree, Paul. POM changes will get efficient only, if
they get picked up. This usually happens long before a release of the
dependent project. And if any problems are found, it is relatively
easy to fix them and bring up a new release.
On Tue, Apr 19, 2011 at 12:11 AM, Paul Bened
46 matches
Mail list logo
