subject:"dependency resolution"

t any thoughts on whether the following
> is a
> > > > > defect:
> > > > > > >
> > > > > > >
> > > > > > > Issue details:
> > > > > > > tl;dr
> > > > > > >
> > > > > > > Maven can resolve dependencies either from:
> > > > > > >
> > > > > > >   *   an external repo
> > > > > > >   *   a class directory of a module being built within the
> reactor
> > > > > > >   *   a packaged jar of a module being built within the reactor
> > > > > > >
> > > > > > > If you run a concurrent multi-module build it is possible to
> get a
> > > race
> > > > > > > condition whereby the build of module Foo may resolve module
> Bar
> > > from
> > > > > > > either of the three resolution channels. This inconsistency can
> > > result
> > > > > in
> > > > > > > the Maven war plugin sometimes failing to build a functional
> war
> > > file.
> > > > > I
> > > > > > > would expect a consistent resolution would always take place.
> > > > > > >
> > > > > > > Full details
> > > > > > > Scenario
> > > > > > >
> > > > > > > Consider you have a repo with the following structure:
> > > > > > >
> > > > > > >App
> > > > > > >
> > > > > > >  / \
> > > > > > >
> > > > > > > /   \
> > > > > > >
> > > > > > >(compile scope)  (test scope)
> > > > > > >
> > > > > > >   /   \
> > > > > > >
> > > > > > > \/_   _\/
> > > > > > >
> > > > > > >  ModuleA  TestSupportModule1
> > > > > > >
> > > > > > > /
> > > > > > >
> > > > > > >/
> > > > > > >
> > > > > > > (compile scope)
> > > > > > >
> > > > > > >  /
> > > > > > >
> > > > > > >\/_
> > > > > > >
> > > > > > > ModuleB
> > > > > > >
> > > > > > >/
> > > > > > >
> > > > > > >   /
> > > > > > >
> > > > > > > (test scope)
> > > > > > >
> > > > > > > /
> > > > > > >
> > > > > > >   \/_
> > > > > > >
> > > > > > > TestSupportModule2
> > > > > > >
> > > > > > > If you were to make a src code change to the following test
> support
> > > > > > > modules:
> > > > > > >
> > > > > > >   *   TestSupportModule1
> > > > > > >   *   TestSupportModule2
> > > > > > >
> > > > > > > Then the minimum number of modules we need to build to verify
> the
> > > > > change
> > > > > > > set is OK is:
> > > > > > >
> > > > > > >   *   TestSupportModule1
> > > > > > >   *   TestSupportModule2
> > > > > > >   *   ModuleB
> > > > > > >   *   App
> > > > > > >
> > > > > > > i.e. there is no requirement to build ModuleA because we know
> that
> > > > > none of
> > > > > > > the src code changes could impact the classpaths used in its
> maven
> > > > > build.
> > > > > > >
> > > > > > > We know that despite 'App' depending (transitively) on ModuleB
> > > there
> > > > > is no
> > > > > > > need for the 'App' build to wait for ModuleB to complete its
> build
> > > > > because
> > > > > > > the src code change to TestSupportModule2 will not impact any
> of
> > > the
> > > > > > > classpaths used in the App maven build. Therefore to get the
> most
> > > > > efficient
> > > > > > > build possible we

RE: Re: Re: Re: Inconsistent dependency resolution behaviour for concurrent multi-module build can cause failures

