Re: MultiMaven project with by sharing dependencyManagement on parent pom

[Nils Breunese]

I don’t believe you can _include_ plugins and plugin dependencies, as far as I 
know you can only _inherit_ them from a parent. And an artifact can only have 
one parent.

There’s import for BOM artifacts, but that only ‘includes’ the 
entries from the BOM’s  section, and doesn’t do anything 
with plugins.

Nils.

> Op 6 jun. 2022, om 20:13 heeft Philipp Kraus  
> het volgende geschreven:
> 
> Hello,
> 
> I have got a MultiMaven project and within this project I have got two parent 
> poms. One of these parent inherits from an external parent. So I would like 
> to share all my build plugins and pluginManagemnt section, like
> 
> My-multi-maven-pom.xml
> 
>   my-plugins-and-pluginDependencies-pom.xml
> 
>   my-parent-pom.xml 
>   -> includes -> my-plugins-and-pluginDependencies-pom.xml
> 
>   my-external-parent-pom.xml 
>   -> inherits -> external-parent-pom.xml 
>   -> includes -> my-plugins-and-pluginDependencies-pom.xml
> 
> How is this possible?
> 
> Thanks a lot
> -
> To unsubscribe, e-mail: users-unsubscr...@maven.apache.org
> For additional commands, e-mail: users-h...@maven.apache.org
> 


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

MultiMaven project with by sharing dependencyManagement on parent pom

[Philipp Kraus]

Hello,

I have got a MultiMaven project and within this project I have got two parent 
poms. One of these parent inherits from an external parent. So I would like to 
share all my build plugins and pluginManagemnt section, like

My-multi-maven-pom.xml

my-plugins-and-pluginDependencies-pom.xml

my-parent-pom.xml 
-> includes -> my-plugins-and-pluginDependencies-pom.xml

my-external-parent-pom.xml 
-> inherits -> external-parent-pom.xml 
-> includes -> my-plugins-and-pluginDependencies-pom.xml

How is this possible?

Thanks a lot
-
To unsubscribe, e-mail: users-unsubscr...@maven.apache.org
For additional commands, e-mail: users-h...@maven.apache.org

Re: Overriding dependencyManagement import version?

[Dan Tran]

@khmarbaise   from  junit issue,  you
mentioned about placing your 'import' above spring boot import, what about
the individual artifact?

-D

On Wed, Apr 1, 2020 at 1:50 PM Dan Tran  wrote:

> found this  ref
> https://github.com/sormuras/junit-platform-maven-plugin/issues/29#issuecomment-456958188
>
>
> Need maven core devs to confirm this
>
> Thanks
>
> -D
>
> On Wed, Apr 1, 2020 at 1:08 PM Dan Tran  wrote:
>
>> Hi
>>
>> I believe in order to do so, I need to place my override above the
>> import, do we have this maven behavior documented somewhere?
>>
>> 
>>
>>   
>>  [mine]
>>   
>>   
>>  [the import BOM]
>>   
>>
>>
>> Thanks
>>
>> -D
>>
>

Re: Overriding dependencyManagement import version?

[Dan Tran]

found this  ref
https://github.com/sormuras/junit-platform-maven-plugin/issues/29#issuecomment-456958188


Need maven core devs to confirm this

Thanks

-D

On Wed, Apr 1, 2020 at 1:08 PM Dan Tran  wrote:

> Hi
>
> I believe in order to do so, I need to place my override above the import,
> do we have this maven behavior documented somewhere?
>
> 
>
>   
>  [mine]
>   
>   
>  [the import BOM]
>   
>
>
> Thanks
>
> -D
>

Overriding dependencyManagement import version?

[Dan Tran]

Hi

I believe in order to do so, I need to place my override above the import,
do we have this maven behavior documented somewhere?


   
  
 [mine]
  
  
 [the import BOM]
  
   

Thanks

-D

Re: Merging dependency exclusions from dependencyManagement and dependencies

[Andreas Hubold]

Hi,

in my original post I've described that exclusions from the 
dependencyManagement are used for downstream projects as long as there 
aren't any exclusions specified at the dependency itself. So the 
conclusion that dependencyManagement isn't transitive cannot be true, at 
least for some cases. The actual behavior seems to be inconsistent and 
rather confusing to me.


Can some Maven expert/maintainer please comment on my original question? 
How is this supposed to work, is this as intended?


Thank you,
Andreas

Andy Feldman wrote on 15.05.19 18:39:

I have observed similar behavior with the version number. My conclusion was
that dependencyManagement is not transitive.

Example of what I observed: I have a project my-library with transitive
dependencies on 3rd-party-library version 1.1 and 1.2 that would normally
resolve to 1.1. I use dependencyManagement in my-library to override it to
1.2. I use my-library from my-project. my-project gets
3rd-party-library 1.1 instead of 1.2.

The docs at
https://maven.apache.org/guides/introduction/introduction-to-dependency-mechanism.html
suggest
that you can manually pull in the dependencyMangement section of another
pom. Look for "Z imports the managed dependencies from both X and Y." I
haven't tried this approach.


On Wed, May 15, 2019 at 2:17 AM Andreas Hubold 
wrote:


Hi all,

I have a question on how effective dependency exclusions are computed.
I'd expect that exclusions are additive when specified for the same
dependency in the dependencyManagement and dependencies sections. This
is also what I read at https://stackoverflow.com/a/10736186

The output of dependency:tree also confirms this for the project that
declares the dependency, however the effects are different for another
project that depends on the former.

I've prepared a simplified example with two projects a and b. You can
find it at https://github.com/ahubold/test-maven-dependency-exclusion

a/pom.xml
- dependencyManagement for httpclient, excluding commons-logging
- dependency on httpclient, excluding commons-codec

b/pom.xml
- dependency on a

The dependency:tree for a/pom.xml shows that exclusions are additive
here and neither commons-logging nor commons-codec show up in the
result. That's fine.

[INFO] a:a:jar:1.0.0-SNAPSHOT
[INFO] \- org.apache.httpcomponents:httpclient:jar:4.5.8:compile
[INFO]\- org.apache.httpcomponents:httpcore:jar:4.4.11:compile

But the dependency:tree for b/pom.xml has a transitive dependency to
commons-logging, which confuses me:

[INFO] b:b:pom:1.0.0-SNAPSHOT
[INFO] \- a:a:jar:1.0.0-SNAPSHOT:compile
[INFO]\- org.apache.httpcomponents:httpclient:jar:4.5.8:compile
[INFO]   +- org.apache.httpcomponents:httpcore:jar:4.4.11:compile
[INFO]   \- commons-logging:commons-logging:jar:1.2:compile

I would have expected to not see commons-logging here. Its exclusion
really seems to be hidden by the exclusion of commons-codec. If I now
change a/pom.xml and remove the exclusion of commons-codec, then
commons-logging will disappear from the dependencies:

[INFO] --- maven-dependency-plugin:2.8:tree (default-cli) @ b ---
[INFO] b:b:pom:1.0.0-SNAPSHOT
[INFO] \- a:a:jar:1.0.0-SNAPSHOT:compile
[INFO]\- org.apache.httpcomponents:httpclient:jar:4.5.8:compile
[INFO]   +- org.apache.httpcomponents:httpcore:jar:4.4.11:compile
[INFO]   \- commons-codec:commons-codec:jar:1.11:compile

My maven version is 3.6.0.

Any thoughts? Is this a bug or intended behavior?

Kind regards,
Andreas

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





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

Re: Merging dependency exclusions from dependencyManagement and dependencies

[Andy Feldman]

I have observed similar behavior with the version number. My conclusion was
that dependencyManagement is not transitive.

Example of what I observed: I have a project my-library with transitive
dependencies on 3rd-party-library version 1.1 and 1.2 that would normally
resolve to 1.1. I use dependencyManagement in my-library to override it to
1.2. I use my-library from my-project. my-project gets
3rd-party-library 1.1 instead of 1.2.

The docs at
https://maven.apache.org/guides/introduction/introduction-to-dependency-mechanism.html
suggest
that you can manually pull in the dependencyMangement section of another
pom. Look for "Z imports the managed dependencies from both X and Y." I
haven't tried this approach.


On Wed, May 15, 2019 at 2:17 AM Andreas Hubold 
wrote:

> Hi all,
>
> I have a question on how effective dependency exclusions are computed.
> I'd expect that exclusions are additive when specified for the same
> dependency in the dependencyManagement and dependencies sections. This
> is also what I read at https://stackoverflow.com/a/10736186
>
> The output of dependency:tree also confirms this for the project that
> declares the dependency, however the effects are different for another
> project that depends on the former.
>
> I've prepared a simplified example with two projects a and b. You can
> find it at https://github.com/ahubold/test-maven-dependency-exclusion
>
> a/pom.xml
> - dependencyManagement for httpclient, excluding commons-logging
> - dependency on httpclient, excluding commons-codec
>
> b/pom.xml
> - dependency on a
>
> The dependency:tree for a/pom.xml shows that exclusions are additive
> here and neither commons-logging nor commons-codec show up in the
> result. That's fine.
>
> [INFO] a:a:jar:1.0.0-SNAPSHOT
> [INFO] \- org.apache.httpcomponents:httpclient:jar:4.5.8:compile
> [INFO]\- org.apache.httpcomponents:httpcore:jar:4.4.11:compile
>
> But the dependency:tree for b/pom.xml has a transitive dependency to
> commons-logging, which confuses me:
>
> [INFO] b:b:pom:1.0.0-SNAPSHOT
> [INFO] \- a:a:jar:1.0.0-SNAPSHOT:compile
> [INFO]\- org.apache.httpcomponents:httpclient:jar:4.5.8:compile
> [INFO]   +- org.apache.httpcomponents:httpcore:jar:4.4.11:compile
> [INFO]   \- commons-logging:commons-logging:jar:1.2:compile
>
> I would have expected to not see commons-logging here. Its exclusion
> really seems to be hidden by the exclusion of commons-codec. If I now
> change a/pom.xml and remove the exclusion of commons-codec, then
> commons-logging will disappear from the dependencies:
>
> [INFO] --- maven-dependency-plugin:2.8:tree (default-cli) @ b ---
> [INFO] b:b:pom:1.0.0-SNAPSHOT
> [INFO] \- a:a:jar:1.0.0-SNAPSHOT:compile
> [INFO]\- org.apache.httpcomponents:httpclient:jar:4.5.8:compile
> [INFO]   +- org.apache.httpcomponents:httpcore:jar:4.4.11:compile
> [INFO]   \- commons-codec:commons-codec:jar:1.11:compile
>
> My maven version is 3.6.0.
>
> Any thoughts? Is this a bug or intended behavior?
>
> Kind regards,
> Andreas
>
> -
> To unsubscribe, e-mail: users-unsubscr...@maven.apache.org
> For additional commands, e-mail: users-h...@maven.apache.org
>
>

Merging dependency exclusions from dependencyManagement and dependencies

[Andreas Hubold]

Hi all,

I have a question on how effective dependency exclusions are computed. 
I'd expect that exclusions are additive when specified for the same 
dependency in the dependencyManagement and dependencies sections. This 
is also what I read at https://stackoverflow.com/a/10736186


The output of dependency:tree also confirms this for the project that 
declares the dependency, however the effects are different for another 
project that depends on the former.


I've prepared a simplified example with two projects a and b. You can 
find it at https://github.com/ahubold/test-maven-dependency-exclusion


a/pom.xml
- dependencyManagement for httpclient, excluding commons-logging
- dependency on httpclient, excluding commons-codec

b/pom.xml
- dependency on a

The dependency:tree for a/pom.xml shows that exclusions are additive 
here and neither commons-logging nor commons-codec show up in the 
result. That's fine.


[INFO] a:a:jar:1.0.0-SNAPSHOT
[INFO] \- org.apache.httpcomponents:httpclient:jar:4.5.8:compile
[INFO]    \- org.apache.httpcomponents:httpcore:jar:4.4.11:compile

But the dependency:tree for b/pom.xml has a transitive dependency to 
commons-logging, which confuses me:


[INFO] b:b:pom:1.0.0-SNAPSHOT
[INFO] \- a:a:jar:1.0.0-SNAPSHOT:compile
[INFO]    \- org.apache.httpcomponents:httpclient:jar:4.5.8:compile
[INFO]   +- org.apache.httpcomponents:httpcore:jar:4.4.11:compile
[INFO]   \- commons-logging:commons-logging:jar:1.2:compile

I would have expected to not see commons-logging here. Its exclusion 
really seems to be hidden by the exclusion of commons-codec. If I now 
change a/pom.xml and remove the exclusion of commons-codec, then 
commons-logging will disappear from the dependencies:


[INFO] --- maven-dependency-plugin:2.8:tree (default-cli) @ b ---
[INFO] b:b:pom:1.0.0-SNAPSHOT
[INFO] \- a:a:jar:1.0.0-SNAPSHOT:compile
[INFO]    \- org.apache.httpcomponents:httpclient:jar:4.5.8:compile
[INFO]   +- org.apache.httpcomponents:httpcore:jar:4.4.11:compile
[INFO]   \- commons-codec:commons-codec:jar:1.11:compile

My maven version is 3.6.0.

Any thoughts? Is this a bug or intended behavior?

Kind regards,
Andreas

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

Re: Maven High memory usage (12G) and big dependencyManagement section (4000 entry)

[Hervé BOUTEMY]

thinking at it: which Maven version are you using?

Did you try Maven 3.6.0? There was a cache added in MNG-6311 that could 
perhaps help.

Regards,

Hervé

Le vendredi 18 janvier 2019, 10:36:13 CET Hervé BOUTEMY a écrit :
> Hi,
> 
> Wow, 1600 modules and 4000 entries in dependencyManagement?
> 
> Did you try to use a memory profiler to see where the memory goes?
> Is there something shareable in public to dig into details?
> 
> Regards,
> 
> Hervé
> 
> Le jeudi 17 janvier 2019, 18:28:57 CET Canivet, Guillaume a écrit :
> > Hi,
> > 
> > Here is my... probleme...
> > 
> > I have a root aggregator with a large amount of modules. (around 1600
> > modules ) All module have the same parent (1.0).
> > That parent is importing a pom (1.0) with a huge dependencyManagement
> > section (4000 entries).
> > 
> > When doing a mvn install (on the root aggregator)   I will consume around
> > 6G to 8G. (kind of expected)
> > 
> > Now I just perform some modification of several modules (5 modules) for a
> > release. Those modules use a new version of the parent(1.2-SNAPSHOT).
> > The parent use a new version of the pom (1.2-SNAPSHOT) with a huge
> > dependencyManagement section.
> > 
> > When doing a mvn install (on the root aggregator) I consume around 12G to
> > 14G. When doing a mvn install (on the root aggregator with the pl option
> > on
> > the 5 modules) I also consume around 12G to 14G.
> > 
> > Now I am really scare for my next release (will I consume an extra 6G for
> > each different version of the parent?), any idea on how to solve this?
> > 
> > Note: It seems that if all the module of the root aggregator are using the
> > same parent version  memory will remain stable.
> > 
> > 
> > Thanks for any tips
> > Guillaume
> > 
> > Information in this e-mail and any attachments is confidential, and may
> > not
> > be copied or used by anyone other than the addressee, nor disclosed to any
> > third party without our permission. There is no intention to create any
> > legally binding contract or other binding commitment through the use of
> > this electronic communication unless it is issued in accordance with the
> > Experian Limited standard terms and conditions of purchase or other
> > express
> > written agreement between Experian Limited and the recipient. Although
> > Experian has taken reasonable steps to ensure that this communication and
> > any attachments are free from computer viruses, you are advised to take
> > your own steps to ensure that they are actually virus free.
> > 
> > Experian Ltd is authorised and regulated by the Financial Conduct
> > Authority. Companies Act information: Registered name: Experian Limited.
> > Registered office: The Sir John Peace Building, Experian Way, NG2
> > Business Park, Nottingham, NG80 1ZZ, United Kingdom. Place of
> > registration: England and Wales. Registered number: 653331.
> > 
> > Vos informations nominatives sont exploitées par la société Scorex S.A.M.
> > (Groupe Experian)  dans le cadre du traitement ayant pour finalité
> > "Gestion
> > de la messagerie électronique professionnelle". Conformément à la loi n°
> > 1.165, modifiée, vous disposez d'un droit d'accès, de rectification et de
> > suppression en écrivant au Secrétariat Général de la société Scorex, sise,
> > 2, rue de la Lüjerneta à Monaco (98000).
> > 
> > Your personal information is used by Scorex S.A.M. (Experian Group) as
> > part
> > of the processing for the purpose of "Professional e-mail management". In
> > accordance with the law n ° 1.165, modified, you have a right of access,
> > correction and suppression by writing to the General Secretariat of the
> > company, located, 2, rue de la Lüjerneta in Monaco (98000).
> 
> -
> To unsubscribe, e-mail: users-unsubscr...@maven.apache.org
> For additional commands, e-mail: users-h...@maven.apache.org





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

Re: Maven High memory usage (12G) and big dependencyManagement section (4000 entry)

[Hervé BOUTEMY]

Hi,

Wow, 1600 modules and 4000 entries in dependencyManagement?

Did you try to use a memory profiler to see where the memory goes?
Is there something shareable in public to dig into details?

Regards,

Hervé

