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-configuration-test has an issue affecting its community
integrati
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
James Carman wrote:
> If you change the group id, it's probably best to go ahead and change
> the package names also, in case two versions show up on the same
> classpath. Maven won't know that org.apache.commons:common-pool is
> the same as commons-pool:commons-pool, so it would potentially put
Hi all,
I'm personally more with Dennis' opinion, but that's just mine idea.
Question to fill the lack of my knowledge: which is the apache way
when not everybody agrees with one opinion and an important decision -
like this - has to be taken?
Many thanks in advance, have a nice day,
Simo
http:/
Well we've had a discussion very similar to this before.
http://www.mail-archive.com/dev@commons.apache.org/msg15748.html
On Oct 16, 2010 6:48 AM, "Simone Tripodi" wrote:
> Hi all,
> I'm personally more with Dennis' opinion, but that's just mine idea.
>
> Question to fill the lack of my knowledge
Hi James,
thanks for the link :)
I'm for consistency too, so even if I'm no to so enthusiast, and since
Lang3 created a precedent, the new pom metadata will be:
groupId: org.apache.commons
artifactId: commons-pool2
version: 2.0
package: org.apache.commons.pool2
I take in charge to perform this mi
On 10 October 2010 20:40, Siegfried Goeschl
wrote:
> Hi folks,
>
> I would like to call a vote for releasing commons-exec-1.1 based on RC1.
> Below you find the RC coordinates
>
> Cheers,
>
> Siegfried Goeschl
>
>
> Tag:
>
> https://svn.apache.org/repos/asf/commons/proper/exec/tags/COMMONS_EXEC_1
I don't think the package/artifact id idea had come about just yet at that
point in Lang's life
On Oct 16, 2010 7:26 AM, "Simone Tripodi" wrote:
> Hi James,
> thanks for the link :)
> I'm for consistency too, so even if I'm no to so enthusiast, and since
> Lang3 created a precedent, the new pom me
On 16 October 2010 06:18, Simone Tripodi wrote:
> yes, understood and agreed.
> BTW I still find redundant that the same field, used with the same
> semantic, is present in Config,Pool and Factory, my proposal was about
> keeping the Config only - immutable fields can be declared there - and
> rem
Thanks for the feedbacks Seb!!!
what about if I start implementing a proposal and then we
progressively refine the design?
Simo
http://people.apache.org/~simonetripodi/
http://www.99soft.org/
On Sat, Oct 16, 2010 at 1:46 PM, sebb wrote:
> On 16 October 2010 06:18, Simone Tripodi wrote:
>> yes
The current build files (Ant and Maven) assume that the Java source
and target versions are 1.3.
However, some of the Java source files make use of methods and classes
that require later versions of Java
For example:
java.net.InterfaceAddress requires 1.6
java.net.NetworkInterface - 1.4
FileOut
On 16 October 2010 13:10, Simone Tripodi wrote:
> Thanks for the feedbacks Seb!!!
> what about if I start implementing a proposal and then we
> progressively refine the design?
Fine by me.
But it might be better to look at how the Tomcat JDBC pool
implementation might be of use before polishing
1.5 is good with me, but then we open up the major/minor version number can
of worms
On Oct 16, 2010 8:40 AM, "sebb" wrote:
> The current build files (Ant and Maven) assume that the Java source
> and target versions are 1.3.
>
> However, some of the Java source files make use of methods and classe
On 16 October 2010 13:46, James Carman wrote:
> 1.5 is good with me, but then we open up the major/minor version number can
> of worms
That's a separate issue.
First we need to resolve the minimum Java version so the code can be built.
> On Oct 16, 2010 8:40 AM, "sebb" wrote:
>> The current bu
On 10/16/2010 02:32 PM, sebb wrote:
The current build files (Ant and Maven) assume that the Java source
and target versions are 1.3.
Exactly.
However, some of the Java source files make use of methods and classes
that require later versions of Java
For example:
java.net.InterfaceAddress re
BTW for the examples there's no version requirement, so
you can use even java6. I don't care.
Dunno if it's possible to have separate compiler settings
in build.xml for that.
Anyhow, like said. common-daemon.jar is 1.3.
Everything else is sugar added, so irrelevant.
On 10/16/2010 02:32 PM, seb
Why the affinity for 1.3? Is it common for the platforms on which daemon is
run to be restricted to 1.3?
On Oct 16, 2010 9:21 AM, "Mladen Turk" wrote:
> BTW for the examples there's no version requirement, so
> you can use even java6. I don't care.
>
> Dunno if it's possible to have separate comp
When you say consistent, what are you referring to? The fact that lang
has done it once?
It is not the Maven way to change the artifactId when a new major
version comes out. And since we are talking about the Maven
"coordinates" (groupId, artifactId, version) I think it is best to
follow the stand
On 16 October 2010 14:14, Mladen Turk wrote:
> On 10/16/2010 02:32 PM, sebb wrote:
>>
>> The current build files (Ant and Maven) assume that the Java source
>> and target versions are 1.3.
>>
>
> Exactly.
>
>> However, some of the Java source files make use of methods and classes
>> that require l
We have come up with a game plan that allows multiple versions of our
libraries to be on the classpath at the same time (changing artifact and
package name). Lang is doing things according to that plan and we hope
others will follow suit. We had this discussion long ago and we don't need
to rehas
On 16 October 2010 14:21, Mladen Turk wrote:
> BTW for the examples there's no version requirement, so
> you can use even java6. I don't care.
>
> Dunno if it's possible to have separate compiler settings
> in build.xml for that.
Yes, that's certainly possible as it has a separate Ant build file.
On 10/16/10 10:03 AM, James Carman wrote:
We have come up with a game plan that allows multiple versions of our
libraries to be on the classpath at the same time (changing artifact and
package name). Lang is doing things according to that plan and we hope
others will follow suit. We had this di
On 10/16/2010 03:27 PM, James Carman wrote:
Why the affinity for 1.3? Is it common for the platforms on which daemon is
run to be restricted to 1.3?
It's not about that. It's about binary compatibility.
You cannot break binary compatibility without changing
the major version.
And yes, some of
Online report :
http://vmbuild.apache.org/continuum/buildResult.action?buildId=1139&projectId=71
Build statistics:
State: Failed
Previous State: Ok
Started at: Sat 16 Oct 2010 14:20:21 +
Finished at: Sat 16 Oct 2010 14:24:16 +
Total time: 3m 54s
Build Trigger: Schedule
Build
On 10/16/2010 03:56 PM, sebb wrote:
Those are all examples *you* made recently.
I created some of the original code, but AFAICT you have added some fixes.
And Main.java and DaemonConfiguration were yours; both use Arrays.copyOf().
Huh. I thought this was 1.3. I'll change that to something
Well at the time, we were under the impression that maven oils only allow
one copy of the group:artifact on the classpath. Has that changed?
On Oct 16, 2010 10:21 AM, "Phil Steitz" wrote:
> On 10/16/10 10:03 AM, James Carman wrote:
>> We have come up with a game plan that allows multiple versions
On Sat, Oct 16, 2010 at 3:21 PM, Phil Steitz wrote:
> On 10/16/10 10:03 AM, James Carman wrote:
>>
>> We have come up with a game plan that allows multiple versions of our
>> libraries to be on the classpath at the same time (changing artifact and
>> package name). Lang is doing things according
On 16 October 2010 15:24, Mladen Turk wrote:
> On 10/16/2010 03:56 PM, sebb wrote:
>>>
>>> Those are all examples *you* made recently.
>>
>> I created some of the original code, but AFAICT you have added some fixes.
Turns out that the non-1.3 code in samples is all in
ProcrunService.logSystemEnvi
On 16 October 2010 15:25, James Carman wrote:
> Well at the time, we were under the impression that maven oils only allow
> one copy of the group:artifact on the classpath. Has that changed?
No, but if one changes groupId, then there is no need to change
artifactId as well.
> On Oct 16, 2010 10
On Sat, Oct 16, 2010 at 10:25 AM, James Carman
wrote:
> Well at the time, we were under the impression that maven oils only allow
> one copy of the group:artifact on the classpath. Has that changed?
>
I'll answer my own question. With this pom.xml file:
http://maven.apache.org/POM/4.0.0";
xmln
On Sat, Oct 16, 2010 at 10:41 AM, sebb wrote:
>
> No, but if one changes groupId, then there is no need to change
> artifactId as well.
>
As I said, it's not required, but preferred to keep things consistent.
Our artifact ids should correspond to the package names.
-
On 10/16/2010 04:37 PM, sebb wrote:
On 16 October 2010 15:24, Mladen Turk wrote:
On 10/16/2010 03:56 PM, sebb wrote:
Those are all examples *you* made recently.
I created some of the original code, but AFAICT you have added some fixes.
Turns out that the non-1.3 code in samples is all in
On 16 October 2010 15:46, James Carman wrote:
> On Sat, Oct 16, 2010 at 10:41 AM, sebb wrote:
>>
>> No, but if one changes groupId, then there is no need to change
>> artifactId as well.
>>
>
> As I said, it's not required, but preferred to keep things consistent.
> Our artifact ids should corre
Checked trunk build on WinXP & Mac OS / jdk 1.6; mvn site ok (besides javadoc
link).
+1
Henrib
--
View this message in context:
http://apache-commons.680414.n4.nabble.com/VOTE-Release-Commons-IO-2-0-based-on-RC5-tp2996424p2998344.html
Sent from the Commons - Dev mailing list archive at Nabble.c
On Sat, Oct 16, 2010 at 10:52 AM, sebb wrote:
>
> Why? I don't see the point.
>
We had this discussion long ago. Let me try to summarize for you.
Suppose Project X wants to use commons foo version 2. Suppose also
that Project X uses Project Y as a dependency and Project Y uses
commons foo versi
On Sat, Oct 16, 2010 at 10:34 AM, Niall Pemberton
wrote:
>
> +1 to what Dennis says. Changing the artifactId doesn't accompilsh
> anything additional if the groupId is changing.
>
Other than keeping things consistent. But, apparently folks around
here aren't as concerned with that as I am, becau
On 16 October 2010 15:46, Mladen Turk wrote:
> On 10/16/2010 04:37 PM, sebb wrote:
>>
>> On 16 October 2010 15:24, Mladen Turk wrote:
>>>
>>> On 10/16/2010 03:56 PM, sebb wrote:
>
> Those are all examples *you* made recently.
I created some of the original code, but AFAICT you h
On 16 October 2010 15:58, wrote:
> Author: mturk
> Date: Sat Oct 16 14:58:39 2010
> New Revision: 1023303
>
> URL: http://svn.apache.org/viewvc?rev=1023303&view=rev
> Log:
> DAEMON-177: Allow fail during init. Patch provided by Nick Griffiths
>
> Added:
>
> commons/proper/daemon/trunk/src/jav
On Sat, Oct 16, 2010 at 4:02 PM, James Carman
wrote:
> On Sat, Oct 16, 2010 at 10:34 AM, Niall Pemberton
> wrote:
>>
>> +1 to what Dennis says. Changing the artifactId doesn't accompilsh
>> anything additional if the groupId is changing.
>>
>
> Other than keeping things consistent. But, apparent
Looks good to me; checked trunk build on WinXP / Mac OS X - jdk1.6.
+1
Henrib
--
View this message in context:
http://apache-commons.680414.n4.nabble.com/VOTE-Release-commons-exec-1-1-based-on-RC1-tp2970579p2998397.html
Sent from the Commons - Dev mailing list archive at Nabble.com.
--
On Sat, Oct 16, 2010 at 12:23 PM, Niall Pemberton
wrote:
>
> Consistency is good, but deciding something based purely on
> *consistency* rather than the merits of the situation is mindless.
>
Trying to keep things consistent is being mindful of the user's needs.
The consistency is part of the si
Hi Seb! :)
Of course, thanks for the suggestion!
Simo
http://people.apache.org/~simonetripodi/
http://www.99soft.org/
On Sat, Oct 16, 2010 at 2:51 PM, sebb wrote:
> On 16 October 2010 13:10, Simone Tripodi wrote:
>> Thanks for the feedbacks Seb!!!
>> what about if I start implementing a propo
On Sat, Oct 16, 2010 at 5:52 PM, James Carman
wrote:
> On Sat, Oct 16, 2010 at 12:23 PM, Niall Pemberton
> wrote:
>>
>> Consistency is good, but deciding something based purely on
>> *consistency* rather than the merits of the situation is mindless.
>>
>
> Trying to keep things consistent is bein
Hi all guys,
please don't take me as mindless guy, I really adore commons and you
can't immagine how
happy - and lucky! - I am to be active part of this community.
I'm an entusiast guy with a strong wish to contribute, BTW I still
miss some core parts of the community ecosystem, so when I've the f
On 10/16/10 12:52 PM, James Carman wrote:
On Sat, Oct 16, 2010 at 12:23 PM, Niall Pemberton
wrote:
Consistency is good, but deciding something based purely on
*consistency* rather than the merits of the situation is mindless.
Trying to keep things consistent is being mindful of the user's
On Sat, Oct 16, 2010 at 6:20 PM, Phil Steitz wrote:
> On 10/16/10 12:52 PM, James Carman wrote:
>>
>> On Sat, Oct 16, 2010 at 12:23 PM, Niall Pemberton
>> wrote:
>>>
>>> Consistency is good, but deciding something based purely on
>>> *consistency* rather than the merits of the situation is mindl
Java 5 or 6 is ok with me but the version number needs to bump.
Gary
On Oct 16, 2010, at 5:53, "James Carman" wrote:
> 1.5 is good with me, but then we open up the major/minor version number can
> of worms
> On Oct 16, 2010 8:40 AM, "sebb" wrote:
>> The current build files (Ant and Maven) ass
On Oct 16, 2010, at 10:21, "Phil Steitz" wrote:
> On 10/16/10 12:52 PM, James Carman wrote:
>> On Sat, Oct 16, 2010 at 12:23 PM, Niall Pemberton
>> wrote:
>>>
>>> Consistency is good, but deciding something based purely on
>>> *consistency* rather than the merits of the situation is mindless.
On 2010-10-16 16:58, James Carman wrote:
> On Sat, Oct 16, 2010 at 10:52 AM, sebb wrote:
>>
>> Why? I don't see the point.
>>
>
> We had this discussion long ago. Let me try to summarize for you.
> Suppose Project X wants to use commons foo version 2. Suppose also
> that Project X uses Project
On Oct 16, 2010, at 7:59, "James Carman" wrote:
> On Sat, Oct 16, 2010 at 10:52 AM, sebb wrote:
>>
>> Why? I don't see the point.
>>
>
> We had this discussion long ago. Let me try to summarize for you.
> Suppose Project X wants to use commons foo version 2. Suppose also
> that Project X us
Ah crap. Will fix tomo.
On 16 Oct 2010 16:34, "sebb" wrote:
> On 16 October 2010 15:58, wrote:
>> Author: mturk
>> Date: Sat Oct 16 14:58:39 2010
>> New Revision: 1023303
>>
>> URL: http://svn.apache.org/viewvc?rev=1023303&view=rev
>> Log:
>> DAEMON-177: Allow fail during init. Patch provided by
On 10/16/10 3:57 PM, Gary Gregory wrote:
On Oct 16, 2010, at 10:21, "Phil Steitz" wrote:
On 10/16/10 12:52 PM, James Carman wrote:
On Sat, Oct 16, 2010 at 12:23 PM, Niall Pemberton
wrote:
Consistency is good, but deciding something based purely on
*consistency* rather than the merits of
I just created a dbcp 1.4 legacy branch, so we can now start work
toward dbcp 2.0 in trunk. Pool is already off to the races. As we
have discussed, I would like to start exploring bringing in the
Tomcat jdbc-pool code, split somehow between [pool] and [dbcp].
To get [dbcp] moving, I would li
If you are changing the groupId, there's no point in changing the artifactId.
On Sat, Oct 16, 2010 at 9:38 PM, Phil Steitz wrote:
> I just created a dbcp 1.4 legacy branch, so we can now start work toward
> dbcp 2.0 in trunk. Pool is already off to the races. As we have discussed,
> I would lik
> -Original Message-
> From: Phil Steitz [mailto:phil.ste...@gmail.com]
> Sent: Saturday, October 16, 2010 19:39
> To: Commons Developers List
> Subject: [dbcp] 2.0 prep
>
> I just created a dbcp 1.4 legacy branch, so we can now start work
> toward dbcp 2.0 in trunk. Pool is already off t
On 10/16/10 11:02 PM, Paul Benedict wrote:
If you are changing the groupId, there's no point in changing the artifactId.
See related discussion on [pool]. While we can avoid changing the
artifactId for 2.0 since the groupId change creates the necessary
separation of artifacts, we will need t
Oh I've been reading :-) I participated in the Lang 3 decision and we
decided (1) new package name (2) new groupId (3) same artifactId.
Why do you think you need to change the artifactId? Look below and
tell me what you don't like about this progression.
commons-dbcp:commons-dbcp:1.4
org.apache.c
On Sun, Oct 17, 2010 at 12:53 AM, Paul Benedict wrote:
> Oh I've been reading :-) I participated in the Lang 3 decision and we
> decided (1) new package name (2) new groupId (3) same artifactId.
>
> Why do you think you need to change the artifactId? Look below and
> tell me what you don't like ab
On Sun, Oct 17, 2010 at 12:53 AM, Paul Benedict wrote:
> Oh I've been reading :-) I participated in the Lang 3 decision and we
> decided (1) new package name (2) new groupId (3) same artifactId.
>
Check out:
http://svn.apache.org/repos/asf/commons/proper/lang/trunk/pom.xml
The artifactId is com
On Sat, Oct 16, 2010 at 11:02 PM, Paul Benedict wrote:
> If you are changing the groupId, there's no point in changing the artifactId.
>
It's like I'm reliving the same day over and over again, like the
movie Groundhog Day. Am I the only one noticing the fact that we have
to rehash this discussi
60 matches
Mail list logo