t; > result
> > > > in
> > > > > > the Maven war plugin sometimes failing to build a functional war
> > file.
> > > > I
> > > > > > would expect a consistent resolution would always take place.
> > > > > >
> > > > > > Full details
> > > > > > Scenario
> > > > > >
> > > > > > Consider you have a repo with the following structure:
> > > > > >
> > > > > >App
> > > > > >
> > > > > >  / \
> > > > > >
> > > > > > /   \
> > > > > >
> > > > > >(compile scope)  (test scope)
> > > > > >
> > > > > >   /   \
> > > > > >
> > > > > > \/_   _\/
> > > > > >
> > > > > >  ModuleA  TestSupportModule1
> > > > > >
> > > > > > /
> > > > > >
> > > > > >/
> > > > > >
> > > > > > (compile scope)
> > > > > >
> > > > > >  /
> > > > > >
> > > > > >\/_
> > > > > >
> > > > > > ModuleB
> > > > > >
> > > > > >/
> > > > > >
> > > > > >   /
> > > > > >
> > > > > > (test scope)
> > > > > >
> > > > > > /
> > > > > >
> > > > > >   \/_
> > > > > >
> > > > > > TestSupportModule2
> > > > > >
> > > > > > If you were to make a src code change to the following test support
> > > > > > modules:
> > > > > >
> > > > > >   *   TestSupportModule1
> > > > > >   *   TestSupportModule2
> > > > > >
> > > > > > Then the minimum number of modules we need to build to verify the
> > > > change
> > > > > > set is OK is:
> > > > > >
> > > > > >   *   TestSupportModule1
> > > > > >   *   TestSupportModule2
> > > > > >   *   ModuleB
> > > > > >   *   App
> > > > > >
> > > > > > i.e. there is no requirement to build ModuleA because we know that
> > > > none of
> > > > > > the src code changes could impact the classpaths used in its maven
> > > > build.
> > > > > >
> > > > > > We know that despite 'App' depending (transitively) on ModuleB
> > there
> > > > is no
> > > > > > need for the 'App' build to wait for ModuleB to complete its build
> > > > because
> > > > > > the src code change to TestSupportModule2 will not impact any of
> > the
> > > > > > classpaths used in the App maven build. Therefore to get the most
> > > > efficient
> > > > > > build possible we ideally would invoke Maven to run with 2 threads
> > and
> > > > with
> > > > > > instruction to build two distinct 'dependency graphs':
> > > > > >
> > > > > >   *   TestSupportModule1 followed by ModuleB
> > > > > >   *   TestSupportModule1 followed by App
> > > > > >
> > > > > > The following Maven command achieves exactly what we want because
> > the
> > > > > > reactor build order is based only on the direct (i.e.
> > non-transitive)
> > > > > > dependencies of the modules provided to the reactor in the build
> > > > command.
> > > > > > Therefore the absence of ModuleA results in two distinct
> > 'dependency
> > > > > > graphs':
> > > > > >
> > > > > > mvn clean verify -pl
> > TestSupportModule1,TestSupportModule2,ModuleB,App
> > > > -T 2
> > > > > >
> > > > > > Note: In reality the code base I maintain has a very large
> > monobuild
> > > > with
> > > > > > 100s of modules and this type of build optimisation makes a
> > significant
> > > > > > difference to the speed of our monobuild (we use
> > > > > >

Re: Re: Re: Inconsistent dependency resolution behaviour for concurrent multi-module build can cause failures

t; > > >
> > > > >   /   \
> > > > >
> > > > > \/_   _\/
> > > > >
> > > > >  ModuleA  TestSupportModule1
> > > > >
> > > > > /
> > > > >
> > > > >/
> > > > >
> > > > > (compile scope)
> > > > >
> > > > >  /
> > > > >
> > > > >\/_
> > > > >
> > > > > ModuleB
> > > > >
> > > > >/
> > > > >
> > > > >   /
> > > > >
> > > > > (test scope)
> > > > >
> > > > > /
> > > > >
> > > > >   \/_
> > > > >
> > > > > TestSupportModule2
> > > > >
> > > > > If you were to make a src code change to the following test support
> > > > > modules:
> > > > >
> > > > >   *   TestSupportModule1
> > > > >   *   TestSupportModule2
> > > > >
> > > > > Then the minimum number of modules we need to build to verify the
> > > change
> > > > > set is OK is:
> > > > >
> > > > >   *   TestSupportModule1
> > > > >   *   TestSupportModule2
> > > > >   *   ModuleB
> > > > >   *   App
> > > > >
> > > > > i.e. there is no requirement to build ModuleA because we know that
> > > none of
> > > > > the src code changes could impact the classpaths used in its maven
> > > build.
> > > > >
> > > > > We know that despite 'App' depending (transitively) on ModuleB
> there
> > > is no
> > > > > need for the 'App' build to wait for ModuleB to complete its build
> > > because
> > > > > the src code change to TestSupportModule2 will not impact any of
> the
> > > > > classpaths used in the App maven build. Therefore to get the most
> > > efficient
> > > > > build possible we ideally would invoke Maven to run with 2 threads
> and
> > > with
> > > > > instruction to build two distinct 'dependency graphs':
> > > > >
> > > > >   *   TestSupportModule1 followed by ModuleB
> > > > >   *   TestSupportModule1 followed by App
> > > > >
> > > > > The following Maven command achieves exactly what we want because
> the
> > > > > reactor build order is based only on the direct (i.e.
> non-transitive)
> > > > > dependencies of the modules provided to the reactor in the build
> > > command.
> > > > > Therefore the absence of ModuleA results in two distinct
> 'dependency
> > > > > graphs':
> > > > >
> > > > > mvn clean verify -pl
> TestSupportModule1,TestSupportModule2,ModuleB,App
> > > -T 2
> > > > >
> > > > > Note: In reality the code base I maintain has a very large
> monobuild
> > > with
> > > > > 100s of modules and this type of build optimisation makes a
> significant
> > > > > difference to the speed of our monobuild (we use
> > > > >
> > >
> https://github.com/gitflow-incremental-builder/gitflow-incremental-builder
> > > > > to automate the logic of determining which modules to include in
> the
> > > > > reactor based on our change set).
> > > > >
> > > > > Issue
> > > > >
> > > > > We have encountered an issue in the above scenario because the
> 'App'
> > > build
> > > > > has a race condition with the ModuleB build which will result in
> one
> > > of the
> > > > > following three outcomes:
> > > > >
> > > > >   *   If the 'App' build starts before the ModuleB build has
> compiled
> > > its
> > > > > src classes then the 'App' build will resolve ModuleB from the
> external
> > > > > repo (i.e. equivalent to ModuleB not being in the reactor at all)
> > > > >   *   If the 'App' build starts after ModuleB has compiled its src
> > > classes
> > > > > but before it has packaged these classes into a jar then the 'App'
> > > build
> > > > > will resolve ModuleB's target/classes direc

RE: Re: Re: Inconsistent dependency resolution behaviour for concurrent multi-module build can cause failures

; > > > modules:
> > > >
> > > >   *   TestSupportModule1
> > > >   *   TestSupportModule2
> > > >
> > > > Then the minimum number of modules we need to build to verify the
> > change
> > > > set is OK is:
> > > >
> > > >   *   TestSupportModule1
> > > >   *   TestSupportModule2
> > > >   *   ModuleB
> > > >   *   App
> > > >
> > > > i.e. there is no requirement to build ModuleA because we know that
> > none of
> > > > the src code changes could impact the classpaths used in its maven
> > build.
> > > >
> > > > We know that despite 'App' depending (transitively) on ModuleB there
> > is no
> > > > need for the 'App' build to wait for ModuleB to complete its build
> > because
> > > > the src code change to TestSupportModule2 will not impact any of the
> > > > classpaths used in the App maven build. Therefore to get the most
> > efficient
> > > > build possible we ideally would invoke Maven to run with 2 threads and
> > with
> > > > instruction to build two distinct 'dependency graphs':
> > > >
> > > >   *   TestSupportModule1 followed by ModuleB
> > > >   *   TestSupportModule1 followed by App
> > > >
> > > > The following Maven command achieves exactly what we want because the
> > > > reactor build order is based only on the direct (i.e. non-transitive)
> > > > dependencies of the modules provided to the reactor in the build
> > command.
> > > > Therefore the absence of ModuleA results in two distinct 'dependency
> > > > graphs':
> > > >
> > > > mvn clean verify -pl TestSupportModule1,TestSupportModule2,ModuleB,App
> > -T 2
> > > >
> > > > Note: In reality the code base I maintain has a very large monobuild
> > with
> > > > 100s of modules and this type of build optimisation makes a significant
> > > > difference to the speed of our monobuild (we use
> > > >
> > https://github.com/gitflow-incremental-builder/gitflow-incremental-builder
> > > > to automate the logic of determining which modules to include in the
> > > > reactor based on our change set).
> > > >
> > > > Issue
> > > >
> > > > We have encountered an issue in the above scenario because the 'App'
> > build
> > > > has a race condition with the ModuleB build which will result in one
> > of the
> > > > following three outcomes:
> > > >
> > > >   *   If the 'App' build starts before the ModuleB build has compiled
> > its
> > > > src classes then the 'App' build will resolve ModuleB from the external
> > > > repo (i.e. equivalent to ModuleB not being in the reactor at all)
> > > >   *   If the 'App' build starts after ModuleB has compiled its src
> > classes
> > > > but before it has packaged these classes into a jar then the 'App'
> > build
> > > > will resolve ModuleB's target/classes directory
> > > >   *   If the 'App' build starts after ModuleB has packaged its jar file
> > > > then the 'App' build will resolve ModuleB's target/ModuleB.jar file.
> > > >
> > > > In many scenarios this dependency resolution inconsistency doesn't
> > > > represent a challenge. However, it does cause an issue in our case
> > because
> > > > the 'App' POM has its Maven packaging stanza configured to war and in
> > the
> > > > scenario where ModuleB's target/classes directory is resolved by the
> > 'App'
> > > > then this results in the resultant 'App' war file being packaged with a
> > > > completely empty ModuleB.jar file.
> > > >
> > > > Proposed solution
> > > >
> > > > Ideally we would like the Maven reactor to retain isolation between the
> > > > two distinct 'dependency graphs' it constructs at instantiation
> > throughout
> > > > the entire Maven build. This would mean, in the simple example above,
> > that
> > > > the 'App' would always resolves ModuleB from the external repo
> > (regardless
> > > > of whether the reactor has built ModuleB or not in a separate
> > 'dependency
> > > > graph' in the reactor).
> > > >
> > > >
> > > >
> > > > Joseph Leonard
> > > > Manager
> > > >
> > > > Alfa
> > > > 
> > > > e: joseph.leon...@alfasystems.com | w: alfasystems.com<
> > > > https://www.alfasystems.com>
> > > > t: +44 (0)20 7588 1800 | Moor Place, 1 Fore Street Avenue, London, EC2Y
> > > > 9DT, GB
> > > > 
> > > >
> > > > The contents of this communication are not intended to be binding or
> > > > constitute any form of offer or acceptance or give rise to any legal
> > > > obligations on behalf of the sender or Alfa. The views or opinions
> > > > expressed represent those of the author and not necessarily those of
> > Alfa.
> > > > This email and any attachments are strictly confidential and are
> > intended
> > > > solely for use by the individual or entity to whom it is addressed. If
> > you
> > > > are not the addressee (or responsible for delivery of the message to
> > the
> > > > addressee) you may not copy, forward, disclose or use any part of the
> > > > message or its attachments. At present the integrity of email across
> > the
> > > > internet cannot be guaranteed and messages sent via this medium are
> > > > potentially at risk. All liability is excluded to the extent permitted
> > by
> > > > law for any claims arising as a result of the use of this medium to
> > > > transmit information by or to Alfa or its affiliates.
> > > >
> > > > Alfa Financial Software Ltd
> > > > Reg. in England No: 0248 2325
> > > >
> > >
> >
>

RE: Re: Inconsistent dependency resolution behaviour for concurrent multi-module build can cause failures

t;> *   TestSupportModule2
> >>> *   ModuleB
> >>> *   App
> >>>
> >>> i.e. there is no requirement to build ModuleA because we know that none 
> >>> of the src code changes could impact the classpaths used in its maven 
> >>> build.

> >
> >>>
> >>> We know that despite 'App' depending (transitively) on ModuleB there is 
> >>> no need for the 'App' build to wait for ModuleB to complete its build 
> >>> because the src code change to TestSupportModule2 will not impact any of 
> >>> the classpaths used in the App maven build. Therefore to get the most 
> >>> efficient build possible we ideally would invoke Maven to run with 2 
> >>> threads and with instruction to build two distinct 'dependency graphs':

> >
> >>>
> >>> *   TestSupportModule1 followed by ModuleB
> >>> *   TestSupportModule1 followed by App
> >>>
> >>> The following Maven command achieves exactly what we want because the 
> >>> reactor build order is based only on the direct (i.e. non-transitive) 
> >>> dependencies of the modules provided to the reactor in the build command. 
> >>> Therefore the absence of ModuleA results in two distinct 'dependency 
> >>> graphs':

> >
> >>>
> >>> mvn clean verify -pl TestSupportModule1,TestSupportModule2,ModuleB,App -T 
> >>> 2
> >>>
> >>> Note: In reality the code base I maintain has a very large monobuild with 
> >>> 100s of modules and this type of build optimisation makes a significant 
> >>> difference to the speed of our monobuild (we use 
> >>> https://github.com/gitflow-incremental-builder/gitflow-incremental-builder
> >>>  to automate the logic of determining which modules to include in the 
> >>> reactor based on our change set).

> >
> >>>
> >>> Issue
> >>>
> >>> We have encountered an issue in the above scenario because the 'App' 
> >>> build has a race condition with the ModuleB build which will result in 
> >>> one of the following three outcomes:

> >
> >>>
> >>> *   If the 'App' build starts before the ModuleB build has compiled its 
> >>> src classes then the 'App' build will resolve ModuleB from the external 
> >>> repo (i.e. equivalent to ModuleB not being in the reactor at all)

> >
> >>> *   If the 'App' build starts after ModuleB has compiled its src classes 
> >>> but before it has packaged these classes into a jar then the 'App' build 
> >>> will resolve ModuleB's target/classes directory

> >
> >>> *   If the 'App' build starts after ModuleB has packaged its jar file 
> >>> then the 'App' build will resolve ModuleB's target/ModuleB.jar file.

> >
> >>>
> >>> In many scenarios this dependency resolution inconsistency doesn't 
> >>> represent a challenge. However, it does cause an issue in our case 
> >>> because the 'App' POM has its Maven packaging stanza configured to war 
> >>> and in the scenario where ModuleB's target/classes directory is resolved 
> >>> by the 'App' then this results in the resultant 'App' war file being 
> >>> packaged with a completely empty ModuleB.jar file.

> >
> >>>
> >>> Proposed solution
> >>>
> >>> Ideally we would like the Maven reactor to retain isolation between the 
> >>> two distinct 'dependency graphs' it constructs at instantiation 
> >>> throughout the entire Maven build. This would mean, in the simple example 
> >>> above, that the 'App' would always resolves ModuleB from the external 
> >>> repo (regardless of whether the reactor has built ModuleB or not in a 
> >>> separate 'dependency graph' in the reactor).

> >
> >>>
> >>>
> >>>
> >>> Joseph Leonard
> >>> Manager
> >>>
> >>> Alfa
> >>> 
> >>> e: joseph.leon...@alfasystems.com | w: 
> >>> alfasystems.com<https://www.alfasystems.com>
> >>> t: +44 (0)20 7588 1800 | Moor Place, 1 Fore Street Avenue, London, EC2Y 
> >>> 9DT, GB
> >>> 
> >>>
> >>> The contents of this communication are not intended to be binding or 
> >>> constitute any form of offer or acceptance or give rise to any legal 
> >>> obligations on behalf of the sender or Alfa. The views or opinions 
> >>> expressed represent those of the author and not necessarily those of 
> >>> Alfa. This email and any attachments are strictly confidential and are 
> >>> intended solely for use by the individual or entity to whom it is 
> >>> addressed. If you are not the addressee (or responsible for delivery of 
> >>> the message to the addressee) you may not copy, forward, disclose or use 
> >>> any part of the message or its attachments. At present the integrity of 
> >>> email across the internet cannot be guaranteed and messages sent via this 
> >>> medium are potentially at risk. All liability is excluded to the extent 
> >>> permitted by law for any claims arising as a result of the use of this 
> >>> medium to transmit information by or to Alfa or its affiliates.

> >
> >>>
> >>> Alfa Financial Software Ltd
> >>> Reg. in England No: 0248 2325
> >>
>
>
> -
> To unsubscribe, e-mail: users-unsubscr...@maven.apache.org
> For additional commands, e-mail: users-h...@maven.apache.org
>
>

Re: Re: Inconsistent dependency resolution behaviour for concurrent multi-module build can cause failures

SupportModule2
> > > >
> > > > Then the minimum number of modules we need to build to verify the
> > change
> > > > set is OK is:
> > > >
> > > >   *   TestSupportModule1
> > > >   *   TestSupportModule2
> > > >   *   ModuleB
> > > >   *   App
> > > >
> > > > i.e. there is no requirement to build ModuleA because we know that
> > none of
> > > > the src code changes could impact the classpaths used in its maven
> > build.
> > > >
> > > > We know that despite 'App' depending (transitively) on ModuleB there
> > is no
> > > > need for the 'App' build to wait for ModuleB to complete its build
> > because
> > > > the src code change to TestSupportModule2 will not impact any of the
> > > > classpaths used in the App maven build. Therefore to get the most
> > efficient
> > > > build possible we ideally would invoke Maven to run with 2 threads
> and
> > with
> > > > instruction to build two distinct 'dependency graphs':
> > > >
> > > >   *   TestSupportModule1 followed by ModuleB
> > > >   *   TestSupportModule1 followed by App
> > > >
> > > > The following Maven command achieves exactly what we want because the
> > > > reactor build order is based only on the direct (i.e. non-transitive)
> > > > dependencies of the modules provided to the reactor in the build
> > command.
> > > > Therefore the absence of ModuleA results in two distinct 'dependency
> > > > graphs':
> > > >
> > > > mvn clean verify -pl
> TestSupportModule1,TestSupportModule2,ModuleB,App
> > -T 2
> > > >
> > > > Note: In reality the code base I maintain has a very large monobuild
> > with
> > > > 100s of modules and this type of build optimisation makes a
> significant
> > > > difference to the speed of our monobuild (we use
> > > >
> >
> https://github.com/gitflow-incremental-builder/gitflow-incremental-builder
> > > > to automate the logic of determining which modules to include in the
> > > > reactor based on our change set).
> > > >
> > > > Issue
> > > >
> > > > We have encountered an issue in the above scenario because the 'App'
> > build
> > > > has a race condition with the ModuleB build which will result in one
> > of the
> > > > following three outcomes:
> > > >
> > > >   *   If the 'App' build starts before the ModuleB build has compiled
> > its
> > > > src classes then the 'App' build will resolve ModuleB from the
> external
> > > > repo (i.e. equivalent to ModuleB not being in the reactor at all)
> > > >   *   If the 'App' build starts after ModuleB has compiled its src
> > classes
> > > > but before it has packaged these classes into a jar then the 'App'
> > build
> > > > will resolve ModuleB's target/classes directory
> > > >   *   If the 'App' build starts after ModuleB has packaged its jar
> file
> > > > then the 'App' build will resolve ModuleB's target/ModuleB.jar file.
> > > >
> > > > In many scenarios this dependency resolution inconsistency doesn't
> > > > represent a challenge. However, it does cause an issue in our case
> > because
> > > > the 'App' POM has its Maven packaging stanza configured to war and in
> > the
> > > > scenario where ModuleB's target/classes directory is resolved by the
> > 'App'
> > > > then this results in the resultant 'App' war file being packaged
> with a
> > > > completely empty ModuleB.jar file.
> > > >
> > > > Proposed solution
> > > >
> > > > Ideally we would like the Maven reactor to retain isolation between
> the
> > > > two distinct 'dependency graphs' it constructs at instantiation
> > throughout
> > > > the entire Maven build. This would mean, in the simple example above,
> > that
> > > > the 'App' would always resolves ModuleB from the external repo
> > (regardless
> > > > of whether the reactor has built ModuleB or not in a separate
> > 'dependency
> > > > graph' in the reactor).
> > > >
> > > >
> > > >
> > > > Joseph Leonard
> > > > Manager
> > > >
> > > > Alfa
> > > > 
> > > > e: joseph.leon...@alfasystems.com | w: alfasystems.com<
> > > > https://www.alfasystems.com>
> > > > t: +44 (0)20 7588 1800 | Moor Place, 1 Fore Street Avenue, London,
> EC2Y
> > > > 9DT, GB
> > > > 
> > > >
> > > > The contents of this communication are not intended to be binding or
> > > > constitute any form of offer or acceptance or give rise to any legal
> > > > obligations on behalf of the sender or Alfa. The views or opinions
> > > > expressed represent those of the author and not necessarily those of
> > Alfa.
> > > > This email and any attachments are strictly confidential and are
> > intended
> > > > solely for use by the individual or entity to whom it is addressed.
> If
> > you
> > > > are not the addressee (or responsible for delivery of the message to
> > the
> > > > addressee) you may not copy, forward, disclose or use any part of the
> > > > message or its attachments. At present the integrity of email across
> > the
> > > > internet cannot be guaranteed and messages sent via this medium are
> > > > potentially at risk. All liability is excluded to the extent
> permitted
> > by
> > > > law for any claims arising as a result of the use of this medium to
> > > > transmit information by or to Alfa or its affiliates.
> > > >
> > > > Alfa Financial Software Ltd
> > > > Reg. in England No: 0248 2325
> > > >
> > >
> >
>

Re: Re: Inconsistent dependency resolution behaviour for concurrent multi-module build can cause failures

2024-02-07 Thread Amn Ojee Uw

o TestSupportModule2 will not impact any of the
> > > classpaths used in the App maven build. Therefore to get the most
> efficient
> > > build possible we ideally would invoke Maven to run with 2 threads and
> with
> > > instruction to build two distinct 'dependency graphs':
> > >
> > >   *   TestSupportModule1 followed by ModuleB
> > >   *   TestSupportModule1 followed by App
> > >
> > > The following Maven command achieves exactly what we want because the
> > > reactor build order is based only on the direct (i.e. non-transitive)
> > > dependencies of the modules provided to the reactor in the build
> command.
> > > Therefore the absence of ModuleA results in two distinct 'dependency
> > > graphs':
> > >
> > > mvn clean verify -pl TestSupportModule1,TestSupportModule2,ModuleB,App
> -T 2
> > >
> > > Note: In reality the code base I maintain has a very large monobuild
> with
> > > 100s of modules and this type of build optimisation makes a significant
> > > difference to the speed of our monobuild (we use
> > >
> https://github.com/gitflow-incremental-builder/gitflow-incremental-builder
> > > to automate the logic of determining which modules to include in the
> > > reactor based on our change set).
> > >
> > > Issue
> > >
> > > We have encountered an issue in the above scenario because the 'App'
> build
> > > has a race condition with the ModuleB build which will result in one
> of the
> > > following three outcomes:
> > >
> > >   *   If the 'App' build starts before the ModuleB build has compiled
> its
> > > src classes then the 'App' build will resolve ModuleB from the external
> > > repo (i.e. equivalent to ModuleB not being in the reactor at all)
> > >   *   If the 'App' build starts after ModuleB has compiled its src
> classes
> > > but before it has packaged these classes into a jar then the 'App'
> build
> > > will resolve ModuleB's target/classes directory
> > >   *   If the 'App' build starts after ModuleB has packaged its jar file
> > > then the 'App' build will resolve ModuleB's target/ModuleB.jar file.
> > >
> > > In many scenarios this dependency resolution inconsistency doesn't
> > > represent a challenge. However, it does cause an issue in our case
> because
> > > the 'App' POM has its Maven packaging stanza configured to war and in
> the
> > > scenario where ModuleB's target/classes directory is resolved by the
> 'App'
> > > then this results in the resultant 'App' war file being packaged with a
> > > completely empty ModuleB.jar file.
> > >
> > > Proposed solution
> > >
> > > Ideally we would like the Maven reactor to retain isolation between the
> > > two distinct 'dependency graphs' it constructs at instantiation
> throughout
> > > the entire Maven build. This would mean, in the simple example above,
> that
> > > the 'App' would always resolves ModuleB from the external repo
> (regardless
> > > of whether the reactor has built ModuleB or not in a separate
> 'dependency
> > > graph' in the reactor).
> > >
> > >
> > >
> > > Joseph Leonard
> > > Manager
> > >
> > > Alfa
> > > 
> > > e: joseph.leon...@alfasystems.com | w: alfasystems.com<
> > > https://www.alfasystems.com>
> > > t: +44 (0)20 7588 1800 | Moor Place, 1 Fore Street Avenue, London, EC2Y
> > > 9DT, GB
> > > 
> > >
> > > The contents of this communication are not intended to be binding or
> > > constitute any form of offer or acceptance or give rise to any legal
> > > obligations on behalf of the sender or Alfa. The views or opinions
> > > expressed represent those of the author and not necessarily those of
> Alfa.
> > > This email and any attachments are strictly confidential and are
> intended
> > > solely for use by the individual or entity to whom it is addressed. If
> you
> > > are not the addressee (or responsible for delivery of the message to
> the
> > > addressee) you may not copy, forward, disclose or use any part of the
> > > message or its attachments. At present the integrity of email across
> the
> > > internet cannot be guaranteed and messages sent via this medium are
> > > potentially at risk. All liability is excluded to the extent permitted
> by
> > > law for any claims arising as a result of the use of this medium to
> > > transmit information by or to Alfa or its affiliates.
> > >
> > > Alfa Financial Software Ltd
> > > Reg. in England No: 0248 2325
> > >
> >
>

Re: Re: Inconsistent dependency resolution behaviour for concurrent multi-module build can cause failures

e src code change to TestSupportModule2 will not impact any of the
> > > classpaths used in the App maven build. Therefore to get the most
> efficient
> > > build possible we ideally would invoke Maven to run with 2 threads and
> with
> > > instruction to build two distinct 'dependency graphs':
> > >
> > >   *   TestSupportModule1 followed by ModuleB
> > >   *   TestSupportModule1 followed by App
> > >
> > > The following Maven command achieves exactly what we want because the
> > > reactor build order is based only on the direct (i.e. non-transitive)
> > > dependencies of the modules provided to the reactor in the build
> command.
> > > Therefore the absence of ModuleA results in two distinct 'dependency
> > > graphs':
> > >
> > > mvn clean verify -pl TestSupportModule1,TestSupportModule2,ModuleB,App
> -T 2
> > >
> > > Note: In reality the code base I maintain has a very large monobuild
> with
> > > 100s of modules and this type of build optimisation makes a significant
> > > difference to the speed of our monobuild (we use
> > >
> https://github.com/gitflow-incremental-builder/gitflow-incremental-builder
> > > to automate the logic of determining which modules to include in the
> > > reactor based on our change set).
> > >
> > > Issue
> > >
> > > We have encountered an issue in the above scenario because the 'App'
> build
> > > has a race condition with the ModuleB build which will result in one
> of the
> > > following three outcomes:
> > >
> > >   *   If the 'App' build starts before the ModuleB build has compiled
> its
> > > src classes then the 'App' build will resolve ModuleB from the external
> > > repo (i.e. equivalent to ModuleB not being in the reactor at all)
> > >   *   If the 'App' build starts after ModuleB has compiled its src
> classes
> > > but before it has packaged these classes into a jar then the 'App'
> build
> > > will resolve ModuleB's target/classes directory
> > >   *   If the 'App' build starts after ModuleB has packaged its jar file
> > > then the 'App' build will resolve ModuleB's target/ModuleB.jar file.
> > >
> > > In many scenarios this dependency resolution inconsistency doesn't
> > > represent a challenge. However, it does cause an issue in our case
> because
> > > the 'App' POM has its Maven packaging stanza configured to war and in
> the
> > > scenario where ModuleB's target/classes directory is resolved by the
> 'App'
> > > then this results in the resultant 'App' war file being packaged with a
> > > completely empty ModuleB.jar file.
> > >
> > > Proposed solution
> > >
> > > Ideally we would like the Maven reactor to retain isolation between the
> > > two distinct 'dependency graphs' it constructs at instantiation
> throughout
> > > the entire Maven build. This would mean, in the simple example above,
> that
> > > the 'App' would always resolves ModuleB from the external repo
> (regardless
> > > of whether the reactor has built ModuleB or not in a separate
> 'dependency
> > > graph' in the reactor).
> > >
> > >
> > >
> > > Joseph Leonard
> > > Manager
> > >
> > > Alfa
> > > 
> > > e: joseph.leon...@alfasystems.com | w: alfasystems.com<
> > > https://www.alfasystems.com>
> > > t: +44 (0)20 7588 1800 | Moor Place, 1 Fore Street Avenue, London, EC2Y
> > > 9DT, GB
> > > 
> > >
> > > The contents of this communication are not intended to be binding or
> > > constitute any form of offer or acceptance or give rise to any legal
> > > obligations on behalf of the sender or Alfa. The views or opinions
> > > expressed represent those of the author and not necessarily those of
> Alfa.
> > > This email and any attachments are strictly confidential and are
> intended
> > > solely for use by the individual or entity to whom it is addressed. If
> you
> > > are not the addressee (or responsible for delivery of the message to
> the
> > > addressee) you may not copy, forward, disclose or use any part of the
> > > message or its attachments. At present the integrity of email across
> the
> > > internet cannot be guaranteed and messages sent via this medium are
> > > potentially at risk. All liability is excluded to the extent permitted
> by
> > > law for any claims arising as a result of the use of this medium to
> > > transmit information by or to Alfa or its affiliates.
> > >
> > > Alfa Financial Software Ltd
> > > Reg. in England No: 0248 2325
> > >
> >
>

Re: Inconsistent dependency resolution behaviour for concurrent multi-module build can cause failures

2024-02-07 Thread Nils Breunese

tor in the build command. 
>>> Therefore the absence of ModuleA results in two distinct 'dependency 
>>> graphs':
> 
>>> 
>>> mvn clean verify -pl TestSupportModule1,TestSupportModule2,ModuleB,App -T 2
>>> 
>>> Note: In reality the code base I maintain has a very large monobuild with 
>>> 100s of modules and this type of build optimisation makes a significant 
>>> difference to the speed of our monobuild (we use 
>>> https://github.com/gitflow-incremental-builder/gitflow-incremental-builder 
>>> to automate the logic of determining which modules to include in the 
>>> reactor based on our change set).
> 
>>> 
>>> Issue
>>> 
>>> We have encountered an issue in the above scenario because the 'App' build 
>>> has a race condition with the ModuleB build which will result in one of the 
>>> following three outcomes:
> 
>>> 
>>> *   If the 'App' build starts before the ModuleB build has compiled its src 
>>> classes then the 'App' build will resolve ModuleB from the external repo 
>>> (i.e. equivalent to ModuleB not being in the reactor at all)
> 
>>> *   If the 'App' build starts after ModuleB has compiled its src classes 
>>> but before it has packaged these classes into a jar then the 'App' build 
>>> will resolve ModuleB's target/classes directory
> 
>>> *   If the 'App' build starts after ModuleB has packaged its jar file then 
>>> the 'App' build will resolve ModuleB's target/ModuleB.jar file.
> 
>>> 
>>> In many scenarios this dependency resolution inconsistency doesn't 
>>> represent a challenge. However, it does cause an issue in our case because 
>>> the 'App' POM has its Maven packaging stanza configured to war and in the 
>>> scenario where ModuleB's target/classes directory is resolved by the 'App' 
>>> then this results in the resultant 'App' war file being packaged with a 
>>> completely empty ModuleB.jar file.
> 
>>> 
>>> Proposed solution
>>> 
>>> Ideally we would like the Maven reactor to retain isolation between the two 
>>> distinct 'dependency graphs' it constructs at instantiation throughout the 
>>> entire Maven build. This would mean, in the simple example above, that the 
>>> 'App' would always resolves ModuleB from the external repo (regardless of 
>>> whether the reactor has built ModuleB or not in a separate 'dependency 
>>> graph' in the reactor).
> 
>>> 
>>> 
>>> 
>>> Joseph Leonard
>>> Manager
>>> 
>>> Alfa
>>> 
>>> e: joseph.leon...@alfasystems.com | w: 
>>> alfasystems.com<https://www.alfasystems.com>
>>> t: +44 (0)20 7588 1800 | Moor Place, 1 Fore Street Avenue, London, EC2Y 
>>> 9DT, GB
>>> 
>>> 
>>> The contents of this communication are not intended to be binding or 
>>> constitute any form of offer or acceptance or give rise to any legal 
>>> obligations on behalf of the sender or Alfa. The views or opinions 
>>> expressed represent those of the author and not necessarily those of Alfa. 
>>> This email and any attachments are strictly confidential and are intended 
>>> solely for use by the individual or entity to whom it is addressed. If you 
>>> are not the addressee (or responsible for delivery of the message to the 
>>> addressee) you may not copy, forward, disclose or use any part of the 
>>> message or its attachments. At present the integrity of email across the 
>>> internet cannot be guaranteed and messages sent via this medium are 
>>> potentially at risk. All liability is excluded to the extent permitted by 
>>> law for any claims arising as a result of the use of this medium to 
>>> transmit information by or to Alfa or its affiliates.
> 
>>> 
>>> Alfa Financial Software Ltd
>>> Reg. in England No: 0248 2325
>> 


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

RE: Re: Inconsistent dependency resolution behaviour for concurrent multi-module build can cause failures

gt; 100s of modules and this type of build optimisation makes a significant
> > difference to the speed of our monobuild (we use
> > https://github.com/gitflow-incremental-builder/gitflow-incremental-builder
> > to automate the logic of determining which modules to include in the
> > reactor based on our change set).
> >
> > Issue
> >
> > We have encountered an issue in the above scenario because the 'App' build
> > has a race condition with the ModuleB build which will result in one of the
> > following three outcomes:
> >
> >   *   If the 'App' build starts before the ModuleB build has compiled its
> > src classes then the 'App' build will resolve ModuleB from the external
> > repo (i.e. equivalent to ModuleB not being in the reactor at all)
> >   *   If the 'App' build starts after ModuleB has compiled its src classes
> > but before it has packaged these classes into a jar then the 'App' build
> > will resolve ModuleB's target/classes directory
> >   *   If the 'App' build starts after ModuleB has packaged its jar file
> > then the 'App' build will resolve ModuleB's target/ModuleB.jar file.
> >
> > In many scenarios this dependency resolution inconsistency doesn't
> > represent a challenge. However, it does cause an issue in our case because
> > the 'App' POM has its Maven packaging stanza configured to war and in the
> > scenario where ModuleB's target/classes directory is resolved by the 'App'
> > then this results in the resultant 'App' war file being packaged with a
> > completely empty ModuleB.jar file.
> >
> > Proposed solution
> >
> > Ideally we would like the Maven reactor to retain isolation between the
> > two distinct 'dependency graphs' it constructs at instantiation throughout
> > the entire Maven build. This would mean, in the simple example above, that
> > the 'App' would always resolves ModuleB from the external repo (regardless
> > of whether the reactor has built ModuleB or not in a separate 'dependency
> > graph' in the reactor).
> >
> >
> >
> > Joseph Leonard
> > Manager
> >
> > Alfa
> > 
> > e: joseph.leon...@alfasystems.com | w: alfasystems.com<
> > https://www.alfasystems.com>
> > t: +44 (0)20 7588 1800 | Moor Place, 1 Fore Street Avenue, London, EC2Y
> > 9DT, GB
> > 
> >
> > The contents of this communication are not intended to be binding or
> > constitute any form of offer or acceptance or give rise to any legal
> > obligations on behalf of the sender or Alfa. The views or opinions
> > expressed represent those of the author and not necessarily those of Alfa.
> > This email and any attachments are strictly confidential and are intended
> > solely for use by the individual or entity to whom it is addressed. If you
> > are not the addressee (or responsible for delivery of the message to the
> > addressee) you may not copy, forward, disclose or use any part of the
> > message or its attachments. At present the integrity of email across the
> > internet cannot be guaranteed and messages sent via this medium are
> > potentially at risk. All liability is excluded to the extent permitted by
> > law for any claims arising as a result of the use of this medium to
> > transmit information by or to Alfa or its affiliates.
> >
> > Alfa Financial Software Ltd
> > Reg. in England No: 0248 2325
> >
>

Re: Inconsistent dependency resolution behaviour for concurrent multi-module build can cause failures

2024-02-06 Thread Tamás Cservenák

Howdy,

To me this looks like Maven is not aware that the App depends on ModuleB...
Are they "plain dependency" linked? Or what kind of dependency we talk
about here?
In short: why would App start while ModuleB (upstream dep) is not done?
Something is fishy here.

T


On Tue, Feb 6, 2024 at 11:40 AM Joseph Leonard <
joseph.leon...@alfasystems.com> wrote:

> Hi all,
>
> It would be great to get any thoughts on whether the following is a defect:
>
>
> Issue details:
> tl;dr
>
> Maven can resolve dependencies either from:
>
>   *   an external repo
>   *   a class directory of a module being built within the reactor
>   *   a packaged jar of a module being built within the reactor
>
> If you run a concurrent multi-module build it is possible to get a race
> condition whereby the build of module Foo may resolve module Bar from
> either of the three resolution channels. This inconsistency can result in
> the Maven war plugin sometimes failing to build a functional war file. I
> would expect a consistent resolution would always take place.
>
> Full details
> Scenario
>
> Consider you have a repo with the following structure:
>
>App
>
>  / \
>
> /   \
>
>(compile scope)  (test scope)
>
>   /   \
>
> \/_   _\/
>
>  ModuleA  TestSupportModule1
>
> /
>
>/
>
> (compile scope)
>
>  /
>
>\/_
>
> ModuleB
>
>/
>
>   /
>
> (test scope)
>
> /
>
>   \/_
>
> TestSupportModule2
>
> If you were to make a src code change to the following test support
> modules:
>
>   *   TestSupportModule1
>   *   TestSupportModule2
>
> Then the minimum number of modules we need to build to verify the change
> set is OK is:
>
>   *   TestSupportModule1
>   *   TestSupportModule2
>   *   ModuleB
>   *   App
>
> i.e. there is no requirement to build ModuleA because we know that none of
> the src code changes could impact the classpaths used in its maven build.
>
> We know that despite 'App' depending (transitively) on ModuleB there is no
> need for the 'App' build to wait for ModuleB to complete its build because
> the src code change to TestSupportModule2 will not impact any of the
> classpaths used in the App maven build. Therefore to get the most efficient
> build possible we ideally would invoke Maven to run with 2 threads and with
> instruction to build two distinct 'dependency graphs':
>
>   *   TestSupportModule1 followed by ModuleB
>   *   TestSupportModule1 followed by App
>
> The following Maven command achieves exactly what we want because the
> reactor build order is based only on the direct (i.e. non-transitive)
> dependencies of the modules provided to the reactor in the build command.
> Therefore the absence of ModuleA results in two distinct 'dependency
> graphs':
>
> mvn clean verify -pl TestSupportModule1,TestSupportModule2,ModuleB,App -T 2
>
> Note: In reality the code base I maintain has a very large monobuild with
> 100s of modules and this type of build optimisation makes a significant
> difference to the speed of our monobuild (we use
> https://github.com/gitflow-incremental-builder/gitflow-incremental-builder
> to automate the logic of determining which modules to include in the
> reactor based on our change set).
>
> Issue
>
> We have encountered an issue in the above scenario because the 'App' build
> has a race condition with the ModuleB build which will result in one of the
> following three outcomes:
>
>   *   If the 'App' build starts before the ModuleB build has compiled its
> src classes then the 'App' build will resolve ModuleB from the external
> repo (i.e. equivalent to ModuleB not being in the reactor at all)
>   *   If the 'App' build starts after ModuleB has compiled its src classes
> but before it has packaged these classes into a jar then the 'App' build
> will resolve ModuleB's target/classes directory
>   *   If the 'App' build starts after ModuleB has packaged its jar file
> then the 'App' build will resolve ModuleB's target/ModuleB.jar file.
>
> In many scenarios this dependency resolution inconsistency doesn't
> represent a challenge. However, it does cause an issue in our case because
> the 'App' POM has its Maven packaging stanza configured to war and in the
> scenario where ModuleB's target/classes directory is resolved by the 'App'
> then this results in the resultant 'App' war file being packaged with a
> completely empty ModuleB.jar file.
>
> Proposed

RE: Inconsistent dependency resolution behaviour for concurrent multi-module build can cause failures

2024-02-06 Thread Joseph Leonard

Note that my diagram formatting is very hard to read in the default formatting 
on this mailing list. If you view my email in 'raw source' then it is easier to 
understand!

On 2024/02/06 10:40:14 Joseph Leonard wrote:
> Hi all,
>
> It would be great to get any thoughts on whether the following is a defect:
>
>
> Issue details:
> tl;dr
>
> Maven can resolve dependencies either from:
>
>   *   an external repo
>   *   a class directory of a module being built within the reactor
>   *   a packaged jar of a module being built within the reactor
>
> If you run a concurrent multi-module build it is possible to get a race 
> condition whereby the build of module Foo may resolve module Bar from either 
> of the three resolution channels. This inconsistency can result in the Maven 
> war plugin sometimes failing to build a functional war file. I would expect a 
> consistent resolution would always take place.

>
> Full details
> Scenario
>
> Consider you have a repo with the following structure:
>
>App
>
>  / \
>
> /   \
>
>(compile scope)  (test scope)
>
>   /   \
>
> \/_   _\/
>
>  ModuleA  TestSupportModule1
>
> /
>
>/
>
> (compile scope)
>
>  /
>
>\/_
>
> ModuleB
>
>/
>
>   /
>
> (test scope)
>
> /
>
>   \/_
>
> TestSupportModule2
>
> If you were to make a src code change to the following test support modules:
>
>   *   TestSupportModule1
>   *   TestSupportModule2
>
> Then the minimum number of modules we need to build to verify the change set 
> is OK is:
>
>   *   TestSupportModule1
>   *   TestSupportModule2
>   *   ModuleB
>   *   App
>
> i.e. there is no requirement to build ModuleA because we know that none of 
> the src code changes could impact the classpaths used in its maven build.

>
> We know that despite 'App' depending (transitively) on ModuleB there is no 
> need for the 'App' build to wait for ModuleB to complete its build because 
> the src code change to TestSupportModule2 will not impact any of the 
> classpaths used in the App maven build. Therefore to get the most efficient 
> build possible we ideally would invoke Maven to run with 2 threads and with 
> instruction to build two distinct 'dependency graphs':

>
>   *   TestSupportModule1 followed by ModuleB
>   *   TestSupportModule1 followed by App
>
> The following Maven command achieves exactly what we want because the reactor 
> build order is based only on the direct (i.e. non-transitive) dependencies of 
> the modules provided to the reactor in the build command. Therefore the 
> absence of ModuleA results in two distinct 'dependency graphs':

>
> mvn clean verify -pl TestSupportModule1,TestSupportModule2,ModuleB,App -T 2
>
> Note: In reality the code base I maintain has a very large monobuild with 
> 100s of modules and this type of build optimisation makes a significant 
> difference to the speed of our monobuild (we use 
> https://github.com/gitflow-incremental-builder/gitflow-incremental-builder to 
> automate the logic of determining which modules to include in the reactor 
> based on our change set).

>
> Issue
>
> We have encountered an issue in the above scenario because the 'App' build 
> has a race condition with the ModuleB build which will result in one of the 
> following three outcomes:

>
>   *   If the 'App' build starts before the ModuleB build has compiled its src 
> classes then the 'App' build will resolve ModuleB from the external repo 
> (i.e. equivalent to ModuleB not being in the reactor at all)

>   *   If the 'App' build starts after ModuleB has compiled its src classes 
> but before it has packaged these classes into a jar then the 'App' build will 
> resolve ModuleB's target/classes directory

>   *   If the 'App' build starts after ModuleB has packaged its jar file then 
> the 'App' build will resolve ModuleB's target/ModuleB.jar file.

>
> In many scenarios this dependency resolution inconsistency doesn't represent 
> a challenge. However, it does cause an issue in our case because the 'App' 
> POM has its Maven packaging stanza configured to war and in the scenario 
> where ModuleB's target/classes directory is resolved by the 'App' then this 
> results in the resultant 'App' war file being packaged with a completely 
> empty ModuleB.jar file.

>
> Proposed solution
>
> Ideally we would like the Maven reactor to retain isolation between the two 
> distinct 'dependency grap

RE: Re: Inconsistent dependency resolution behaviour for concurrent multi-module build can cause failures

2024-02-06 Thread Joseph Leonard

Thanks Nils,
maven-build-cache-extension looks very interesting generally – I will have a 
play with it.
With regards to this issue, the maven-build-cache-extension overview references 
“Subtree support for multimodule projects builds part of the codebase in 
isolation” which sounded similar to the solution I am proposing for this issue. 
Unfortunately, after enabling the maven-build-cache-extension I still hit the 
same issue.
Joe

On 2024/02/06 12:54:59 Nils Breunese wrote:
> I can’t comment on your question directly, but I just wanted to say that your 
> use case sounds like it could benefit from the Maven Build Cache Extension 
> (https://maven.apache.org/extensions/maven-build-cache-extension/).

>
> Just my 2 cents.
>
> Nils.
>
> > Op 6 feb 2024 om 11:40 heeft Joseph Leonard  het 
> > volgende geschreven:
> >
> > Hi all,
> >
> > It would be great to get any thoughts on whether the following is a defect:
> >
> >
> > Issue details:
> > tl;dr
> >
> > Maven can resolve dependencies either from:
> >
> >  *   an external repo
> >  *   a class directory of a module being built within the reactor
> >  *   a packaged jar of a module being built within the reactor
> >
> > If you run a concurrent multi-module build it is possible to get a race 
> > condition whereby the build of module Foo may resolve module Bar from 
> > either of the three resolution channels. This inconsistency can result in 
> > the Maven war plugin sometimes failing to build a functional war file. I 
> > would expect a consistent resolution would always take place.

> >
> > Full details
> > Scenario
> >
> > Consider you have a repo with the following structure:
> >
> >   App
> >
> > / \
> >
> >/   \
> >
> >   (compile scope)  (test scope)
> >
> >  /   \
> >
> >\/_   _\/
> >
> > ModuleA  TestSupportModule1
> >
> >/
> >
> >   /
> >
> >(compile scope)
> >
> > /
> >
> >   \/_
> >
> >ModuleB
> >
> >   /
> >
> >  /
> >
> >(test scope)
> >
> >/
> >
> >  \/_
> >
> > TestSupportModule2
> >
> > If you were to make a src code change to the following test support modules:
> >
> >  *   TestSupportModule1
> >  *   TestSupportModule2
> >
> > Then the minimum number of modules we need to build to verify the change 
> > set is OK is:
> >
> >  *   TestSupportModule1
> >  *   TestSupportModule2
> >  *   ModuleB
> >  *   App
> >
> > i.e. there is no requirement to build ModuleA because we know that none of 
> > the src code changes could impact the classpaths used in its maven build.

> >
> > We know that despite 'App' depending (transitively) on ModuleB there is no 
> > need for the 'App' build to wait for ModuleB to complete its build because 
> > the src code change to TestSupportModule2 will not impact any of the 
> > classpaths used in the App maven build. Therefore to get the most efficient 
> > build possible we ideally would invoke Maven to run with 2 threads and with 
> > instruction to build two distinct 'dependency graphs':

> >
> >  *   TestSupportModule1 followed by ModuleB
> >  *   TestSupportModule1 followed by App
> >
> > The following Maven command achieves exactly what we want because the 
> > reactor build order is based only on the direct (i.e. non-transitive) 
> > dependencies of the modules provided to the reactor in the build command. 
> > Therefore the absence of ModuleA results in two distinct 'dependency 
> > graphs':

> >
> > mvn clean verify -pl TestSupportModule1,TestSupportModule2,ModuleB,App -T 2
> >
> > Note: In reality the code base I maintain has a very large monobuild with 
> > 100s of modules and this type of build optimisation makes a significant 
> > difference to the speed of our monobuild (we use 
> > https://github.com/gitflow-incremental-builder/gitflow-incremental-builder 
> > to automate the logic of determining which modules to include in the 
> > reactor based on our change set).

> >
> > Issue
> >
> > We have encountered an issue in the above scenario because the 'App' build 
> > has a race condition with the ModuleB build which will result in one of the 
> > following three outcomes:

> >
>

Re: Inconsistent dependency resolution behaviour for concurrent multi-module build can cause failures

2024-02-06 Thread Greg Chabala

My two cents:

a very large monobuild with 100s of modules


These are the kinds of problems you find when you're abusing the
multi-module system. Multi-module builds are a last resort for me, when
there are couplings between artifacts that need to be released
simultaneously, e.g. API and implementation artifacts. Do you have 100
artifacts that all depend on each other and need simultaneous release? That
sounds like a tightly coupled mess. Keep your builds in independent
projects instead of modules and avoid these issues.

Re: Inconsistent dependency resolution behaviour for concurrent multi-module build can cause failures

2024-02-06 Thread Nils Breunese

I can’t comment on your question directly, but I just wanted to say that your 
use case sounds like it could benefit from the Maven Build Cache Extension 
(https://maven.apache.org/extensions/maven-build-cache-extension/).

Just my 2 cents.

Nils.

> Op 6 feb 2024 om 11:40 heeft Joseph Leonard  
> het volgende geschreven:
> 
> Hi all,
> 
> It would be great to get any thoughts on whether the following is a defect:
> 
> 
> Issue details:
> tl;dr
> 
> Maven can resolve dependencies either from:
> 
>  *   an external repo
>  *   a class directory of a module being built within the reactor
>  *   a packaged jar of a module being built within the reactor
> 
> If you run a concurrent multi-module build it is possible to get a race 
> condition whereby the build of module Foo may resolve module Bar from either 
> of the three resolution channels. This inconsistency can result in the Maven 
> war plugin sometimes failing to build a functional war file. I would expect a 
> consistent resolution would always take place.
> 
> Full details
> Scenario
> 
> Consider you have a repo with the following structure:
> 
>   App
> 
> / \
> 
>/   \
> 
>   (compile scope)  (test scope)
> 
>  /   \
> 
>\/_   _\/
> 
> ModuleA  TestSupportModule1
> 
>/
> 
>   /
> 
>(compile scope)
> 
> /
> 
>   \/_
> 
>ModuleB
> 
>   /
> 
>  /
> 
>(test scope)
> 
>/
> 
>  \/_
> 
> TestSupportModule2
> 
> If you were to make a src code change to the following test support modules:
> 
>  *   TestSupportModule1
>  *   TestSupportModule2
> 
> Then the minimum number of modules we need to build to verify the change set 
> is OK is:
> 
>  *   TestSupportModule1
>  *   TestSupportModule2
>  *   ModuleB
>  *   App
> 
> i.e. there is no requirement to build ModuleA because we know that none of 
> the src code changes could impact the classpaths used in its maven build.
> 
> We know that despite 'App' depending (transitively) on ModuleB there is no 
> need for the 'App' build to wait for ModuleB to complete its build because 
> the src code change to TestSupportModule2 will not impact any of the 
> classpaths used in the App maven build. Therefore to get the most efficient 
> build possible we ideally would invoke Maven to run with 2 threads and with 
> instruction to build two distinct 'dependency graphs':
> 
>  *   TestSupportModule1 followed by ModuleB
>  *   TestSupportModule1 followed by App
> 
> The following Maven command achieves exactly what we want because the reactor 
> build order is based only on the direct (i.e. non-transitive) dependencies of 
> the modules provided to the reactor in the build command. Therefore the 
> absence of ModuleA results in two distinct 'dependency graphs':
> 
> mvn clean verify -pl TestSupportModule1,TestSupportModule2,ModuleB,App -T 2
> 
> Note: In reality the code base I maintain has a very large monobuild with 
> 100s of modules and this type of build optimisation makes a significant 
> difference to the speed of our monobuild (we use 
> https://github.com/gitflow-incremental-builder/gitflow-incremental-builder to 
> automate the logic of determining which modules to include in the reactor 
> based on our change set).
> 
> Issue
> 
> We have encountered an issue in the above scenario because the 'App' build 
> has a race condition with the ModuleB build which will result in one of the 
> following three outcomes:
> 
>  *   If the 'App' build starts before the ModuleB build has compiled its src 
> classes then the 'App' build will resolve ModuleB from the external repo 
> (i.e. equivalent to ModuleB not being in the reactor at all)
>  *   If the 'App' build starts after ModuleB has compiled its src classes but 
> before it has packaged these classes into a jar then the 'App' build will 
> resolve ModuleB's target/classes directory
>  *   If the 'App' build starts after ModuleB has packaged its jar file then 
> the 'App' build will resolve ModuleB's target/ModuleB.jar file.
> 
> In many scenarios this dependency resolution inconsistency doesn't represent 
> a challenge. However, it does cause an issue in our case because the 'App' 
> POM has its Maven packaging stanza configured to war and in the scenario 
> where ModuleB's target/classes directory is resolved by the 'App' then this 
> results in the resultant 'App' war file being packaged with a completely 
> empty ModuleB.jar file.
> 
> Proposed solution

Inconsistent dependency resolution behaviour for concurrent multi-module build can cause failures

2024-02-06 Thread Joseph Leonard

Hi all,

It would be great to get any thoughts on whether the following is a defect:


Issue details:
tl;dr

Maven can resolve dependencies either from:

  *   an external repo
  *   a class directory of a module being built within the reactor
  *   a packaged jar of a module being built within the reactor

If you run a concurrent multi-module build it is possible to get a race 
condition whereby the build of module Foo may resolve module Bar from either of 
the three resolution channels. This inconsistency can result in the Maven war 
plugin sometimes failing to build a functional war file. I would expect a 
consistent resolution would always take place.

Full details
Scenario

Consider you have a repo with the following structure:

   App

 / \

/   \

   (compile scope)  (test scope)

  /   \

\/_   _\/

 ModuleA  TestSupportModule1

/

   /

(compile scope)

 /

   \/_

ModuleB

   /

  /

(test scope)

/

  \/_

TestSupportModule2

If you were to make a src code change to the following test support modules:

  *   TestSupportModule1
  *   TestSupportModule2

Then the minimum number of modules we need to build to verify the change set is 
OK is:

  *   TestSupportModule1
  *   TestSupportModule2
  *   ModuleB
  *   App

i.e. there is no requirement to build ModuleA because we know that none of the 
src code changes could impact the classpaths used in its maven build.

We know that despite 'App' depending (transitively) on ModuleB there is no need 
for the 'App' build to wait for ModuleB to complete its build because the src 
code change to TestSupportModule2 will not impact any of the classpaths used in 
the App maven build. Therefore to get the most efficient build possible we 
ideally would invoke Maven to run with 2 threads and with instruction to build 
two distinct 'dependency graphs':

  *   TestSupportModule1 followed by ModuleB
  *   TestSupportModule1 followed by App

The following Maven command achieves exactly what we want because the reactor 
build order is based only on the direct (i.e. non-transitive) dependencies of 
the modules provided to the reactor in the build command. Therefore the absence 
of ModuleA results in two distinct 'dependency graphs':

mvn clean verify -pl TestSupportModule1,TestSupportModule2,ModuleB,App -T 2

Note: In reality the code base I maintain has a very large monobuild with 100s 
of modules and this type of build optimisation makes a significant difference 
to the speed of our monobuild (we use 
https://github.com/gitflow-incremental-builder/gitflow-incremental-builder to 
automate the logic of determining which modules to include in the reactor based 
on our change set).

Issue

We have encountered an issue in the above scenario because the 'App' build has 
a race condition with the ModuleB build which will result in one of the 
following three outcomes:

  *   If the 'App' build starts before the ModuleB build has compiled its src 
classes then the 'App' build will resolve ModuleB from the external repo (i.e. 
equivalent to ModuleB not being in the reactor at all)
  *   If the 'App' build starts after ModuleB has compiled its src classes but 
before it has packaged these classes into a jar then the 'App' build will 
resolve ModuleB's target/classes directory
  *   If the 'App' build starts after ModuleB has packaged its jar file then 
the 'App' build will resolve ModuleB's target/ModuleB.jar file.

In many scenarios this dependency resolution inconsistency doesn't represent a 
challenge. However, it does cause an issue in our case because the 'App' POM 
has its Maven packaging stanza configured to war and in the scenario where 
ModuleB's target/classes directory is resolved by the 'App' then this results 
in the resultant 'App' war file being packaged with a completely empty 
ModuleB.jar file.

Proposed solution

Ideally we would like the Maven reactor to retain isolation between the two 
distinct 'dependency graphs' it constructs at instantiation throughout the 
entire Maven build. This would mean, in the simple example above, that the 
'App' would always resolves ModuleB from the external repo (regardless of 
whether the reactor has built ModuleB or not in a separate 'dependency graph' 
in the reactor).



Joseph Leonard
Manager

Alfa

e: joseph.leon...@alfasystems.com | w: 
alfasystems.com<https://www.alfasystems.com>
t: +44 (0)20 7588 1800 | Moor Place, 1 Fore Street Avenue, London, EC2Y 9DT, GB


The contents of this communication are not intended to be binding or constitute 
any form of offer or acceptance or give rise to any legal obligations on behalf 
of the sender or Alfa. The views or opinions expressed represent those of the 
author and not neces

Dependency resolution with -am/-amd

2020-03-12 Thread Mitch Denny

I’m using Maven in a CI scenario right now making use of the -am and -amd 
switches. We are having an issue right now with how the list of projects to 
make is solved. Consider the following five projects:

A, B, C, D, and E.

The dependencies between these projects are as follows:

E depends on A
E depends on C
E depends on D
C depends on A
C depends on B
D depends on A
B depends on A

So I execute the following command:

mvn install -pl C -am -amd

The following happens:

A builds because C depends on it (-am switch)
B builds because C depends on it (-am switch)
C builds because it is in the project list (-pl switch)
E builds because it depends on C … but fails (-amd switch)
D does not build

D is not covered by -am (makes sense) but I was surprised that -amd didn’t 
result in it getting picked up. I thought that when Maven was resolving the 
dependencies to build it would see that D was in the graph and in order to 
successfully build E, it would also need to build D.

But it appears that -amd doesn’t work that way. In these scenarios, what is the 
expected way to resolve this dependency arrangement. Assume that this is just a 
subset of a larger graph and my intention is not to build the entire graph.

One thing that I am considering doing is making D depend explicitly on C via a 
test dependency. This seems to work, but feels hacky. In a picture this is what 
our graph looks like:

[cid:image001.png@01D5F94D.BA6AD820]



Sent from Mail for Windows 10

Re: Shade Plugin dependency resolution

2019-08-23 Thread Debraj Manna

Anyone any update on this?


On Thu, Aug 22, 2019 at 8:06 PM Debraj Manna 
wrote:

> Hi
>
> Is there any doc or link that explains how does shade Plugin resolves the
> dependency that is to be added in the uber jar?
>

Shade Plugin dependency resolution

2019-08-22 Thread Debraj Manna

Hi

Is there any doc or link that explains how does shade Plugin resolves the
dependency that is to be added in the uber jar?

RE: Strange result between "bundle" and "jar" type wrt javadoc and dependency resolution

2016-10-29 Thread KARR, DAVID

> -Original Message-
> From: Stian Soiland-Reyes [mailto:st...@apache.org]
> Sent: Friday, October 28, 2016 5:26 PM
> To: Maven Users List <users@maven.apache.org>
> Subject: Re: Strange result between "bundle" and "jar" type wrt javadoc
> and dependency resolution
> 
> Bundle is a special type used by the maven bundle plugin, which replaces
> the normal jar with one augmented with OSGi metadata.
> 
> It is also possible to augment the replaced JAR further, e.g. shadow
> classes from other dependencies.
> 
> When deployed, the result is still a *.jar, so it can be used as a
> jar dependency. To use the bundle dependency would require
> the maven bundle Plugin to intervene to still look up the jar, otherwise
> Maven would look for a *.bundle file, which would not exist in the maven
> repository.
> 
> Therefore I think you should never need to specify bundle within a
> .

At least this part confirms everything I thought I knew, so good. 

> httpclient-osgi is such a shadowed package, bundling several of the
> httpclient libraries. One thing to be careful with on this particular
> bundle is that it is not very useful from other Maven OSGi projects, as
> the httpclient-osgi pom also has transitive dependencies on the
> libraries which are also inside the httpclient-osgi jar. That might
> cause some confusion for Javadoc with duplicate classes, or problems I'd
> you get version mismatches.
> 
> In
> https://github.com/apache/jena/blob/master/apache-jena-osgi/jena-
> osgi/pom.xml#L153
> we therefore had to use lots of exclusions. Ironically the o e
> dependency of httpclient-osgi that *is* needed, httpcore-osgi, is NOT
> declared in the pom of httpclient-osgi, so that must also be added with
> similar exclusions.
> 
> Now if your project is not itself an OSGi project and don't use
> bundle in its own pom, then you probably don't need
> httpclient-osgi and can exclude it and use the regular httpclient
> dependencies instead.

This is an OSGi project, and the subproject with this dependency is producing a 
bundle.

Besides httpclient-osgi, we also have a httpcore-osgi dependency (curiously, 
version 4.4, not 4.5.2).

> On 28 Oct 2016 5:40 pm, "KARR, DAVID" <dk0...@att.com> wrote:
> 
> > I have a subproject in a large multi-module project with the following
> > dependency:
> > --
> > 
> > org.apache.httpcomponents
> > httpclient-osgi
> > 4.5.2
> > bundle
> > 
> > --
> >
> > The project builds without error.
> >
> > I was working on implementing Javadoc generation in this tree.  When I
> > ran the "aggregate-jar" goal from the toplevel, it gave me an error
> > saying it couldn't find this artifact.  This was initially mystifying
> > (and still is somewhat).
> >
> > We use an intranet Maven repo, so it's pulling from that instead of
> > mavencentral.  When I looked in the repo itself, I noticed that it had
> > that artifact, but not the "bundle" type.  It just had the plain jar
> > (I assume I would see something in the directory saying it was a
> bundle).
> >
> > When I looked in my local repo, it also only had the plain jar (I even
> > cleared out the local repo and reran the build to regenerate it).
> >
> > I then tried commenting out the "type" property and also cleared out
> > that section of the local repo.  As before, the subproject built
> without error.
> > In addition, the toplevel Javadoc generation did not fail.
> >
> > It seems like the regular Maven dependency mechanism was happy with
> > getting just the "jar" artifact, even though the dependency specified
> > the "bundle" type, but the Javadoc generation would only work with the
> > exact type as specified.
> >
> > I don't know if there's a bug here, but there's certainly something
> > odd going on here.
> >
> > Can anyone explain what happened here?
> >
> > -
> > To unsubscribe, e-mail: users-unsubscr...@maven.apache.org
> > For additional commands, e-mail: users-h...@maven.apache.org
> >
> >

Re: Strange result between "bundle" and "jar" type wrt javadoc and dependency resolution

2016-10-28 Thread Stian Soiland-Reyes

Bundle is a special type used by the maven bundle plugin, which replaces
the normal jar with one augmented with OSGi metadata.

It is also possible to augment the replaced JAR further, e.g. shadow
classes from other dependencies.

When deployed, the result is still a *.jar, so it can be used as a
jar dependency. To use the bundle dependency would require the
maven bundle Plugin to intervene to still look up the jar, otherwise Maven
would look for a *.bundle file, which would not exist in the maven
repository.

Therefore I think you should never need to specify bundle within a
.

httpclient-osgi is such a shadowed package, bundling several of the
httpclient libraries. One thing to be careful with on this particular
bundle is that it is not very useful from other Maven OSGi projects, as the
httpclient-osgi pom also has transitive dependencies on the libraries which
are also inside the httpclient-osgi jar. That might cause some confusion
for Javadoc with duplicate classes, or problems I'd you get version
mismatches.

In
https://github.com/apache/jena/blob/master/apache-jena-osgi/jena-osgi/pom.xml#L153
we therefore had to use lots of exclusions. Ironically the o e dependency
of httpclient-osgi that *is* needed, httpcore-osgi, is NOT declared in the
pom of httpclient-osgi, so that must also be added with similar exclusions.

Now if your project is not itself an OSGi project and don't use
bundle in its own pom, then you probably don't need
httpclient-osgi and can exclude it and use the regular httpclient
dependencies instead.

On 28 Oct 2016 5:40 pm, "KARR, DAVID"  wrote:

> I have a subproject in a large multi-module project with the following
> dependency:
> --
> 
> org.apache.httpcomponents
> httpclient-osgi
> 4.5.2
> bundle
> 
> --
>
> The project builds without error.
>
> I was working on implementing Javadoc generation in this tree.  When I ran
> the "aggregate-jar" goal from the toplevel, it gave me an error saying it
> couldn't find this artifact.  This was initially mystifying (and still is
> somewhat).
>
> We use an intranet Maven repo, so it's pulling from that instead of
> mavencentral.  When I looked in the repo itself, I noticed that it had that
> artifact, but not the "bundle" type.  It just had the plain jar (I assume I
> would see something in the directory saying it was a bundle).
>
> When I looked in my local repo, it also only had the plain jar (I even
> cleared out the local repo and reran the build to regenerate it).
>
> I then tried commenting out the "type" property and also cleared out that
> section of the local repo.  As before, the subproject built without error.
> In addition, the toplevel Javadoc generation did not fail.
>
> It seems like the regular Maven dependency mechanism was happy with
> getting just the "jar" artifact, even though the dependency specified the
> "bundle" type, but the Javadoc generation would only work with the exact
> type as specified.
>
> I don't know if there's a bug here, but there's certainly something odd
> going on here.
>
> Can anyone explain what happened here?
>
> -
> To unsubscribe, e-mail: users-unsubscr...@maven.apache.org
> For additional commands, e-mail: users-h...@maven.apache.org
>
>

Strange result between "bundle" and "jar" type wrt javadoc and dependency resolution

2016-10-28 Thread KARR, DAVID

I have a subproject in a large multi-module project with the following 
dependency:
--

org.apache.httpcomponents
httpclient-osgi
4.5.2
bundle

--

The project builds without error.

I was working on implementing Javadoc generation in this tree.  When I ran the 
"aggregate-jar" goal from the toplevel, it gave me an error saying it couldn't 
find this artifact.  This was initially mystifying (and still is somewhat).

We use an intranet Maven repo, so it's pulling from that instead of 
mavencentral.  When I looked in the repo itself, I noticed that it had that 
artifact, but not the "bundle" type.  It just had the plain jar (I assume I 
would see something in the directory saying it was a bundle).

When I looked in my local repo, it also only had the plain jar (I even cleared 
out the local repo and reran the build to regenerate it).

I then tried commenting out the "type" property and also cleared out that 
section of the local repo.  As before, the subproject built without error.  In 
addition, the toplevel Javadoc generation did not fail.

It seems like the regular Maven dependency mechanism was happy with getting 
just the "jar" artifact, even though the dependency specified the "bundle" 
type, but the Javadoc generation would only work with the exact type as 
specified.

I don't know if there's a bug here, but there's certainly something odd going 
on here.

Can anyone explain what happened here?

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

aggregation and dependency resolution

2015-11-05 Thread Jeremy Long

I have been struggling with creating an aggregate goal that successfully works
and I was hoping someone on this list could help. The plugin is
dependency-check-maven <
https://github.com/jeremylong/DependencyCheck/tree/master/dependency-check-maven
>; it performs identification (CPE <https://nvd.nist.gov/cpe.cfm>) and
known vulnerability (CVE <http://cve.mitre.org/>) reporting on dependencies
used by the project.

In order to perform CPE identification, the plugin needs maven to resolve each
modules’ dependencies. If we have a simple multi-module project:

Parent
-Child1
-Child2

If one defines the aggregate goal in the Parent, when the plugin
executes dependency
resolution (obviously) hasn’t executed on the child modules. As such, my
plugin is unable analyze the dependencies of the child modules.

I am currently using a hack, which turns out to be broken, that waits until the
plugin executes in the last module in the reactor and then builds the aggregate
report and over-writes the blank report that was generated when Parent was
processed. This “worked” in some cases, but fails for anything beyond
site:site. Running site:stage, due to execution order, would copy the blank
report into the staging directory prior to the correct report being
generated.

Does anyone have any suggestions for building an aggregate goal that requires
dependency resolution of all child modules? Is there a convenient API that
I am missing to trigger dependency resolution in child modeules?

Thanks in advance,

Jeremy

Re: Parallel builds and dependency resolution

2015-04-10 Thread Karl Heinz Marbaise


Hi Laurence,

On 4/10/15 9:29 PM, Laurence Bordowitz wrote:

 Remove every content from your local repository ($HOME/.m2/repository
 simply empty)...and just do:
 
 mvn package
 
 does this work without any problem..?

The command we use for building is

mvn -P[profile] clean install -T 1C


No please really check with an empty repository and simply:

mvn clean package

No -T option and do not use install !!!

I recommend to check your build first via the above...

BTW: How many modules do you have? Do you know the number of lines of 
code (may be counted by Sonaqube) ?




And the profile is only used at the very end of the build for some
proprietary packaging thing.

 Which Maven version do you use?

Apache Maven 3.2.1, using Java version 1.8.0.31


with JDK 1.8.0.40 ...there have been fixed some bugs which had causes 
some issues as far as i know




 Which Maven Plugins do you use in which versions? Where does this
 problem happen?
 
 From which of your plugins is this message emitted ?



It is really important to know which plugin versions you usecause 
there had been some problems in parallelization


Simplest is if you create a log file of the build run and do the following:


cat mvn.log | egrep -a \[INFO\] ---  | cut -d  -f3 | sort -u

or you can use the log file which is produced for example from Jenkins 
on console. This will give a list of plugins with their appropriate 
versions without any internal details only a list like this:


appassembler-maven-plugin:1.9:assemble
maven-assembly-plugin:2.5.3:single
maven-clean-plugin:2.6.1:clean
maven-compiler-plugin:3.2:compile
maven-compiler-plugin:3.2:testCompile
maven-ear-plugin:2.10:ear
maven-ear-plugin:2.10:generate-application-xml
maven-ejb-plugin:2.5:ejb
maven-enforcer-plugin:1.4:enforce
maven-jar-plugin:2.5:jar
maven-resources-plugin:2.7:resources
maven-resources-plugin:2.7:testResources
maven-shade-plugin:2.3:shade
maven-surefire-plugin:2.18.1:test
maven-war-plugin:2.6:war

Things like this had been there:

https://issues.apache.org/jira/browse/MEAR-201?jql=project%20%3D%20MEAR%20AND%20fixVersion%20%3D%202.10


The problem does not really look like a typical concurrent issue...




Not sure... it just says:

[INFO] Building [project_name] 1.1-SNAPSHOT

I guess that's the maven compiler plugin?

 Does this happen every time at the same are or more on coincidence?

Every time that it does happen, it always happens around the same
compile duration, around five or six minutes into the usually 30 minute
build. Haven't kept track of whether it happens during the same absolute
time, but that might be a good thing to track.


you should check this...




 BTW: I assume you are using a repository manager ? Which one? In which
 version?

It's an internally developed proxy system; if the dependency can't be
resolved internally, it goes to a cache.


Why not using a repository manager like Nexus, Artifactory or Archiva ?





-- Larry Bordowitz



On Friday, April 10, 2015 12:00 PM, Karl Heinz Marbaise
khmarba...@gmx.de wrote:


Hi Laurence,

before you are searching phantoms i would suggest to first check if you
can build without any issue by the following reprequisites on command line:

Remove every content from your local repository ($HOME/.m2/repository
simply empty)...and just do:

mvn package

does this work without any problem..?


Furthermore could you give more information like the following:

Which Maven version do you use?

Which Maven Plugins do you use in which versions? Where does this
problem happen?

 From which of your plugins is this message emitted ?

Does this happen every time at the same are or more on coincidence?

BTW: I assume you are using a repository manager ? Which one? In which
version?


Kind regards
Karl Heinz Marbaise

On 4/10/15 8:35 PM, Laurence Bordowitz wrote:
  I'm having a problem where building a large multi-module project in
parallel causes the dependency resolution to fail:
org.apache.maven.lifecycle.LifecycleExecutionException: Failed to
execute goal on project [PROJECT]: Could not resolve dependencies for
project [company].[groupid].[PROJECT]:[PROJECT]:jar:1.1-SNAPSHOT: Could
not find artifact com.jayway.jsonpath:json-path:jar:0.9.1
 
  Normally, the answer to this would be, you didn't set up your
repository correctly, check your company's mirrors, etc. However, our
builds usually succeed, and all the dependencies resolve. In fact, this
only happens in about 10% of the builds, and with different jars
(although often the same set of jars). Earlier in the same build where
the log line above comes from, we get this message:
  b17:53:20/b [INFO] Downloading:
http://[MAVEN-REPO]/proximity/repository/public/com/jayway/jsonpath/json-path/0.9.1/json-path-0.9.1.jar
  b17:53:20/b [INFO] Changes detected - recompiling the module!
  b17:53:20/b [INFO] Compiling 7 source files to
[/location/of/different/project]
  b17:53:20/b [INFO]
  b17:53:20/b [INFO] --- maven-clean-plugin:2.6:clean
(default-clean) @ [Yet

Re: Parallel builds and dependency resolution

2015-04-10 Thread Jason van Zyl

You may want to take a look at the following:

https://github.com/takari/core-extensions-example

On Apr 10, 2015, at 3:29 PM, Laurence Bordowitz 
lbordow...@yahoo-inc.com.INVALID wrote:

 Remove every content from your local repository ($HOME/.m2/repository 
 simply empty)...and just do:
 
 mvn package
 
 does this work without any problem..?
 The command we use for building is 
 
 mvn -P[profile] clean install -T 1C
 And the profile is only used at the very end of the build for some 
 proprietary packaging thing.
 Which Maven version do you use?
 Apache Maven 3.2.1, using Java version 1.8.0.31
 
 Which Maven Plugins do you use in which versions? Where does this 
 problem happen?
 
 From which of your plugins is this message emitted ?
 Not sure... it just says:
 [INFO] Building [project_name] 1.1-SNAPSHOT
 I guess that's the maven compiler plugin?
 
 Does this happen every time at the same are or more on coincidence?
 Every time that it does happen, it always happens around the same compile 
 duration, around five or six minutes into the usually 30 minute build. 
 Haven't kept track of whether it happens during the same absolute time, but 
 that might be a good thing to track.
 
 BTW: I assume you are using a repository manager ? Which one? In which 
 version?
 It's an internally developed proxy system; if the dependency can't be 
 resolved internally, it goes to a cache. 
 
 -- Larry Bordowitz
 
 
 
 On Friday, April 10, 2015 12:00 PM, Karl Heinz Marbaise 
 khmarba...@gmx.de wrote:
 
 
 Hi Laurence,
 
 before you are searching phantoms i would suggest to first check if you 
 can build without any issue by the following reprequisites on command line:
 
 Remove every content from your local repository ($HOME/.m2/repository 
 simply empty)...and just do:
 
 mvn package
 
 does this work without any problem..?
 
 
 Furthermore could you give more information like the following:
 
 Which Maven version do you use?
 
 Which Maven Plugins do you use in which versions? Where does this 
 problem happen?
 
 From which of your plugins is this message emitted ?
 
 Does this happen every time at the same are or more on coincidence?
 
 BTW: I assume you are using a repository manager ? Which one? In which 
 version?
 
 
 Kind regards
 Karl Heinz Marbaise
 
 On 4/10/15 8:35 PM, Laurence Bordowitz wrote:
 I'm having a problem where building a large multi-module project in parallel 
 causes the dependency resolution to fail:  
 org.apache.maven.lifecycle.LifecycleExecutionException: Failed to execute 
 goal on project [PROJECT]: Could not resolve dependencies for project 
 [company].[groupid].[PROJECT]:[PROJECT]:jar:1.1-SNAPSHOT: Could not find 
 artifact com.jayway.jsonpath:json-path:jar:0.9.1
 
 Normally, the answer to this would be, you didn't set up your repository 
 correctly, check your company's mirrors, etc. However, our builds usually 
 succeed, and all the dependencies resolve. In fact, this only happens in 
 about 10% of the builds, and with different jars (although often the same 
 set of jars). Earlier in the same build where the log line above comes from, 
 we get this message:
 b17:53:20/b [INFO] Downloading: 
 http://[MAVEN-REPO]/proximity/repository/public/com/jayway/jsonpath/json-path/0.9.1/json-path-0.9.1.jar
 b17:53:20/b [INFO] Changes detected - recompiling the module!
 b17:53:20/b [INFO] Compiling 7 source files to 
 [/location/of/different/project]
 b17:53:20/b [INFO]
 b17:53:20/b [INFO] --- maven-clean-plugin:2.6:clean (default-clean) @ 
 [Yet another project] ---
 b17:53:20/b [INFO] Downloaded: 
 http://[MAVEN-REPO]/proximity/repository/public/com/jayway/jsonpath/json-path/0.9.1/json-path-0.9.1.jar
  (93 KB at 11504.3 KB/sec)
 
 Moreover, some dependencies are being downloaded twice. This has led me to 
 the conclusion that there's a race condition happening with dependencies. 
 Two modules, in parallel, detect that a resource is missing. They both 
 download it. Sometime between the opening and use of a dependency resource 
 in one module, another download from a parallel-built module finishes 
 downloading and rewrites the file. Suddenly, the resource is missing!
 Is this right? Has anybody else had this problem? Does anybody know of any 
 workaround? I tried mvn dependency:go-offline, but that requires 
 dependencies that aren't built yet, and its group-id exclusion doesn't work 
 when it's not a plugin.
 
 Here's the stack trace:
 b17:53:20/b org.apache.maven.lifecycle.LifecycleExecutionException: 
 Failed to execute goal on project [PROJECT]: Could not resolve dependencies 
 for project [company].[groupid].[PROJECT]:[PROJECT]:jar:1.1-SNAPSHOT: Could 
 not find artifact com.jayway.jsonpath:json-path:jar:0.9.1
 b17:53:20/bat 
 org.apache.maven.lifecycle.internal.LifecycleDependencyResolver.getDependencies(LifecycleDependencyResolver.java:220)
 b17:53:20/bat 
 org.apache.maven.lifecycle.internal.LifecycleDependencyResolver.resolveProjectDependencies(LifecycleDependencyResolver.java

Re: Plugin dependency resolution from plugin pom?

2015-03-31 Thread Gary Kennedy

The setting used in the original plugin.xml for 
requiresDependencyResolutionString is runtime. I am not changing this when I am 
repackaging the plugin.

Also, it's the plugin dependencies that are not being resolved, not the 
project. (My test project is not using any dependencies)

Cheers,
Gary

On 27 Mar 2015, at 1:16 am, Martin Gainty mgai...@hotmail.com wrote:

 plugin.xml
 requiresDependencyResolution
 
 
 
  String
 
 
 
Flags this Mojo as requiring the dependencies in the specified 
 class path to be resolved before it can
execute: compile, runtime, test,
compile+runtime (since Maven 3.0) or runtime+system (since Maven 
 3.0)
 
 Default value is: runtime.
 https://maven.apache.org/ref/3.2.1/maven-plugin-api/plugin.html
 
 does setting in plugin.xml requiresDependencyResolutionString not force 
 dependencies to be resolved?
 
 for your next run can you display debug info and error info so we can see 
 determine the behaviour of the reactor?
 
 mvn -e -X phase
 
 ?
 Martin 
 
 
 From: g...@apnic.net
 To: users@maven.apache.org
 Subject: Plugin dependency resolution from plugin pom?
 Date: Mon, 23 Mar 2015 22:41:39 +
 
 I'm trying to patch a third-party plugin at the moment as a temporary 
 workaround for a problem. (I don't want to get into details because it's not 
 important)
 
 So I currently have a 'patch project' that depends on the plugin, uses the 
 maven-dependency-plugin to unpack the dependant plugin (without the 
 replacement files), contains the replacement files, does some replacer magic 
 on the extracted plugin.xml to fixup the version/etc, and then package it 
 all.
 
 This all works fine, in that the new project jar is a good content copy of 
 the old plugin with all the changes needed.
 
 However, when using the new plugin, several dependency errors occur. (i.e., 
 the dependencies of the old plugin are not pulled in).
 
 This confused me for a while because the maven plugin.xml file correctly 
 lists all the dependencies. After a bit more playing around I worked out 
 that this is because the plugin dependency resolution comes from the plugins 
 pom.xml and NOT the plugin.xml file.
 
 So my main question for the group is: How/Can I, at build time, add the 
 dependency (and properties, if possible) section from the old plugin pom 
 into my new plugin's artefact pom? (So not the project pom itself, but the 
 one written to the maven repository)
 
 And because I'm curious, does anyone know,
   a) why the plugin.xml contains the dependencies if they are not used?
 or b) why the pom.xml is used instead of the plugin.xml to resolve 
 dependencies? (I suspect aether + coding simplicity for this one)
 
 Cheers,
 Gary
 
 
 -
 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: Plugin dependency resolution from plugin pom?

2015-03-31 Thread Gary Kennedy

Yes, that would be the smarter option, wouldn't it. :$ *bangs head on desk*

I am still curious though as to why the plugin.xml contains a dependency 
section if it's the plugin's pom file that is used for resolution, and/or why 
the pom file is used over the plugin file? The plugin.xml file contains 
everything else regarding the plugin usage, and I think that's throwing me off.

Cheers,
Gary

On 27 Mar 2015, at 1:26 am, Curtis Rueden ctrue...@wisc.edu wrote:

 Hi Gary,
 
 I'm trying to patch a third-party plugin at the moment as a temporary
 workaround for a problem. (I don't want to get into details because
 it's not important)
 
 Since the workaround is temporary, could you not simply clone the plugin's
 SCM repository to a local Git repository, then create a branch with your
 changes? Then rebuild the plugin whenever you like and use it. No need for
 all the hoop-jumping it sounds like you're doing now...
 
 Regards,
 Curtis
 
 On Mon, Mar 23, 2015 at 5:41 PM, Gary Kennedy g...@apnic.net wrote:
 
 I'm trying to patch a third-party plugin at the moment as a temporary
 workaround for a problem. (I don't want to get into details because it's
 not important)
 
 So I currently have a 'patch project' that depends on the plugin, uses the
 maven-dependency-plugin to unpack the dependant plugin (without the
 replacement files), contains the replacement files, does some replacer
 magic on the extracted plugin.xml to fixup the version/etc, and then
 package it all.
 
 This all works fine, in that the new project jar is a good content copy of
 the old plugin with all the changes needed.
 
 However, when using the new plugin, several dependency errors occur.
 (i.e., the dependencies of the old plugin are not pulled in).
 
 This confused me for a while because the maven plugin.xml file correctly
 lists all the dependencies. After a bit more playing around I worked out
 that this is because the plugin dependency resolution comes from the
 plugins pom.xml and NOT the plugin.xml file.
 
 So my main question for the group is: How/Can I, at build time, add the
 dependency (and properties, if possible) section from the old plugin pom
 into my new plugin's artefact pom? (So not the project pom itself, but the
 one written to the maven repository)
 
 And because I'm curious, does anyone know,
   a) why the plugin.xml contains the dependencies if they are not used?
 or b) why the pom.xml is used instead of the plugin.xml to resolve
 dependencies? (I suspect aether + coding simplicity for this one)
 
 Cheers,
 Gary
 
 
 -
 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: Plugin dependency resolution from plugin pom?

2015-03-26 Thread Curtis Rueden

Hi Gary,

 I'm trying to patch a third-party plugin at the moment as a temporary
 workaround for a problem. (I don't want to get into details because
 it's not important)

Since the workaround is temporary, could you not simply clone the plugin's
SCM repository to a local Git repository, then create a branch with your
changes? Then rebuild the plugin whenever you like and use it. No need for
all the hoop-jumping it sounds like you're doing now...

Regards,
Curtis

On Mon, Mar 23, 2015 at 5:41 PM, Gary Kennedy g...@apnic.net wrote:

 I'm trying to patch a third-party plugin at the moment as a temporary
 workaround for a problem. (I don't want to get into details because it's
 not important)

 So I currently have a 'patch project' that depends on the plugin, uses the
 maven-dependency-plugin to unpack the dependant plugin (without the
 replacement files), contains the replacement files, does some replacer
 magic on the extracted plugin.xml to fixup the version/etc, and then
 package it all.

 This all works fine, in that the new project jar is a good content copy of
 the old plugin with all the changes needed.

 However, when using the new plugin, several dependency errors occur.
 (i.e., the dependencies of the old plugin are not pulled in).

 This confused me for a while because the maven plugin.xml file correctly
 lists all the dependencies. After a bit more playing around I worked out
 that this is because the plugin dependency resolution comes from the
 plugins pom.xml and NOT the plugin.xml file.

 So my main question for the group is: How/Can I, at build time, add the
 dependency (and properties, if possible) section from the old plugin pom
 into my new plugin's artefact pom? (So not the project pom itself, but the
 one written to the maven repository)

 And because I'm curious, does anyone know,
a) why the plugin.xml contains the dependencies if they are not used?
 or b) why the pom.xml is used instead of the plugin.xml to resolve
 dependencies? (I suspect aether + coding simplicity for this one)

 Cheers,
 Gary


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

RE: Plugin dependency resolution from plugin pom?

2015-03-26 Thread Martin Gainty

plugin.xml
requiresDependencyResolution



  String



Flags this Mojo as requiring the dependencies in the specified 
class path to be resolved before it can
execute: compile, runtime, test,
compile+runtime (since Maven 3.0) or runtime+system (since Maven 
3.0)
  
Default value is: runtime.
https://maven.apache.org/ref/3.2.1/maven-plugin-api/plugin.html

does setting in plugin.xml requiresDependencyResolutionString not force 
dependencies to be resolved?

for your next run can you display debug info and error info so we can see 
determine the behaviour of the reactor?

mvn -e -X phase

?
Martin 


 From: g...@apnic.net
 To: users@maven.apache.org
 Subject: Plugin dependency resolution from plugin pom?
 Date: Mon, 23 Mar 2015 22:41:39 +
 
 I'm trying to patch a third-party plugin at the moment as a temporary 
 workaround for a problem. (I don't want to get into details because it's not 
 important)
 
 So I currently have a 'patch project' that depends on the plugin, uses the 
 maven-dependency-plugin to unpack the dependant plugin (without the 
 replacement files), contains the replacement files, does some replacer magic 
 on the extracted plugin.xml to fixup the version/etc, and then package it all.
 
 This all works fine, in that the new project jar is a good content copy of 
 the old plugin with all the changes needed.
 
 However, when using the new plugin, several dependency errors occur. (i.e., 
 the dependencies of the old plugin are not pulled in).
 
 This confused me for a while because the maven plugin.xml file correctly 
 lists all the dependencies. After a bit more playing around I worked out that 
 this is because the plugin dependency resolution comes from the plugins 
 pom.xml and NOT the plugin.xml file.
 
 So my main question for the group is: How/Can I, at build time, add the 
 dependency (and properties, if possible) section from the old plugin pom into 
 my new plugin's artefact pom? (So not the project pom itself, but the one 
 written to the maven repository)
 
 And because I'm curious, does anyone know,
a) why the plugin.xml contains the dependencies if they are not used?
 or b) why the pom.xml is used instead of the plugin.xml to resolve 
 dependencies? (I suspect aether + coding simplicity for this one)
 
 Cheers,
 Gary
 
 
 -
 To unsubscribe, e-mail: users-unsubscr...@maven.apache.org
 For additional commands, e-mail: users-h...@maven.apache.org

Plugin dependency resolution from plugin pom?

2015-03-23 Thread Gary Kennedy

I'm trying to patch a third-party plugin at the moment as a temporary 
workaround for a problem. (I don't want to get into details because it's not 
important)

So I currently have a 'patch project' that depends on the plugin, uses the 
maven-dependency-plugin to unpack the dependant plugin (without the replacement 
files), contains the replacement files, does some replacer magic on the 
extracted plugin.xml to fixup the version/etc, and then package it all.

This all works fine, in that the new project jar is a good content copy of the 
old plugin with all the changes needed.

However, when using the new plugin, several dependency errors occur. (i.e., the 
dependencies of the old plugin are not pulled in).

This confused me for a while because the maven plugin.xml file correctly lists 
all the dependencies. After a bit more playing around I worked out that this is 
because the plugin dependency resolution comes from the plugins pom.xml and NOT 
the plugin.xml file.

So my main question for the group is: How/Can I, at build time, add the 
dependency (and properties, if possible) section from the old plugin pom into 
my new plugin's artefact pom? (So not the project pom itself, but the one 
written to the maven repository)

And because I'm curious, does anyone know,
   a) why the plugin.xml contains the dependencies if they are not used?