Le jeudi 17 janvier 2019, 18:28:57 CET Canivet, Guillaume a écrit :
> Hi,
> 
> Here is my... probleme...
> 
> I have a root aggregator with a large amount of modules. (around 1600
> modules ) All module have the same parent (1.0).
> That parent is importing a pom (1.0) with a huge dependencyManagement
> section (4000 entries).
> 
> When doing a mvn install (on the root aggregator)   I will consume around 6G
> to 8G. (kind of expected)
> 
> Now I just perform some modification of several modules (5 modules) for a
> release. Those modules use a new version of the parent(1.2-SNAPSHOT).
> The parent use a new version of the pom (1.2-SNAPSHOT) with a huge
> dependencyManagement section.
> 
> When doing a mvn install (on the root aggregator) I consume around 12G to
> 14G. When doing a mvn install (on the root aggregator with the pl option on
> the 5 modules) I also consume around 12G to 14G.
> 
> Now I am really scare for my next release (will I consume an extra 6G for
> each different version of the parent?), any idea on how to solve this?
> 
> Note: It seems that if all the module of the root aggregator are using the
> same parent version  memory will remain stable.
> 
> 
> Thanks for any tips
> Guillaume
> 
> Information in this e-mail and any attachments is confidential, and may not
> be copied or used by anyone other than the addressee, nor disclosed to any
> third party without our permission. There is no intention to create any
> legally binding contract or other binding commitment through the use of
> this electronic communication unless it is issued in accordance with the
> Experian Limited standard terms and conditions of purchase or other express
> written agreement between Experian Limited and the recipient. Although
> Experian has taken reasonable steps to ensure that this communication and
> any attachments are free from computer viruses, you are advised to take
> your own steps to ensure that they are actually virus free.
> 
> Experian Ltd is authorised and regulated by the Financial Conduct Authority.
> Companies Act information: Registered name: Experian Limited. Registered
> office: The Sir John Peace Building, Experian Way, NG2 Business Park,
> Nottingham, NG80 1ZZ, United Kingdom. Place of registration: England and
> Wales. Registered number: 653331.
> 
> Vos informations nominatives sont exploitées par la société Scorex S.A.M.
> (Groupe Experian)  dans le cadre du traitement ayant pour finalité "Gestion
> de la messagerie électronique professionnelle". Conformément à la loi n°
> 1.165, modifiée, vous disposez d'un droit d'accès, de rectification et de
> suppression en écrivant au Secrétariat Général de la société Scorex, sise,
> 2, rue de la Lüjerneta à Monaco (98000).
> 
> Your personal information is used by Scorex S.A.M. (Experian Group) as part
> of the processing for the purpose of "Professional e-mail management". In
> accordance with the law n ° 1.165, modified, you have a right of access,
> correction and suppression by writing to the General Secretariat of the
> company, located, 2, rue de la Lüjerneta in Monaco (98000).





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

Maven High memory usage (12G) and big dependencyManagement section (4000 entry)

[Canivet, Guillaume]

Hi,

Here is my... probleme...

I have a root aggregator with a large amount of modules. (around 1600 modules )
All module have the same parent (1.0).
That parent is importing a pom (1.0) with a huge dependencyManagement section 
(4000 entries).

When doing a mvn install (on the root aggregator)   I will consume around 6G to 
8G. (kind of expected)

Now I just perform some modification of several modules (5 modules) for a 
release.
Those modules use a new version of the parent(1.2-SNAPSHOT).
The parent use a new version of the pom (1.2-SNAPSHOT) with a huge 
dependencyManagement section.

When doing a mvn install (on the root aggregator) I consume around 12G to 14G.
When doing a mvn install (on the root aggregator with the pl option on the 5 
modules) I also consume around 12G to 14G.

Now I am really scare for my next release (will I consume an extra 6G for each 
different version of the parent?), any idea on how to solve this?

Note: It seems that if all the module of the root aggregator are using the same 
parent version  memory will remain stable.


Thanks for any tips
Guillaume

Information in this e-mail and any attachments is confidential, and may not be 
copied or used by anyone other than the addressee, nor disclosed to any third 
party without our permission. There is no intention to create any legally 
binding contract or other binding commitment through the use of this electronic 
communication unless it is issued in accordance with the Experian Limited 
standard terms and conditions of purchase or other express written agreement 
between Experian Limited and the recipient. Although Experian has taken 
reasonable steps to ensure that this communication and any attachments are free 
from computer viruses, you are advised to take your own steps to ensure that 
they are actually virus free. 

Experian Ltd is authorised and regulated by the Financial Conduct Authority.
Companies Act information: Registered name: Experian Limited. Registered 
office: The Sir John Peace Building, Experian Way, NG2 Business Park, 
Nottingham, NG80 1ZZ, United Kingdom. Place of registration: England and Wales. 
Registered number: 653331.

Vos informations nominatives sont exploitées par la société Scorex S.A.M. 
(Groupe Experian)  dans le cadre du traitement ayant pour finalité "Gestion de 
la messagerie électronique professionnelle". Conformément à la loi n° 1.165, 
modifiée, vous disposez d'un droit d'accès, de rectification et de suppression 
en écrivant au Secrétariat Général de la société Scorex, sise, 2, rue de la 
Lüjerneta à Monaco (98000).

Your personal information is used by Scorex S.A.M. (Experian Group) as part of 
the processing for the purpose of "Professional e-mail management". In 
accordance with the law n ° 1.165, modified, you have a right of access, 
correction and suppression by writing to the General Secretariat of the 
company, located, 2, rue de la Lüjerneta in Monaco (98000).

Reading dependencyManagement element with resolver

[Elliotte Rusty Harold]

Using the Maven resolver, is there an API hiding somewhere to read the
dependencyManagement element from a pom and return the list of
dependencies being managed?

That is, something short of just parsing the XML with XOM or
equivalent. I figure something inside Maven Resolver must be doing
that, but I can't find it.

P.S. The Maven resolver git repo at
https://git-wip-us.apache.org/repos/asf/maven-resolver.git/ seems to
have gone 404.

-- 
Elliotte Rusty Harold
elh...@ibiblio.org

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

Re: Injecting a transitive dependency via dependencyManagement

[Stephen Connolly]

You could create your own safe-batik-bridge which is empty and has both
dependencies and then just ask everyone to use that instead...

Or deploy to your proxy of central a batik-bridge:1.8-yourcompany-1 and use
depMgmt to pin that version

On Thursday 13 October 2016, Curtis Rueden <ctrue...@wisc.edu> wrote:

> Hi everyone,
>
> I have a project [1] which depends on
> org.apache.xmlgraphics:batik-bridge:1.8, which in turn requires
> org.apache.xmlgraphics:xmlgraphics-commons:2.1 at runtime.
>
> Unfortunately, the POM for batik-bridge somehow does not declare the
> xmlgraphics-commons dependency [2], even though it definitely needs it [3].
>
> Of course, as a good citizen I should contact upstream and ask about this.
> But in the meantime, I want to work around it. I could add a runtime
> dependency on xmlgraphics-commons to my project POM, but what would be
> really nice would be the ability to declare additional transitive
> dependencies in the dependencyManagement section, as has been discussed
> here previously [4], since I want to ensure that any project which depends
> on batik-bridge via our parent POM will inherit a transitive
> xmlgraphics-common dependency.
>
> Unfortunately, based on the previous discussion, I surmise that there is
> currently no mechanism for this? Is there an existing issue? If not, should
> I file one? Or is what I'm looking for here fundamentally undesirable?
>
> Regards,
> Curtis
>
> [1] https://github.com/fiji/IO
> [2]
> https://repo1.maven.org/maven2/org/apache/xmlgraphics/
> batik-bridge/1.8/batik-bridge-1.8.pom
> [3]
> https://github.com/apache/batik/blob/batik-1_8/sources/
> org/apache/batik/bridge/PaintServer.java#L46-L53
> [4]
> http://maven.40175.n5.nabble.com/How-to-manage-dependency-
> quot-includes-quot-td5857771.html
>
> --
> Curtis Rueden
> LOCI software architect - http://loci.wisc.edu/software
> ImageJ2 lead, Fiji maintainer - http://imagej.net/User:Rueden
>


-- 
Sent from my phone

Injecting a transitive dependency via dependencyManagement

[Curtis Rueden]

Hi everyone,

I have a project [1] which depends on
org.apache.xmlgraphics:batik-bridge:1.8, which in turn requires
org.apache.xmlgraphics:xmlgraphics-commons:2.1 at runtime.

Unfortunately, the POM for batik-bridge somehow does not declare the
xmlgraphics-commons dependency [2], even though it definitely needs it [3].

Of course, as a good citizen I should contact upstream and ask about this.
But in the meantime, I want to work around it. I could add a runtime
dependency on xmlgraphics-commons to my project POM, but what would be
really nice would be the ability to declare additional transitive
dependencies in the dependencyManagement section, as has been discussed
here previously [4], since I want to ensure that any project which depends
on batik-bridge via our parent POM will inherit a transitive
xmlgraphics-common dependency.

Unfortunately, based on the previous discussion, I surmise that there is
currently no mechanism for this? Is there an existing issue? If not, should
I file one? Or is what I'm looking for here fundamentally undesirable?

Regards,
Curtis

[1] https://github.com/fiji/IO
[2]
https://repo1.maven.org/maven2/org/apache/xmlgraphics/batik-bridge/1.8/batik-bridge-1.8.pom
[3]
https://github.com/apache/batik/blob/batik-1_8/sources/org/apache/batik/bridge/PaintServer.java#L46-L53
[4]
http://maven.40175.n5.nabble.com/How-to-manage-dependency-quot-includes-quot-td5857771.html

--
Curtis Rueden
LOCI software architect - http://loci.wisc.edu/software
ImageJ2 lead, Fiji maintainer - http://imagej.net/User:Rueden

Re: dependencyManagement BOM question

[Christian Schulte]

Am 08/23/16 um 21:27 schrieb David Hoffer:
> I have some questions regarding how importing a pom type dependency in my
> dependencyManagement section really works (e.g. BOM dependency).  At a
> basic level I understand it will effectively add all its dependencies
> defined in its dependencyManagement section to my dependencyManagement
> section.

Not all. Only the dependencies not already declared in your effective
dependency management. Implemented in class
'org.apache.maven.model.composition.DefaultDependencyManagementImporter'

<https://git-wip-us.apache.org/repos/asf?p=maven.git;a=blob;f=maven-model-builder/src/main/java/org/apache/maven/model/composition/DefaultDependencyManagementImporter.java;h=c3a0201b34be6402333f90ed4b807ec62e9ff898;hb=HEAD>

based on method 'getManagementKey' of class
'org.apache.maven.model.Dependency'

<https://git-wip-us.apache.org/repos/asf?p=maven.git;a=blob;f=maven-model/src/main/mdo/maven.mdo;h=8abf29ed89d256e5dbf889f7e813c1d5bf79844e;hb=629fd749e59a679809c86eb26d554520e4de3a78#l1456>.

> 
> However the imported pom uses variables for all the versions and defines
> them in its pom.  Now if I want to use a different version and also have
> the version variable (same variable name) set in my pom, which version will
> be used?

Maven imports the effective dependency management of the BOM (after
inheritance, interpolation, etc.). Consider the BOM a standalone project
without any relationship to the importing POM.

> 
> What about order of the BOM import?  Does the order of the BOM import
> matter with respect to other non imported dependencyManagement
> dependencies?  If my POM has the same dependency of the imported one which
> one will be used?  Lets say in one case I'm using a property variable to
> specify the version and also if I use a literal version.
> 

Effective dependencies of the POM override what gets imported. See
above. When using multiple BOM imports in the POM, the order of
declaration of those imports matter (after inheritance, interpolation,
etc.). As of Maven 3.4.0-SNAPSHOT you'll get a warning when your POM
depends on this "first declaration wins" itch. Relying on the order of
XML elements should be avoided.

Regards,
-- 
Christian


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

dependencyManagement BOM question

[David Hoffer]

I have some questions regarding how importing a pom type dependency in my
dependencyManagement section really works (e.g. BOM dependency).  At a
basic level I understand it will effectively add all its dependencies
defined in its dependencyManagement section to my dependencyManagement
section.

However the imported pom uses variables for all the versions and defines
them in its pom.  Now if I want to use a different version and also have
the version variable (same variable name) set in my pom, which version will
be used?

What about order of the BOM import?  Does the order of the BOM import
matter with respect to other non imported dependencyManagement
dependencies?  If my POM has the same dependency of the imported one which
one will be used?  Lets say in one case I'm using a property variable to
specify the version and also if I use a literal version.

-Dave

Re: DependencyManagement task in ant ?

[Anders Hammar]

http://wiki.eclipse.org/Aether/Ant_Tasks

/Anders

On Tue, May 19, 2015 at 12:32 AM, Zk W mpc8...@gmail.com wrote:

 Hi All

 Is there a maven ant tasks of DependencyManagement ?
 If not, how can we create dependencies task such that it can perform
 dependency management using the parent-child inheritance or import model ?
 Concrete simple examples would help.

 Thank you.

DependencyManagement task in ant ?

[Zk W]

Hi All

Is there a maven ant tasks of DependencyManagement ?
If not, how can we create dependencies task such that it can perform
dependency management using the parent-child inheritance or import model ?
Concrete simple examples would help.

Thank you.

Problems with dependencyManagement in maven-release-plugin

[Santiago Gala]

Hi, we are in the following (simplified and inherited) situation:

