Re: Maven's classpaths (Was: [discuss] Java 5)

[Aa...@Globus.ch]

Emmanuel Hugonnet <eh...@orange-ft.com> schrieb am 28.11.2006 
15:54:34:

> >> I have to edit the pom.xml of 
> >> maven-plugin-tools-java to set the version of qdox to 1.6.1 and then 
all 
> >> is fine.
> Hi,
> This is a temporary solution I use with a proximity proxy and an 
> overriding pom.xml but my question is more theorical than practical ;-)
> Why can't I override this dependency?

In the pom, you can tell maven how to compile and test *your* code. From 
maven's point of view, the maven-plugin-tools-java is "external" and 
outside the scope of the dependencies in your pom.xml.

Imagine: A plugin depends on some class in qdox 1.5 which is deprecated 
and was removed in qdox 1.6. Now, your project says "I depend on qdox 
1.6". If maven took this into account when loading plugins, the plugin 
wouldn't work and there was no way to make it work without breaking the 
build of your project. A deadlock.

Therefore, maven carefully separates the classpaths from every plugin from 
your project. You can have plugin A which needs qdox 1.5 and plugin B 
which needs qdox 2.0 in the *same* build and include qdox 1.6 in your 
project and it will work.

A solution might be to extend maven's xml merge mechanism. If you could 
add "patches" to pom.xml and settings.xml//profile, then it would be 
possible to override the values in other POM's (for example, to patch the 
POM of maven-plugin-tools-java to depend on a different version of qdox).

Here, I must ask how economical that would be. As it is, the solution is 
simple (at least when you're used at how simple it is to setup and compile 
maven projects) and the question is how useful such a patch mechanism will 
be (ie. how often can you fix your problems with it?).

Regards,

-- 
Aaron Digulla


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

Re: Maven's classpaths (Was: [discuss] Java 5)

[Emmanuel Hugonnet <eh...@orange-ft.com>]

Aaron.Digulla@Globus.ch a écrit :
> Emmanuel Hugonnet <eh...@orange-ft.com> schrieb am 28.11.2006 
> 15:54:34:
>
>   
>>>> I have to edit the pom.xml of 
>>>> maven-plugin-tools-java to set the version of qdox to 1.6.1 and then 
>>>>         
> all 
>   
>>>> is fine.
>>>>         
>> Hi,
>> This is a temporary solution I use with a proximity proxy and an 
>> overriding pom.xml but my question is more theorical than practical ;-)
>> Why can't I override this dependency?
>>     
>
> In the pom, you can tell maven how to compile and test *your* code. From 
> maven's point of view, the maven-plugin-tools-java is "external" and 
> outside the scope of the dependencies in your pom.xml.
>
> Imagine: A plugin depends on some class in qdox 1.5 which is deprecated 
> and was removed in qdox 1.6. Now, your project says "I depend on qdox 
> 1.6". If maven took this into account when loading plugins, the plugin 
> wouldn't work and there was no way to make it work without breaking the 
> build of your project. A deadlock.
>
> Therefore, maven carefully separates the classpaths from every plugin from 
> your project. You can have plugin A which needs qdox 1.5 and plugin B 
> which needs qdox 2.0 in the *same* build and include qdox 1.6 in your 
> project and it will work.
>
> A solution might be to extend maven's xml merge mechanism. If you could 
> add "patches" to pom.xml and settings.xml//profile, then it would be 
> possible to override the values in other POM's (for example, to patch the 
> POM of maven-plugin-tools-java to depend on a different version of qdox).
>
> Here, I must ask how economical that would be. As it is, the solution is 
> simple (at least when you're used at how simple it is to setup and compile 
> maven projects) and the question is how useful such a patch mechanism will 
> be (ie. how often can you fix your problems with it?).
>
> Regards,
>
>   
Hi,
Thank you, this was the answer I was looking for :o) I thought I was 
missing something and you pointed right to it. I understand your point 
of view and agree with it. I will stick to my solution with my modified 
version of maven-plugin-tools-java waiting for the futur release.
Regards,
Emmanuel

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