or b) why the pom.xml is used instead of the plugin.xml to resolve 
dependencies? (I suspect aether + coding simplicity for this one)

Cheers,
Gary


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

Re: Maven phase that runs before dependency resolution

2015-03-11 Thread Manfred Moser

You can do that with a LifecycleParticipant.. the Android Maven Plugin has an
example that works with the dependencies and deals with resolving transitive
dependencies of AAR and APKLIB artifacts.

Check it out at

https://github.com/simpligility/android-maven-plugin/blob/master/src/main/java/com/jayway/maven/plugins/android/phase_prebuild/ClasspathModifierLifecycleParticipant.java

richard_senior wrote on 10.03.2015 09:03:

There is currently no phase in which you can run a plugin that is before
dependency resolution.
I believe this is a problem for Maven.
Imagine I wanted to create a plugin which could be used by the whole
company, and enforced a particular version naming strategy.
So take Spring for example, they are using an RC and RELEASE naming
convention.
Imagine I wanted to allow people to name their artifacts _BRANCH_5.
My plugin with find that and realise that a repository named
'http://blah/blah/BRANCH_5' should be added to the repositories list (before
resolution obviously).
Also, I can now get my plugin to add a different distrubutionManagement
section allowing the artifacts to be deployed to
http://blah/blah/BRANCH_5.