* we use git (wth gerrit) as SCM and review system
* we have a parent project, (let's call it com.example:P) with dependency
management and all our internal and external dependencies there (except for
the partent itself)
* let's say we have a 'son' project com.example.test:A without other
dependencies

P version 1.0.0-SNAPSHOT POM specifies A version as ${project.version}, so
it moves in synchronicity with P

we want to use maven release plugin to prepare two local changes for its
release. I use shell to illustrate, but the process can equally be done by
hand

export VERSION=1.0.0
export NEW_VERSION=1.0.1-SNAPSHOT

# Release the parent with 1.0
mvn -B -Dmaven.repo.local=${LOCAL_REPO} release:clean release:prepare
-DreleaseVersion=${VERSION} -Dtag=P-${VERSION}
-DdevelopmentVersion=${NEW_VERSION} -DpushChanges=false
#... it works

Now, after I approve the changes in P, I got for A
# clone and cd to A working copy
mvn -B release:clean release:prepare -DreleaseVersion=${VERSION}
-Dtag=${project}-${VERSION} -DdevelopmentVersion=${NEW_VERSION}
-DpushChanges=false -Dproject.rel.com.example.test.P=${VERSION}
-Dproject.dev.com.example.test.P=${NEW_VERSION}
# it does not work

It refuses to release or to take those values from the parametes. I must do
the release without the -B, using yes\n\n, 1.0.0, 1.0.1-SNAPSHOT,
A-1.0.0\n

In case there are other dependencies (say, B that depends on P and A), the
plugin will ask for the versions of A, and the will not use them. It looks
like a separate issue, which could be summarized as
* maven-release-plugin does not recompute effective POM after new parent
version is give.

The first one could be summarized ad:
* maven-release-plugin does not allow to script versions for the parent
element in the POM.

All tests done with maven 3.0.4 and maven release plugin 2.4.1 and 2.4.2,
just in case.

Any clue?

Regards
Santiago

Checking dependencyManagement content

[Stephane Nicoll]

Hi,

As far as I know, there is no plugin out there that validates the content
of the dependencyManagement section. There are more and more people using
the so-called Bill of materials out there and having such a goal would be
nice to make sure that the dependencies listed there are valid (still
exists, proper type, etc)

Anybody knows if such initiative exists?

Thanks,
S.

Re: mvn -amd should honour dependencyManagement POM imports

[Ansgar Konermann]

Am 18.03.2013 19:01, schrieb Stephen Connolly:
 Smells like a bug, I'd be interested in other's thoughts, but absence
 further input to the contrary, please one a jira

Filed MNG-5455 [1]

Best regards
Ansgar


[1] https://jira.codehaus.org/browse/MNG-5455




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

mvn -amd should honour dependencyManagement POM imports

[Ansgar Konermann]

Hi all,

some colleagues and me are wondering if it is intentional that mvn -amd
does not build submodules which depend on a POM via means of a POM
import in the dependencyManagement section, like so:

  dependencyManagement
dependencies
  dependency
groupIdamd-test/groupId
artifactIddependency-management/artifactId
version1.0/version
scopeimport/scope
typepom/type
  /dependency
/dependencies
  /dependencyManagement

I set up an example project here:
https://github.com/ansgarkonermann/maven-amd-experiment

The project has three submodules:

  modules
moduledependency-management/module
modulejava-library/module
modulegui/module
  /modules

Both 'java-library' and 'gui' import 'dependency-management'.

We'd expect Maven to build gui and java-library when issuing mvn -amd
-pl dependency-management, however only dependency-management gets build.

Is this by intention or more of a potentially missing feature?

From our point of view, it would be advantageous to have this as a Maven
feature, so we can update the dependency management POM(s) in our
project and call mvn -amd to build all modules depending on the changed
dependency management POM.

Is it possible to implement this in Maven? In your opinion, is it also a
useful feature?

Best regards

Ansgar

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

Re: mvn -amd should honour dependencyManagement POM imports

[Stephen Connolly]

Smells like a bug, I'd be interested in other's thoughts, but absence
further input to the contrary, please one a jira

On Monday, 18 March 2013, Ansgar Konermann wrote:

 Hi all,

 some colleagues and me are wondering if it is intentional that mvn -amd
 does not build submodules which depend on a POM via means of a POM
 import in the dependencyManagement section, like so:

   dependencyManagement
 dependencies
   dependency
 groupIdamd-test/groupId
 artifactIddependency-management/artifactId
 version1.0/version
 scopeimport/scope
 typepom/type
   /dependency
 /dependencies
   /dependencyManagement

 I set up an example project here:
 https://github.com/ansgarkonermann/maven-amd-experiment

 The project has three submodules:

   modules
 moduledependency-management/module
 modulejava-library/module
 modulegui/module
   /modules

 Both 'java-library' and 'gui' import 'dependency-management'.

 We'd expect Maven to build gui and java-library when issuing mvn -amd
 -pl dependency-management, however only dependency-management gets build.

 Is this by intention or more of a potentially missing feature?

 From our point of view, it would be advantageous to have this as a Maven
 feature, so we can update the dependency management POM(s) in our
 project and call mvn -amd to build all modules depending on the changed
 dependency management POM.

 Is it possible to implement this in Maven? In your opinion, is it also a
 useful feature?

 Best regards

 Ansgar

 -
 To unsubscribe, e-mail: users-unsubscr...@maven.apache.org javascript:;
 For additional commands, e-mail: users-h...@maven.apache.orgjavascript:;



-- 
Sent from my phone

Using scope in dependencyManagement: good idea or bad?

[Andreas Sewe]

Hi all,

the subject say it all: Is declaring scopes in the dependencyManagement
section of your parent POM a good idea or a bad idea?

Best wishes,

Andreas

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

Re: Using scope in dependencyManagement: good idea or bad?

[Joachim Van der Auwera]

In my experience a bad idea (bitten by this in the past). If the same 
dependency is mentioned in dependencyManagement in various places, then 
you may end up with the wrong scope.


I use dependencyManagement to specify the version and possibly 
exclusions. Scope is still managed in the dependency declaration itself.


Kind regards,
Joachim

On 01-06-12 15:05, Andreas Sewe wrote:

Hi all,

the subject say it all: Is declaring scopes in the dependencyManagement
section of your parent POM a good idea or a bad idea?

Best wishes,

Andreas

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




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

Re: Using scope in dependencyManagement: good idea or bad?

[Andreas Sewe]

Joachim Van der Auwera wrote:
 In my experience a bad idea (bitten by this in the past). If the same
 dependency is mentioned in dependencyManagement in various places, then
 you may end up with the wrong scope.
 
 I use dependencyManagement to specify the version and possibly
 exclusions. Scope is still managed in the dependency declaration itself.

Makes sense. I was basically wondering if everyone considers this to
*always* be a bad idea or whether there are exceptions (like a
provided-scoped servlet-api, where a different scope might evne be
considered a bug).

Best wishes,

Andreas

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

Re: Using scope in dependencyManagement: good idea or bad?

[Wayne Fay]

 the subject say it all: Is declaring scopes in the dependencyManagement
 section of your parent POM a good idea or a bad idea?

Unless you are employing an approach wherein all of those deps will be
scope provided [because you are providing them in the application
server's shared libs folder], I think it is a bad idea.

So I guess specifically for provided-scoped things, I support it, but
not for any others.

Wayne

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

RE: Using scope in dependencyManagement: good idea or bad?

[Thiessen, Todd (Todd)]

+1 here. I find it valuable to changing scope to provided.

 -Original Message-
 From: Wayne Fay [mailto:wayne...@gmail.com]
 Sent: Friday, June 01, 2012 10:53 AM
 To: Maven Users List
 Subject: Re: Using scope in dependencyManagement: good idea or bad?
 
  the subject say it all: Is declaring scopes in the
 dependencyManagement
  section of your parent POM a good idea or a bad idea?
 
 Unless you are employing an approach wherein all of those deps will be
 scope provided [because you are providing them in the application
 server's shared libs folder], I think it is a bad idea.
 
 So I guess specifically for provided-scoped things, I support it, but
 not for any others.
 
 Wayne
 
 -
 To unsubscribe, e-mail: users-unsubscr...@maven.apache.org
 For additional commands, e-mail: users-h...@maven.apache.org

Re: Using scope in dependencyManagement: good idea or bad?

[Mark Struberg]

I sometimes use this for libraries (like e.g. openwebbeans-impl) which I 
normally only have a runtime dependency for (generally defined via 
dependencyManagement). 


But in some cases you need to access some internal details. Usually I move 
those parts to some 'utility' module which then has a compile time dependency 
to the needed library.


LieGrue,
strub



- Original Message -
 From: Thiessen, Todd (Todd) tthies...@avaya.com
 To: Maven Users List users@maven.apache.org
 Cc: 
 Sent: Friday, June 1, 2012 5:20 PM
 Subject: RE: Using scope in dependencyManagement: good idea or bad?
 
 +1 here. I find it valuable to changing scope to provided.
 
  -Original Message-
  From: Wayne Fay [mailto:wayne...@gmail.com]
  Sent: Friday, June 01, 2012 10:53 AM
  To: Maven Users List
  Subject: Re: Using scope in dependencyManagement: good idea or bad?
 
   the subject say it all: Is declaring scopes in the
  dependencyManagement
   section of your parent POM a good idea or a bad idea?
 
  Unless you are employing an approach wherein all of those deps will be
  scope provided [because you are providing them in the application
  server's shared libs folder], I think it is a bad idea.
 
  So I guess specifically for provided-scoped things, I support it, but
  not for any others.
 
  Wayne
 
  -
  To unsubscribe, e-mail: users-unsubscr...@maven.apache.org
  For additional commands, e-mail: users-h...@maven.apache.org
 
 
 -
 To unsubscribe, e-mail: users-unsubscr...@maven.apache.org
 For additional commands, e-mail: users-h...@maven.apache.org
 

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

Re: Using scope in dependencyManagement: good idea or bad?

[Mirko Friedenhagen]

Hello,

we use this for dependencies which should go the test scope by default
as well. This prevents stuff like junit or mockito to be part of WARs,
e.g. The only drawback here are our integration test suites where a
lot of the code resides in src/main.

Same goes for logback-classic, which may be used in libraries in the
scope test but should be explicitely declared as either provided (by
our internal tomcat containers). As we use jcl-over-slf4j we define
commons-logging as provided by jcl-over-slf4j as well, so we do not
have to redeclare this in every application again.

Regards Mirko


On Fri, Jun 1, 2012 at 6:03 PM, Mark Struberg strub...@yahoo.de wrote:
 I sometimes use this for libraries (like e.g. openwebbeans-impl) which I 
 normally only have a runtime dependency for (generally defined via 
 dependencyManagement).


 But in some cases you need to access some internal details. Usually I move 
 those parts to some 'utility' module which then has a compile time dependency 
 to the needed library.


 LieGrue,
 strub



 - Original Message -
 From: Thiessen, Todd (Todd) tthies...@avaya.com
 To: Maven Users List users@maven.apache.org
 Cc:
 Sent: Friday, June 1, 2012 5:20 PM
 Subject: RE: Using scope in dependencyManagement: good idea or bad?

 +1 here. I find it valuable to changing scope to provided.

  -Original Message-
  From: Wayne Fay [mailto:wayne...@gmail.com]
  Sent: Friday, June 01, 2012 10:53 AM
  To: Maven Users List
  Subject: Re: Using scope in dependencyManagement: good idea or bad?

   the subject say it all: Is declaring scopes in the
  dependencyManagement
   section of your parent POM a good idea or a bad idea?

  Unless you are employing an approach wherein all of those deps will be
  scope provided [because you are providing them in the application
  server's shared libs folder], I think it is a bad idea.

  So I guess specifically for provided-scoped things, I support it, but
  not for any others.

  Wayne

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


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


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


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

Dependency resolution and dependencyManagement: overriding of scope?

[Laird Nelson]

I submitted a bug on the maven-ear-plugin:
http://jira.codehaus.org/browse/MEAR-143

I think that in the comments I'm being told that dependency management works
in a particular way that I don't see any (documentation) evidence for.  I am
happy to admit I am wrong, if indeed I am wrong.

I would like to educate myself on how dependency management really works so
that either I can close the bug or figure out what the root cause is.

My reference material is
http://maven.apache.org/guides/introduction/introduction-to-dependency-mechanism.html#Dependency_Management;
please let me know in this discussion if this is outdated or wrong.

There is a section in that document that begins with A second, and very
important  In what follows I'll refer to that section's projects A and
B, and will excerpt from them.

In that section, you will see that project A has a dependencyManagement
section that--among other things--defines an artifact, c, as having scope
compile:

!-- In A's pom.xml; condensed for brevity --
dependencyManagement
  dependency
groupIdtest/groupId
artifactIdc/artifactId
version1.0/version
scopecompile/scope !-- look: compile scope --
  /dependency
/dependencyManagement

Then you will see a pom.xml for project B that (a) inherits from project A
(thus inheriting its dependencyManagement section) and (b) establishes a
dependency on artifact c, without having to specify its version.  You will
also notice that the dependency on project c overrides the scope of c to be
runtime, not compile:

!-- In B's pom.xml, whose parent is A's pom.xml (above); condensed for
brevity --
dependencies
  dependency
groupIdtest/groupId
artifactIdc/artifactId
scoperuntime/scope !-- look: runtime scope --
  /dependency
/dependencies

Again, you'll note that there is no version element, but there is a
scoperuntime/scope element.

My interpretation of this is that when all is said and done, *B will depend
on version 1.0 of artifact c in runtime scope, not compile scope.*

Is that correct? My maven-ear-plugin bug rests on the fact that this is the
expected behavior.

Next, if that's correct, I would also expect that if artifact c had any
transitive runtime dependencies they would be available in B's runtime
classpath (as defined by the somewhat baffling table in
http://maven.apache.org/guides/introduction/introduction-to-dependency-mechanism.html#Dependency_Scope).
Is that correct?

Thank you for the education.

Best,
Laird

-- 
http://about.me/lairdnelson

Re: Maven unnecessarily downloads all dependencies from parent, POM's dependencyManagement?

[Richard Kennard]

Apologies - I was wrong about this.

Maven does only download those lt;dependencyManagementgt; dependencies 
necessary for the current child POM, not unrelated ones. It was just 
downloading much more than I expected!

Richard.


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

Maven unnecessarily downloads all dependencies from parent POM's dependencyManagement?

[Richard Kennard]

Hi guys,

First, thanks for a terrific tool in Maven!

For my Open Source project Metawidget (http://metawidget.org) I am distributing 
the examples as standalone Maven projects with their own POMs. However each
POM shares a couple of levels of parent POM, with the top-level parent POM 
defining a dependencyManagement block of artifact versions. I believe this is
pretty common practice?

I instruct my users to first download metawidget-1.20-examples.zip 
(http://metawidget.org/download.php), then extract it and build, say, the GWT 
example
(which has a couple shared projects) using:

-pl org.metawidget.examples.gwt:addressbook-gwt -am install
   
What I *expect* to happen is that Maven builds 
'org.metawidget.examples.gwt:addressbook-gwt' (-pl) and shared projects (-am) 
and automatically downloads
all dependencies related to their dependencies blocks.

What *actually* happens, however, is that Maven seems to traverse up the 
heirarchy to the top-level POM, into its dependencyManagement block, and 
proceed
to download *every* dependency in there. This includes many dependencies that 
have nothing to do with src/examples/gwt/addressbook/pom.xml or its shared
projects.

This behaviour is really killing my user's experience, as it can take over an 
hour to download all dependencyManagement dependencies on a clean machine -
when only a dozen or so are needed for the sake of the tutorial.

Is this a bug? Is there anyway to prevent Maven exhibiting this behaviour?

Regards,

Richard.

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

Should maven release plugin also change versions in dependencyManagement entries?

[Igor Petruk]

Subj. They don't get transformed? Am I doing something wrong, or it is not a 
feature of a plugin?

Thanks

Re: Versions in dependencyManagement vs dependency?

[Laird Nelson]

On Wed, Mar 30, 2011 at 12:44 AM, Anders Hammar and...@hammar.net wrote:

 Be aware that you're talking of two different strategies. Using a pom
 artifact as a dependency and using import scope to import depMgmt declared
 in another pom. Two different things!


Yes, that's exactly my point.  I've seen import scope documented before, but
I've not seen simply having a dependency of type pom documented anywhere on
the Maven site.

Thanks,
Laird

Versions in dependencyManagement vs dependency?

[Brinker, Don-NONEMP]

Got a bit of an architecture/style question here.

I'm familiar with the use of the dependencyManagement block in a parent pom to 
fix versions of or otherwise configure a dependency.  However, except for cases 
which need it (for example, when transitive dependencies are otherwise pulling 
in two versions of the same JAR) I typically don't put versions there, but 
instead in the pom where I'm declaring the dependency itself.  I think this is 
pretty much SOP, if I'm not mistaken.

Now someone on my team has asked why we shouldn't put ALL versions in the 
parent POM (in dependencyManagement blocks, so as not to create additional 
dependencies).  While my initial gut reaction is that's a bad idea (since 
dependency info would then be in at least two places) I thought I'd see if 
anyone else there has tried this and has any pros or cons around the practice.

Thanks

-  Don

Re: Versions in dependencyManagement vs dependency?

[Stephen Connolly]

it depends on how often you update versions and how often you will
release the parent.

if you update versions very often, but you don't want to release the
parent very often, then don't do it.

what I tend to do is aggregate the version info as high up in each
independently releasable tree.

On 29 March 2011 15:13, Brinker, Don-NONEMP dbrin...@collegeboard.org wrote:
 Got a bit of an architecture/style question here.

 I'm familiar with the use of the dependencyManagement block in a parent pom 
 to fix versions of or otherwise configure a dependency.  However, except for 
 cases which need it (for example, when transitive dependencies are otherwise 
 pulling in two versions of the same JAR) I typically don't put versions 
 there, but instead in the pom where I'm declaring the dependency itself.  I 
 think this is pretty much SOP, if I'm not mistaken.

 Now someone on my team has asked why we shouldn't put ALL versions in the 
 parent POM (in dependencyManagement blocks, so as not to create additional 
 dependencies).  While my initial gut reaction is that's a bad idea (since 
 dependency info would then be in at least two places) I thought I'd see if 
 anyone else there has tried this and has any pros or cons around the practice.

 Thanks

 -          Don


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

Re: Versions in dependencyManagement vs dependency?

[juranta]

Well, we put all the versions in the parent pom. It makes the versions easy
to change from the project's perspective. You don't have to browse through
many files to see where the dependency is declared. Also, two or more of the
sub-project may have a dependency on a same artifact, and if you put the
version in the parent pom, you have the version in only one place.

--
View this message in context: 
http://maven.40175.n5.nabble.com/Versions-in-dependencyManagement-vs-dependency-tp4269473p4269530.html
Sent from the Maven - Users mailing list archive at Nabble.com.

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

Re: Versions in dependencyManagement vs dependency?

[Jörg Schaible]

juranta wrote:

 Well, we put all the versions in the parent pom. It makes the versions
 easy to change from the project's perspective. You don't have to browse
 through many files to see where the dependency is declared. Also, two or
 more of the sub-project may have a dependency on a same artifact, and if
 you put the version in the parent pom, you have the version in only one
 place.

Same here. No version info in explicit dependencies.

- Jörg


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

Re: Versions in dependencyManagement vs dependency?

[Ron Wheeler]

We follow Stephen's path but build aggregation poms that only contain 
libraries so that our project POMs only depend on our libraries.
For example if the war file needs the Apache Commons that we support in 
our development environment, the project will depend on the current 
version of ours-lib-commons.pom.
This reduces the project poms to 5-6 dependencies that are almost always 
the same so it is easy to start a new WAR project.


This provides central control (only 3 developers) over what versions are 
used and the JAR file produced by the library pom is shared in Tomcat 
and has provided scope in the WAR project so the war files are really 
small with only our code and WEB-INF files included. This makes the 
developers life easy since the versions of libraries are settled once 
for each release and are not a PITA for the programmer.


This saves a lot of time when building and deploying since we use web 
services and lots of other big tool kits that can take a 20K of classes, 
jsps, etc. and turn it into a 20M monster.

We have about 10 library POMs and over 50 war file POMs.

Ron

On 29/03/2011 12:39 PM, Jörg Schaible wrote:

juranta wrote:


Well, we put all the versions in the parent pom. It makes the versions
easy to change from the project's perspective. You don't have to browse
through many files to see where the dependency is declared. Also, two or
more of the sub-project may have a dependency on a same artifact, and if
you put the version in the parent pom, you have the version in only one
place.

Same here. No version info in explicit dependencies.

- Jörg


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





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

Re: Versions in dependencyManagement vs dependency?

[Laird Nelson]

On Tue, Mar 29, 2011 at 1:22 PM, Ron Wheeler rwhee...@artifact-software.com
 wrote:

 We follow Stephen's path but build aggregation poms that only contain
 libraries so that our project POMs only depend on our libraries.
 For example if the war file needs the Apache Commons that we support in our
 development environment, the project will depend on the current version of
 ours-lib-commons.pom.


Just out of curiosity, where is it written down that one can depend on an
artifact of type pom?  I've always been curious about this.

L

Re: Versions in dependencyManagement vs dependency?

[Wendy Smoak]

On Tue, Mar 29, 2011 at 1:59 PM, Laird Nelson ljnel...@gmail.com wrote:

 Just out of curiosity, where is it written down that one can depend on an
 artifact of type pom?  I've always been curious about this.

Are you asking about import scope?
http://maven.apache.org/guides/introduction/introduction-to-dependency-mechanism.html#Importing_Dependencies

-- 
Wendy

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

Re: Versions in dependencyManagement vs dependency?

[Laird Nelson]

On Tue, Mar 29, 2011 at 2:01 PM, Wendy Smoak wsm...@gmail.com wrote:

 Are you asking about import scope?

 http://maven.apache.org/guides/introduction/introduction-to-dependency-mechanism.html#Importing_Dependencies


I guess I am; is it required that when you're using import scope that the
type element be set to pom?

I assume, therefore, that type pom is not applicable anywhere else except
(a) inside a dependency management entry that (b) has scope import?

L

Re: Versions in dependencyManagement vs dependency?

[Ron Wheeler]

On 29/03/2011 1:59 PM, Laird Nelson wrote:

On Tue, Mar 29, 2011 at 1:22 PM, Ron Wheelerrwhee...@artifact-software.com

wrote:
We follow Stephen's path but build aggregation poms that only contain
libraries so that our project POMs only depend on our libraries.
For example if the war file needs the Apache Commons that we support in our
development environment, the project will depend on the current version of
ours-lib-commons.pom.


Just out of curiosity, where is it written down that one can depend on an
artifact of type pom?  I've always been curious about this.

L

In the case that I described, the actual dependency is on the JAR.

The aggregation POM produces a JAR that is deployed in our Nexus and is 
available like any other third party library and installed in Tomcat's 
/lib as part of the application upgrade.


In the days of cloud servers, a Tomcat dedicated to one application is 
pretty easy to defend if anyone questions the possibility of library 
conflicts between applications.


Sorry for the confusion.
A bit of sloppy writing.
I will try to defend myself by characterizing my description as over 
abstracted.

We only use scope compile or provided.


Ron


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

Re: Versions in dependencyManagement vs dependency?

[Anders Hammar]

Tim talks about this in this blog post:
http://www.sonatype.com/people/2009/10/maven-tips-and-tricks-grouping-dependencies/

A pom artifact is an artifact like all others...it's just that the artifact
is the pom itself.

/Anders

On Tue, Mar 29, 2011 at 19:59, Laird Nelson ljnel...@gmail.com wrote:

 On Tue, Mar 29, 2011 at 1:22 PM, Ron Wheeler 
 rwhee...@artifact-software.com
  wrote:

  We follow Stephen's path but build aggregation poms that only contain
  libraries so that our project POMs only depend on our libraries.
  For example if the war file needs the Apache Commons that we support in
 our
  development environment, the project will depend on the current version
 of
  ours-lib-commons.pom.
 

 Just out of curiosity, where is it written down that one can depend on an
 artifact of type pom?  I've always been curious about this.

 L

Re: Versions in dependencyManagement vs dependency?

[Laird Nelson]

On Tue, Mar 29, 2011 at 3:35 PM, Anders Hammar and...@hammar.net wrote:

 Tim talks about this in this blog post:

 http://www.sonatype.com/people/2009/10/maven-tips-and-tricks-grouping-dependencies/


Thank you, yes, this is the first I've seen this documented.  So that seems
like you don't need scopeimport/scope in order to depend on an artifact
with typepom/type.  This is very useful to see.  I wish it were
documented more prominently.

Best,
Laird

Re: Versions in dependencyManagement vs dependency?

[Anders Hammar]

Be aware that you're talking of two different strategies. Using a pom
artifact as a dependency and using import scope to import depMgmt declared
in another pom. Two different things!

/Anders

On Tue, Mar 29, 2011 at 22:18, Laird Nelson ljnel...@gmail.com wrote:

 On Tue, Mar 29, 2011 at 3:35 PM, Anders Hammar and...@hammar.net wrote:

  Tim talks about this in this blog post:
 
 
 http://www.sonatype.com/people/2009/10/maven-tips-and-tricks-grouping-dependencies/
 

 Thank you, yes, this is the first I've seen this documented.  So that seems
 like you don't need scopeimport/scope in order to depend on an artifact
 with typepom/type.  This is very useful to see.  I wish it were
 documented more prominently.

 Best,
 Laird

Release plugin and dependencyManagement for modules - changes in last version?

[Kaiser, Nils]

Hello,

In our multi-module project we included the module dependencies in the 
dependencyManagement of the parent POM to be able to leave out versions in the 
module POMs. Here a snippet extracted from the master POM:

project ...
...
groupId.../groupId
artifactIdnotif-platform/artifactId
packagingpom/packaging
version1.3.1-SNAPSHOT/version
...
modules
   modulecore-model/module
   modulecore-persistence/module
   modulecore-datasource/module
   modulecore-webapp/module
   modulenotif-core/module
   modulenotif-model/module
...
/modules

dependencyManagement
   dependencies
   dependency
   
groupIdde.adesso.mobile.devicebackend/groupId
   
artifactIdnotif-core/artifactId
   
version1.3.1-SNAPSHOT/version
   /dependency
   dependency
   
groupIdde.adesso.mobile.devicebackend/groupId
   
artifactIdnotif-model/artifactId
   
version1.3.1-SNAPSHOT/version
   /dependency
   dependency
   
groupIdde.adesso.mobile.devicebackend/groupId
   
artifactIdnotif-persistence/artifactId
   
version1.3.1-SNAPSHOT/version
   /dependency
...

We used continuum and the release plugin to manage the releases. In the past, 
the release plugin had no problems with updating the versions in the 
dependenyManagement of the parent POM.

However, since version 2.0 (beta8 is automatically used, but 2.0 shows the same 
behavior) the release plugin does not change the versions in the 
dependencyManagement of the parent POM anymore. It thus produces a broken 
project after running the release plugin, as the module versions are changed in 
the respective module POMs,  but not in the dependencyManagement of the master 
POM.

Is it an error in the new release plugin version?

Is use of module dependency versions in dependencyManagement of the POM 
discouraged now?

Should I submit an issue?

Best regards,

Nils Kaiser

Re: Release plugin and dependencyManagement for modules - changes in last version?

[Kumar Ampani]

Did you try using ${project.version} in the dependency management section ?


On 4/29/10, Kaiser, Nils kai...@adesso-mobile.de wrote:
 Hello,

 In our multi-module project we included the module dependencies in the
 dependencyManagement of the parent POM to be able to leave out versions in
 the module POMs. Here a snippet extracted from the master POM:

 project ...
 ...
 groupId.../groupId
 artifactIdnotif-platform/artifactId
 packagingpom/packaging
 version1.3.1-SNAPSHOT/version
 ...
 modules
modulecore-model/module
modulecore-persistence/module
modulecore-datasource/module
modulecore-webapp/module
modulenotif-core/module
modulenotif-model/module
 ...
 /modules

 dependencyManagement
dependencies
dependency

 groupIdde.adesso.mobile.devicebackend/groupId

 artifactIdnotif-core/artifactId

 version1.3.1-SNAPSHOT/version
/dependency
dependency

 groupIdde.adesso.mobile.devicebackend/groupId

 artifactIdnotif-model/artifactId

 version1.3.1-SNAPSHOT/version
/dependency
dependency

 groupIdde.adesso.mobile.devicebackend/groupId

 artifactIdnotif-persistence/artifactId

 version1.3.1-SNAPSHOT/version
/dependency
 ...

 We used continuum and the release plugin to manage the releases. In the
 past, the release plugin had no problems with updating the versions in the
 dependenyManagement of the parent POM.

 However, since version 2.0 (beta8 is automatically used, but 2.0 shows the
 same behavior) the release plugin does not change the versions in the
 dependencyManagement of the parent POM anymore. It thus produces a broken
 project after running the release plugin, as the module versions are changed
 in the respective module POMs,  but not in the dependencyManagement of the
 master POM.

 Is it an error in the new release plugin version?

 Is use of module dependency versions in dependencyManagement of the POM
 discouraged now?

 Should I submit an issue?

 Best regards,

 Nils Kaiser


-- 
Sent from my mobile device

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

dependencyManagement and Manifest.MF issue

[torsten . reinhard]

Hi, 

in our build, we have a module C with a dependeny to module B, having a 
dependency to module A in version A-4.0.14, but managed to version 
A-4.0.15.
Thus, this version and dependency is build into Manifest.MF of module C:

Class-Path: B-1.0.0-SNAPSHOT.jar A-4.0.15.jar

Later on, we pick up module C, and copy all dependencies of it into a 
directory structure - assuming, that a complete classpath will result.
When copying dependencies, not version A-4.0.15 is copied, but A-4.0.14 
(coming from module B´s dependencies).

= We now have a runtime problem, because in Manifest.MF A-4.0.15 is 
stated, but A-4.0.14 was copied.

Any suggestions how to handle this?

Thanx, Torsten

Re: dependencyManagement and Manifest.MF issue

[Jörg Schaible]

Hi Torsten,
torsten.reinh...@gi-de.com wrote at Dienstag, 23. Februar 2010 15:24:

 Hi,
 
 in our build, we have a module C with a dependeny to module B, having a
 dependency to module A in version A-4.0.14, but managed to version
 A-4.0.15.
 Thus, this version and dependency is build into Manifest.MF of module C:
 
 Class-Path: B-1.0.0-SNAPSHOT.jar A-4.0.15.jar
 
 Later on, we pick up module C, and copy all dependencies of it into a
 directory structure - assuming, that a complete classpath will result.
 When copying dependencies, not version A-4.0.15 is copied, but A-4.0.14
 (coming from module B´s dependencies).
 
 = We now have a runtime problem, because in Manifest.MF A-4.0.15 is
 stated, but A-4.0.14 was copied.
 
 Any suggestions how to handle this?

Use a dependencyManagement section in a shared parent POM where you define 
the versions of your direct and transitive deps. NOte, that such a parent 
POM does not have to be in the parent directory, but can be an artifact on 
its own right with own release cycle.

- Jörg


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

Error using dependencyManagement element in profile

[Matthew Adams]

Hi all,

I'm trying to support different JPA implementations in my build.

According to 
http://maven.apache.org/guides/introduction/introduction-to-profiles.html,
I can specify the dependencyManagement element in a build profile.
However, when I do, I get a POM parse error with the following error
reason:

Reason: Parse error reading POM. Reason: Unrecognised tag:
'dependency' (position: START_TAG seen
...dependencyManagement\r\n\t\t\t\tdependency... @329:17)  for
project

Here's the relevant portion from my root pom:

profiles
profile
iddatanucleus/id
activation
activeByDefaulttrue/activeByDefault
/activation
properties
jpa.impldatanucleus/jpa.impl
/properties
dependencyManagement
dependency
groupIdorg.datanucleus/groupId

artifactIddatanucleus-core/artifactId
version2.0.0-m4/version
/dependency
...
/dependencyManagement
/profile
...

What am I doing wrong?

Thanks in advance,
Matthew

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

Re: Error using dependencyManagement element in profile

[Justin Edelson]

It needs to be
dependencyManagement
*  dependencies*
dependency
 groupIdorg.datanucleus/groupId
 artifactIddatanucleus-core/artifactId
 version2.0.0-m4/version
...more...
/dependency
 * /dependencies*
/dependencyManagement

See
http://maven.apache.org/ref/2.2.1/maven-model/maven.html#class_dependencyManagement

http://maven.apache.org/ref/2.2.1/maven-model/maven.html#class_dependencyManagement
Justin

On Mon, Dec 14, 2009 at 10:03 AM, Matthew Adams matt...@matthewadams.mewrote:

 Hi all,

 I'm trying to support different JPA implementations in my build.

 According to
 http://maven.apache.org/guides/introduction/introduction-to-profiles.html,
 I can specify the dependencyManagement element in a build profile.
 However, when I do, I get a POM parse error with the following error
 reason:

 Reason: Parse error reading POM. Reason: Unrecognised tag:
 'dependency' (position: START_TAG seen
 ...dependencyManagement\r\n\t\t\t\tdependency... @329:17)  for
 project

 Here's the relevant portion from my root pom:

profiles
profile
iddatanucleus/id
activation
activeByDefaulttrue/activeByDefault
/activation
properties
jpa.impldatanucleus/jpa.impl
/properties
dependencyManagement
dependency
groupIdorg.datanucleus/groupId

  artifactIddatanucleus-core/artifactId
version2.0.0-m4/version
/dependency
...
/dependencyManagement
/profile
...

 What am I doing wrong?

 Thanks in advance,
 Matthew

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

Re: Error using dependencyManagement element in profile

[Matthew Adams]

Duh.  My bad.  I figured it had to be something simple.  Thanks!

On Mon, Dec 14, 2009 at 7:10 AM, Justin Edelson justinedel...@gmail.com wrote:
 It needs to be
 dependencyManagement
 *  dependencies*
    dependency
         groupIdorg.datanucleus/groupId
         artifactIddatanucleus-core/artifactId
         version2.0.0-m4/version
    ...more...
    /dependency
  * /dependencies*
 /dependencyManagement

 See
 http://maven.apache.org/ref/2.2.1/maven-model/maven.html#class_dependencyManagement

 http://maven.apache.org/ref/2.2.1/maven-model/maven.html#class_dependencyManagement
 Justin

 On Mon, Dec 14, 2009 at 10:03 AM, Matthew Adams 
 matt...@matthewadams.mewrote:

 Hi all,

 I'm trying to support different JPA implementations in my build.

 According to
 http://maven.apache.org/guides/introduction/introduction-to-profiles.html,
 I can specify the dependencyManagement element in a build profile.
 However, when I do, I get a POM parse error with the following error
 reason:

 Reason: Parse error reading POM. Reason: Unrecognised tag:
 'dependency' (position: START_TAG seen
 ...dependencyManagement\r\n\t\t\t\tdependency... @329:17)  for
 project

 Here's the relevant portion from my root pom:

            profiles
                profile
                        iddatanucleus/id
                        activation
                                activeByDefaulttrue/activeByDefault
                        /activation
                        properties
                                jpa.impldatanucleus/jpa.impl
                        /properties
                        dependencyManagement
                                dependency
                                        groupIdorg.datanucleus/groupId

  artifactIddatanucleus-core/artifactId
                                        version2.0.0-m4/version
                                /dependency
                                ...
                        /dependencyManagement
                /profile
                ...

 What am I doing wrong?

 Thanks in advance,
 Matthew

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






-- 
mailto:matt...@matthewadams.me
skype:matthewadams12
yahoo:matthewadams
aol:matthewadams12
google-talk:matthewadam...@gmail.com
msn:matt...@matthewadams.me
http://matthewadams.me
http://www.linkedin.com/in/matthewadams

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

Automating dependencyManagement enforcement

[Bryan Loofbourrow]

I'm hoping for advice about the best way to accomplish something in
Maven. I am willing to write a plugin if that's the right answer.

 

Here's the thing I want to accomplish:

 

Given a Maven project that builds an ear/war, and which contains a
dependencyManagement section, generally inherited from its parent or a
more distant ancestor, fail the Maven build if any version chosen for
inclusion in the reactor (or the ear or war, if you want to look at it
that way) does not match the version declared in the
dependencyManagement section.

 

The point being, of course, to catch those cases where Maven's version
choices override the ones I made in dependencyManagement, and fail fast.


 

So, is there a way to do it now? If not, what would be the best practice
for accomplishing it? Write a plugin that executes as part of the ear
build? Write a plugin that executes as part of some separate analysis
project, and which uses the ear artifact as a dependency or parameter?

 

I will confess that there's part of me that thinks that this whole need
should not arise, that Maven should simply decline to add anything to
the reactor that matches something declared in dependencyManagement in
every way except for a mismatching version. That's a separate
discussion. If anyone knows whether 3.0 operates more like that, I'd be
interested to know it.

 

Thanks,

 

-- Bryan

 

Bryan Loofbourrow

Principal Software Engineer

Amdocs Interactive

o:+1.206.830.7724 | m: +1.707.849.8892 |

bry...@amdocs.com mailto:bry...@amdocs.com 



This message and the information contained herein is proprietary and 
confidential and subject to the Amdocs policy statement,
you may review at http://www.amdocs.com/email_disclaimer.asp

Re: Automating dependencyManagement enforcement

[Adam Leggett (UPCO)]

Have you checked the possibility of using the enforcer plugin for your
use case?

This does something close:
http://maven.apache.org/enforcer/enforcer-rules/bannedDependencies.html

or you could try creating a custom rule:

http://maven.apache.org/enforcer/enforcer-api/writing-a-custom-rule.html

Adam



On Tue, 2009-12-01 at 03:09 -0800, Bryan Loofbourrow wrote:
 I'm hoping for advice about the best way to accomplish something in
 Maven. I am willing to write a plugin if that's the right answer.
 
  
 
 Here's the thing I want to accomplish:
 
  
 
 Given a Maven project that builds an ear/war, and which contains a
 dependencyManagement section, generally inherited from its parent or a
 more distant ancestor, fail the Maven build if any version chosen for
 inclusion in the reactor (or the ear or war, if you want to look at it
 that way) does not match the version declared in the
 dependencyManagement section.
 
  
 
 The point being, of course, to catch those cases where Maven's version
 choices override the ones I made in dependencyManagement, and fail fast.
 
 
  
 
 So, is there a way to do it now? If not, what would be the best practice
 for accomplishing it? Write a plugin that executes as part of the ear
 build? Write a plugin that executes as part of some separate analysis
 project, and which uses the ear artifact as a dependency or parameter?
 
  
 
 I will confess that there's part of me that thinks that this whole need
 should not arise, that Maven should simply decline to add anything to
 the reactor that matches something declared in dependencyManagement in
 every way except for a mismatching version. That's a separate
 discussion. If anyone knows whether 3.0 operates more like that, I'd be
 interested to know it.
 
  
 
 Thanks,
 
  
 
 -- Bryan
 
  
 
 Bryan Loofbourrow
 
 Principal Software Engineer
 
 Amdocs Interactive
 
 o:+1.206.830.7724 | m: +1.707.849.8892 |
 
 bry...@amdocs.com mailto:bry...@amdocs.com 
 
 
 
 This message and the information contained herein is proprietary and 
 confidential and subject to the Amdocs policy statement,
 you may review at http://www.amdocs.com/email_disclaimer.asp


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

Re: Automating dependencyManagement enforcement

[Anders Hammar]

In Maven you can force a specific version to be used by adding square
brackets:
version[1.0]/version
By doing so you'll make sure Maven doesn't override your version of choice.
However, this will impact projects depending on your artifacts. Normally the
version defined closest to the level you're building has preference, but
forcing a specific version will change that behavior. Also, if two different
versions are forced the build will fail.

/Anders

On Tue, Dec 1, 2009 at 12:09, Bryan Loofbourrow 
bryan.loofbour...@amdocs.com wrote:


 I'm hoping for advice about the best way to accomplish something in
 Maven. I am willing to write a plugin if that's the right answer.



 Here's the thing I want to accomplish:



 Given a Maven project that builds an ear/war, and which contains a
 dependencyManagement section, generally inherited from its parent or a
 more distant ancestor, fail the Maven build if any version chosen for
 inclusion in the reactor (or the ear or war, if you want to look at it
 that way) does not match the version declared in the
 dependencyManagement section.



 The point being, of course, to catch those cases where Maven's version
 choices override the ones I made in dependencyManagement, and fail fast.




 So, is there a way to do it now? If not, what would be the best practice
 for accomplishing it? Write a plugin that executes as part of the ear
 build? Write a plugin that executes as part of some separate analysis
 project, and which uses the ear artifact as a dependency or parameter?



 I will confess that there's part of me that thinks that this whole need
 should not arise, that Maven should simply decline to add anything to
 the reactor that matches something declared in dependencyManagement in
 every way except for a mismatching version. That's a separate
 discussion. If anyone knows whether 3.0 operates more like that, I'd be
 interested to know it.



 Thanks,



 -- Bryan



 Bryan Loofbourrow

 Principal Software Engineer

 Amdocs Interactive

 o:+1.206.830.7724 | m: +1.707.849.8892 |

 bry...@amdocs.com mailto:bry...@amdocs.com



 This message and the information contained herein is proprietary and
 confidential and subject to the Amdocs policy statement,
 you may review at http://www.amdocs.com/email_disclaimer.asp

RE: Automating dependencyManagement enforcement

[Bryan Loofbourrow]

 Have you checked the possibility of using the enforcer plugin for
your use case?

It's a point. But really all that adds to this, that I can see, is the
ability to fail the build, which is already easy to from within a plugin
you're writing.

 This does something close:

http://maven.apache.org/enforcer/enforcer-rules/bannedDependencies.html

I don't see how to parameterize this with the dependencyManagement
values. But it does seem like a usefully rich source of code to examine.

 Adam

Thanks,

-- Bryan




On Tue, 2009-12-01 at 03:09 -0800, Bryan Loofbourrow wrote:
 I'm hoping for advice about the best way to accomplish something in
 Maven. I am willing to write a plugin if that's the right answer.
 
  
 
 Here's the thing I want to accomplish:
 
  
 
 Given a Maven project that builds an ear/war, and which contains a
 dependencyManagement section, generally inherited from its parent or a
 more distant ancestor, fail the Maven build if any version chosen for
 inclusion in the reactor (or the ear or war, if you want to look at it
 that way) does not match the version declared in the
 dependencyManagement section.
 
  
 
 The point being, of course, to catch those cases where Maven's version
 choices override the ones I made in dependencyManagement, and fail
fast.
 
 
  
 
 So, is there a way to do it now? If not, what would be the best
practice
 for accomplishing it? Write a plugin that executes as part of the ear
 build? Write a plugin that executes as part of some separate analysis
 project, and which uses the ear artifact as a dependency or parameter?
 
  
 
 I will confess that there's part of me that thinks that this whole
need
 should not arise, that Maven should simply decline to add anything to
 the reactor that matches something declared in dependencyManagement in
 every way except for a mismatching version. That's a separate
 discussion. If anyone knows whether 3.0 operates more like that, I'd
be
 interested to know it.
 
  
 
 Thanks,
 
  
 
 -- Bryan
 
  
 
 Bryan Loofbourrow
 
 Principal Software Engineer
 
 Amdocs Interactive
 
 o:+1.206.830.7724 | m: +1.707.849.8892 |
 
 bry...@amdocs.com mailto:bry...@amdocs.com 
 
 
 
 This message and the information contained herein is proprietary and
confidential and subject to the Amdocs policy statement,
 you may review at http://www.amdocs.com/email_disclaimer.asp


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


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

RE: Automating dependencyManagement enforcement

[Bryan Loofbourrow]

From: anders.g.ham...@gmail.com [mailto:anders.g.ham...@gmail.com] On
Behalf Of Anders Hammar
Sent: Tuesday, December 01, 2009 4:27 AM
To: Maven Users List
Subject: Re: Automating dependencyManagement enforcement

In Maven you can force a specific version to be used by adding square
brackets:
version[1.0]/version
By doing so you'll make sure Maven doesn't override your version of
choice.
However, this will impact projects depending on your artifacts. Normally
the
version defined closest to the level you're building has preference, but
forcing a specific version will change that behavior. Also, if two
different
versions are forced the build will fail.

/Anders


That's almost there, isn't it? But you're right, it's too heavy handed
for what I want, which is more about maintaining control over
third-party artifact versions when I build a particular assembly that
packages them (war, ear, tgz, ...),  than about forcing everyone who
uses the artifacts of mine that went into that assembly, to make their
own assemblies, to be required to insist on using those versions.

Thanks,

-- Bryan


This message and the information contained herein is proprietary and 
confidential and subject to the Amdocs policy statement,
you may review at http://www.amdocs.com/email_disclaimer.asp

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

Parent multimodule pom dependencyManagement block for defining versions of modules contained in the same multimodule project

[Baptiste MATHUS]

Hi all,

Well, I tried to find a clear title. But it wasn't so simple :-). So I'll
describe my question below.
This is more a best practice question than a feasibility one. In fact, we
already use but feel not sure if this is correct.

We have a multimodule project that contains some modules.
Something like :


multimodule project (with unique version for all artefacts parent and
children) :
parent-pom
project1/
project2/ (depends on project1)
project3/
project4/
...

Then we have projects that :

   - use some of the projects above.
   - always inherit the parent-pom above that defines a dependencyManagement
   block


The question is :
Is there a problem to put project1, project2... in the parent-pom
dependencyManagement block of the parent-pom project ?

I think this could create kind of circularity (I know this is not a real
dependency). In fact, this would make project1,2... depend on parent-pom.
And in turn, parent-pom would kind of know those projects inside the depMgmt
block.

Do you see a problem doing that?

I hope I'm being clear.

Thanks for any answer.
Cheers.

-- 
Baptiste Batmat MATHUS - http://batmat.net
Save a tree,
Eat a beaver!

Re: Parent multimodule pom dependencyManagement block for defining versions of modules contained in the same multimodule project

[Jörg Schaible]

Hi,

Baptiste MATHUS wrote at Mittwoch, 4. November 2009 11:06:

 Hi all,
 
 Well, I tried to find a clear title. But it wasn't so simple :-). So I'll
 describe my question below.
 This is more a best practice question than a feasibility one. In fact, we
 already use but feel not sure if this is correct.
 
 We have a multimodule project that contains some modules.
 Something like :
 
 
 multimodule project (with unique version for all artefacts parent and
 children) :
 parent-pom
 project1/
 project2/ (depends on project1)
 project3/
 project4/
 ...
 
 Then we have projects that :
 
- use some of the projects above.
- always inherit the parent-pom above that defines a
dependencyManagement block
 
 
 The question is :
 Is there a problem to put project1, project2... in the parent-pom
 dependencyManagement block of the parent-pom project ?

No.

 I think this could create kind of circularity (I know this is not a real
 dependency).

As you said, only dependency declaration can generate circles.

 In fact, this would make project1,2... depend on parent-pom. 
 And in turn, parent-pom would kind of know those projects inside the
 depMgmt block.
 
 Do you see a problem doing that?

No, we're doing this since years now.

 I hope I'm being clear.

Clear enough ;-)

- Jörg


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

Problems with exact versions in dependencyManagement

[Will Horn]

I use dependencyManagement in a root pom to handle all the artifact versions
for a complex project.  From the documentation [1] and [2], I see that 

version1.0.0/version

is a soft version and 

version[1.0.0]/version

is an exact version.  An exact version seems much preferable to a soft
version.  I would like to know exactly which versions of different third
party artifacts are being used in my application.

However, exact versions have caused quite a few headaches.  For one, many
artifacts in the central repo don't have correct metadata.xml and thus maven
won't resolve [1.0.0] even though the artifact is there ([3] is such an
example).

I just created http://jira.codehaus.org/browse/MNG-4159 because
DefaultDependencyTreeBuilder throws and NPE when used against a project that
has exact versions in its dependencyManagement.

Exact versions seem to be really buggy and it seems to be because no one
uses them!  Is there another way to manage versions so I can be sure maven
is using exactly the one I want?

[2] has a comment about exact versions We point this out to make you aware
of the option, but use it sparingly and only when really needed. The
preferred way to resolve this is via dependencyManagement.  I don't see how
dependencyManagement addresses this.

Thanks,
Will


[1]
http://docs.codehaus.org/display/MAVEN/Dependency+Mediation+and+Conflict+Resolution#DependencyMediationandConflictResolution-DependencyVersionRanges
[2]
http://www.sonatype.com/books/maven-book/reference/pom-relationships-sect-version-ranges.html
[3]
http://repo2.maven.org/maven2/net/java/dev/glazedlists/glazedlists_java15/maven-metadata.xml
only lists 1.6.1 even though 1.7.0 and 1.8.0 are in the repo.  An dependency
on glazedlists [1.8.0] will fail to resolve.
-- 
View this message in context: 
http://www.nabble.com/Problems-with-exact-versions-in-dependencyManagement-tp23508559p23508559.html
Sent from the Maven - Users mailing list archive at Nabble.com.


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

Re: resolve dependencyManagement dependencies from a bill of materials (bom) pom

[Thejaswi Narayana]

I guess the Maven dependency plugin goals do that. Do not remember which
ones. 


Jim Sellers wrote:
 
 Hi all.
 
 For the company that I work at we've got a bill of materials (bom) pom
 that contains dependencies that we know will work together.  Projects will
 use the import scope to pull this into their own projects.  However, there
 is a possibility of putting in an artifact that won't be resolved by our
 corp proxy (archiva).
 
 Does anyone know of a plugin or way when running the a phase of the bom it
 will try and resolve and download these dependencies?  That way a mistake
 can be found at that stage that something is wrong.
 
 eg. if the pom depends on org.hibernate:hibernate-core:999, you won't see
 any issue until the projects that use that pom are built.
 
 Thanks for your time!
 Jim
 
 

-- 
View this message in context: 
http://www.nabble.com/resolve-dependencyManagement-dependencies-from-a-bill-of-materials--%28bom%29-pom-tp23164670p23411964.html
Sent from the Maven - Users mailing list archive at Nabble.com.


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

Re: resolve dependencyManagement dependencies from a bill of materials (bom) pom

[Jim Sellers]

No goals in the dependency do this as far as I know.  Just for fun I tried
to run all the goals to see if one of them would do it, but they don't.

There is a ticket open for having a tree for the dep management section,
and I believe that would work for me.
http://jira.codehaus.org/browse/MDEP-201

Thanks.
Jim


On Wed, May 6, 2009 at 1:44 PM, Thejaswi Narayana thejasw...@gmail.comwrote:


 I guess the Maven dependency plugin goals do that. Do not remember which
 ones.


 Jim Sellers wrote:
 
  Hi all.
 
  For the company that I work at we've got a bill of materials (bom) pom
  that contains dependencies that we know will work together.  Projects
 will
  use the import scope to pull this into their own projects.  However,
 there
  is a possibility of putting in an artifact that won't be resolved by our
  corp proxy (archiva).
 
  Does anyone know of a plugin or way when running the a phase of the bom
 it
  will try and resolve and download these dependencies?  That way a mistake
  can be found at that stage that something is wrong.
 
  eg. if the pom depends on org.hibernate:hibernate-core:999, you won't see
  any issue until the projects that use that pom are built.
 
  Thanks for your time!
  Jim
 
 

 --
 View this message in context:
 http://www.nabble.com/resolve-dependencyManagement-dependencies-from-a-bill-of-materials--%28bom%29-pom-tp23164670p23411964.html
 Sent from the Maven - Users mailing list archive at Nabble.com.


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

dependencyManagement

[EJ Ciramella]

I have a quick question about dependencyManagement - if moduleA has a
dependencyManagement tag that pulls in a pom that has a bunch of
dependencies.
 
ModuleB depends on moduleA.  During a build of ModuleB, I can see it
trying to get at the pom specified in the dependencyManagement section
of moduleA, but it can't seem to find it in our local repository.  Yet,
building moduleA, there are no problems.
 
Am I missing some thing with regard to how these import scoped
dependencies work?
 
 

Re: dependencyManagement

[Jörg Schaible]

EJ Ciramella wrote:

 I have a quick question about dependencyManagement - if moduleA has a
 dependencyManagement tag that pulls in a pom that has a bunch of
 dependencies.
  
 ModuleB depends on moduleA.  During a build of ModuleB, I can see it
 trying to get at the pom specified in the dependencyManagement section
 of moduleA, but it can't seem to find it in our local repository.  Yet,
 building moduleA, there are no problems.
  
 Am I missing some thing with regard to how these import scoped
 dependencies work?

This is MNG-3553 ... see also current discussion on dev. I've been hit by
Arnaud's case also.

- Jörg


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

RE: Re: dependencyManagement

[EJ Ciramella]

Nice - thanks for the quick reply.

Can I have that hour of my life back now :-)

We are using 2.0.9 and it's not a trivial thing to get people and our 
environments updated.

Is this truly fixed in 2.0.something beyond what I'm using? Or 2.2.0? 

-Original Message-
From: news [mailto:n...@ger.gmane.org] On Behalf Of Jörg Schaible
Sent: Wednesday, May 06, 2009 7:30 PM
To: users@maven.apache.org
Subject: Re: dependencyManagement

EJ Ciramella wrote:

 I have a quick question about dependencyManagement - if moduleA has a 
 dependencyManagement tag that pulls in a pom that has a bunch of 
 dependencies.
  
 ModuleB depends on moduleA.  During a build of ModuleB, I can see it 
 trying to get at the pom specified in the dependencyManagement section 
 of moduleA, but it can't seem to find it in our local repository.  
 Yet, building moduleA, there are no problems.
  
 Am I missing some thing with regard to how these import scoped 
 dependencies work?

This is MNG-3553 ... see also current discussion on dev. I've been hit by 
Arnaud's case also.

- Jörg


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


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

Clarification on dependencyManagement

[Grant Rettke]

Hi folks,

When you use the dependencyManagement section in a parent POM, its
purpose is to allow for children to optionally specify those entries
dependencies, without a version number. It is a convenience.

When you specify them, though, are you making those entries serve as
dependencies for the POM in which they are defined?

My understanding is YES, because if you were to enter them in the
dependencies section, they they would automatically be dependencies in
the child POM, too.

Best wishes,

Grant

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

Re: Clarification on dependencyManagement

[Nick Stolwijk]

NO, ;) , not all dependencies in the parent should be dependencies of
the child, that is completely up to the child project. For example, in
the parent pom you have defined the depManagement for Hibernate,
Spring-MVC and commons-validator. You have different child modules:
project-web, project-model and project-data. Project-web should have a
dependency on spring-mvc and commons-validator, project-data on
hibernate and project-model on commons-validator. You set the version
numbers in the parent pom and define the exact dependencies in the
child poms.

Hth,

Nick Stolwijk
~Java Developer~

Iprofs BV.
Claus Sluterweg 125
2012 WS Haarlem
www.iprofs.nl



On Fri, May 1, 2009 at 1:41 AM, Grant Rettke gret...@acm.org wrote:
 My understanding is YES, because if you were to enter them in the
 dependencies section, they they would automatically be dependencies in
 the child POM, too.

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

resolve dependencyManagement dependencies from a bill of materials (bom) pom

[Jim Sellers]

Hi all.

For the company that I work at we've got a bill of materials (bom) pom
that contains dependencies that we know will work together.  Projects will
use the import scope to pull this into their own projects.  However, there
is a possibility of putting in an artifact that won't be resolved by our
corp proxy (archiva).

Does anyone know of a plugin or way when running the a phase of the bom it
will try and resolve and download these dependencies?  That way a mistake
can be found at that stage that something is wrong.

eg. if the pom depends on org.hibernate:hibernate-core:999, you won't see
any issue until the projects that use that pom are built.

Thanks for your time!
Jim

updating dependencyManagement section in pom.xml using Maven Embedder

[Sankaran, Nambi]

Hi
 
I need to change the versions of dependencies in dependencyManagement in
my super pom for each new release.
So, I am doing that using MavenEmbedder.
when the pom.xml is saved back to the disk, the maven expressions are
replaced by actual values based on the project.
 
 
MavenEmbedder embedder = new MavenEmbedder(configuration);

MavenEmbedderLogger logger = new MavenEmbedderConsoleLogger();

embedder.setLogger(logger);



MavenProject project = embedder.readProject( new File(pomFilePath) );



// set the version

project.setVersion(version);



// get the distributionManagement Section

DistributionManagement distributionMgmt=
project.getDistributionManagement();



// update the URL for distributionMgmt

DeploymentRepository repository = new DeploymentRepository();

repository.setUrl(repositoryUrl );

distributionMgmt.setRepository(repository);



 

// write the pom file

BufferedWriter writer = new BufferedWriter(new FileWriter( pomFilePath
));

project.writeModel(writer);

 
 
What is the best way to update dependencyManagement section using maven
embedder?
 
Thanks
Nambi
 

dependencyManagement do not work for attached artifacts

[Mark Struberg]

Hi!

I'm not sure if this behaviour is by design or a bug.

The situation:

I have 2 modules in my project

1.) openwebbeans-impl
2.) openwebbeans-tck (there is a reason for having this in a separate module 
currently)

