Paul Benedict wrote:
> When I was patching Hibernate, they needed different sources because
> of JDBC3/4 incompatibility. It just wasn't possible to compile for
> both dependencies.
>
> I just checked with Brett Porter of Maven. He says that if the sources
> are identical, you can use qualifiers;
If we want to implement LANG-508 (Validate: add message parameter
construction via elllipsis notation to speed up processing), I am
really concerned with the many overloaded versions of #validIndex()
and #notEmpty() that solely differ by static argument type:
Collection, Object, Object[], CharSeque
sebb wrote:
> I've updated the Commons Logging version, because that's obviously sensible.
>
> The Maven dependency checker suggests the following updates:
>
> org.apache.geronimo.modules:geronimo-transaction ... 1.2-beta -> 2.1.4
> (test scope)
> org.apache.geronimo.specs:geronimo-jta_1.1_spec .
When I was patching Hibernate, they needed different sources because
of JDBC3/4 incompatibility. It just wasn't possible to compile for
both dependencies.
I just checked with Brett Porter of Maven. He says that if the sources
are identical, you can use qualifiers; otherwise it would conflict
when
On Wed, Nov 25, 2009 at 11:09 PM, Phil Steitz wrote:
> Niall Pemberton wrote:
>> On Wed, Nov 25, 2009 at 10:55 PM, Mladen Turk wrote:
>>> On 11/25/2009 10:26 PM, Phil Steitz wrote:
Done now. The site is up at http://commons.apache.org/sandbox/runtime/
and the main commons site menus an
Niall,
Since the "sources" and "javadocs" are qualifiers, I am concerned
there is an incompatibility here. I can't prove it, but I suspect
there might be.
Paul
On Wed, Nov 25, 2009 at 6:51 PM, Niall Pemberton
wrote:
> On Thu, Nov 26, 2009 at 12:46 AM, Paul Benedict wrote:
>> Does adding a clas
I've updated the Commons Logging version, because that's obviously sensible.
The Maven dependency checker suggests the following updates:
org.apache.geronimo.modules:geronimo-transaction ... 1.2-beta -> 2.1.4
(test scope)
org.apache.geronimo.specs:geronimo-jta_1.1_spec . 1.1 -> 1.1.1
(opt
On Thu, Nov 26, 2009 at 12:46 AM, Paul Benedict wrote:
> Does adding a classifier like "jdbc3" affect the creation of the
> -source and -javadoc classifiers?
I don't believe it should - those are produced by the sources and
javadoc plugins respectively. In the commons build those plugins are
conf
Does adding a classifier like "jdbc3" affect the creation of the
-source and -javadoc classifiers?
On Wed, Nov 25, 2009 at 6:06 PM, Phil Steitz wrote:
> Niall Pemberton wrote:
>> On Wed, Nov 25, 2009 at 11:39 PM, Niall Pemberton
>> wrote:
>>> On Wed, Nov 25, 2009 at 11:31 PM, Phil Steitz wrote:
Niall Pemberton wrote:
> On Wed, Nov 25, 2009 at 11:39 PM, Niall Pemberton
> wrote:
>> On Wed, Nov 25, 2009 at 11:31 PM, Phil Steitz wrote:
>>> Niall Pemberton wrote:
On Wed, Nov 25, 2009 at 10:23 PM, Paul Benedict
wrote:
> Phil,
>
> I don't think you should be modifying t
On Wed, Nov 25, 2009 at 11:39 PM, Niall Pemberton
wrote:
> On Wed, Nov 25, 2009 at 11:31 PM, Phil Steitz wrote:
>> Niall Pemberton wrote:
>>> On Wed, Nov 25, 2009 at 10:23 PM, Paul Benedict
>>> wrote:
Phil,
I don't think you should be modifying the version (and groups, really)
>>
On Wed, Nov 25, 2009 at 11:31 PM, Phil Steitz wrote:
> Niall Pemberton wrote:
>> On Wed, Nov 25, 2009 at 10:23 PM, Paul Benedict wrote:
>>> Phil,
>>>
>>> I don't think you should be modifying the version (and groups, really)
>>> here. All the artifacts belong to version 1.3.
>>>
>>> Maven does ha
I think Niall has good counterpoints. I think his point is summed up with:
* Keep same groupId
* Keep same artifactId
* Keep same version
* Different classifiers are appropriate.
If so, I am +1 with it.
Paul
On Wed, Nov 25, 2009 at 5:25 PM, Niall Pemberton
wrote:
> On Wed, Nov 25, 2009 at 10:2
Niall Pemberton wrote:
> On Wed, Nov 25, 2009 at 10:23 PM, Paul Benedict wrote:
>> Phil,
>>
>> I don't think you should be modifying the version (and groups, really)
>> here. All the artifacts belong to version 1.3.
>>
>> Maven does have a concept of a qualifier, but according to Sonatype,
>> it's
On Wed, Nov 25, 2009 at 10:23 PM, Paul Benedict wrote:
> Phil,
>
> I don't think you should be modifying the version (and groups, really)
> here. All the artifacts belong to version 1.3.
>
> Maven does have a concept of a qualifier, but according to Sonatype,
> it's only to capture milestone build
Olivier Lamy wrote:
> Hi Folks,
> If you change groupId could you please provide a relocation pom in the
> old groupId
> commons-dbcp:commons-dbcp:1.3 -> org.apache.commons:commons-dbcp-jdbc3:1.3
Will do if we decide to go that route.
Phil
>
> --
> Olivier
>
> 2009/11/26 Phil Steitz :
>> Paul B
Niall Pemberton wrote:
> On Wed, Nov 25, 2009 at 10:55 PM, Mladen Turk wrote:
>> On 11/25/2009 10:26 PM, Phil Steitz wrote:
>>> Done now. The site is up at http://commons.apache.org/sandbox/runtime/
>>> and the main commons site menus and component table have been
>>> updated (will take an hour o
Correction:
For users who use employ version ranges in their POMs like "[1.3,)"
they are telling Maven they want >= 1.3. It is misleading -- I
actually believe wrong -- to say that the "1.3-jdbc3" version is a
greater version than
than version "1.3".
Paul
On Wed, Nov 25, 2009 at 5:05 PM, Paul Be
Hi Folks,
If you change groupId could you please provide a relocation pom in the
old groupId
commons-dbcp:commons-dbcp:1.3 -> org.apache.commons:commons-dbcp-jdbc3:1.3
--
Olivier
2009/11/26 Phil Steitz :
> Paul Benedict wrote:
>> Phil,
>>
>> I don't think you should be modifying the version (and
Brent,
If you haven't read the Sonatype link, it tells some important things
about how the version number is interpreted by Maven. The standard is
using 3 numbers, and it allows Maven to know that, for example, 1.3 <
1.4. But what happens if you version as "1.3-jdbc3"? Is anyone going
to confident
On Wed, Nov 25, 2009 at 10:55 PM, Mladen Turk wrote:
> On 11/25/2009 10:26 PM, Phil Steitz wrote:
>>>
>> Done now. The site is up at http://commons.apache.org/sandbox/runtime/
>> and the main commons site menus and component table have been
>> updated (will take an hour or so to replicate).
>>
>
Paul Benedict wrote:
> Phil,
>
> I don't think you should be modifying the version (and groups, really)
> here. All the artifacts belong to version 1.3.
>
> Maven does have a concept of a qualifier, but according to Sonatype,
> it's only to capture milestone builds:
> http://www.sonatype.com/book
On Wed, Nov 25, 2009 at 4:23 PM, Paul Benedict wrote:
>
> Phil,
>
> I don't think you should be modifying the version (and groups, really)
> here. All the artifacts belong to version 1.3.
>
> Maven does have a concept of a qualifier, but according to Sonatype,
> it's only to capture milestone buil
On 11/25/2009 10:26 PM, Phil Steitz wrote:
Done now. The site is up at http://commons.apache.org/sandbox/runtime/
and the main commons site menus and component table have been
updated (will take an hour or so to replicate).
Excellent. Many thanks.
Sorry the template was misleading and ou
Phil,
I don't think you should be modifying the version (and groups, really)
here. All the artifacts belong to version 1.3.
Maven does have a concept of a qualifier, but according to Sonatype,
it's only to capture milestone builds:
http://www.sonatype.com/books/maven-book/reference/pom-relationsh
Phil Steitz wrote:
> I am about to roll an RC and I need to make sure all are OK with the
> artifact names and repo placement
>
> JDBC 4 version (JDK 1.6)
> groupId org.apache.maven
Oops! I obviously mean commons above :)
> artifactID commons-dbcp
> version 1.3
>
> JDBC 3 version (JDK 1.4-1.5)
I am about to roll an RC and I need to make sure all are OK with the
artifact names and repo placement
JDBC 4 version (JDK 1.6)
groupId org.apache.maven
artifactID commons-dbcp
version 1.3
JDBC 3 version (JDK 1.4-1.5)
groupId commons-dbcp
artifactId commons-dbcp
version 1.3-jdbc3
Giving the 1.3
Mladen Turk wrote:
> On 11/25/2009 06:42 PM, Phil Steitz wrote:
>>
>> Would you be OK with maven 2 to build the runtime site?
>
> I really don't care. If maven2 is required, fine with me.
>
>>
>> I can set this up for you, but to maintain it you will need maven 2.
>>
>
> That would be perfect.
>
sebb wrote:
> At present, in order to build DBCP using Ant, one has to copy
> build.properties.sample to build.properties otherwise none of the
> dependencies are found.
The build.properties.sample props only work if you have a m2 local
repo. I would prefer to leave as is so user knows what they
At present, in order to build DBCP using Ant, one has to copy
build.properties.sample to build.properties otherwise none of the
dependencies are found.
Seems to me the Ant file should load properties from
build.properties.sample immediately after loading from
build.properties - if that exists. Bui
sebb wrote:
> On 24/11/2009, Phil Steitz wrote:
>> sebb wrote:
>> > On 24/11/2009, sebb wrote:
>> >> On 24/11/2009, Phil Steitz wrote:
>> >> > Phil Steitz wrote:
>> >> > > sebb wrote:
>> >> > >> On 22/11/2009, Phil Steitz wrote:
>> >> > >>> I am running into some problems preparing
On 11/25/2009 06:42 PM, Phil Steitz wrote:
Would you be OK with maven 2 to build the runtime site?
I really don't care. If maven2 is required, fine with me.
I can set this up for you, but to maintain it you will need maven 2.
That would be perfect.
Thanks
--
^TM
--
Mladen Turk wrote:
> On 11/25/2009 04:02 PM, Phil Steitz wrote:
>>
>> Looks like [runtime] has a Maven 1 build.
>
> It doesn't. Those are generated files.
> Build system will use ant with Runtime's own
> ant extensions for making custom .jar files
> containing both Java and Native components.
>
>
sebb wrote:
> On 25/11/2009, Phil Steitz wrote:
>> sebb wrote:
>> > On 23/11/2009, sebb wrote:
>> >> The JUnit tests produce a lot of output, even if the tests are
>> successful.
>> >>
>> >> Is there really any need to print stack traces in the following method?
>> >>
>> >> TestSharedPoo
Hi Jukka,
Hi,
Apache Mahout is moving to fully a Maven-based build/release process
and they're having problems with the commons-cli 2.0 dependency which
I believe they get through Hadoop. To solve the dependency issue,
Mahout has deployed that snapshot to Maven central as
org.apache.mahout.comm
Thanks Nial; package name change committed in trunk
(http://svn.apache.org/viewvc?rev=884175&view=rev).
--
View this message in context:
http://n4.nabble.com/JEXL-2-0-o-a-c-jexl-or-o-a-c-jexl2-tp727081p787678.html
Sent from the Commons - Dev mailing list archive at Nabble.com.
On 25/11/2009, Phil Steitz wrote:
> sebb wrote:
> > On 23/11/2009, sebb wrote:
> >> The JUnit tests produce a lot of output, even if the tests are successful.
> >>
> >> Is there really any need to print stack traces in the following method?
> >>
> >> TestSharedPoolDataSource.PoolTest.run(
sebb wrote:
> On 23/11/2009, sebb wrote:
>> The JUnit tests produce a lot of output, even if the tests are successful.
>>
>> Is there really any need to print stack traces in the following method?
>>
>> TestSharedPoolDataSource.PoolTest.run()
>>
>> I propose to comment them out.
>>
>> Similarl
On 11/25/2009 04:02 PM, Phil Steitz wrote:
Looks like [runtime] has a Maven 1 build.
It doesn't. Those are generated files.
Build system will use ant with Runtime's own
ant extensions for making custom .jar files
containing both Java and Native components.
Let me know if you have problems,
On Wed, Nov 25, 2009 at 2:56 PM, Niall Pemberton
wrote:
> On Wed, Nov 25, 2009 at 2:25 PM, henrib wrote:
>>
>>
>> One last thing, just to be safe; if I was to perform the serie of 'svn
>> mv...' on the java files in the trunk, anything that currently depends upon
>> JEXL's trunk would stop compil
On Wed, Nov 25, 2009 at 4:52 AM, Mladen Turk wrote:
> Hi,
>
> I'd like to list the sandbox/runtime on the main commons page.
> What's needed for that (given that I have xdocs directory and
> index.xml in there)
>
Its slightly arcane, I'm afraid. Brief pointers below (I'm in a rush),
feel free to
Mladen Turk wrote:
> Hi,
>
> I'd like to list the sandbox/runtime on the main commons page.
> What's needed for that (given that I have xdocs directory and
> index.xml in there)
>
> IMHO the project-template should include the skeleton
> index.xml and sample resources (if that's how it's done)
>
On Wed, Nov 25, 2009 at 9:37 AM, sebb wrote:
> On 25/11/2009, henrib wrote:
>>
>>
>> One last thing, just to be safe; if I was to perform the serie of 'svn
>> mv...' on the java files in the trunk, anything that currently depends upon
>> JEXL's trunk would stop compiling.
>
> Why? So long as t
On Wed, Nov 25, 2009 at 2:25 PM, henrib wrote:
>
>
> One last thing, just to be safe; if I was to perform the serie of 'svn
> mv...' on the java files in the trunk, anything that currently depends upon
> JEXL's trunk would stop compiling.
>
> This would imply the gump/nightly commons builds that h
On 25/11/2009, henrib wrote:
>
>
> One last thing, just to be safe; if I was to perform the serie of 'svn
> mv...' on the java files in the trunk, anything that currently depends upon
> JEXL's trunk would stop compiling.
Why? So long as the result of the commits was still consistent, I
don't s
One last thing, just to be safe; if I was to perform the serie of 'svn
mv...' on the java files in the trunk, anything that currently depends upon
JEXL's trunk would stop compiling.
This would imply the gump/nightly commons builds that happily cope with the
current JEXL trunk will fail forever
Hi,
I'd like to list the sandbox/runtime on the main commons page.
What's needed for that (given that I have xdocs directory and
index.xml in there)
IMHO the project-template should include the skeleton
index.xml and sample resources (if that's how it's done)
If anyone can explain how to create
47 matches
Mail list logo