By the simple act of naming artifacts I can now manage multiple workstreams
in my pipeline with ease, and without requiring special settings files or
parent POM's.

While I'm on the subject of Maven deficiencies, why is it not possible to
specify distrubutionManagement in settings?
In fact.. it doesn't matter why... it's wrong.
Sometimes ... just sometimes.. I do believe I might try Gradle.

--
View this message in context:
http://maven.40175.n5.nabble.com/Maven-phase-that-runs-before-dependency-resolution-tp5828729.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: Maven phase that runs before dependency resolution

2015-03-11 Thread Karl Heinz Marbaise

Hi,

On 3/10/15 5:37 PM, Karl Heinz Marbaise wrote:

Hi,

On 3/10/15 5:03 PM, richard_senior wrote:

There is currently no phase in which you can run a plugin that is before
dependency resolution.

I missed a thing completely...

Starting with Maven 3.0.3 there exists the possibility to use an
EventSpy to extend Maven (it's not a plugin correct) but would solve
exactly your needs...

http://maven.apache.org/ref/3.0.3/maven-core/apidocs/org/apache/maven/eventspy/EventSpy.html

In the newest Maven version (3.3.0??)
http://jira.codehaus.org/browse/MNG-5771 there is more convinient way to
add extensions...

Hm...The question is what exactly would you like to solve?

I believe this is a problem for Maven.

Not really..there are some very rare special circumstances...which might
be improved...

Imagine I wanted to create a plugin which could be used by the whole
company, and enforced a particular version naming strategy.

If you really want to force a whole company the correct location would
be the repository manager and not the build tool...cause everything will
be deployed to the repository...

The naming rules can be supported by some kind of plugin for your build
tools (whatever build tool you use)...In Maven sounds like a job for
maven-enforcer...(creating your own rule) or using the existing ones...

So take Spring for example, they are using an RC and RELEASE naming
convention.

It can also being handled just simply by doing release via CI solution
which does not allow to change the versions and follow a particular rule
set...(automation is the keyword).

Imagine I wanted to allow people to name their artifacts _BRANCH_5.

What do you exactly mean? Are we talking about groupId, artifactId,
version (classifiers etc.) ?

In a corporate environment they are not allowed to do what they like
they have to follow rules (as defined)...

My plugin with find that and realise that a repository named
'http://blah/blah/BRANCH_5' should be added to the repositories list
(before
resolution obviously).

Now you are talking about repositories? Something completely different...

Also, I can now get my plugin to add a different distrubutionManagement
section allowing the artifacts to be deployed to
http://blah/blah/BRANCH_5.

In a corporate environment having different repositories will cause many
headaches...and has no benefit instead of a single repository (despite
the fact of SNAPSHOT/Releases etc.)...

Apart from that you can define some properties in distributionManagment
which can be defined on command line...and defaults can be picked up
from settings.xml file (on CI)

By the simple act of naming artifacts I can now manage multiple
workstreams
in my pipeline with ease, and without requiring special settings files or
parent POM's.

What kind of things are you talking ?
Can you give an example?

Branches?

While I'm on the subject of Maven deficiencies, why is it not possible to
specify distrubutionManagement in settings?

Cause it's defined (xsd http://maven.apache.org/xsd/settings-1.0.0.xsd)
that way...if it's a good idea that's a different story...It might
belong into the settings.xml on the first glance..but settings.xml is
also not the best idea...see http://jira.codehaus.org/browse/MNG-5657

Furthermore there are differences between project and system
configuration parts...

And currently i see distributionManagement as project parts...which can
be defined in a corporate parent pom

In fact.. it doesn't matter why... it's wrong.

In some rare situations it looks like being wrong

Sometimes ... just sometimes.. I do believe I might try Gradle.

Just try Gradle...but not all that glitters is gold...

So the conclusion of your post?

Kind regards
Karl Heinz Marbaise

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

Re: Maven phase that runs before dependency resolution

2015-03-10 Thread Karl Heinz Marbaise


Hi,

On 3/10/15 5:03 PM, richard_senior wrote:

There is currently no phase in which you can run a plugin that is before
dependency resolution.


Hm...The question is what exactly would you like to solve?


I believe this is a problem for Maven.


Not really..there are some very rare special circumstances...which might 
be improved...



Imagine I wanted to create a plugin which could be used by the whole
company, and enforced a particular version naming strategy.


If you really want to force a whole company the correct location would 
be the repository manager and not the build tool...cause everything will 
be deployed to the repository...


The naming rules can be supported by some kind of plugin for your build 
tools (whatever build tool you use)...In Maven sounds like a job for 
maven-enforcer...(creating your own rule) or using the existing ones...



So take Spring for example, they are using an RC and RELEASE naming
convention.


It can also being handled just simply by doing release via CI solution 
which does not allow to change the versions and follow a particular rule 
set...(automation is the keyword).



Imagine I wanted to allow people to name their artifacts _BRANCH_5.
What do you exactly mean? Are we talking about groupId, artifactId, 
version (classifiers etc.) ?


In a corporate environment they are not allowed to do what they like 
they have to follow rules (as defined)...



My plugin with find that and realise that a repository named
'http://blah/blah/BRANCH_5' should be added to the repositories list (before
resolution obviously).


Now you are talking about repositories? Something completely different...


Also, I can now get my plugin to add a different distrubutionManagement
section allowing the artifacts to be deployed to
http://blah/blah/BRANCH_5.


In a corporate environment having different repositories will cause many 
headaches...and has no benefit instead of a single repository (despite 
the fact of SNAPSHOT/Releases etc.)...


Apart from that you can define some properties in distributionManagment 
which can be defined on command line...and defaults can be picked up 
from settings.xml file (on CI)




By the simple act of naming artifacts I can now manage multiple workstreams
in my pipeline with ease, and without requiring special settings files or
parent POM's.


What kind of things are you talking ?
Can you give an example?

Branches?



While I'm on the subject of Maven deficiencies, why is it not possible to
specify distrubutionManagement in settings?


Cause it's defined (xsd http://maven.apache.org/xsd/settings-1.0.0.xsd) 
that way...if it's a good idea that's a different story...It might 
belong into the settings.xml on the first glance..but settings.xml is 
also not the best idea...see http://jira.codehaus.org/browse/MNG-5657


Furthermore there are differences between project and system 
configuration parts...


And currently i see distributionManagement as project parts...which can 
be defined in a corporate parent pom



In fact.. it doesn't matter why... it's wrong.


In some rare situations it looks like being wrong


Sometimes ... just sometimes.. I do believe I might try Gradle.


Just try Gradle...but not all that glitters is gold...

So the conclusion of your post?

Kind regards
Karl Heinz Marbaise

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

Maven phase that runs before dependency resolution

2015-03-10 Thread richard_senior

There is currently no phase in which you can run a plugin that is before
dependency resolution.
I believe this is a problem for Maven.
Imagine I wanted to create a plugin which could be used by the whole
company, and enforced a particular version naming strategy.
So take Spring for example, they are using an RC and RELEASE naming
convention.
Imagine I wanted to allow people to name their artifacts _BRANCH_5.
My plugin with find that and realise that a repository named
'http://blah/blah/BRANCH_5' should be added to the repositories list (before
resolution obviously).
Also, I can now get my plugin to add a different distrubutionManagement
section allowing the artifacts to be deployed to
http://blah/blah/BRANCH_5.

By the simple act of naming artifacts I can now manage multiple workstreams
in my pipeline with ease, and without requiring special settings files or
parent POM's.

While I'm on the subject of Maven deficiencies, why is it not possible to
specify distrubutionManagement in settings?
In fact.. it doesn't matter why... it's wrong.
Sometimes ... just sometimes.. I do believe I might try Gradle.



--
View this message in context: 
http://maven.40175.n5.nabble.com/Maven-phase-that-runs-before-dependency-resolution-tp5828729.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: Dependency resolution kicks in too early

2013-02-14 Thread Reinhard Nägele

I don't think it is a good idea to pollute Maven Central with this 
artifact under a different groupId.


Reinhard

Am 13.02.2013 17:09, schrieb Stephen Connolly:

Yes, I agree, but I have had to do it myself some times... in more radical
cases this has evolved into a complete fork for me (e.g. redmine-java-api)


On 13 February 2013 15:33, Anders Hammar and...@hammar.net wrote:


Right, I was thinking they would deploy it to their Nexus instance where
they deploy their own oss product.
Having the same jar in two different groupIds in central only confuses
people and causes problems I think. We should try to avoid that.

/Anders


On Wed, Feb 13, 2013 at 4:27 PM, Stephen Connolly 
stephen.alan.conno...@gmail.com wrote:


On 13 February 2013 15:19, Anders Hammar and...@hammar.net wrote:


deploy it to your own groupId


Isn't it better if he uses the original groupId and artifactId, but

adds

a

qualifier to the version indicating that it's their release?


Well... the chain you have to go when deploying something into central
under a groupId that you do not own is something like:

1. Show that you have engaged the owning project and that they are not
pushing a version
2. Show blah blah blah
3.
4.
5. Ok, create the bundle and upload it

And given that he said the owning project is working on uploading to
central, he's going to fail on step 1... so if it is urgent the lesser

evil

is his own groupId...

That said it would be best to keep the groupId it will end up with.



Like if he
would have patched an official release.

/Anders




On 13 February 2013 14:54, Reinhard Nägele 

reinhard.naeg...@mgm-tp.com

wrote:
Normally, I'd deploy it to our Nexus. But in this case, this is not
possible. We are open-sourcing one of our products and need a

third-party

dependency which is not yet available on Maven Central. We are

working

with

the developer of the library to fix this, but until this is the

case,

we

need a temporary solution.

Reinhard


Am 11.02.2013 15:27, schrieb Ron Wheeler:

  Why not just load these stray orphans into your MRM once and then

treat

them and normal dependencies.

Ron

On 11/02/2013 4:17 AM, Reinhard Nägele wrote:


Hello,

A couple of years ago I used a plugin execution in the validate

phase

to

bootstrap jars that were not available on Maven Central as

suggested

in

[1]. I needed to do the same thing again today but noticed that

this

approach does not seem to work any more with Maven 3. Right after

running

Maven, dependency resolution kicks in making the build fail even

before the

install plugin gets a chance to install the missing dependency.

Here's

what

I'm doing:

plugin
   groupIdorg.apache.maven.**plugins/groupId
   artifactIdmaven-install-**plugin/artifactId
   executions
 execution
   idboostrap-some-depencency/**id
   goals
 goalinstall-file/goal
   /goals
   phasevalidate/phase
   configuration
 groupIdcom.some.groupid/**groupId
 artifactIdsome-artifact/**artifactId
 version${some.artifact.**version}/version
 packagingjar/packaging
filebootstrap-lib/some-**artifact-${some.artifact.**
version}.jar/file


sourcesbootstrap-lib/some-**artifact-${some.artifact.**version}-sources.jar/sources

   /configuration
 /execution
   /executions
/plugin
...
dependency
   groupIdcom.some.groupid/**groupId
   artifactIdsome-artifact/**artifactId
   version${some.artifact.**version}/version
/dependency
...
properties
some.artifact.version1.2.3/**some.artifact.version
/properties

[1] http://www.blackbit.be/2010/**04/15/maven-automatically-**
install-dependencies-during-**build/

http://www.blackbit.be/2010/04/15/maven-automatically-install-dependencies-during-build/

Is this no longer possible? I'd really prefer this approach over

using

a

system dependency.

Thanks,
Reinhard


--**--**
-
To unsubscribe, e-mail: users-unsubscribe@maven.**apache.org

users-unsubscr...@maven.apache.org

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








--**--**-

To unsubscribe, e-mail: users-unsubscribe@maven.**apache.org

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: Dependency resolution kicks in too early

2013-02-14 Thread Stephen Connolly

, Reinhard Nägele wrote:

  Hello,

 A couple of years ago I used a plugin execution in the validate

 phase

 to

 bootstrap jars that were not available on Maven Central as

 suggested

 in

 [1]. I needed to do the same thing again today but noticed that

 this

 approach does not seem to work any more with Maven 3. Right after

 running

 Maven, dependency resolution kicks in making the build fail even

 before the

 install plugin gets a chance to install the missing dependency.

 Here's

 what

 I'm doing:

 plugin
groupIdorg.apache.maven.plugins/groupId
artifactIdmaven-install-plugin/artifactId
executions
  execution
idboostrap-some-depencency/id
goals
  goalinstall-file/goal
/goals
phasevalidate/phase
configuration
  groupIdcom.some.groupid/groupId
  artifactIdsome-artifact/artifactId
  version${some.artifact.version}/version
  packagingjar/packaging
 filebootstrap-lib/some-artifact-${some.artifact.**
 version}.jar/file

  sourcesbootstrap-lib/some-artifact-${some.artifact.
 version}-sources.jar/sources

/configuration
  /execution
/executions
 /plugin
 ...
 dependency
groupIdcom.some.groupid/groupId
artifactIdsome-artifact/artifactId
version${some.artifact.version}/version
 /dependency
 ...
 properties
 some.artifact.version1.2.3/some.artifact.version
 /properties

 [1] 
 http://www.blackbit.be/2010/04/15/maven-automatically-**http://www.blackbit.be/2010/**04/15/maven-automatically-**
 install-dependencies-during-build/

 http://www.blackbit.be/2010/**04/15/maven-automatically-**
 install-dependencies-during-**build/http://www.blackbit.be/2010/04/15/maven-automatically-install-dependencies-during-build/

 Is this no longer possible? I'd really prefer this approach over

 using

 a

 system dependency.

 Thanks,
 Reinhard


 --**
 --**
 -
 To unsubscribe, e-mail: 
 users-unsubscribe@maven.**apac**he.orghttp://apache.org
 

 users-unsubscribe@maven.**apache.orgusers-unsubscr...@maven.apache.org
 

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





  --**
 --**-

 To unsubscribe, e-mail: 
 users-unsubscribe@maven.**apac**he.orghttp://apache.org
 

 users-unsubscribe@maven.**apache.orgusers-unsubscr...@maven.apache.org
 

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




 --**--**-
 To unsubscribe, e-mail: 
 users-unsubscribe@maven.**apache.orgusers-unsubscr...@maven.apache.org

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

Re: Dependency resolution kicks in too early

2013-02-13 Thread Reinhard Nägele

Normally, I'd deploy it to our Nexus. But in this case, this is not 
possible. We are open-sourcing one of our products and need a 
third-party dependency which is not yet available on Maven Central. We 
are working with the developer of the library to fix this, but until 
this is the case, we need a temporary solution.


Reinhard


Am 11.02.2013 15:27, schrieb Ron Wheeler:
Why not just load these stray orphans into your MRM once and then 
treat them and normal dependencies.


Ron

On 11/02/2013 4:17 AM, Reinhard Nägele wrote:

Hello,

A couple of years ago I used a plugin execution in the validate phase 
to bootstrap jars that were not available on Maven Central as 
suggested in [1]. I needed to do the same thing again today but 
noticed that this approach does not seem to work any more with Maven 
3. Right after running Maven, dependency resolution kicks in making 
the build fail even before the install plugin gets a chance to 
install the missing dependency. Here's what I'm doing:


plugin
  groupIdorg.apache.maven.plugins/groupId
  artifactIdmaven-install-plugin/artifactId
  executions
execution
  idboostrap-some-depencency/id
  goals
goalinstall-file/goal
  /goals
  phasevalidate/phase
  configuration
groupIdcom.some.groupid/groupId
artifactIdsome-artifact/artifactId
version${some.artifact.version}/version
packagingjar/packaging
filebootstrap-lib/some-artifact-${some.artifact.version}.jar/file
sourcesbootstrap-lib/some-artifact-${some.artifact.version}-sources.jar/sources 


  /configuration
/execution
  /executions
/plugin
...
dependency
  groupIdcom.some.groupid/groupId
  artifactIdsome-artifact/artifactId
  version${some.artifact.version}/version
/dependency
...
properties
some.artifact.version1.2.3/some.artifact.version
/properties

[1] 
http://www.blackbit.be/2010/04/15/maven-automatically-install-dependencies-during-build/


Is this no longer possible? I'd really prefer this approach over 
using a system dependency.


Thanks,
Reinhard


-
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: Dependency resolution kicks in too early

2013-02-13 Thread Stephen Connolly

deploy it to your own groupId


On 13 February 2013 14:54, Reinhard Nägele reinhard.naeg...@mgm-tp.comwrote:

 Normally, I'd deploy it to our Nexus. But in this case, this is not
 possible. We are open-sourcing one of our products and need a third-party
 dependency which is not yet available on Maven Central. We are working with
 the developer of the library to fix this, but until this is the case, we
 need a temporary solution.

 Reinhard


 Am 11.02.2013 15:27, schrieb Ron Wheeler:

  Why not just load these stray orphans into your MRM once and then treat
 them and normal dependencies.

 Ron

 On 11/02/2013 4:17 AM, Reinhard Nägele wrote:

 Hello,

 A couple of years ago I used a plugin execution in the validate phase to
 bootstrap jars that were not available on Maven Central as suggested in
 [1]. I needed to do the same thing again today but noticed that this
 approach does not seem to work any more with Maven 3. Right after running
 Maven, dependency resolution kicks in making the build fail even before the
 install plugin gets a chance to install the missing dependency. Here's what
 I'm doing:

 plugin
   groupIdorg.apache.maven.**plugins/groupId
   artifactIdmaven-install-**plugin/artifactId
   executions
 execution
   idboostrap-some-depencency/**id
   goals
 goalinstall-file/goal
   /goals
   phasevalidate/phase
   configuration
 groupIdcom.some.groupid/**groupId
 artifactIdsome-artifact/**artifactId
 version${some.artifact.**version}/version
 packagingjar/packaging
 filebootstrap-lib/some-**artifact-${some.artifact.**
 version}.jar/file
 sourcesbootstrap-lib/some-**artifact-${some.artifact.**version}-sources.jar/sources

   /configuration
 /execution
   /executions
 /plugin
 ...
 dependency
   groupIdcom.some.groupid/**groupId
   artifactIdsome-artifact/**artifactId
   version${some.artifact.**version}/version
 /dependency
 ...
 properties
 some.artifact.version1.2.3/**some.artifact.version
 /properties

 [1] http://www.blackbit.be/2010/**04/15/maven-automatically-**
 install-dependencies-during-**build/http://www.blackbit.be/2010/04/15/maven-automatically-install-dependencies-during-build/

 Is this no longer possible? I'd really prefer this approach over using a
 system dependency.

 Thanks,
 Reinhard


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






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

Re: Dependency resolution kicks in too early

2013-02-13 Thread Anders Hammar

 deploy it to your own groupId


Isn't it better if he uses the original groupId and artifactId, but adds a
qualifier to the version indicating that it's their release? Like if he
would have patched an official release.

/Anders




 On 13 February 2013 14:54, Reinhard Nägele reinhard.naeg...@mgm-tp.com
 wrote:

  Normally, I'd deploy it to our Nexus. But in this case, this is not
  possible. We are open-sourcing one of our products and need a third-party
  dependency which is not yet available on Maven Central. We are working
 with
  the developer of the library to fix this, but until this is the case, we
  need a temporary solution.
 
  Reinhard
 
 
  Am 11.02.2013 15:27, schrieb Ron Wheeler:
 
   Why not just load these stray orphans into your MRM once and then treat
  them and normal dependencies.
 
  Ron
 
  On 11/02/2013 4:17 AM, Reinhard Nägele wrote:
 
  Hello,
 
  A couple of years ago I used a plugin execution in the validate phase
 to
  bootstrap jars that were not available on Maven Central as suggested in
  [1]. I needed to do the same thing again today but noticed that this
  approach does not seem to work any more with Maven 3. Right after
 running
  Maven, dependency resolution kicks in making the build fail even
 before the
  install plugin gets a chance to install the missing dependency. Here's
 what
  I'm doing:
 
  plugin
groupIdorg.apache.maven.**plugins/groupId
artifactIdmaven-install-**plugin/artifactId
executions
  execution
idboostrap-some-depencency/**id
goals
  goalinstall-file/goal
/goals
phasevalidate/phase
configuration
  groupIdcom.some.groupid/**groupId
  artifactIdsome-artifact/**artifactId
  version${some.artifact.**version}/version
  packagingjar/packaging
  filebootstrap-lib/some-**artifact-${some.artifact.**
  version}.jar/file
 
 sourcesbootstrap-lib/some-**artifact-${some.artifact.**version}-sources.jar/sources
 
/configuration
  /execution
/executions
  /plugin
  ...
  dependency
groupIdcom.some.groupid/**groupId
artifactIdsome-artifact/**artifactId
version${some.artifact.**version}/version
  /dependency
  ...
  properties
  some.artifact.version1.2.3/**some.artifact.version
  /properties
 
  [1] http://www.blackbit.be/2010/**04/15/maven-automatically-**
  install-dependencies-during-**build/
 http://www.blackbit.be/2010/04/15/maven-automatically-install-dependencies-during-build/
 
 
  Is this no longer possible? I'd really prefer this approach over using
 a
  system dependency.
 
  Thanks,
  Reinhard
 
 
  --**--**
  -
  To unsubscribe, e-mail: users-unsubscribe@maven.**apache.org
 users-unsubscr...@maven.apache.org
  For additional commands, e-mail: users-h...@maven.apache.org
 
 
 
 
 
 
  --**--**-
  To unsubscribe, e-mail: users-unsubscribe@maven.**apache.org
 users-unsubscr...@maven.apache.org
  For additional commands, e-mail: users-h...@maven.apache.org

Re: Dependency resolution kicks in too early

2013-02-13 Thread Stephen Connolly

On 13 February 2013 15:19, Anders Hammar and...@hammar.net wrote:

  deploy it to your own groupId
 

 Isn't it better if he uses the original groupId and artifactId, but adds a
 qualifier to the version indicating that it's their release?


Well... the chain you have to go when deploying something into central
under a groupId that you do not own is something like:

1. Show that you have engaged the owning project and that they are not
pushing a version
2. Show blah blah blah
3.
4.
5. Ok, create the bundle and upload it

And given that he said the owning project is working on uploading to
central, he's going to fail on step 1... so if it is urgent the lesser evil
is his own groupId...

That said it would be best to keep the groupId it will end up with.


 Like if he
 would have patched an official release.

 /Anders


 
 
  On 13 February 2013 14:54, Reinhard Nägele reinhard.naeg...@mgm-tp.com
  wrote:
 
   Normally, I'd deploy it to our Nexus. But in this case, this is not
   possible. We are open-sourcing one of our products and need a
 third-party
   dependency which is not yet available on Maven Central. We are working
  with
   the developer of the library to fix this, but until this is the case,
 we
   need a temporary solution.
  
   Reinhard
  
  
   Am 11.02.2013 15:27, schrieb Ron Wheeler:
  
Why not just load these stray orphans into your MRM once and then
 treat
   them and normal dependencies.
  
   Ron
  
   On 11/02/2013 4:17 AM, Reinhard Nägele wrote:
  
   Hello,
  
   A couple of years ago I used a plugin execution in the validate phase
  to
   bootstrap jars that were not available on Maven Central as suggested
 in
   [1]. I needed to do the same thing again today but noticed that this
   approach does not seem to work any more with Maven 3. Right after
  running
   Maven, dependency resolution kicks in making the build fail even
  before the
   install plugin gets a chance to install the missing dependency.
 Here's
  what
   I'm doing:
  
   plugin
 groupIdorg.apache.maven.**plugins/groupId
 artifactIdmaven-install-**plugin/artifactId
 executions
   execution
 idboostrap-some-depencency/**id
 goals
   goalinstall-file/goal
 /goals
 phasevalidate/phase
 configuration
   groupIdcom.some.groupid/**groupId
   artifactIdsome-artifact/**artifactId
   version${some.artifact.**version}/version
   packagingjar/packaging
   filebootstrap-lib/some-**artifact-${some.artifact.**
   version}.jar/file
  
 
 sourcesbootstrap-lib/some-**artifact-${some.artifact.**version}-sources.jar/sources
  
 /configuration
   /execution
 /executions
   /plugin
   ...
   dependency
 groupIdcom.some.groupid/**groupId
 artifactIdsome-artifact/**artifactId
 version${some.artifact.**version}/version
   /dependency
   ...
   properties
   some.artifact.version1.2.3/**some.artifact.version
   /properties
  
   [1] http://www.blackbit.be/2010/**04/15/maven-automatically-**
   install-dependencies-during-**build/
 
 http://www.blackbit.be/2010/04/15/maven-automatically-install-dependencies-during-build/
  
  
   Is this no longer possible? I'd really prefer this approach over
 using
  a
   system dependency.
  
   Thanks,
   Reinhard
  
  
   --**--**
   -
   To unsubscribe, e-mail: users-unsubscribe@maven.**apache.org
  users-unsubscr...@maven.apache.org
   For additional commands, e-mail: users-h...@maven.apache.org
  
  
  
  
  
  
  
 --**--**-
   To unsubscribe, e-mail: users-unsubscribe@maven.**apache.org
  users-unsubscr...@maven.apache.org
   For additional commands, e-mail: users-h...@maven.apache.org

Re: Dependency resolution kicks in too early

2013-02-13 Thread Anders Hammar

Right, I was thinking they would deploy it to their Nexus instance where
they deploy their own oss product.
Having the same jar in two different groupIds in central only confuses
people and causes problems I think. We should try to avoid that.

/Anders


On Wed, Feb 13, 2013 at 4:27 PM, Stephen Connolly 
stephen.alan.conno...@gmail.com wrote:

 On 13 February 2013 15:19, Anders Hammar and...@hammar.net wrote:

   deploy it to your own groupId
  
 
  Isn't it better if he uses the original groupId and artifactId, but adds
 a
  qualifier to the version indicating that it's their release?


 Well... the chain you have to go when deploying something into central
 under a groupId that you do not own is something like:

 1. Show that you have engaged the owning project and that they are not
 pushing a version
 2. Show blah blah blah
 3.
 4.
 5. Ok, create the bundle and upload it

 And given that he said the owning project is working on uploading to
 central, he's going to fail on step 1... so if it is urgent the lesser evil
 is his own groupId...

 That said it would be best to keep the groupId it will end up with.


  Like if he
  would have patched an official release.
 
  /Anders
 
 
  
  
   On 13 February 2013 14:54, Reinhard Nägele 
 reinhard.naeg...@mgm-tp.com
   wrote:
  
Normally, I'd deploy it to our Nexus. But in this case, this is not
possible. We are open-sourcing one of our products and need a
  third-party
dependency which is not yet available on Maven Central. We are
 working
   with
the developer of the library to fix this, but until this is the case,
  we
need a temporary solution.
   
Reinhard
   
   
Am 11.02.2013 15:27, schrieb Ron Wheeler:
   
 Why not just load these stray orphans into your MRM once and then
  treat
them and normal dependencies.
   
Ron
   
On 11/02/2013 4:17 AM, Reinhard Nägele wrote:
   
Hello,
   
A couple of years ago I used a plugin execution in the validate
 phase
   to
bootstrap jars that were not available on Maven Central as
 suggested
  in
[1]. I needed to do the same thing again today but noticed that
 this
approach does not seem to work any more with Maven 3. Right after
   running
Maven, dependency resolution kicks in making the build fail even
   before the
install plugin gets a chance to install the missing dependency.
  Here's
   what
I'm doing:
   
plugin
  groupIdorg.apache.maven.**plugins/groupId
  artifactIdmaven-install-**plugin/artifactId
  executions
execution
  idboostrap-some-depencency/**id
  goals
goalinstall-file/goal
  /goals
  phasevalidate/phase
  configuration
groupIdcom.some.groupid/**groupId
artifactIdsome-artifact/**artifactId
version${some.artifact.**version}/version
packagingjar/packaging
filebootstrap-lib/some-**artifact-${some.artifact.**
version}.jar/file
   
  
 
 sourcesbootstrap-lib/some-**artifact-${some.artifact.**version}-sources.jar/sources
   
  /configuration
/execution
  /executions
/plugin
...
dependency
  groupIdcom.some.groupid/**groupId
  artifactIdsome-artifact/**artifactId
  version${some.artifact.**version}/version
/dependency
...
properties
some.artifact.version1.2.3/**some.artifact.version
/properties
   
[1] http://www.blackbit.be/2010/**04/15/maven-automatically-**
install-dependencies-during-**build/
  
 
 http://www.blackbit.be/2010/04/15/maven-automatically-install-dependencies-during-build/
   
   
Is this no longer possible? I'd really prefer this approach over
  using
   a
system dependency.
   
Thanks,
Reinhard
   
   
--**--**
-
To unsubscribe, e-mail: users-unsubscribe@maven.**apache.org
   users-unsubscr...@maven.apache.org
For additional commands, e-mail: users-h...@maven.apache.org
   
   
   
   
   
   
   
  --**--**-
To unsubscribe, e-mail: users-unsubscribe@maven.**apache.org
   users-unsubscr...@maven.apache.org
For additional commands, e-mail: users-h...@maven.apache.org

Re: Dependency resolution kicks in too early

2013-02-13 Thread Stephen Connolly

Yes, I agree, but I have had to do it myself some times... in more radical
cases this has evolved into a complete fork for me (e.g. redmine-java-api)


On 13 February 2013 15:33, Anders Hammar and...@hammar.net wrote:

 Right, I was thinking they would deploy it to their Nexus instance where
 they deploy their own oss product.
 Having the same jar in two different groupIds in central only confuses
 people and causes problems I think. We should try to avoid that.

 /Anders


 On Wed, Feb 13, 2013 at 4:27 PM, Stephen Connolly 
 stephen.alan.conno...@gmail.com wrote:

  On 13 February 2013 15:19, Anders Hammar and...@hammar.net wrote:
 
deploy it to your own groupId
   
  
   Isn't it better if he uses the original groupId and artifactId, but
 adds
  a
   qualifier to the version indicating that it's their release?
 
 
  Well... the chain you have to go when deploying something into central
  under a groupId that you do not own is something like:
 
  1. Show that you have engaged the owning project and that they are not
  pushing a version
  2. Show blah blah blah
  3.
  4.
  5. Ok, create the bundle and upload it
 
  And given that he said the owning project is working on uploading to
  central, he's going to fail on step 1... so if it is urgent the lesser
 evil
  is his own groupId...
 
  That said it would be best to keep the groupId it will end up with.
 
 
   Like if he
   would have patched an official release.
  
   /Anders
  
  
   
   
On 13 February 2013 14:54, Reinhard Nägele 
  reinhard.naeg...@mgm-tp.com
wrote:
   
 Normally, I'd deploy it to our Nexus. But in this case, this is not
 possible. We are open-sourcing one of our products and need a
   third-party
 dependency which is not yet available on Maven Central. We are
  working
with
 the developer of the library to fix this, but until this is the
 case,
   we
 need a temporary solution.

 Reinhard


 Am 11.02.2013 15:27, schrieb Ron Wheeler:

  Why not just load these stray orphans into your MRM once and then
   treat
 them and normal dependencies.

 Ron

 On 11/02/2013 4:17 AM, Reinhard Nägele wrote:

 Hello,

 A couple of years ago I used a plugin execution in the validate
  phase
to
 bootstrap jars that were not available on Maven Central as
  suggested
   in
 [1]. I needed to do the same thing again today but noticed that
  this
 approach does not seem to work any more with Maven 3. Right after
running
 Maven, dependency resolution kicks in making the build fail even
before the
 install plugin gets a chance to install the missing dependency.
   Here's
what
 I'm doing:

 plugin
   groupIdorg.apache.maven.**plugins/groupId
   artifactIdmaven-install-**plugin/artifactId
   executions
 execution
   idboostrap-some-depencency/**id
   goals
 goalinstall-file/goal
   /goals
   phasevalidate/phase
   configuration
 groupIdcom.some.groupid/**groupId
 artifactIdsome-artifact/**artifactId
 version${some.artifact.**version}/version
 packagingjar/packaging
 filebootstrap-lib/some-**artifact-${some.artifact.**
 version}.jar/file

   
  
 
 sourcesbootstrap-lib/some-**artifact-${some.artifact.**version}-sources.jar/sources

   /configuration
 /execution
   /executions
 /plugin
 ...
 dependency
   groupIdcom.some.groupid/**groupId
   artifactIdsome-artifact/**artifactId
   version${some.artifact.**version}/version
 /dependency
 ...
 properties
 some.artifact.version1.2.3/**some.artifact.version
 /properties

 [1] http://www.blackbit.be/2010/**04/15/maven-automatically-**
 install-dependencies-during-**build/
   
  
 
 http://www.blackbit.be/2010/04/15/maven-automatically-install-dependencies-during-build/


 Is this no longer possible? I'd really prefer this approach over
   using
a
 system dependency.

 Thanks,
 Reinhard


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







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

Dependency resolution kicks in too early

2013-02-11 Thread Reinhard Nägele


Hello,

A couple of years ago I used a plugin execution in the validate phase to 
bootstrap jars that were not available on Maven Central as suggested in 
[1]. I needed to do the same thing again today but noticed that this 
approach does not seem to work any more with Maven 3. Right after 
running Maven, dependency resolution kicks in making the build fail even 
before the install plugin gets a chance to install the missing 
dependency. Here's what I'm doing:


plugin
  groupIdorg.apache.maven.plugins/groupId
  artifactIdmaven-install-plugin/artifactId
  executions
execution
  idboostrap-some-depencency/id
  goals
goalinstall-file/goal
  /goals
  phasevalidate/phase
  configuration
groupIdcom.some.groupid/groupId
artifactIdsome-artifact/artifactId
version${some.artifact.version}/version
packagingjar/packaging
filebootstrap-lib/some-artifact-${some.artifact.version}.jar/file
sourcesbootstrap-lib/some-artifact-${some.artifact.version}-sources.jar/sources
  /configuration
/execution
  /executions
/plugin
...
dependency
  groupIdcom.some.groupid/groupId
  artifactIdsome-artifact/artifactId
  version${some.artifact.version}/version
/dependency
...
properties
  some.artifact.version1.2.3/some.artifact.version
/properties

[1] 
http://www.blackbit.be/2010/04/15/maven-automatically-install-dependencies-during-build/


Is this no longer possible? I'd really prefer this approach over using a 
system dependency.


Thanks,
Reinhard


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

Re: Dependency resolution kicks in too early

2013-02-11 Thread Ron Wheeler

Why not just load these stray orphans into your MRM once and then treat 
them and normal dependencies.


Ron

On 11/02/2013 4:17 AM, Reinhard Nägele wrote:

Hello,

A couple of years ago I used a plugin execution in the validate phase 
to bootstrap jars that were not available on Maven Central as 
suggested in [1]. I needed to do the same thing again today but 
noticed that this approach does not seem to work any more with Maven 
3. Right after running Maven, dependency resolution kicks in making 
the build fail even before the install plugin gets a chance to install 
the missing dependency. Here's what I'm doing:


plugin
  groupIdorg.apache.maven.plugins/groupId
  artifactIdmaven-install-plugin/artifactId
  executions
execution
  idboostrap-some-depencency/id
  goals
goalinstall-file/goal
  /goals
  phasevalidate/phase
  configuration
groupIdcom.some.groupid/groupId
artifactIdsome-artifact/artifactId
version${some.artifact.version}/version
packagingjar/packaging
filebootstrap-lib/some-artifact-${some.artifact.version}.jar/file
sourcesbootstrap-lib/some-artifact-${some.artifact.version}-sources.jar/sources 


  /configuration
/execution
  /executions
/plugin
...
dependency
  groupIdcom.some.groupid/groupId
  artifactIdsome-artifact/artifactId
  version${some.artifact.version}/version
/dependency
...
properties
  some.artifact.version1.2.3/some.artifact.version
/properties

[1] 
http://www.blackbit.be/2010/04/15/maven-automatically-install-dependencies-during-build/


Is this no longer possible? I'd really prefer this approach over using 
a system dependency.


Thanks,
Reinhard


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





--
Ron Wheeler
President
Artifact Software Inc
email: rwhee...@artifact-software.com
skype: ronaldmwheeler
phone: 866-970-2435, ext 102


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

Re: Dependency resolution kicks in too early

2013-02-11 Thread Baptiste MATHUS

+1.
The right approach is to use a MRM.
You were unlucky to find an article that is actually more a quite dirty
hack than a solution.

You shouldn't put dependencies inside your SCM.
Put those dependencies once into the maven repository manager, and be happy
with a clean and simple build.

Cheers

2013/2/11 Ron Wheeler rwhee...@artifact-software.com

Why not just load these stray orphans into your MRM once and then treat
them and normal dependencies.

Ron

On 11/02/2013 4:17 AM, Reinhard Nägele wrote:

Hello,

A couple of years ago I used a plugin execution in the validate phase to
bootstrap jars that were not available on Maven Central as suggested in
[1]. I needed to do the same thing again today but noticed that this
approach does not seem to work any more with Maven 3. Right after running
Maven, dependency resolution kicks in making the build fail even before the
install plugin gets a chance to install the missing dependency. Here's what
I'm doing:

plugin
groupIdorg.apache.maven.**plugins/groupId
artifactIdmaven-install-**plugin/artifactId
executions
execution
idboostrap-some-depencency/**id
goals
goalinstall-file/goal
/goals
phasevalidate/phase
configuration
groupIdcom.some.groupid/**groupId
artifactIdsome-artifact/**artifactId
version${some.artifact.**version}/version
packagingjar/packaging
filebootstrap-lib/some-**artifact-${some.artifact.**version}.jar/file
sourcesbootstrap-lib/some-**artifact-${some.artifact.**version}-sources.jar/sources

/configuration
/execution
/executions
/plugin
...
dependency
groupIdcom.some.groupid/**groupId
artifactIdsome-artifact/**artifactId
version${some.artifact.**version}/version
/dependency
...
properties
some.artifact.version1.2.3/**some.artifact.version
/properties

[1] http://www.blackbit.be/2010/**04/15/maven-automatically-**
install-dependencies-during-**build/http://www.blackbit.be/2010/04/15/maven-automatically-install-dependencies-during-build/

Is this no longer possible? I'd really prefer this approach over using a
system dependency.

Thanks,
Reinhard

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

--
Ron Wheeler
President
Artifact Software Inc
email: rwhee...@artifact-software.com
skype: ronaldmwheeler
phone: 866-970-2435, ext 102

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

--
Baptiste Batmat MATHUS - http://batmat.net
Sauvez un arbre,
Mangez un castor ! nbsp;! users-h...@maven.apache.org

Re: Dependency resolution kicks in too early

2013-02-11 Thread Brian Fox

You've run into a non-supported edge case.


On Mon, Feb 11, 2013 at 4:17 AM, Reinhard Nägele 
reinhard.naeg...@mgm-tp.com wrote:

 Hello,

 A couple of years ago I used a plugin execution in the validate phase to
 bootstrap jars that were not available on Maven Central as suggested in
 [1]. I needed to do the same thing again today but noticed that this
 approach does not seem to work any more with Maven 3. Right after running
 Maven, dependency resolution kicks in making the build fail even before the
 install plugin gets a chance to install the missing dependency. Here's what
 I'm doing:

 plugin
   groupIdorg.apache.maven.**plugins/groupId
   artifactIdmaven-install-**plugin/artifactId
   executions
 execution
   idboostrap-some-depencency/**id
   goals
 goalinstall-file/goal
   /goals
   phasevalidate/phase
   configuration
 groupIdcom.some.groupid/**groupId
 artifactIdsome-artifact/**artifactId
 version${some.artifact.**version}/version
 packagingjar/packaging
 filebootstrap-lib/some-**artifact-${some.artifact.**version}.jar/file
 sourcesbootstrap-lib/some-**artifact-${some.artifact.**
 version}-sources.jar/sources
   /configuration
 /execution
   /executions
 /plugin
 ...
 dependency
   groupIdcom.some.groupid/**groupId
   artifactIdsome-artifact/**artifactId
   version${some.artifact.**version}/version
 /dependency
 ...
 properties
   some.artifact.version1.2.3/**some.artifact.version
 /properties

 [1] http://www.blackbit.be/2010/**04/15/maven-automatically-**
 install-dependencies-during-**build/http://www.blackbit.be/2010/04/15/maven-automatically-install-dependencies-during-build/

 Is this no longer possible? I'd really prefer this approach over using a
 system dependency.

 Thanks,
 Reinhard


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

Re: Dependency resolution kicks in too early

2013-02-11 Thread Hilco Wijbenga

On 11 February 2013 01:17, Reinhard Nägele reinhard.naeg...@mgm-tp.com wrote:
 A couple of years ago I used a plugin execution in the validate phase to
 bootstrap jars that were not available on Maven Central as suggested in [1].
 I needed to do the same thing again today but noticed that this approach
 does not seem to work any more with Maven 3. Right after running Maven,
 dependency resolution kicks in making the build fail even before the install
 plugin gets a chance to install the missing dependency. Here's what I'm
 doing:

snip/
 [1]
 http://www.blackbit.be/2010/04/15/maven-automatically-install-dependencies-during-build/

 Is this no longer possible? I'd really prefer this approach over using a
 system dependency.

You can probably do this (or something very similar) using a multi-module build.

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

Dependency resolution problem

2012-03-19 Thread Niranjan Rao

After banging my head for half an hour, I finally figured what was 
wrong. I was trying to use org.xerial:sqlite-jdbc version 3.7.2 on maven 
3. This jar is part of central repository and I was able to to see when 
I went to local nexus mirror.


However maven was not seeing it. Any time I tried compilation, I was 
getting error about unable to resolve dependencies. It turned out that 
this artifact is dependent upon some other artifacts which come from 
xerial.org repository. If maven had told me about the actual missing 
dependencies, it would have been much easier.


Was there any switch that I could have used to the name of actual 
missing dependency? During my tries maven only complained about 
dependency that was in my pom and not the transitive dependencies.


I managed to fix it by adding xerial mirror to my nexus, but this can be 
baffling problem as error message was misleading.


Regards,

Niranjan

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

RE: Dependency resolution problem

2012-03-19 Thread Amir Gheibi

Wouldn't -x option give debug information from which the actual problem can 
be found and resolved?

-Original Message-
From: Niranjan Rao [mailto:nhr...@gmail.com]
Sent: March-19-12 1:31 PM
To: Maven Users List
Subject: Dependency resolution problem

After banging my head for half an hour, I finally figured what was wrong. I was 
trying to use org.xerial:sqlite-jdbc version 3.7.2 on maven 3. This jar is part 
of central repository and I was able to to see when I went to local nexus 
mirror.

However maven was not seeing it. Any time I tried compilation, I was getting 
error about unable to resolve dependencies. It turned out that this artifact is 
dependent upon some other artifacts which come from xerial.org repository. If 
maven had told me about the actual missing dependencies, it would have been 
much easier.

Was there any switch that I could have used to the name of actual missing 
dependency? During my tries maven only complained about dependency that was in 
my pom and not the transitive dependencies.

I managed to fix it by adding xerial mirror to my nexus, but this can be 
baffling problem as error message was misleading.

Regards,

Niranjan

-
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 plugin for dependency resolution

2011-12-22 Thread Karl Heinz Marbaise

Hi,

have you taken a look into the maven-dependency-plugin code ? This works as
well in M2 as well in M3 ...

Aether is intended only for M3 world...within a plugin you can get the
Dependencies via:

this.project.getArtifacts();

if you inject the MavenProject on your plugin parameters:

/**
* The Maven project.
*
* @parameter expression=${project}
* @required
* @readonly
*/
protected MavenProject project;


Take a look at:
https://github.com/khmarbaise/Maven-License-Verifier-Plugin/blob/master/src/main/java/com/soebes/maven/plugins/mlv/AbstractLicenseVerifierPlugIn.java

Or take a look at the Maven-dependency-plugin...code...might be a better
place...

Kind regards
Karl Heinz Marbaise

-
Kind regards
Karl Heinz Marbaise

http://www.soebes.de
http://www.skmwiki.de
http://supose.org/wiki/supose
--
View this message in context: 
http://maven.40175.n5.nabble.com/Maven-plugin-for-dependency-resolution-tp5093256p5094161.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: Maven plugin for dependency resolution

2011-12-22 Thread Marek Psiuk

Hi Karl,

thanks for help.
Yes I spotted this depedency-plugin and managed to write simple POC which
works (to some extent).

The thing is that I wanted also to sort of run my plugin from standalone
java application (Eclipse - Run As - Java Application). Aether is great
for such kind of things. I wonder if You could point me to a source which
tells how to run maven-2 plugins ... outside of maven.

Kind Regards,

Marek Psiuk

On Thu, Dec 22, 2011 at 10:57 AM, Karl Heinz Marbaise k...@soebes.dewrote:

Hi,

have you taken a look into the maven-dependency-plugin code ? This works as
well in M2 as well in M3 ...

Aether is intended only for M3 world...within a plugin you can get the
Dependencies via:

this.project.getArtifacts();

if you inject the MavenProject on your plugin parameters:

/**
* The Maven project.
*
* @parameter expression=${project}
* @required
* @readonly
*/
protected MavenProject project;

Take a look at:

https://github.com/khmarbaise/Maven-License-Verifier-Plugin/blob/master/src/main/java/com/soebes/maven/plugins/mlv/AbstractLicenseVerifierPlugIn.java

Or take a look at the Maven-dependency-plugin...code...might be a better
place...

Kind regards
Karl Heinz Marbaise

-
Kind regards
Karl Heinz Marbaise

http://www.soebes.de
http://www.skmwiki.de
http://supose.org/wiki/supose
--
View this message in context:
http://maven.40175.n5.nabble.com/Maven-plugin-for-dependency-resolution-tp5093256p5094161.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

Maven plugin for dependency resolution

2011-12-21 Thread Marek Psiuk

Hello,

I am working on a maven plugin which is supposed to write a list of
dependencies (all dependencies, also transitive ones) of the current
artifact to the file. All those dependencies are OSGi bundles which are
used in the following step in a pax runner to launch OSGi environment. I
found aether and managed to write simple POC which lists dependencies that
I need. However I have the following problem. I want my plugin to be usable
in both maven-2.x and maven-3.x and I cannot force aether to work in
maven-2.x.
Is there some uniform way of getting all transitive dependencies of the
current artifact which would be compatible with both maven-2.x and
maven-3.x?

For now I figured out that I can built separate JAR artifact which
assemblies all needed depedencies (aether and others) and then simply do:
Process p = Runtime
.getRuntime()
.exec(java -jar artifact.jar-with-dependencies.jar);

Yeah I know that it's ugly but it works :]. Another workaround would be to
also have this separate JAR and jail it in my own classloader - not that
hard to do.

Anyway I cannot figure out straighforward solution.

I would be thankful for any help.


Kind Regards,

Marek Psiuk

Dependency resolution and dependencyManagement: overriding of scope?

2011-09-28 Thread 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: Dependency resolution problem

2011-09-07 Thread Wayne Fay

 P - A (1.1.0) - B (2.1.0)
 P - B (1.3.0)

 should cause a build failure, a setup like

 P - A (1.1.0) - B (1.5.0)
 P - B (1.3.0)

 should not, but we have to guarantee, that B (1.5.0) is resolved, not B
 (1.3.0), which is not the standard maven dependency resolution.

Locking down versions of dependencies with [x.y] should get you at
least some of the way there. You should also be using pluginManagement
and dependencyManagement to specify versions of things in one place
(in the parent P) to avoid some of this in the first place. The
versions plugin may also be something that you should look at.

Wayne

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

Dependency resolution problem

2011-09-05 Thread frank . jakop

Hello,

we are currently migrating from Ant to Maven and are encountering some 
dependency resolution issues.

According to the documentation Maven resolves by 
nearest-to-root-algorithm, so given a project structure like

P - A (1.1.0) - B (1.5.0)
P - B (1.3.0)

meaning P depends on A in version 1.1 etc. would resolve A (1.1) and B 
(1.3). 

Our semantics for compatibility assumes different major numbers as 
generally incompatible, which should result in a build failure. All 
different minor numbers are treatet as generally backwards compatible.

A project setup like
 
P - A (1.1.0) - B (2.1.0)
P - B (1.3.0)

should cause a build failure, a setup like

P - A (1.1.0) - B (1.5.0)
P - B (1.3.0)

should not, but we have to guarantee, that B (1.5.0) is resolved, not B 
(1.3.0), which is not the standard maven dependency resolution.

Has anyone an idea how to solve this?

Regards

Frank Jakop

Multi-module project dependency resolution

2011-03-17 Thread Deepesh Damodaran

Hi,

I have a multi module project with two modules(mod1 and mod2). mod2 depends
on mod1 so added this as a dependency to the mod2/pom.xml.

I have a couple of plug-ins (maven-enforce-plugin) enabled in individual
module's pom.xml. All of them are tied to ( generate-resources) lifecycle
less than compile lifecycle.

And when I am trying to run *mvn generate-resources* it fails saying that
cannot resolve  com.test:mod1:jar:1.0-SNAPSHOT. I haven't ran any previous
build so this jar was not available in either local repo or remote repo.

This works fine if we ran any goals greater than or equal to compile since
the compiled classes directory added to classpath.

Is there any way that we can avoid dependency resolution before compile
phase, so that we can execute pre-compile tasks independently?

Any help or suggestions will be greatly appreciated.

Version of Maven used is 2.2.1

Below is my project structure.

myp
|-- mod1
|   |-- pom.xml
|   `-- src
|   `-- main
|   `-- java
|   `-- com
|   `-- test
|   |-- A.java
|   `-- B.java
|-- mod2
|   |-- pom.xml
|   `-- src
|   `-- main
|   `-- java
|   `-- com
|   `-- test
`-- pom.xml

Parent pom.xml

?xml version=1.0?
project xmlns=http://maven.apache.org/POM/4.0.0; xmlns:xsi=
http://www.w3.org/2001/XMLSchema-instance; xsi:schemaLocation=
http://maven.apache.org/POM/4.0.0 http://maven.apache.org/maven-v4_0_0.xsd;
  modelVersion4.0.0/modelVersion
  groupIdcom.test/groupId
  artifactIdmyp/artifactId
  packagingpom/packaging
  version1.0-SNAPSHOT/version
  namemyp Maven Multi Project/name
  dependencyManagement
dependencies
  dependency
groupIdcom.test/groupId
artifactIdmod1/artifactId
version1.0-SNAPSHOT/version
  /dependency
  dependency
groupIdcom.test/groupId
artifactIdmod2/artifactId
version1.0-SNAPSHOT/version
  /dependency
/dependencies
  /dependencyManagement
  modules
modulemod1/module
modulemod2/module
  /modules
  properties
tomcat.base/home/test/apache-tomcat-5.5.23/tomcat.base
tomcat.home${tomcat.base}/tomcat.home
tomcat.version5.5.23/tomcat.version
  /properties
/project

mod1/pom.xml

?xml version=1.0?
project xmlns=http://maven.apache.org/POM/4.0.0; xmlns:xsi=
http://www.w3.org/2001/XMLSchema-instance; xsi:schemaLocation=
http://maven.apache.org/POM/4.0.0 http://maven.apache.org/maven-v4_0_0.xsd;
  modelVersion4.0.0/modelVersion
  artifactIdmod1/artifactId
  packagingjar/packaging
  version1.0-SNAPSHOT/version
  nameModule 1/name
  parent
groupIdcom.test/groupId
artifactIdmyp/artifactId
version1.0-SNAPSHOT/version
  /parent
  dependencies
dependency
  groupIdjunit/groupId
  artifactIdjunit/artifactId
  version3.8.1/version
  scopetest/scope
/dependency
  /dependencies
/project

mod2/pom.xml

project xmlns=http://maven.apache.org/POM/4.0.0; xmlns:xsi=
http://www.w3.org/2001/XMLSchema-instance; xsi:schemaLocation=
http://maven.apache.org/POM/4.0.0 http://maven.apache.org/maven-v4_0_0.xsd;
  modelVersion4.0.0/modelVersion
  artifactIdmod2/artifactId
  packagingjar/packaging
  version1.0-SNAPSHOT/version
  nameModule 2/name
  parent
groupIdcom.test/groupId
artifactIdmyp/artifactId
version1.0-SNAPSHOT/version
  /parent
  dependencies
dependency
  groupIdcom.test/groupId
  artifactIdmod1/artifactId
  version1.0-SNAPSHOT/version
/dependency
dependency
  groupIdjunit/groupId
  artifactIdjunit/artifactId
  version3.8.1/version
  scopetest/scope
/dependency
  /dependencies
build
plugins
  plugin
groupIdorg.apache.maven.plugins/groupId
artifactIdmaven-enforcer-plugin/artifactId
version1.0/version
executions
  execution
idValidate/id
phasegenerate-resources/phase
goals
  goalenforce/goal
/goals
configuration
  rules
requireProperty
  propertytomcat.base/property
  messageTomcat Base Needed/message
/requireProperty
requireProperty
  propertytomcat.home/property
  messageTomcat Home Needed/message
/requireProperty
requireProperty
  propertytomcat.version/property
  messageTomcat Version Needed/message
/requireProperty
  /rules
/configuration
  /execution
/executions
  /plugin
/plugins
  /build
/project


Thanks and Regards,
Deepesh

Re: Multi-module project dependency resolution

2011-03-17 Thread Barrie Treloar

On Thu, Mar 17, 2011 at 10:04 AM, Deepesh Damodaran deeps...@gmail.comwrote:

 Hi,

 I have a multi module project with two modules(mod1 and mod2). mod2 depends
 on mod1 so added this as a dependency to the mod2/pom.xml.

 I have a couple of plug-ins (maven-enforce-plugin) enabled in individual
 module's pom.xml. All of them are tied to ( generate-resources) lifecycle
 less than compile lifecycle.

 And when I am trying to run *mvn generate-resources* it fails saying that
 cannot resolve  com.test:mod1:jar:1.0-SNAPSHOT. I haven't ran any previous
 build so this jar was not available in either local repo or remote repo.

 This works fine if we ran any goals greater than or equal to compile since
 the compiled classes directory added to classpath.

 Is there any way that we can avoid dependency resolution before compile
 phase, so that we can execute pre-compile tasks independently?

 Any help or suggestions will be greatly appreciated.


Your mod2/pom.xml declares itself as requiring mod1.
Why are you trying to run any goal besides install?

Remember this isn't ant and running install will run the previous lifecycle
goals for you.

Dependency Resolution and Version Range Conflicts

2011-02-25 Thread Sean Floyd

Hello,

the client I currently work for has strange requirements when it comes to maven 
version ranges.

Part 1:

Snapshots should not be included in Version Ranges, unless they are 
specifically mentioned in the upper or lower bound e.g.

[0.5,1.0) should not match 0.6-SNAPSHOT
[0.6-SNAPSHOT,1.0) should match 0.6-SNAPSHOT, but not 0.6.1-SNAPSHOT

(This is loosely equivalent to http://jira.codehaus.org/browse/MNG-3092 , and 
my client has previously used maven 2.09 with the patch attached to this issue)

I have managed to implement this functionality in Maven 3 using a) the patch I 
contributed to this issue: http://jira.codehaus.org/browse/MNG-5017 and b) a 
custom VersionScheme implementation that extends GenericVersionScheme and 
decorates the GenericVersionConstraint objects with the above requirements.