The impl contains test code (e.g. MockManager) which I like to use in the tck 
module, so I used the maven-jar-plugin:test-jar to additionally create an 
attached artifact with classifier tests

Now my problem:

The dependencyManagement in the parent pom contains the version for 
openwebbeans-impl, but this version doesn't work for all attached items of this 
artifact. So maven is complaining about not finding the version of 
openwebbeans-impl:tests.

I'd expect maven to use the version of the main artifact if no special version 
is defined for an attached artifact.
Otherwise I'd have to maintain the version of impl twice in my 
dependencyManagement section

WDYT? bug or by design?

txs and LieGrue,
strub




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

Re: dependencyManagement do not work for attached artifacts

[Jörg Schaible]

Mark Struberg wrote:

 Hi!
 
 I'm not sure if this behaviour is by design or a bug.
 
 The situation:
 
 I have 2 modules in my project
 
 1.) openwebbeans-impl
 2.) openwebbeans-tck (there is a reason for having this in a separate
 module currently)
 
 The impl contains test code (e.g. MockManager) which I like to use in the
 tck module, so I used the maven-jar-plugin:test-jar to additionally create
 an attached artifact with classifier tests
 
 Now my problem:
 
 The dependencyManagement in the parent pom contains the version for
 openwebbeans-impl, but this version doesn't work for all attached items of
 this artifact. So maven is complaining about not finding the version of
 openwebbeans-impl:tests.
 
 I'd expect maven to use the version of the main artifact if no special
 version is defined for an attached artifact. Otherwise I'd have to
 maintain the version of impl twice in my dependencyManagement section
 
 WDYT? bug or by design?

