antLib not producing same classpath as Mvn

[Kallin Nagelberg <ka...@gmail.com>]

I've found what looks like a bug in the Maven Antlib, but I thought I
should check here first before sending the issue to JIRA as I am a
relatively new Maven user.

I've created a pom that transitively has two paths to the artifact
commons-logging. Due to the structure of the poms this resulted in 1.0
being selected instead of what I needed, 1.0.4. In an attempt to
resolve this I added the following to my SuperPom from which all
others inherit:

<dependencyManagement>
        <dependencies>
<dependency>
                <groupId>commons-logging</groupId>
                <artifactId>commons-logging</artifactId>
                <version>1.0.4</version>
            </dependency>
</dependencies>
    </dependencyManagement>

Now, when I run mvn dependency:resolve on my child pom it changes the
resolved dependency from 1.0 to 1.0.4 as I desired. Hurrah!
Unfortunately when I reference the classpath produced by this pom in
my ant script it still shows the 1.0 version on the classpath. It
seems that the maven antLib is not taking the parent's dependency
management section into account. I've heard that the maven antlib does
not always function as maven should. Is this true?

Regards,
Kallin Nagelberg.

---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@maven.apache.org
For additional commands, e-mail: users-help@maven.apache.org

Re: antLib not producing same classpath as Mvn

[Hervé BOUTEMY <he...@free.fr>]

Maven Ant Tasks should resolve dependencies exactly like Maven in command 
line. But there are code duplications between the command line usage of Maven 
internals and Ant tasks' usage: sometimes, this leads to unwanted 
differences.
FYI, in Maven 2.1, a component has been created to avoid this problem: this is 
the Embedder, a facade to Maven internals for integration use into any tool. 
Embedder is used in Maven command line, in Eclipse integrations like 
m2eclipse or Q4E, and will be used by Maven Ant Tasks 2.1.

But of Maven Ant Tasks 2.0.x, there is no Embedder...

There is already a Jira issue for such a difference of dependencies 
resolution: http://jira.codehaus.org/browse/MANTTASKS-91.

Your case seems totally different: I'm really interested if you can build a 
minimal test-case I could incorporate into the tasks unit tests.

Regards,

Hervé

Le mardi 20 novembre 2007, Kallin Nagelberg a écrit :
> I've found what looks like a bug in the Maven Antlib, but I thought I
> should check here first before sending the issue to JIRA as I am a
> relatively new Maven user.
>
> I've created a pom that transitively has two paths to the artifact
> commons-logging. Due to the structure of the poms this resulted in 1.0
> being selected instead of what I needed, 1.0.4. In an attempt to
> resolve this I added the following to my SuperPom from which all
> others inherit:
>
> <dependencyManagement>
>         <dependencies>
> <dependency>
>                 <groupId>commons-logging</groupId>
>                 <artifactId>commons-logging</artifactId>
>                 <version>1.0.4</version>
>             </dependency>
> </dependencies>
>     </dependencyManagement>
>
> Now, when I run mvn dependency:resolve on my child pom it changes the
> resolved dependency from 1.0 to 1.0.4 as I desired. Hurrah!
> Unfortunately when I reference the classpath produced by this pom in
> my ant script it still shows the 1.0 version on the classpath. It
> seems that the maven antLib is not taking the parent's dependency
> management section into account. I've heard that the maven antlib does
> not always function as maven should. Is this true?
>
> Regards,
> Kallin Nagelberg.
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@maven.apache.org
> For additional commands, e-mail: users-help@maven.apache.org



---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@maven.apache.org
For additional commands, e-mail: users-help@maven.apache.org