Now I just have to hope that MNG-5017 gets accepted (or else my client will 
again have a complicated migration path for future versions)

Part2:

It gets even more complicated, unfortunately. My client's requirement is as 
follows:

if a project has several paths to a given dependency and at least one path 
includes a SNAPSHOT version, then this version should be included in all 
version constraints for this node

Example:

[this project]
|  |
|  +-- artifactA -- artifactB [0.5,1.0)
|
+- artifactC -- artifactB [0.4,) 

in this scenario, version 0.5-SNAPSHOT won't be included

[this project]
|  |
|  +-- artifactA -- artifactB [0.5-SNAPSHOT,1.0)
|
+- artifactC -- artifactB [0.4,)

in this scenario, version 0.5-SNAPSHOT will be included, as it is included in 
at least one version range

Obviously, I can't implement this requirement with my above approach alone. 
From what I see so far, I will have to use a DependencyGraphTransformer 
somehow. I can think of the following approach:

a) Implement a DependencyGraphTransformer that is added in the Transformer 
chain before NearestVersionConflictResolver. b) This Transformer would check 
all version constraints for the current node to see if this scenario applies. 
c) If it does, this Transformer would have to change all constraints in the 
current node to allow snapshots.

Since I already use Custom VersionConstraint decorators, b) and c) will be easy 
to achieve, however a) is the problem.