By design. Each classifier defines a separate artifact with individual
settings for version and scope. Typically you will set scope test for
this artifact in your depMgmnt section ...

- Jörg


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

Re: dependencyManagement do not work for attached artifacts

[Mark Struberg]

Hi Jörg!

 Typically you will set scope test for
 this artifact in your depMgmnt section ...

Yup, but this means that the version has to be set twice.
Also I'm not sure if the maven-release-plugin can handle 2 dependencyManagement 
entries for the same module correctly.

Has anyone tried releasing such a scenario yet?

txs and LieGrue,
strub

--- Jörg Schaible joerg.schai...@gmx.de schrieb am Sa, 17.1.2009:

 Von: Jörg Schaible joerg.schai...@gmx.de
 Betreff: Re: dependencyManagement do not work for attached artifacts
 An: users@maven.apache.org
 Datum: Samstag, 17. Januar 2009, 15:53
 Mark Struberg wrote:
 
  Hi!
  
  I'm not sure if this behaviour is by design or a
 bug.
  
  The situation:
  
  I have 2 modules in my project
  
  1.) openwebbeans-impl
  2.) openwebbeans-tck (there is a reason for having
 this in a separate
  module currently)
  
  The impl contains test code (e.g. MockManager) which I
 like to use in the
  tck module, so I used the maven-jar-plugin:test-jar to
 additionally create
  an attached artifact with classifier tests
  
  Now my problem:
  
  The dependencyManagement in the parent pom contains
 the version for
  openwebbeans-impl, but this version doesn't work
 for all attached items of
  this artifact. So maven is complaining about not
 finding the version of
  openwebbeans-impl:tests.
  
  I'd expect maven to use the version of the main
 artifact if no special
  version is defined for an attached artifact. Otherwise
 I'd have to
  maintain the version of impl twice in my
 dependencyManagement section
  
  WDYT? bug or by design?
 
 By design. Each classifier defines a separate artifact with
 individual
 settings for version and scope. Typically you will set
 scope test for
 this artifact in your depMgmnt section ...
 
 - Jörg
 
 




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