The way I see is to

- implement an AbstractMavenLifecycleParticipant and register it as a
  component (store the artifact in $MAVEN_HOME/lib/ext)
- in AbstractMavenLifecycleParticipant.afterSessionStart(session), get
  the current DependencyGraphTransformer from
  session.getRepositorySession()
- Create a ChainedDependencyGraphTransformer delegating to
  a) my custom transformer and
  b) the previous transformer
- inject that ChainedDependencyGraphTransformer back into
  session.getRepository() (probably using 
  org.sonatype.guice.bean.reflect.BeanProperty.set(bean, value))

Would that approach work? Is there a better way to implement this functionality?

Thanks in advance,

Sean Floyd
-- 
Empfehlen Sie GMX DSL Ihren Freunden und Bekannten und wir
belohnen Sie mit bis zu 50,- Euro! https://freundschaftswerbung.gmx.de

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

Re: Maven dependency resolution failure?

2010-12-12 Thread Anders Hammar

Yes, adding a plugin in the pluginManagement section doesn't actual bind it.
For a binding, you need to have it in build.plugins.

/Anders

On Sun, Dec 12, 2010 at 08:33, Elliot Huntington 
elliot.hunting...@gmail.com wrote:

 Yes, here is the build section of pom.xml:

build
finalName${artifactId}/finalName
pluginManagement
plugins
plugin
artifactIdmaven-compiler-plugin/artifactId
version2.3.1/version
configuration
source1.6/source
target1.6/target
/configuration
/plugin
 plugin
groupIdorg.apache.maven.plugins/groupId
 artifactIdmaven-jar-plugin/artifactId
version2.3.1/version
configuration
archive
manifest
addClasspathtrue/addClasspath
/manifest
manifestEntries

 SplashScreen-Imagesplash.jpg/SplashScreen-Image
Main-Classmy.package.Main/Main-Class
/manifestEntries
/archive
finalName${artifactId}-tmp/finalName
/configuration
/plugin
 plugin
groupIdorg.apache.maven.plugins/groupId
artifactIdmaven-shade-plugin/artifactId
version1.4/version
executions
execution
phasepackage/phase
goals
goalshade/goal
/goals
configuration

 shadedArtifactAttachedtrue/shadedArtifactAttached

 shadedClassifierNameshaded/shadedClassifierName
 transformers
transformer

 implementation=org.apache.maven.plugins.shade.resource.AppendingTransformer

 resourceMETA-INF/spring.handlers/resource
/transformer
transformer

 implementation=org.apache.maven.plugins.shade.resource.AppendingTransformer

 resourceMETA-INF/spring.schemas/resource
/transformer
/transformers
/configuration
/execution
/executions
/plugin
 /plugins
/pluginManagement
/build

 Here is the output from running mvn:

 C:\projects\personal\svn\myprojectmvn clean package -Dmaven.test.skip=true
 [INFO] Scanning for projects...
 [INFO]
 
 [INFO] Building myproject
 [INFO]task-segment: [clean, package]
 [INFO]
 
 [INFO] *[clean:clean {execution: default-clean}]*
 [INFO] Deleting directory C:\projects\personal\svn\myproject\target
 [INFO] *[resources:resources {execution: default-resources}]*
 [INFO] Using 'UTF-8' encoding to copy filtered resources.
 [INFO] Copying 12 resources
 [INFO] *[compiler:compile {execution: default-compile}]*
 [INFO] Compiling 40 source files to
 C:\projects\personal\svn\myproject\target\classes
 [INFO] *[resources:testResources {execution: default-testResources}]*
 [INFO] Using 'UTF-8' encoding to copy filtered resources.
 [INFO] skip non existing resourceDirectory
 C:\projects\personal\svn\myproject\src\test\resources
 [INFO] *[compiler:testCompile {execution: default-testCompile}]*
 [INFO] Not compiling test sources
 [INFO] *[surefire:test {execution: default-test}]*
 [INFO] Tests are skipped.
 [INFO] *[jar:jar {execution: default-jar}]*
 [INFO] Building jar:
 C:\projects\personal\svn\myproject\target\myproject-tmp.jar
 [INFO]
 
 [INFO] BUILD SUCCESSFUL
 [INFO]
 
 [INFO] Total time: 13 seconds
 [INFO] Finished at: Sun Dec 12 00:24:54 MST 2010
 [INFO] Final Memory: 36M/196M
 [INFO]
 

 Based on this output, and looking in the jar that is created, the shade
 plugin was not invoked. I don't see any output that indicates that
 [shade:shade {execution: ...}] is being executed.

 Am I missing something here?

 Thanks,
 Elliot


 On Thu, Dec 9, 2010 at 11:28 PM, Anders Hammar and...@hammar.net wrote:

  Do you have this snippet in the pluginManagement section by any chance?
 If
  so, it does actually bind it.
 
  /Anders
 
  On Thu, Dec 9, 2010 at 23:32, Elliot Huntington 
  elliot.hunting...@gmail.com
   wrote:
 
   Thank you! I don't know how I overlooked that.

Re: Maven dependency resolution failure?

2010-12-12 Thread Elliot Huntington

Thank you!