RE: dependencyManagement do not work for attached artifacts

[Brian E. Fox]

Specify another dependencyManagement and specify the classifier tests and it 
will work. Classifier is part of the coordinates and if you skip it, it's 
assumed to be null. If you want to keep both entries in sync, then define a 
property for the version.

-Original Message-
From: Mark Struberg [mailto:strub...@yahoo.de] 
Sent: Saturday, January 17, 2009 5:27 AM
To: users@maven.apache.org
Subject: dependencyManagement do not work for attached artifacts

Hi!

I'm not sure if this behaviour is by design or a bug.

The situation:

I have 2 modules in my project

1.) openwebbeans-impl
2.) openwebbeans-tck (there is a reason for having this in a separate module 
currently)

The impl contains test code (e.g. MockManager) which I like to use in the tck 
module, so I used the maven-jar-plugin:test-jar to additionally create an 
attached artifact with classifier tests

Now my problem:

The dependencyManagement in the parent pom contains the version for 
openwebbeans-impl, but this version doesn't work for all attached items of this 
artifact. So maven is complaining about not finding the version of 
openwebbeans-impl:tests.

I'd expect maven to use the version of the main artifact if no special version 
is defined for an attached artifact.
Otherwise I'd have to maintain the version of impl twice in my 
dependencyManagement section

WDYT? bug or by design?

txs and LieGrue,
strub


  

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

RE: dependencyManagement do not work for attached artifacts

[Mark Struberg]

Thanks Brian!

I know about this approach, but I'm not sure if the maven-release-plugin can 
handle this case properly! So if I do a full release, will the versions of 
_both_ references in the dependencyManagement section be updated correctly, or 
only the one without classifier?

Regarding the property: the property-expansion takes place before the project 
tree is built, isn't? If so, this should work (assuming a yes in above case) 
since the maven-release-plugin would get the proper version string filled in 
before.

txs,
strub

--- Brian E. Fox bri...@reply.infinity.nu schrieb am Sa, 17.1.2009:

 Von: Brian E. Fox bri...@reply.infinity.nu
 Betreff: RE: dependencyManagement do not work for attached artifacts
 An: Maven Users List users@maven.apache.org
 Datum: Samstag, 17. Januar 2009, 19:33
 Specify another dependencyManagement and specify the
 classifier tests and it will work. Classifier is
 part of the coordinates and if you skip it, it's assumed
 to be null. If you want to keep both entries in sync, then
 define a property for the version.
 
 -Original Message-
 From: Mark Struberg [mailto:strub...@yahoo.de] 
 Sent: Saturday, January 17, 2009 5:27 AM
 To: users@maven.apache.org
 Subject: dependencyManagement do not work for attached
 artifacts
 
 Hi!
 
 I'm not sure if this behaviour is by design or a bug.
 
 The situation:
 
 I have 2 modules in my project
 
 1.) openwebbeans-impl
 2.) openwebbeans-tck (there is a reason for having this in
 a separate module currently)
 
 The impl contains test code (e.g. MockManager) which I like
 to use in the tck module, so I used the
 maven-jar-plugin:test-jar to additionally create an attached
 artifact with classifier tests
 
 Now my problem:
 
 The dependencyManagement in the parent pom contains the
 version for openwebbeans-impl, but this version doesn't
 work for all attached items of this artifact. So maven is
 complaining about not finding the version of
 openwebbeans-impl:tests.
 
 I'd expect maven to use the version of the main
 artifact if no special version is defined for an attached
 artifact.
 Otherwise I'd have to maintain the version of impl
 twice in my dependencyManagement section
 
 WDYT? bug or by design?
 
 txs and LieGrue,
 strub
 
 
   
 
 -
 To unsubscribe, e-mail: users-unsubscr...@maven.apache.org
 For additional commands, e-mail:
 users-h...@maven.apache.org




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

Re: dependencyManagement do not work for attached artifacts

[Jörg Schaible]

Mark Struberg wrote:

 Hi Jörg!
 
 Typically you will set scope test for
 this artifact in your depMgmnt section ...
 
 Yup, but this means that the version has to be set twice.
 Also I'm not sure if the maven-release-plugin can handle 2
 dependencyManagement entries for the same module correctly.
 
 Has anyone tried releasing such a scenario yet?

Yes, it does.

- Jörg


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

MultiModule and DependencyManagement?

[Mohan K R]