On Sun, Dec 12, 2010 at 2:50 AM, Anders Hammar and...@hammar.net wrote:

 Yes, adding a plugin in the pluginManagement section doesn't actual bind
 it.
 For a binding, you need to have it in build.plugins.

 /Anders

 On Sun, Dec 12, 2010 at 08:33, Elliot Huntington 
 elliot.hunting...@gmail.com wrote:

  Yes, here is the build section of pom.xml:
 
 build
 finalName${artifactId}/finalName
 pluginManagement
 plugins
 plugin
 artifactIdmaven-compiler-plugin/artifactId
 version2.3.1/version
 configuration
 source1.6/source
 target1.6/target
 /configuration
 /plugin
  plugin
 groupIdorg.apache.maven.plugins/groupId
  artifactIdmaven-jar-plugin/artifactId
 version2.3.1/version
 configuration
 archive
 manifest
 addClasspathtrue/addClasspath
 /manifest
 manifestEntries
 
  SplashScreen-Imagesplash.jpg/SplashScreen-Image
 Main-Classmy.package.Main/Main-Class
 /manifestEntries
 /archive
 finalName${artifactId}-tmp/finalName
 /configuration
 /plugin
  plugin
 groupIdorg.apache.maven.plugins/groupId
 artifactIdmaven-shade-plugin/artifactId
 version1.4/version
 executions
 execution
 phasepackage/phase
 goals
 goalshade/goal
 /goals
 configuration
 
  shadedArtifactAttachedtrue/shadedArtifactAttached
 
  shadedClassifierNameshaded/shadedClassifierName
  transformers
 transformer
 
 
 implementation=org.apache.maven.plugins.shade.resource.AppendingTransformer
 
  resourceMETA-INF/spring.handlers/resource
 /transformer
 transformer
 
 
 implementation=org.apache.maven.plugins.shade.resource.AppendingTransformer
 
  resourceMETA-INF/spring.schemas/resource
 /transformer
 /transformers
 /configuration
 /execution
 /executions
 /plugin
  /plugins
 /pluginManagement
 /build
 
  Here is the output from running mvn:
 
  C:\projects\personal\svn\myprojectmvn clean package
 -Dmaven.test.skip=true
  [INFO] Scanning for projects...
  [INFO]
  
  [INFO] Building myproject
  [INFO]task-segment: [clean, package]
  [INFO]
  
  [INFO] *[clean:clean {execution: default-clean}]*
  [INFO] Deleting directory C:\projects\personal\svn\myproject\target
  [INFO] *[resources:resources {execution: default-resources}]*
  [INFO] Using 'UTF-8' encoding to copy filtered resources.
  [INFO] Copying 12 resources
  [INFO] *[compiler:compile {execution: default-compile}]*
  [INFO] Compiling 40 source files to
  C:\projects\personal\svn\myproject\target\classes
  [INFO] *[resources:testResources {execution: default-testResources}]*
  [INFO] Using 'UTF-8' encoding to copy filtered resources.
  [INFO] skip non existing resourceDirectory
  C:\projects\personal\svn\myproject\src\test\resources
  [INFO] *[compiler:testCompile {execution: default-testCompile}]*
  [INFO] Not compiling test sources
  [INFO] *[surefire:test {execution: default-test}]*
  [INFO] Tests are skipped.
  [INFO] *[jar:jar {execution: default-jar}]*
  [INFO] Building jar:
  C:\projects\personal\svn\myproject\target\myproject-tmp.jar
  [INFO]
  
  [INFO] BUILD SUCCESSFUL
  [INFO]
  
  [INFO] Total time: 13 seconds
  [INFO] Finished at: Sun Dec 12 00:24:54 MST 2010
  [INFO] Final Memory: 36M/196M
  [INFO]
  
 
  Based on this output, and looking in the jar that is created, the shade
  plugin was not invoked. I don't see any output that indicates that
  [shade:shade {execution: ...}] is being executed.
 
  Am I missing something here?
 
  Thanks,
  Elliot
 
 
  On Thu, Dec 9, 2010 at 11:28 PM, Anders Hammar and...@hammar.net
 wrote:
 
   Do you have this snippet in the pluginManagement

Re: Maven dependency resolution failure?

2010-12-11 Thread Elliot Huntington

Yes, here is the build section of pom.xml:

build
finalName${artifactId}/finalName
pluginManagement
plugins
plugin
artifactIdmaven-compiler-plugin/artifactId
version2.3.1/version
configuration
source1.6/source
target1.6/target
/configuration
/plugin
plugin
groupIdorg.apache.maven.plugins/groupId
artifactIdmaven-jar-plugin/artifactId
version2.3.1/version
configuration
archive
manifest
addClasspathtrue/addClasspath
/manifest
manifestEntries

SplashScreen-Imagesplash.jpg/SplashScreen-Image
Main-Classmy.package.Main/Main-Class
/manifestEntries
/archive
finalName${artifactId}-tmp/finalName
/configuration
/plugin
plugin
groupIdorg.apache.maven.plugins/groupId
artifactIdmaven-shade-plugin/artifactId
version1.4/version
executions
execution
phasepackage/phase
goals
goalshade/goal
/goals
configuration

shadedArtifactAttachedtrue/shadedArtifactAttached

shadedClassifierNameshaded/shadedClassifierName
transformers
transformer
implementation=org.apache.maven.plugins.shade.resource.AppendingTransformer

resourceMETA-INF/spring.handlers/resource
/transformer
transformer
implementation=org.apache.maven.plugins.shade.resource.AppendingTransformer

resourceMETA-INF/spring.schemas/resource
/transformer
/transformers
/configuration
/execution
/executions
/plugin
/plugins
/pluginManagement
/build

Here is the output from running mvn:

C:\projects\personal\svn\myprojectmvn clean package -Dmaven.test.skip=true
[INFO] Scanning for projects...
[INFO]

[INFO] Building myproject
[INFO]task-segment: [clean, package]
[INFO]

[INFO] *[clean:clean {execution: default-clean}]*
[INFO] Deleting directory C:\projects\personal\svn\myproject\target
[INFO] *[resources:resources {execution: default-resources}]*
[INFO] Using 'UTF-8' encoding to copy filtered resources.
[INFO] Copying 12 resources
[INFO] *[compiler:compile {execution: default-compile}]*
[INFO] Compiling 40 source files to
C:\projects\personal\svn\myproject\target\classes
[INFO] *[resources:testResources {execution: default-testResources}]*
[INFO] Using 'UTF-8' encoding to copy filtered resources.
[INFO] skip non existing resourceDirectory
C:\projects\personal\svn\myproject\src\test\resources
[INFO] *[compiler:testCompile {execution: default-testCompile}]*
[INFO] Not compiling test sources
[INFO] *[surefire:test {execution: default-test}]*
[INFO] Tests are skipped.
[INFO] *[jar:jar {execution: default-jar}]*
[INFO] Building jar:
C:\projects\personal\svn\myproject\target\myproject-tmp.jar
[INFO]

[INFO] BUILD SUCCESSFUL
[INFO]

[INFO] Total time: 13 seconds
[INFO] Finished at: Sun Dec 12 00:24:54 MST 2010
[INFO] Final Memory: 36M/196M
[INFO]


Based on this output, and looking in the jar that is created, the shade
plugin was not invoked. I don't see any output that indicates that
[shade:shade {execution: ...}] is being executed.

Am I missing something here?

Thanks,
Elliot


On Thu, Dec 9, 2010 at 11:28 PM, Anders Hammar and...@hammar.net wrote:

 Do you have this snippet in the pluginManagement section by any chance? If
 so, it does actually bind it.

 /Anders

 On Thu, Dec 9, 2010 at 23:32, Elliot Huntington 
 elliot.hunting...@gmail.com
  wrote:

  Thank you! I don't know how I overlooked that. I thought I checked the
  repository and saw it there.
 
  Now, for some reason the plugin is not activated when I run mvn package
 
  I have my pom.xml configured with this:
 
 plugin
 groupIdorg.apache.maven.plugins/groupId

Limiting dependency resolution depth

Hi,

I'm pretty new to Java and Maven, so my question may be very naive
and/or stupid, apologies for that.
I'm trying to compile an open-source project (if that matters, it's
https://plugins.atlassian.com/plugin/details/4832 ), which is supposed
to be built with Maven. I've got Maven 3 installed (Apache Maven 3.0.1
(r1038046; 2010-11-23 10:58:32+)). This pretty small project
depends on a larger one (Atlassian JIRA), which has some Maven
support, but the public repos are not well maintained, and there are a
lot of broken dependencies, therefore the dependency resolution
process fails.
However, I have all of the first level (direct) dependencies resolved.
As far as my knowledge goes, it's enough to have the first level
dependencies to compile a Java project, and that's exactly what I
want. Is there a way to tell Maven to stop resolving 2 level
dependencies, and just try compiling the project? I tried to Google
for this, no luck; and the guides on mvn dependency resolution don't
help either.

Thanks,
Mate

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

Re: Limiting dependency resolution depth

2010-12-10 Thread Tamás Cservenák

Hi,

Okay, but to be able to help, we need more:

1) where are the sources you try to build? (especially POM)
2) what is the failure? dependency resolution fails as missing a
dependency or what?
3) check for network failures on your side, and repeat builds with -U to
force maven to try again (the fact that a dep was not found is cached)


Thanks,
~t~

On Fri, Dec 10, 2010 at 1:22 PM, Mate Varga mate.va...@gmail.com wrote:

 Hi,

 I'm pretty new to Java and Maven, so my question may be very naive
 and/or stupid, apologies for that.
 I'm trying to compile an open-source project (if that matters, it's
 https://plugins.atlassian.com/plugin/details/4832 ), which is supposed
 to be built with Maven. I've got Maven 3 installed (Apache Maven 3.0.1
 (r1038046; 2010-11-23 10:58:32+)). This pretty small project
 depends on a larger one (Atlassian JIRA), which has some Maven
 support, but the public repos are not well maintained, and there are a
 lot of broken dependencies, therefore the dependency resolution
 process fails.
 However, I have all of the first level (direct) dependencies resolved.
 As far as my knowledge goes, it's enough to have the first level
 dependencies to compile a Java project, and that's exactly what I
 want. Is there a way to tell Maven to stop resolving 2 level
 dependencies, and just try compiling the project? I tried to Google
 for this, no luck; and the guides on mvn dependency resolution don't
 help either.

 Thanks,
 Mate

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

Re: Limiting dependency resolution depth

Hello Tamas,

1) Sources are checked out from SVN to the local drive.
2) Yes, missing dependencies. The problems stem from things like
missing maven-metadata files in the public repos. (I've checked that,
the repo maintainers do know about the inconsistencies, but they
refuse to fix it.)
3) I've done all of that, and I've manually checked the online repos
-- the dependency chain is broken, -U, :purge-local-repository does
not help, and my network connection is all right.

I could go and fetch all the required jars/wars/etc. manually and
deploy them into my internal repo, but I want to avoid that if it's
possible.

Udv,
Mate


2010/12/10 Tamás Cservenák ta...@cservenak.net:
 Hi,

 Okay, but to be able to help, we need more:

 1) where are the sources you try to build? (especially POM)
 2) what is the failure? dependency resolution fails as missing a
 dependency or what?
 3) check for network failures on your side, and repeat builds with -U to
 force maven to try again (the fact that a dep was not found is cached)


 Thanks,
 ~t~

 On Fri, Dec 10, 2010 at 1:22 PM, Mate Varga mate.va...@gmail.com wrote:

 Hi,

 I'm pretty new to Java and Maven, so my question may be very naive
 and/or stupid, apologies for that.
 I'm trying to compile an open-source project (if that matters, it's
 https://plugins.atlassian.com/plugin/details/4832 ), which is supposed
 to be built with Maven. I've got Maven 3 installed (Apache Maven 3.0.1
 (r1038046; 2010-11-23 10:58:32+)). This pretty small project
 depends on a larger one (Atlassian JIRA), which has some Maven
 support, but the public repos are not well maintained, and there are a
 lot of broken dependencies, therefore the dependency resolution
 process fails.
 However, I have all of the first level (direct) dependencies resolved.
 As far as my knowledge goes, it's enough to have the first level
 dependencies to compile a Java project, and that's exactly what I
 want. Is there a way to tell Maven to stop resolving 2 level
 dependencies, and just try compiling the project? I tried to Google
 for this, no luck; and the guides on mvn dependency resolution don't
 help either.

 Thanks,
 Mate

 -
 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: Limiting dependency resolution depth

2010-12-10 Thread Wendy Smoak

On Fri, Dec 10, 2010 at 7:22 AM, Mate Varga mate.va...@gmail.com wrote:
 However, I have all of the first level (direct) dependencies resolved.
 As far as my knowledge goes, it's enough to have the first level
 dependencies to compile a Java project,

Not necessarily... it depends on whether the project developers are
relying on transitive dependencies to bring in other stuff they need.

For example, I can declare a dependency on Struts and then use
BeanUtils classes in my code, because I know the Struts dependency
will give me BeanUtils transitively.

In any case, you can't just 'turn off' transitive dependency
resolution in Maven.

You mentioned you have an internal repo already, so if the maintainers
of the remote repos you're trying to pull from won't cooperate, put
the needed artifacts in your own repo and you'll be good to go.

-- 
Wendy

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

Re: Limiting dependency resolution depth

Thanks.

 You mentioned you have an internal repo already, so if the maintainers
 of the remote repos you're trying to pull from won't cooperate, put
 the needed artifacts in your own repo and you'll be good to go.

Yeah, that's what I wanted to avoid. I will do it if there is no other
way, but I find it a bit annoying that it is not possible to cut off
the dependency chain at a certain point.


 For example, I can declare a dependency on Struts and then use
 BeanUtils classes in my code, because I know the Struts dependency
 will give me BeanUtils transitively.

Well, my view is that if you're directly referencing a type, then it
should be a direct dependency in your project -- because the project's
dependencies are not part of the interface, e.g. if Struts' deps get
changed, then your project might break even the interface remains the
same.


 In any case, you can't just 'turn off' transitive dependency
 resolution in Maven.

:(

Thanks,

Mate

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

Re: Limiting dependency resolution depth

2010-12-10 Thread Stefan Seidel

Hi Mate,

you can, as a workaround, download the pom.xml of your dependency and copy 
those dependencies into your own pom.xml (or another one which only contains 
those). Then change/add the scope of all those dependencies to provided, 
which should effectively disable deeper dependency resolution.

Stefan

On Fri, 10 Dec 2010 12:56:49 +
Mate Varga mate.va...@gmail.com wrote:

 Hello Tamas,
 
 1) Sources are checked out from SVN to the local drive.
 2) Yes, missing dependencies. The problems stem from things like
 missing maven-metadata files in the public repos. (I've checked that,
 the repo maintainers do know about the inconsistencies, but they
 refuse to fix it.)
 3) I've done all of that, and I've manually checked the online repos
 -- the dependency chain is broken, -U, :purge-local-repository does
 not help, and my network connection is all right.
 
 I could go and fetch all the required jars/wars/etc. manually and
 deploy them into my internal repo, but I want to avoid that if it's
 possible.
 
 Udv,
 Mate
 
 
 2010/12/10 Tamás Cservenák ta...@cservenak.net:
  Hi,
 
  Okay, but to be able to help, we need more:
 
  1) where are the sources you try to build? (especially POM)
  2) what is the failure? dependency resolution fails as missing a
  dependency or what?
  3) check for network failures on your side, and repeat builds with -U to
  force maven to try again (the fact that a dep was not found is cached)
 
 
  Thanks,
  ~t~
 
  On Fri, Dec 10, 2010 at 1:22 PM, Mate Varga mate.va...@gmail.com wrote:
 
  Hi,
 
  I'm pretty new to Java and Maven, so my question may be very naive
  and/or stupid, apologies for that.
  I'm trying to compile an open-source project (if that matters, it's
  https://plugins.atlassian.com/plugin/details/4832 ), which is supposed
  to be built with Maven. I've got Maven 3 installed (Apache Maven 3.0.1
  (r1038046; 2010-11-23 10:58:32+)). This pretty small project
  depends on a larger one (Atlassian JIRA), which has some Maven
  support, but the public repos are not well maintained, and there are a
  lot of broken dependencies, therefore the dependency resolution
  process fails.
  However, I have all of the first level (direct) dependencies resolved.
  As far as my knowledge goes, it's enough to have the first level
  dependencies to compile a Java project, and that's exactly what I
  want. Is there a way to tell Maven to stop resolving 2 level
  dependencies, and just try compiling the project? I tried to Google
  for this, no luck; and the guides on mvn dependency resolution don't
  help either.
 
  Thanks,
  Mate
 
  -
  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
 


-- 
Mit freundlichen Grüßen,

Stefan Seidel
Software-Entwickler

VUB Printmedia GmbH
Chopinstraße 4, 04103 Leipzig
tel.+49 (341) 9 60 50 93
fax.+49 (341) 9 60 50 92
mail.   ssei...@vub.de 
web.www.vub.de

VUB Printmedia GmbH
HRB Köln 24015
GF Dr. A. Preuss Neudorf, Dr. C. Preuss Neudorf

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

Re: Limiting dependency resolution depth

Thanks, that's a good idea.

On Fri, Dec 10, 2010 at 2:07 PM, Stefan Seidel ssei...@vub.de wrote:
 Hi Mate,

 you can, as a workaround, download the pom.xml of your dependency and copy 
 those dependencies into your own pom.xml (or another one which only contains 
 those). Then change/add the scope of all those dependencies to provided, 
 which should effectively disable deeper dependency resolution.

 Stefan

 On Fri, 10 Dec 2010 12:56:49 +
 Mate Varga mate.va...@gmail.com wrote:

 Hello Tamas,

 1) Sources are checked out from SVN to the local drive.
 2) Yes, missing dependencies. The problems stem from things like
 missing maven-metadata files in the public repos. (I've checked that,
 the repo maintainers do know about the inconsistencies, but they
 refuse to fix it.)
 3) I've done all of that, and I've manually checked the online repos
 -- the dependency chain is broken, -U, :purge-local-repository does
 not help, and my network connection is all right.

 I could go and fetch all the required jars/wars/etc. manually and
 deploy them into my internal repo, but I want to avoid that if it's
 possible.

 Udv,
 Mate


 2010/12/10 Tamás Cservenák ta...@cservenak.net:
  Hi,
 
  Okay, but to be able to help, we need more:
 
  1) where are the sources you try to build? (especially POM)
  2) what is the failure? dependency resolution fails as missing a
  dependency or what?
  3) check for network failures on your side, and repeat builds with -U to
  force maven to try again (the fact that a dep was not found is cached)
 
 
  Thanks,
  ~t~
 
  On Fri, Dec 10, 2010 at 1:22 PM, Mate Varga mate.va...@gmail.com wrote:
 
  Hi,
 
  I'm pretty new to Java and Maven, so my question may be very naive
  and/or stupid, apologies for that.
  I'm trying to compile an open-source project (if that matters, it's
  https://plugins.atlassian.com/plugin/details/4832 ), which is supposed
  to be built with Maven. I've got Maven 3 installed (Apache Maven 3.0.1
  (r1038046; 2010-11-23 10:58:32+)). This pretty small project
  depends on a larger one (Atlassian JIRA), which has some Maven
  support, but the public repos are not well maintained, and there are a
  lot of broken dependencies, therefore the dependency resolution
  process fails.
  However, I have all of the first level (direct) dependencies resolved.
  As far as my knowledge goes, it's enough to have the first level
  dependencies to compile a Java project, and that's exactly what I
  want. Is there a way to tell Maven to stop resolving 2 level
  dependencies, and just try compiling the project? I tried to Google
  for this, no luck; and the guides on mvn dependency resolution don't
  help either.
 
  Thanks,
  Mate
 
  -
  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



 --
 Mit freundlichen Grüßen,

 Stefan Seidel
 Software-Entwickler
 
 VUB Printmedia GmbH
 Chopinstraße 4, 04103 Leipzig
 tel.    +49 (341) 9 60 50 93
 fax.    +49 (341) 9 60 50 92
 mail.   ssei...@vub.de
 web.    www.vub.de

 VUB Printmedia GmbH
 HRB Köln 24015
 GF Dr. A. Preuss Neudorf, Dr. C. Preuss Neudorf

 -
 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: Limiting dependency resolution depth

2010-12-10 Thread Ron Wheeler

Mate,
You might get more help if you actually provided some details about what
is your build is actually saying and what repos are broken.

Ron

On 10/12/2010 9:07 AM, Stefan Seidel wrote:

Hi Mate,

you can, as a workaround, download the pom.xml of your dependency and copy those dependencies into
your own pom.xml (or another one which only contains those). Then change/add the scope
of all those dependencies to provided, which should effectively disable deeper
dependency resolution.

Stefan

On Fri, 10 Dec 2010 12:56:49 +
Mate Vargamate.va...@gmail.com wrote:

Hello Tamas,

1) Sources are checked out from SVN to the local drive.
2) Yes, missing dependencies. The problems stem from things like
missing maven-metadata files in the public repos. (I've checked that,
the repo maintainers do know about the inconsistencies, but they
refuse to fix it.)
3) I've done all of that, and I've manually checked the online repos
-- the dependency chain is broken, -U, :purge-local-repository does
not help, and my network connection is all right.

I could go and fetch all the required jars/wars/etc. manually and
deploy them into my internal repo, but I want to avoid that if it's
possible.

Udv,
Mate

2010/12/10 Tamás Cservenákta...@cservenak.net:

Hi,

Okay, but to be able to help, we need more:

1) where are the sources you try to build? (especially POM)
2) what is the failure? dependency resolution fails as missing a
dependency or what?
3) check for network failures on your side, and repeat builds with -U to
force maven to try again (the fact that a dep was not found is cached)

Thanks,
~t~

On Fri, Dec 10, 2010 at 1:22 PM, Mate Vargamate.va...@gmail.com wrote:

Hi,

I'm pretty new to Java and Maven, so my question may be very naive
and/or stupid, apologies for that.
I'm trying to compile an open-source project (if that matters, it's
https://plugins.atlassian.com/plugin/details/4832 ), which is supposed
to be built with Maven. I've got Maven 3 installed (Apache Maven 3.0.1
(r1038046; 2010-11-23 10:58:32+)). This pretty small project
depends on a larger one (Atlassian JIRA), which has some Maven
support, but the public repos are not well maintained, and there are a
lot of broken dependencies, therefore the dependency resolution
process fails.
However, I have all of the first level (direct) dependencies resolved.
As far as my knowledge goes, it's enough to have the first level
dependencies to compile a Java project, and that's exactly what I
want. Is there a way to tell Maven to stop resolving2 level
dependencies, and just try compiling the project? I tried to Google
for this, no luck; and the guides on mvn dependency resolution don't
help either.

Thanks,
Mate

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

Re: Limiting dependency resolution depth