It appears that I'm missing something critical here, so please help me out.
I have a standard
multi-module project like this. (I'm using Maven 2.0.9, JDK5).

 parent (P) -
|- module A
|- module B
|- module C


A,B,C all inherit from the parent P.

Now in my parent POM (P): I have a dependencyManagement section in the POM.
 depedencyManagement
dependencies
   dependency
   groupIdlog4j/groupId
   artifactIdlog4j/artifactId
   version1.2.14/version
   dependency
   ...  bunch of others ...
dependencies
 /dependencyManagement

Now in module A (I have a dependency on log4j), so only thing that I provide
is (notice no version):

dependencies
   dependency
   groupIdlog4j/groupId
   artifactIdlog4j/artifactId
   dependency
   ...  bunch of others ...
dependencies

Now in module B depends on module A so I have this in my dependency:
dependencies
   dependency
   groupId${project.groupId}/groupId
   artifactIdmodule_A/artifactId !-- NOTICE MODULE A --
   version${project.version}/version
   dependency
   ...  bunch of others ...*but no log4j*
dependencies
NOTE: I do use log4j in B, but it got transitively pulled in. So far so
good.

Now Module C, depends on Module B. So what I have is:
dependencies
   dependency
   groupId${project.groupId}/groupId
   artifactIdmodule_B/artifactId   !-- NOTICE MODULE B
--
   version${project.version}/version
   dependency
   ...  bunch of others ...
dependencies
Now, I do use some log4j calls (LogFactory), but for some reason log4j does
not
get pulled in transitively??? I have to explicitly give a dependency on
log4j *or*
module_A to get it to compile??

My first that was, all transitive dependencies on module_B should get pulled
in which
means module_A and in turn its transitive dependency log4j. But nothing of
this sort
is happening? Any ideas? Is it the dependecyManagement section (which has
the version)
that is messing me up, since C does inherit from P?

Thanks
Mohan K

Re: MultiModule and DependencyManagement?

[Walid jo Gedeon]

Hello Mohan,

In more technical jargon, log4j in your example is a compile time dependency
of A, and only a runtime dependency of C, which means that if you want to
make log4j calls in C, you need to declare it as a compile time dependency
(default scope).

HTH,
w

On Sun, Nov 30, 2008 at 12:20 AM, Mohan K R [EMAIL PROTECTED] wrote:

 It appears that I'm missing something critical here, so please help me out.
 I have a standard
 multi-module project like this. (I'm using Maven 2.0.9, JDK5).

  parent (P) -
|- module A
|- module B
|- module C


 A,B,C all inherit from the parent P.

 Now in my parent POM (P): I have a dependencyManagement section in the POM.
  depedencyManagement
dependencies
   dependency
   groupIdlog4j/groupId
   artifactIdlog4j/artifactId
   version1.2.14/version
   dependency
   ...  bunch of others ...
dependencies
  /dependencyManagement

 Now in module A (I have a dependency on log4j), so only thing that I
 provide
 is (notice no version):

dependencies
   dependency
   groupIdlog4j/groupId
   artifactIdlog4j/artifactId
   dependency
   ...  bunch of others ...
dependencies

 Now in module B depends on module A so I have this in my dependency:
dependencies
   dependency
   groupId${project.groupId}/groupId
   artifactIdmodule_A/artifactId !-- NOTICE MODULE A --
   version${project.version}/version
   dependency
   ...  bunch of others ...*but no log4j*
dependencies
 NOTE: I do use log4j in B, but it got transitively pulled in. So far so
 good.

 Now Module C, depends on Module B. So what I have is:
dependencies
   dependency
   groupId${project.groupId}/groupId
   artifactIdmodule_B/artifactId   !-- NOTICE MODULE B
 --
   version${project.version}/version
   dependency
   ...  bunch of others ...
dependencies
 Now, I do use some log4j calls (LogFactory), but for some reason log4j does
 not
 get pulled in transitively??? I have to explicitly give a dependency on
 log4j *or*
 module_A to get it to compile??

 My first that was, all transitive dependencies on module_B should get
 pulled
 in which
 means module_A and in turn its transitive dependency log4j. But nothing of
 this sort
 is happening? Any ideas? Is it the dependecyManagement section (which has
 the version)
 that is messing me up, since C does inherit from P?

 Thanks
 Mohan K

Re: MultiModule and DependencyManagement?

[Mohan K R]

Thanks Stevo! Forgot to metion that it does work fine in eclipse (I'm using
m2eclipse plugin
but it fails when I compile it from the CLI). I will give the above project
a shot. Thanks again
Mohan

On Sat, Nov 29, 2008 at 6:05 PM, Stevo Slavić [EMAIL PROTECTED] wrote:

 Hello Mohan,

 Attached you can find an archive with eclipse maven multi-module project
 created as one you've described, so you can see transitive dependencies are
 working as expected. Your project is obviously somewhat different than what
 you described, and it is having effect on dependencies not being passed on.
 Check dependency scope and read 
 thishttp://maven.apache.org/guides/introduction/introduction-to-dependency-mechanism.html,
 maybe it will help.

 Regards,
 Stevo.


 On Sun, Nov 30, 2008 at 12:20 AM, Mohan K R [EMAIL PROTECTED] wrote:

 It appears that I'm missing something critical here, so please help me
 out.
 I have a standard
 multi-module project like this. (I'm using Maven 2.0.9, JDK5).

  parent (P) -
|- module A
|- module B
|- module C


 A,B,C all inherit from the parent P.

 Now in my parent POM (P): I have a dependencyManagement section in the
 POM.
  depedencyManagement
dependencies
   dependency
   groupIdlog4j/groupId
   artifactIdlog4j/artifactId
   version1.2.14/version
   dependency
   ...  bunch of others ...
dependencies
  /dependencyManagement

 Now in module A (I have a dependency on log4j), so only thing that I
 provide
 is (notice no version):

dependencies
   dependency
   groupIdlog4j/groupId
   artifactIdlog4j/artifactId
   dependency
   ...  bunch of others ...
dependencies

 Now in module B depends on module A so I have this in my dependency:
dependencies
   dependency
   groupId${project.groupId}/groupId
   artifactIdmodule_A/artifactId !-- NOTICE MODULE A --
   version${project.version}/version
   dependency
   ...  bunch of others ...*but no log4j*
dependencies
 NOTE: I do use log4j in B, but it got transitively pulled in. So far so
 good.

 Now Module C, depends on Module B. So what I have is:
dependencies
   dependency
   groupId${project.groupId}/groupId
   artifactIdmodule_B/artifactId   !-- NOTICE MODULE B
 --
   version${project.version}/version
   dependency
   ...  bunch of others ...
dependencies
 Now, I do use some log4j calls (LogFactory), but for some reason log4j
 does
 not
 get pulled in transitively??? I have to explicitly give a dependency on
 log4j *or*
 module_A to get it to compile??

 My first that was, all transitive dependencies on module_B should get
 pulled
 in which
 means module_A and in turn its transitive dependency log4j. But nothing of
 this sort
 is happening? Any ideas? Is it the dependecyManagement section (which has
 the version)
 that is messing me up, since C does inherit from P?

 Thanks
 Mohan K



 -
 To unsubscribe, e-mail: [EMAIL PROTECTED]
 For additional commands, e-mail: [EMAIL PROTECTED]

Re: MultiModule and DependencyManagement?

[Mohan K R]

Thanks Walid. I think this is where my confusion is, the default scope is
compile. And
as per the matrix on the maven site it has an asterik describing the scope
resolution.
(for transitive dependencies)

quote from docs: (
http://maven.apache.org/guides/introduction/introduction-to-dependency-mechanism.html
)

*(*) Note:* it is intended that this should be runtime scope instead, so
that all compile dependencies must be explicitly listed - however, there is
the case where the library you depend on extends a class from another
library, forcing you to have available at compile time. For this reason,
compile time dependencies remain as compile scope even when they are
transitive.

The above is the explanation for compile time dependency, as per above, it
should not
be runtime scope in C as you described or am I interpreting this wrong? It
appears that
if your explanation is right, then the doc should change that to runtime, at
least that
is what appears to be the behaviour in Maven 2.0.9.


Thanks again



On Sat, Nov 29, 2008 at 6:08 PM, Walid jo Gedeon [EMAIL PROTECTED] wrote:

 Hello Mohan,

 In more technical jargon, log4j in your example is a compile time
 dependency
 of A, and only a runtime dependency of C, which means that if you want to
 make log4j calls in C, you need to declare it as a compile time dependency
 (default scope).

 HTH,
 w

 On Sun, Nov 30, 2008 at 12:20 AM, Mohan K R [EMAIL PROTECTED] wrote:

  It appears that I'm missing something critical here, so please help me
 out.
  I have a standard
  multi-module project like this. (I'm using Maven 2.0.9, JDK5).
 
   parent (P) -
 |- module A
 |- module B
 |- module C
 
 
  A,B,C all inherit from the parent P.
 
  Now in my parent POM (P): I have a dependencyManagement section in the
 POM.
   depedencyManagement
 dependencies
dependency
groupIdlog4j/groupId
artifactIdlog4j/artifactId
version1.2.14/version
dependency
...  bunch of others ...
 dependencies
   /dependencyManagement
 
  Now in module A (I have a dependency on log4j), so only thing that I
  provide
  is (notice no version):
 
 dependencies
dependency
groupIdlog4j/groupId
artifactIdlog4j/artifactId
dependency
...  bunch of others ...
 dependencies
 
  Now in module B depends on module A so I have this in my dependency:
 dependencies
dependency
groupId${project.groupId}/groupId
artifactIdmodule_A/artifactId !-- NOTICE MODULE A --
version${project.version}/version
dependency
...  bunch of others ...*but no log4j*
 dependencies
  NOTE: I do use log4j in B, but it got transitively pulled in. So far so
  good.
 
  Now Module C, depends on Module B. So what I have is:
 dependencies
dependency
groupId${project.groupId}/groupId
artifactIdmodule_B/artifactId   !-- NOTICE MODULE
 B
  --
version${project.version}/version
dependency
...  bunch of others ...
 dependencies
  Now, I do use some log4j calls (LogFactory), but for some reason log4j
 does
  not
  get pulled in transitively??? I have to explicitly give a dependency on
  log4j *or*
  module_A to get it to compile??
 
  My first that was, all transitive dependencies on module_B should get
  pulled
  in which
  means module_A and in turn its transitive dependency log4j. But nothing
 of
  this sort
  is happening? Any ideas? Is it the dependecyManagement section (which has
  the version)
  that is messing me up, since C does inherit from P?
 
  Thanks
  Mohan K
 

Re: MultiModule and DependencyManagement?

[Barrie Treloar]

On Sun, Nov 30, 2008 at 9:50 AM, Mohan K R [EMAIL PROTECTED] wrote:
 It appears that I'm missing something critical here, so please help me out.
 I have a standard
 multi-module project like this. (I'm using Maven 2.0.9, JDK5).

  parent (P) -
|- module A
|- module B
|- module C
[del]
 NOTE: I do use log4j in B, but it got transitively pulled in. So far so
 good.

WARNING!

It is BAD practice to use a dependency that you do not declare.

If you are using log4j in module B, make sure that you declare it.

You can use dependency:analyze to show you where you may need to fix things up.
It doesn't work very well on the test scopes because there is no
equivalent of runtime for test.

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

RE: dependency and dependencymanagement - confusion

[kvenkatraman]

Thanks Matt . Now I am clear about dependencyManagement

Thanks
kumar
-- 
View this message in context: 
http://www.nabble.com/dependency-and-dependencymanagement---confusion-tp20318920p20356379.html
Sent from the Maven - Users mailing list archive at Nabble.com.


-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

RE: dependency and dependencymanagement - confusion

[Matthew Tordoff]

If you have additional dependencies in project B that aren't in A, and
those dependencies have an additional dependencies which are the same as
those in project A, but of a different version. Then you require
dependency management.

The best way to look at it is to see a tree of dependencies, each with
their own subdependencies. If at any point in that tree you have two
dependencies on the same component, however, with different versions,
you need to specify which version to use in preference.

Matt

-Original Message-
From: kvenkatraman [mailto:[EMAIL PROTECTED] 
Sent: 04 November 2008 09:35
To: users@maven.apache.org
Subject: dependency and dependencymanagement - confusion


I have project A and B. B is the child of A. So B Inherits properties
and dependencies of A.
If I have x version of dependency in A , same will be available for B
also.

Then why do we need dependencyManagement , because by changing the
version of dependency in A will automatically availabe in B.

When dependency of A is avaliable in B due to inheritance , then why are
we required to call the parent dependency with group-id:artifactid
for managed dependency

I have searched a lot to question and i am still confused.

thanks in advance
kumar

--
View this message in context:
http://www.nabble.com/dependency-and-dependencymanagement---confusion-tp
20318920p20318920.html
Sent from the Maven - Users mailing list archive at Nabble.com.


-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]




The content of this e-mail is confidential and may be privileged. It may be 
read, copied and used only by the intended recipient and may not be disclosed, 
copied or distributed. If you received this email in error, please contact the 
sender immediately by return e-mail or by telephoning +44 20 7260 2000, delete 
it and do not disclose its contents to any person. You should take full 
responsibility for checking this email for viruses. Markit reserves the right 
to monitor all e-mail communications through its network.
Markit and its affiliated companies make no warranty as to the accuracy or 
completeness of any information contained in this message and hereby exclude 
any liability of any kind for the information contained herein. Any opinions 
expressed in this message are those of the author and do not necessarily 
reflect the opinions of Markit.
For full details about Markit, its offerings and legal terms and conditions, 
please see Markit's website at http://www.markit.com http://www.markit.com/ .

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

dependency and dependencymanagement - confusion

[kvenkatraman]

I have project A and B. B is the child of A. So B Inherits properties and
dependencies of A.
If I have x version of dependency in A , same will be available for B also.

Then why do we need dependencyManagement , because by changing the version
of dependency in A will automatically availabe in B.

When dependency of A is avaliable in B due to inheritance , then why are we
required to call the parent dependency with group-id:artifactid for
managed dependency

I have searched a lot to question and i am still confused.

thanks in advance
kumar

-- 
View this message in context: 
http://www.nabble.com/dependency-and-dependencymanagement---confusion-tp20318920p20318920.html
Sent from the Maven - Users mailing list archive at Nabble.com.


-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

DependencyManagement and range constraints

[Kees van Dieren]

Hi all,

We have a problem with DependencyManagement and range constraints; the
version in DependencyManagement seems to override all ranges defined
elsewhere (as if they have never been there).  What we need, is that range
constraints still apply to guarantee compatibility between the dependencies.

We have the following situation:
ProjectA
ProjectB version 0.4.0 has dependency on projectA, with range [0.5.0,)
ProjectC has a dependencyManagement section, in which projectA is defined on
version 0.4.0 and projectB is defined on version 0.4.0

Maven should warn us that this will not work: projectB requires version
0.5.0 or higher, however this doesn't work.

We have tried the following versions in dependencyManagement:
version[0.4.0]/version
version0.4.0/version

From ranges perspective, I would expect that [0.4.0] should be the correct
one. However, than the dependencyManagent version gets ignored!
Version 0.4.0 makes the dependencyManagement apply, but the build does not
fail because of the defined range dependencies.

According to MNG-3396 it should have been solved in 2.0.9, quote from issue:
 If you try to force a version out of the range in the dependencyManagement
it is ignored.

However, we are using that and we still have this problem.

Any suggestions?

Thanks for your help!

Best regards,

Kees van Dieren

-- 
Squins IT Solutions
Kees van Dieren
Oranjestraat 23
2983 HL Ridderkerk
Phone: +31 180 41 45 20
Mobile: +31 6 30 41 38 41
www: http://squins.com

What's the defference between the dependencyManagement and dependencies?

[陈思淼]

 dependencyManagement
dependencies
  dependency
groupIdtest/groupId
artifactIdd/artifactId
version1.0/version
  /dependency
/dependencies
  /dependencyManagement


  dependencies
dependency
  groupIdmaven-test/groupId
  artifactIda/artifactId
  version1.0/version
  scoperuntime/scope
/dependency
dependency
  groupIdmaven-test/groupId
  artifactIdc/artifactId
  scoperuntime/scope
/dependency
  /dependencies

Re: What's the defference between the dependencyManagement and dependencies?

[Wayne Fay]

Primarily, dependencyManagement does not actually attach an artifact
dependency to a given project, while declaring a dependency does
exactly that.

So you could have a project with 10 items in depMgmt and no deps which
tells users (and Maven) that it can be built all on its own.

Wayne

2008/10/8 陈思淼 [EMAIL PROTECTED]:
  dependencyManagement
dependencies
  dependency
groupIdtest/groupId
artifactIdd/artifactId
version1.0/version
  /dependency
/dependencies
  /dependencyManagement


  dependencies
dependency
  groupIdmaven-test/groupId
  artifactIda/artifactId
  version1.0/version
  scoperuntime/scope
/dependency
dependency
  groupIdmaven-test/groupId
  artifactIdc/artifactId
  scoperuntime/scope
/dependency
  /dependencies

Re: What's the defference between the dependencyManagement and dependencies?

[Stephen Connolly]

OK, I'll start back a piece from your question.

When you do

project
  ...
  artifactIda/artifactId
  ...
  dependencies
  dependency
groupIdfoo/groupId
artifactIdbar/artifactId
version1.0/version
  /dependency
  ...
  /dependencies
  ...
/project

what you are doing is telling maven that your project a needs foo:bar
and would, if its opinion counts, prefer to use version 1.0

If I have another project with

project
  ...
  artifactIdb/artifactId
  ...
  dependencies
  dependency
groupIdfoo/groupId
artifactIdbar/artifactId
version2.0/version
  /dependency
  ...
  /dependencies
  ...
/project

If project c lists a  b as it's dependencies, which version of
foo:bar will maven use?

a would prefer 1.0
b would prefer 2.0

There are rules which allow Maven to deterministically figure this out
(in this case the first dependency listed in project c will win,
unless c depends on foo:bar directly itself)

so for

project
  ...
  artifactIdc/artifactId
  ...
  dependencies
  dependency
...
artifactIdb/artifactId
...
  /dependency
  dependency
...
artifactIda/artifactId
...
  /dependency
  ...
  /dependencies
  ...
/project

c will end up using version 2.0.

The dependencyManagement is a way of more strongly hinting to maven
that it should use a specific version...

so since c does not directly depend on foo:bar, we don't really want
to add foo:bar as a dependency of project c.

By adding it as a dependencyManagement we can tell maven, oh by the
way, if you see this dependency, i'd really really like it if you can
use this version.

The other use case for dependencyManagement is to put it in a parent
pom... that way all the parent's children do not have to keep
specifying the version... in fact they can safely omit the version

-Stephen

2008/10/8 Wayne Fay [EMAIL PROTECTED]:
 Primarily, dependencyManagement does not actually attach an artifact
 dependency to a given project, while declaring a dependency does
 exactly that.

 So you could have a project with 10 items in depMgmt and no deps which
 tells users (and Maven) that it can be built all on its own.

 Wayne

 2008/10/8 陈思淼 [EMAIL PROTECTED]:
  dependencyManagement
dependencies
  dependency
groupIdtest/groupId
artifactIdd/artifactId
version1.0/version
  /dependency
/dependencies
  /dependencyManagement


dependency
  groupIdmaven-test/groupId
  artifactIdc/artifactId
  scoperuntime/scope
/dependency
  /dependencies

Re: What's the defference between the dependencyManagement and dependencies?

[陈思淼]

I think the dependencyManagement mechanism is Less usefull,because when the
transitive dependency conflict. In some case, It need strict function
and pressure test to decide which version to use.
and the SCM should control the authority to decide which version to override
another depends on the test result. so the config should not be define in
the pom.xml.


2008/10/8 Stephen Connolly [EMAIL PROTECTED]

 OK, I'll start back a piece from your question.

 When you do

 project
  ...
  artifactIda/artifactId
  ...
  dependencies
  dependency
groupIdfoo/groupId
artifactIdbar/artifactId
 version1.0/version
  /dependency
  ...
  /dependencies
   ...
 /project

 what you are doing is telling maven that your project a needs foo:bar
 and would, if its opinion counts, prefer to use version 1.0

 If I have another project with

 project
  ...
  artifactIdb/artifactId
  ...
  dependencies
  dependency
groupIdfoo/groupId
artifactIdbar/artifactId
version2.0/version
  /dependency
  ...
  /dependencies
  ...
 /project

 If project c lists a  b as it's dependencies, which version of
 foo:bar will maven use?

 a would prefer 1.0
 b would prefer 2.0

 There are rules which allow Maven to deterministically figure this out
 (in this case the first dependency listed in project c will win,
 unless c depends on foo:bar directly itself)

 so for

 project
  ...
  artifactIdc/artifactId
  ...
  dependencies
  dependency
...
artifactIdb/artifactId
...
  /dependency
  dependency
...
artifactIda/artifactId
...
  /dependency
  ...
  /dependencies
  ...
 /project

 c will end up using version 2.0.

 The dependencyManagement is a way of more strongly hinting to maven
 that it should use a specific version...

 so since c does not directly depend on foo:bar, we don't really want
 to add foo:bar as a dependency of project c.

 By adding it as a dependencyManagement we can tell maven, oh by the
 way, if you see this dependency, i'd really really like it if you can
 use this version.

 The other use case for dependencyManagement is to put it in a parent
 pom... that way all the parent's children do not have to keep
 specifying the version... in fact they can safely omit the version

 -Stephen

 2008/10/8 Wayne Fay [EMAIL PROTECTED]:
  Primarily, dependencyManagement does not actually attach an artifact
  dependency to a given project, while declaring a dependency does
  exactly that.
 
  So you could have a project with 10 items in depMgmt and no deps which
  tells users (and Maven) that it can be built all on its own.
 
  Wayne
 
  2008/10/8 陈思淼 [EMAIL PROTECTED]:
   dependencyManagement
 dependencies
   dependency
 groupIdtest/groupId
 artifactIdd/artifactId
 version1.0/version
   /dependency
 /dependencies
   /dependencyManagement
 
 
 dependency
   groupIdmaven-test/groupId
   artifactIdc/artifactId
   scoperuntime/scope
 /dependency
   /dependencies
 
 

Re: scope-import and dependencyManagement

[webhiker]

Stephen, I don't think you are correct, it IS supposed to be used that way,
and that's what all the Maven documentation lists as examples and operating
behaviour :

http://maven.apache.org/guides/introduction/introduction-to-dependency-mechanism.html

I'm having the exact same issue. Using identical examples to the Maven docs,
if I omit the version tag in the child pom, the build always fails with
missing version tag error.

There appears to be something wrong with the code. I'm running Maven 2.0.9


Stephen Connolly-2 wrote:
 
 Each project can list _only the dependencies that it has_ while using the
 import to ensure that only a single suite of dependency versions are used,
 I
 would guess.
 
 It's to separate inheritance from dependency management
 
 On Tue, Sep 16, 2008 at 4:25 PM, Barry Kaplan [EMAIL PROTECTED] wrote:
 

 What is the value of importing into dependencyManagement if those
 dependencies cannot then be refered to in the regular dependencies? I'm
 missing the purpose/value.
 --
 View this message in context:
 http://www.nabble.com/scope-import-and-dependencyManagement-tp19512161p19514217.html
 Sent from the Maven - Users mailing list archive at Nabble.com.


 -
 To unsubscribe, e-mail: [EMAIL PROTECTED]
 For additional commands, e-mail: [EMAIL PROTECTED]


 
 

-- 
View this message in context: 
http://www.nabble.com/scope-import-and-dependencyManagement-tp19512161p19795461.html
Sent from the Maven - Users mailing list archive at Nabble.com.


-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Re: scope-import and dependencyManagement

[webhiker]

Here's an excerpt from Maven docs about how it should work :
dependencyManagement: is used by POMs to help manage dependency information
across all of its children. If the my-parent project uses
dependencyManagement to define a dependency on junit:junit:4.0, then POMs
inheriting from this one can set their dependency giving the groupId=junit
and artifactId=junit only, then Maven will fill in the version set by the
parent. The benefits of this method are obvious. Dependency details can be
set in one central location, which will propagate to all inheriting POMs. In
addition, the version and scope of artifacts which are incorporated from
transitive dependencies may also be controlled by specifying them in a
dependency management section.



webhiker wrote:
 
 Stephen, I don't think you are correct, it IS supposed to be used that
 way, and that's what all the Maven documentation lists as examples and
 operating behaviour :
 
 http://maven.apache.org/guides/introduction/introduction-to-dependency-mechanism.html
 
 I'm having the exact same issue. Using identical examples to the Maven
 docs, if I omit the version tag in the child pom, the build always fails
 with missing version tag error.
 
 There appears to be something wrong with the code. I'm running Maven 2.0.9
 
 
 Stephen Connolly-2 wrote:
 
 Each project can list _only the dependencies that it has_ while using the
 import to ensure that only a single suite of dependency versions are
 used, I
 would guess.
 
 It's to separate inheritance from dependency management
 
 On Tue, Sep 16, 2008 at 4:25 PM, Barry Kaplan [EMAIL PROTECTED]
 wrote:
 

 What is the value of importing into dependencyManagement if those
 dependencies cannot then be refered to in the regular dependencies? I'm
 missing the purpose/value.
 --
 View this message in context:
 http://www.nabble.com/scope-import-and-dependencyManagement-tp19512161p19514217.html
 Sent from the Maven - Users mailing list archive at Nabble.com.


 -
 To unsubscribe, e-mail: [EMAIL PROTECTED]
 For additional commands, e-mail: [EMAIL PROTECTED]


 
 
 
 

-- 
View this message in context: 
http://www.nabble.com/scope-import-and-dependencyManagement-tp19512161p19795572.html
Sent from the Maven - Users mailing list archive at Nabble.com.


-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

RE: DependencyManagement to force scope

[softwarepills]

I have just remeber my problems with this: in many cases you define the
versions with DepencyManagement in a parent POM to align them in all the
modules, but, for one child (or via import scope) module you want them to be
provided beacause other module provides them. Then, in your child pom you
don't want to set the version again, as it is the reponsability of the
parent POM. Yes, you can upgrade to provided in the direct dependencies
section, but what about the transitive ones?.

So i think there is a common use case in where it is very usefull to modify
declare only the scope but not the version in the DependencyManagement.


Anders Hammar wrote:
 
 Well, as I see things, if you specify the artifact as provided then you
 also want to define the version that is provided. IMO you do want to use
 the same version in your Maven build as you're going to use in the
 targeted environment. In fact, this was one of my key points in a Maven
 talk I did at our local jug earlier this week.
 Why would you use a different version (and/or implementation) in your
 build than you're going to use when deployd?
 
 /Anders
 
 
 softwarepills wrote:
 
 I see. Thank you.
 
 So we can modify version, version an scope, but not, only scope. This is
 a problem when you only want using it to upgrade a dependency to
 provided. Then you are also manipulatig the version that should be
 resolved by Maven.
 
 So it seems its not a good idea using it to exclude a sticky transitive
 dependency that someone has set as compile but in your context is
 provided, right?
 
 
 Anders Hammar wrote:
 
 I'm not sure about the optional tag, but it does apply to version.
 DependencyManagement is where you can  specify the version to use for
 transitive dependencies.
 http://maven.apache.org/guides/introduction/introduction-to-dependency-mechanism.html#Dependency_Management
 
 /Anders
 
 
 softwarepills wrote:
 
 To clarify more the matter.
 
 Should we think about DependencyManagement no only as a default value
 provider, but also as a modifier of inherited dependencies? 
 Does it apply to other parameters like the version itself and
 optional?.
 
 
 Jörg Schaible-3 wrote:
 
 softwarepills wrote:
 I usually think in DependencyManagement as a by default section, i
 mean, the version and scope you set in DependencyManagement is the
 version and scope you get if ommited in the real dependency in the
 POM
 and child POMs.
 
 But, i have found that if i insert  provided scope in the
 DependencyManagement section, any compile dependency and transitive
 compile dependency will be upgraded to provided.
 
 Is this correct?
 
 Yes.
 
 Is this the intended behavior? 
 
 Yes.
 
 If yes, this is a inetresting tool to exclude artifacts form being
 packaged, right?
 
 Yes. 
 
 :)
 
 You'll need M2.0.6 or greater though ...
 
 -Jörg
 
 -
 To unsubscribe, e-mail: [EMAIL PROTECTED]
 For additional commands, e-mail: [EMAIL PROTECTED]
 
 
 
 
 
 
 
 
 
 
 

-- 
View this message in context: 
http://www.nabble.com/DependencyManagement-to-force-scope-tp19776450p19796224.html
Sent from the Maven - Users mailing list archive at Nabble.com.


-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Re: scope-import and dependencyManagement

[Stephen Connolly]

I think you are mis-interpreting what I said.

You have the following structure

/pom.xml (agregator)
 +suite/pom.xml (the suite dependencies)
 +client/pom.xml (the client thing we are building)
 +web/pom.xml (the web ting we are building)

If you have only one corporate pom (not shown on the tree) then you
can get away with everything ultimately inheriting from the corporate
pom by having a parent tree like

/pom.xml ---is-a-child-of--- /suite/pom.xml
/client/pom.xml ---is-a-child-of--- /suite/pom.xml
/web/pom.xml ---is-a-child-of--- /suite/pom.xml
/suite/pom.xml ---is-a-child-of--- corporate-pom.xml

And you'd put your dependencyManagement in /suite/pom.xml

The question is why have this scopeimport/scope

The reason is you may have corporate standards for different
packagings... and they may not work in the one pom.xml

In that case you would have

corporate-root-pom.xml
corporate-jar-pom.xml ---is-a-child-of--- corporate-root-pom.xml
corporate-war-pom.xml ---is-a-child-of--- corporate-root-pom.xml

And then
/pom.xml ---is-a-child-of--- corporate-aggregator-pom.xml
/client/pom.xml ---is-a-child-of--- corporate-jar-pom.xml
/web/pom.xml ---is-a-child-of--- corporate-war-pom.xml

Now the problem is how do I ensure that client and web have the same
dependencyMangement sections?

The answer is import scope so in that case you have

/suite/pom.xml ---is-a-child-of--- corporate-root-pom.xml
/client/pom.xml ---is-a-child-of--- corporate-jar-pom.xml with
dependency on /suite/pom.xml: scope=import
/web/pom.xml ---is-a-child-of--- corporate-war-pom.xml with
dependency on /suite/pom.xml: scope=import

I was explaining *why* you would want import scope.  I don't know *if*
import scope works... only *why* one would want it in the first place

- Stephen


2008/10/3 webhiker [EMAIL PROTECTED]:

 Stephen, I don't think you are correct, it IS supposed to be used that way,
 and that's what all the Maven documentation lists as examples and operating
 behaviour :

 http://maven.apache.org/guides/introduction/introduction-to-dependency-mechanism.html

 I'm having the exact same issue. Using identical examples to the Maven docs,
 if I omit the version tag in the child pom, the build always fails with
 missing version tag error.

 There appears to be something wrong with the code. I'm running Maven 2.0.9


 Stephen Connolly-2 wrote:

 Each project can list _only the dependencies that it has_ while using the
 import to ensure that only a single suite of dependency versions are used,
 I
 would guess.

 It's to separate inheritance from dependency management

 On Tue, Sep 16, 2008 at 4:25 PM, Barry Kaplan [EMAIL PROTECTED] wrote:


 What is the value of importing into dependencyManagement if those
 dependencies cannot then be refered to in the regular dependencies? I'm
 missing the purpose/value.
 --
 View this message in context:
 http://www.nabble.com/scope-import-and-dependencyManagement-tp19512161p19514217.html
 Sent from the Maven - Users mailing list archive at Nabble.com.


 -
 To unsubscribe, e-mail: [EMAIL PROTECTED]
 For additional commands, e-mail: [EMAIL PROTECTED]





 --
 View this message in context: 
 http://www.nabble.com/scope-import-and-dependencyManagement-tp19512161p19795461.html
 Sent from the Maven - Users mailing list archive at Nabble.com.


 -
 To unsubscribe, e-mail: [EMAIL PROTECTED]
 For additional commands, e-mail: [EMAIL PROTECTED]



-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Re: scope-import and dependencyManagement

[webhiker]

OK, so that's not the issue I was trying to discuss then.
But for those who had the same problem as I did, I have a solution :

if you have the following structure :

pom.xml
child-project1\pom.xml
child-project2\pom.xml

If you add in the depManagement to the root pom, the others will not work
(in my case anyway) because Maven downloads the root pom from your
repository (which in the initial case didn't have the depManagement
definitions) instead of looking at the version on disk.
So it's a chieck-egg problem - you can't deploy your new pom because it
won't build!

Solution is to manually copy the modified root pom either to your remote
repository or to the local repo (USER_HOME\.m2 or whatever)

cheers


Stephen Connolly-2 wrote:
 
 I think you are mis-interpreting what I said.
 
 You have the following structure
 
 /pom.xml (agregator)
  +suite/pom.xml (the suite dependencies)
  +client/pom.xml (the client thing we are building)
  +web/pom.xml (the web ting we are building)
 
 If you have only one corporate pom (not shown on the tree) then you
 can get away with everything ultimately inheriting from the corporate
 pom by having a parent tree like
 
 /pom.xml ---is-a-child-of--- /suite/pom.xml
 /client/pom.xml ---is-a-child-of--- /suite/pom.xml
 /web/pom.xml ---is-a-child-of--- /suite/pom.xml
 /suite/pom.xml ---is-a-child-of--- corporate-pom.xml
 
 And you'd put your dependencyManagement in /suite/pom.xml
 
 The question is why have this scopeimport/scope
 
 The reason is you may have corporate standards for different
 packagings... and they may not work in the one pom.xml
 
 In that case you would have
 
 corporate-root-pom.xml
 corporate-jar-pom.xml ---is-a-child-of--- corporate-root-pom.xml
 corporate-war-pom.xml ---is-a-child-of--- corporate-root-pom.xml
 
 And then
 /pom.xml ---is-a-child-of--- corporate-aggregator-pom.xml
 /client/pom.xml ---is-a-child-of--- corporate-jar-pom.xml
 /web/pom.xml ---is-a-child-of--- corporate-war-pom.xml
 
 Now the problem is how do I ensure that client and web have the same
 dependencyMangement sections?
 
 The answer is import scope so in that case you have
 
 /suite/pom.xml ---is-a-child-of--- corporate-root-pom.xml
 /client/pom.xml ---is-a-child-of--- corporate-jar-pom.xml with
 dependency on /suite/pom.xml: scope=import
 /web/pom.xml ---is-a-child-of--- corporate-war-pom.xml with
 dependency on /suite/pom.xml: scope=import
 
 I was explaining *why* you would want import scope.  I don't know *if*
 import scope works... only *why* one would want it in the first place
 
 - Stephen
 
 
 2008/10/3 webhiker [EMAIL PROTECTED]:

 Stephen, I don't think you are correct, it IS supposed to be used that
 way,
 and that's what all the Maven documentation lists as examples and
 operating
 behaviour :

 http://maven.apache.org/guides/introduction/introduction-to-dependency-mechanism.html

 I'm having the exact same issue. Using identical examples to the Maven
 docs,
 if I omit the version tag in the child pom, the build always fails with
 missing version tag error.

 There appears to be something wrong with the code. I'm running Maven
 2.0.9


 Stephen Connolly-2 wrote:

 Each project can list _only the dependencies that it has_ while using
 the
 import to ensure that only a single suite of dependency versions are
 used,
 I
 would guess.

 It's to separate inheritance from dependency management

 On Tue, Sep 16, 2008 at 4:25 PM, Barry Kaplan [EMAIL PROTECTED]
 wrote:


 What is the value of importing into dependencyManagement if those
 dependencies cannot then be refered to in the regular dependencies? I'm
 missing the purpose/value.
 --
 View this message in context:
 http://www.nabble.com/scope-import-and-dependencyManagement-tp19512161p19514217.html
 Sent from the Maven - Users mailing list archive at Nabble.com.


 -
 To unsubscribe, e-mail: [EMAIL PROTECTED]
 For additional commands, e-mail: [EMAIL PROTECTED]





 --
 View this message in context:
 http://www.nabble.com/scope-import-and-dependencyManagement-tp19512161p19795461.html
 Sent from the Maven - Users mailing list archive at Nabble.com.


 -
 To unsubscribe, e-mail: [EMAIL PROTECTED]
 For additional commands, e-mail: [EMAIL PROTECTED]


 
 -
 To unsubscribe, e-mail: [EMAIL PROTECTED]
 For additional commands, e-mail: [EMAIL PROTECTED]
 
 
 

-- 
View this message in context: 
http://www.nabble.com/scope-import-and-dependencyManagement-tp19512161p19798389.html
Sent from the Maven - Users mailing list archive at Nabble.com.


-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Re: scope-import and dependencyManagement

[Stephen Connolly]

Nahhh much easier

mvn -N install

in the directory where your root pom is...

that will restrict the build to the current pom only and not build the
child modules

2008/10/3 webhiker [EMAIL PROTECTED]:

 OK, so that's not the issue I was trying to discuss then.
 But for those who had the same problem as I did, I have a solution :

 if you have the following structure :

 pom.xml
 child-project1\pom.xml
 child-project2\pom.xml

 If you add in the depManagement to the root pom, the others will not work
 (in my case anyway) because Maven downloads the root pom from your
 repository (which in the initial case didn't have the depManagement
 definitions) instead of looking at the version on disk.
 So it's a chieck-egg problem - you can't deploy your new pom because it
 won't build!

 Solution is to manually copy the modified root pom either to your remote
 repository or to the local repo (USER_HOME\.m2 or whatever)

 cheers


 Stephen Connolly-2 wrote:

 I think you are mis-interpreting what I said.

 You have the following structure

 /pom.xml (agregator)
  +suite/pom.xml (the suite dependencies)
  +client/pom.xml (the client thing we are building)
  +web/pom.xml (the web ting we are building)

 If you have only one corporate pom (not shown on the tree) then you
 can get away with everything ultimately inheriting from the corporate
 pom by having a parent tree like

 /pom.xml ---is-a-child-of--- /suite/pom.xml
 /client/pom.xml ---is-a-child-of--- /suite/pom.xml
 /web/pom.xml ---is-a-child-of--- /suite/pom.xml
 /suite/pom.xml ---is-a-child-of--- corporate-pom.xml

 And you'd put your dependencyManagement in /suite/pom.xml

 The question is why have this scopeimport/scope

 The reason is you may have corporate standards for different
 packagings... and they may not work in the one pom.xml

 In that case you would have

 corporate-root-pom.xml
 corporate-jar-pom.xml ---is-a-child-of--- corporate-root-pom.xml
 corporate-war-pom.xml ---is-a-child-of--- corporate-root-pom.xml

 And then
 /pom.xml ---is-a-child-of--- corporate-aggregator-pom.xml
 /client/pom.xml ---is-a-child-of--- corporate-jar-pom.xml
 /web/pom.xml ---is-a-child-of--- corporate-war-pom.xml

 Now the problem is how do I ensure that client and web have the same
 dependencyMangement sections?

 The answer is import scope so in that case you have

 /suite/pom.xml ---is-a-child-of--- corporate-root-pom.xml
 /client/pom.xml ---is-a-child-of--- corporate-jar-pom.xml with
 dependency on /suite/pom.xml: scope=import
 /web/pom.xml ---is-a-child-of--- corporate-war-pom.xml with
 dependency on /suite/pom.xml: scope=import

 I was explaining *why* you would want import scope.  I don't know *if*
 import scope works... only *why* one would want it in the first place

 - Stephen


 2008/10/3 webhiker [EMAIL PROTECTED]:

 Stephen, I don't think you are correct, it IS supposed to be used that
 way,
 and that's what all the Maven documentation lists as examples and
 operating
 behaviour :

 http://maven.apache.org/guides/introduction/introduction-to-dependency-mechanism.html

 I'm having the exact same issue. Using identical examples to the Maven
 docs,
 if I omit the version tag in the child pom, the build always fails with
 missing version tag error.

 There appears to be something wrong with the code. I'm running Maven
 2.0.9


 Stephen Connolly-2 wrote:

 Each project can list _only the dependencies that it has_ while using
 the
 import to ensure that only a single suite of dependency versions are
 used,
 I
 would guess.

 It's to separate inheritance from dependency management

 On Tue, Sep 16, 2008 at 4:25 PM, Barry Kaplan [EMAIL PROTECTED]
 wrote:


 What is the value of importing into dependencyManagement if those
 dependencies cannot then be refered to in the regular dependencies? I'm
 missing the purpose/value.
 --
 View this message in context:
 http://www.nabble.com/scope-import-and-dependencyManagement-tp19512161p19514217.html
 Sent from the Maven - Users mailing list archive at Nabble.com.


 -
 To unsubscribe, e-mail: [EMAIL PROTECTED]
 For additional commands, e-mail: [EMAIL PROTECTED]





 --
 View this message in context:
 http://www.nabble.com/scope-import-and-dependencyManagement-tp19512161p19795461.html
 Sent from the Maven - Users mailing list archive at Nabble.com.


 -
 To unsubscribe, e-mail: [EMAIL PROTECTED]
 For additional commands, e-mail: [EMAIL PROTECTED]



 -
 To unsubscribe, e-mail: [EMAIL PROTECTED]
 For additional commands, e-mail: [EMAIL PROTECTED]




 --
 View this message in context: 
 http://www.nabble.com/scope-import-and-dependencyManagement-tp19512161p19798389.html
 Sent from the Maven - Users mailing list archive at Nabble.com.


 -
 To unsubscribe

DependencyManagement to force scope

[softwarepills]

I usually think in DependencyManagement as a by default section, i mean,
the version and scope you set in DependencyManagement is the version and
scope you get if ommited in the real dependency in the POM and child POMs.

But, i have found that if i insert  provided scope in the
DependencyManagement section, any compile dependency and transitive compile
dependency will be upgraded to provided.

Is this correct? Is this the intended behavior? If yes, this is a
inetresting tool to exclude artifacts form being packaged, right?


-- 
View this message in context: 
http://www.nabble.com/DependencyManagement-to-force-scope-tp19776450p19776450.html
Sent from the Maven - Users mailing list archive at Nabble.com.


-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

RE: DependencyManagement to force scope

[Jörg Schaible]

softwarepills wrote:
 I usually think in DependencyManagement as a by default section, i
 mean, the version and scope you set in DependencyManagement is the
 version and scope you get if ommited in the real dependency in the POM
 and child POMs.
 
 But, i have found that if i insert  provided scope in the
 DependencyManagement section, any compile dependency and transitive
 compile dependency will be upgraded to provided.
 
 Is this correct?

Yes.

 Is this the intended behavior? 

Yes.

 If yes, this is a inetresting tool to exclude artifacts form being packaged, 
 right?

Yes. 

:)

You'll need M2.0.6 or greater though ...

-Jörg

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Re: DependencyManagement to force scope

[softwarepills]

Short and clear.

I didn't found this in either the two books of Maven or in the Maven docs.

Thanks a lot.


softwarepills wrote:
 
 I usually think in DependencyManagement as a by default section, i mean,
 the version and scope you set in DependencyManagement is the version and
 scope you get if ommited in the real dependency in the POM and child POMs.
 
 But, i have found that if i insert  provided scope in the
 DependencyManagement section, any compile dependency and transitive
 compile dependency will be upgraded to provided.
 
 Is this correct? Is this the intended behavior? If yes, this is a
 inetresting tool to exclude artifacts form being packaged, right?
 
 
 

-- 
View this message in context: 
http://www.nabble.com/DependencyManagement-to-force-scope-tp19776450p19776793.html
Sent from the Maven - Users mailing list archive at Nabble.com.


-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

RE: DependencyManagement to force scope

[softwarepills]

To clarify more the matter.

Should we think about DependencyManagement no only as a default value
provider, but also as a modifier of inherited dependencies? 
Does it apply to other parameters like the version itself and optional?.


Jörg Schaible-3 wrote:
 
 softwarepills wrote:
 I usually think in DependencyManagement as a by default section, i
 mean, the version and scope you set in DependencyManagement is the
 version and scope you get if ommited in the real dependency in the POM
 and child POMs.
 
 But, i have found that if i insert  provided scope in the
 DependencyManagement section, any compile dependency and transitive
 compile dependency will be upgraded to provided.
 
 Is this correct?
 
 Yes.
 
 Is this the intended behavior? 
 
 Yes.
 
 If yes, this is a inetresting tool to exclude artifacts form being
 packaged, right?
 
 Yes. 
 
 :)
 
 You'll need M2.0.6 or greater though ...
 
 -Jörg
 
 -
 To unsubscribe, e-mail: [EMAIL PROTECTED]
 For additional commands, e-mail: [EMAIL PROTECTED]
 
 
 

-- 
View this message in context: 
http://www.nabble.com/DependencyManagement-to-force-scope-tp19776450p19776904.html
Sent from the Maven - Users mailing list archive at Nabble.com.


-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]