Re: Dependency JDK convergence rule?

[Florent Biville]

That's perfect, thanks :)

On Tue, Oct 10, 2023 at 3:02 PM Slawomir Jaranowski 
wrote:

> Hi,
>
> Did you try:
> https://www.mojohaus.org/extra-enforcer-rules/enforceBytecodeVersion.html
>
> wt., 10 paź 2023 o 14:40 Florent Biville 
> napisał(a):
>
> > Hello,
> >
> > I could not find what I'm looking for in the built-in rules of the
> enforcer
> > plugin: https://maven.apache.org/enforcer/enforcer-rules/index.html.
> >
> > Is there something available today to make sure that all dependencies
> have
> > the same JDK baseline? Is it even feasible to implement such a check?
> >
> > Best regards,
> > Florent
> >
>
>
> --
> Sławomir Jaranowski
>

Re: Dependency JDK convergence rule?

[Slawomir Jaranowski]

Hi,

Did you try:
https://www.mojohaus.org/extra-enforcer-rules/enforceBytecodeVersion.html

wt., 10 paź 2023 o 14:40 Florent Biville 
napisał(a):

> Hello,
>
> I could not find what I'm looking for in the built-in rules of the enforcer
> plugin: https://maven.apache.org/enforcer/enforcer-rules/index.html.
>
> Is there something available today to make sure that all dependencies have
> the same JDK baseline? Is it even feasible to implement such a check?
>
> Best regards,
> Florent
>


-- 
Sławomir Jaranowski

Re: Dependency version change on dependency import

[Nils Breunese]

Rimvydas Vaidelis  wrote:

> Thank you for the answer. I know that I can override the dependency version
> in pom that imports the bom module. I wanted to avoid duplicating of the
> dependency overriding in my library and in another project. However now I
> see that it is the only way to implement what I want.

What exactly do you need to duplicate? You could also specify the override 
version on the dependency directly, without putting it in dependencyManagement, 
but I personally only manage versions in dependencyManagement, because I often 
work on multi-module projects and consider that a good practice.

Another way to override a specific dependency would be to have a dedicated 
Maven property for it, so you’d only have to override that one.

I’m also kind of wondering why you have this use case. Generally when I import 
a BOM and need a new version of some dependency I just change the version of 
the whole BOM import, because that is supposed to be a consistent set of 
modules. Couldn’t you do that instead of overriding only one version from the 
BOM?

> Actually it was
> strange to me that maven does not respect active profiles on dependency
> import request. Maybe there is a reason why it is like that. It would be
> good if somebody could comment that. Is it by design or it is just
> implemented in this way?

When you use import you’re only importing  
as far as I know, so if there are  in the BOM those will not be 
imported.

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

Re: Dependency version change on dependency import

[Rimvydas Vaidelis]

Hi Nils,

Thank you for the answer. I know that I can override the dependency version
in pom that imports the bom module. I wanted to avoid duplicating of the
dependency overriding in my library and in another project. However now I
see that it is the only way to implement what I want. Actually it was
strange to me that maven does not respect active profiles on dependency
import request. Maybe there is a reason why it is like that. It would be
good if somebody could comment that. Is it by design or it is just
implemented in this way?

--
Rimvydas

On Sat, Mar 12, 2022 at 2:42 AM Nils Breunese  wrote:

> Rimvydas Vaidelis  wrote:
>
> > I have a multi-module project and I want to create a bill of materials
> > (BOM) module. BOM module contains dependencyManagement. My parent module
> > imports BOM module. BOM module will be used in another project that is
> > going to use my library. In development environment I would like to
> change
> > version of one dependency. I tried to do that using a profile but it
> seems
> > that maven does not activate the profile while performing import. Is it a
> > normal behavior? Maybe you could recommend any other way to implement
> > dependency version change in development environment.
>
> I believe you can add a regular dependency entry for the artifact for
> which you want to override the version, like this:
>
> 
> 
>   
> 
>   com.example
>   example-bom
>   1.0.0
>   pom
>   import
> 
> 
>   com.example
>   example-artifact-from-bom-i-want-to-override
>   1.1.0-SNAPSHOT
> 
>   
> 
>
> 
>   
> com.example
> example-artifact-managed-by-bom
>   
>   
> com.example
> example-artifact-from-bom-i-want-to-override
>   
> 
> 
>
> Nils.
> -
> To unsubscribe, e-mail: users-unsubscr...@maven.apache.org
> For additional commands, e-mail: users-h...@maven.apache.org
>
>

Re: Dependency version change on dependency import

[Nils Breunese]

Rimvydas Vaidelis  wrote:

> I have a multi-module project and I want to create a bill of materials
> (BOM) module. BOM module contains dependencyManagement. My parent module
> imports BOM module. BOM module will be used in another project that is
> going to use my library. In development environment I would like to change
> version of one dependency. I tried to do that using a profile but it seems
> that maven does not activate the profile while performing import. Is it a
> normal behavior? Maybe you could recommend any other way to implement
> dependency version change in development environment.

I believe you can add a regular dependency entry for the artifact for which you 
want to override the version, like this:



  

  com.example
  example-bom
  1.0.0
  pom
  import


  com.example
  example-artifact-from-bom-i-want-to-override
  1.1.0-SNAPSHOT

  



  
com.example
example-artifact-managed-by-bom
  
  
com.example
example-artifact-from-bom-i-want-to-override
  



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

Re: Dependency plugin unpack plugin dependencies

[Benjamin Marwell]

Hi Alexander,

this is an old thread, but no one has replied yet.
While I think this is possible – what are you trying to achieve?
Or in other words: WHY do you need the dependencies unpacked? What do
you do with them?


Regards,
Ben

On 2020/08/19 18:23:06, Alexander Broekhuis  wrote:
> Hi all,
>
> I currently have a setup in which I have some custom artifacts that I use
> as dependencies and unpack using unpack-dependencies.
> This all works great, but now I also have a custom plugin which needs one
> of the custom artifacts as dependency. I don't see those dependencies being
> unpacked.  Is this correct, or am I doing something wrong?
>
> I know I can add the dependency as "regular" dependency as workaround, but
> I'd like to be able to define the plugin in a parent's pluginManagement
> with it's dependencies so that dependant project can enable the plugin when
> needed without having to define the dependency, or always have it being
> unpacked even if not needed.
>
> Basically my pom looks like this (meta):
>
> // Those are unpacked as expected
> 
> 
> 
>
> // Those dependencies are not unpacked
> 
> 
> 
> 
> 
> 
> 
>
> --
> Met vriendelijke groet,
>
> Alexander Broekhuis
>

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

Re: Dependency is missed while using maven-assembly-plugin

[Сергей Вайсман]

Hello, Thorsten

Thank you very much for the help! Yes, this is the reason of my problem.

I tested it on next releases of batik and found that the dependency 
structure

changed in next versions and there's no batik-js in dependency tree.
Unfortunately, I couldn't upgrade version because in real project these
batik 1.7 libraries are used in some third-party plugin used by our
GUI developers.

For my case it was convenient to use exclusions for batik-script and
batik-bridge. And use these excluded dependencies external.
Like this.

    
        
            internal-module-groupId
internal-module-artifactId
            
                
org.apache.xmlgraphics
batik-bridge
                
                
org.apache.xmlgraphics
batik-script
                
            
        
        
            org.apache.xmlgraphics
            batik-script
            1.7
        
        
            org.apache.xmlgraphics
            batik-bridge
            1.7
        
    


Anyway, thank you for your responses!
Have a nice day!


--
Regards,
Sergey Vaysman


On 03.04.2018 14:05, Thorsten Heit wrote:

Hi Sergey,


I updated to the latest maven version 3.5.3 and configured the project
to use
the latest maven-assembly-plugin version 3.1.0.

You seem to be hit by
https://issues.apache.org/jira/projects/MASSEMBLY/issues/MASSEMBLY-782.

In short: You have circular dependencies in Batik 1.7:
batik-bridge -> batik-script -> batik-bridge...

Can you use a newer version of batik-transcoder such as 1.8, 1.9 or 1.9.1
(all available on Maven Central)?


Regards

Thorsten



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

Re: Re: Dependency is missed while using maven-assembly-plugin

[Thorsten Heit]

Hi Sergey,

> I updated to the latest maven version 3.5.3 and configured the project 
> to use
> the latest maven-assembly-plugin version 3.1.0.

You seem to be hit by 
https://issues.apache.org/jira/projects/MASSEMBLY/issues/MASSEMBLY-782.

In short: You have circular dependencies in Batik 1.7:
batik-bridge -> batik-script -> batik-bridge...

Can you use a newer version of batik-transcoder such as 1.8, 1.9 or 1.9.1 
(all available on Maven Central)?


Regards

Thorsten

Re: Re: Dependency is missed while using maven-assembly-plugin

[Thorsten Heit]

Hi,

> The first thing I need to mention that I gave you a wrong version of 
> maven-assembly-plugin.
> Maven-assembly-plugin version: 2.2-beta-5
> Apache Maven 3.2.5 (12a6b3acb947671f09b81f49094c53f426d8cea1; 
> 2014-12-14T20:29:23+03:00)
> Maven home: C:\soft\apache-maven-3.2.5
> Java version: 1.8.0_131, vendor: Oracle Corporation
> Java home: C:\Program Files\Java\jdk1.8.0_131\jre
> Default locale: ru_RU, platform encoding: Cp1251
> OS name: "windows 7", version: "6.1", arch: "amd64", family: "dos"

Can you try with with m-assembly-p 3.1.0 and see whether this behaves 
different?
Could you switch to a newer version of Maven, i.e. 3.5.3 (the newest?


Regards

Thorsten

Re: Dependency is missed while using maven-assembly-plugin

[Martin Gainty]

ran mvn package against pom.xml from supplied project.zip with no missing 
dependencies:


[DEBUG] Goal:  
org.apache.maven.plugins:maven-assembly-plugin:2.2-beta-5:single (default)
[DEBUG] Style: Regular
[DEBUG] Configuration: 

  ${appendAssemblyId}
  ${attach}
  
  ${classifier}
  ${descriptor}
  ${descriptorId}
  
src/main/assembly/assembly-descriptor.xml
  
  ${assembly.dryRun}
  
  
  ${ignoreMissingDescriptor}
  ${includeSite}
  
  ${session}
  
  
  
  
  ${runOnlyAtExecutionRoot}
  
  ${skipAssembly}
  ${tarLongFileMode}
  
  

[DEBUG] ===
[DEBUG] Dependency collection stats: {ConflictMarker.analyzeTime=1972051, 
ConflictMarker.markTime=738132, ConflictMarker.nodeCount=84, 
ConflictIdSorter.graphTime=1371731, ConflictIdSorter.topsortTime=935252, 
ConflictIdSorter.conflictIdCount=24, ConflictIdSorter.conflictIdCycleCount=3, 
ConflictResolver.totalTime=8674975, ConflictResolver.conflictItemCount=82, 
DefaultDependencyCollector.collectTime=137005478, 
DefaultDependencyCollector.transformTime=16792725}
[DEBUG] ru.spi2.test:sbercap-dependencies:jar:1.0-SNAPSHOT
[DEBUG]org.apache.xmlgraphics:batik-transcoder:jar:1.7:compile
[DEBUG]   org.apache.xmlgraphics:fop:jar:0.94:compile
[DEBUG]  org.apache.xmlgraphics:xmlgraphics-commons:jar:1.2:compile
[DEBUG]  commons-logging:commons-logging:jar:1.0.4:compile
[DEBUG]  commons-io:commons-io:jar:1.1:compile
[DEBUG]  
org.apache.avalon.framework:avalon-framework-api:jar:4.3.1:compile
[DEBUG]  
org.apache.avalon.framework:avalon-framework-impl:jar:4.3.1:compile
[DEBUG]   org.apache.xmlgraphics:batik-awt-util:jar:1.7:compile
[DEBUG]   org.apache.xmlgraphics:batik-bridge:jar:1.7:compile
[DEBUG]  org.apache.xmlgraphics:batik-anim:jar:1.7:compile
[DEBUG]  org.apache.xmlgraphics:batik-css:jar:1.7:compile
[DEBUG]  org.apache.xmlgraphics:batik-ext:jar:1.7:compile
[DEBUG]  org.apache.xmlgraphics:batik-parser:jar:1.7:compile
[DEBUG]  org.apache.xmlgraphics:batik-script:jar:1.7:compile
[DEBUG] org.apache.xmlgraphics:batik-js:jar:1.7:compile


I am baffled why your dependency manager is skipping batik-js:1.7?


with same pom.xml can you
mvn dependency:tree >output

and send us output
?

Martin
__




From: Сергей Вайсман 
Sent: Monday, April 2, 2018 10:24 AM
To: users@maven.apache.org
Subject: Dependency is missed while using maven-assembly-plugin

Hello.

I have a problem using maven-assembly-plugin.

I want to get during package phase a directory with all project dependencies.
But I have a transitive dependency with compile scope which is missed from
assembly output directory.

The missed jar is batik-js-1.7.jar. Here is a dependency tree for this jar

[INFO] --- maven-dependency-plugin:2.8:tree (default-cli) @ 
sbercap-dependencies ---
[INFO] ru.spi2.test:sbercap-dependencies:jar:1.0-SNAPSHOT
[INFO] \- org.apache.xmlgraphics:batik-transcoder:jar:1.7:compile
...
[INFO]+- org.apache.xmlgraphics:batik-bridge:jar:1.7:compile
[INFO]|  +- org.apache.xmlgraphics:batik-anim:jar:1.7:compile
[INFO]|  +- org.apache.xmlgraphics:batik-css:jar:1.7:compile
[INFO]|  +- org.apache.xmlgraphics:batik-ext:jar:1.7:compile
[INFO]|  +- org.apache.xmlgraphics:batik-parser:jar:1.7:compile
[INFO]|  +- org.apache.xmlgraphics:batik-script:jar:1.7:compile
[INFO]|  |  \- org.apache.xmlgraphics:batik-js:jar:1.7:compile
...

When assembly plugin is finished, others dependencies (batik-anim-1.7.jar,
batik-css-1.7.jar) are added to output directory successfully. The 
batik-js-1.7.jar
is missed (screenshot no-batik-js-in-assembly-output.png attached).

On the other side, if I try to copy all dependencies using 
maven-dependency-plugin,
the batik-js-1.7.jar is successfully added to the folder (screenshot
batik-js-in-dependencies attached).

Here is my dependencies and build blocks from pom.xml



org.apache.xmlgraphics
batik-transcoder
1.7






org.apache.maven.plugins
maven-dependency-plugin


copy
package

copy-dependencies



${project.build.directory}/dependency-libs







org.apache.maven.plugins
maven-assembly-plugin


package

single

   

Re: Please officially support RELEASE and LATEST (was: Re: dependency question)

[Curtis Rueden]

Hi Charles & everyone,

> To prevent SNAPSHOT churn you can use a plugin like
> exists-maven-plugin
> (https://chonton.github.io/exists-maven-plugin/0.0.2/plugin-info.html
> )
> to prevent re-releasing unchanged artifacts.

Thanks for the suggestion. I think exists-maven-plugin is really useful for
some scenarios.

However, I want to comment that I think one should not use
exists-maven-plugin in this way to address a symptom—400 forbidden errors
when redeploying same version to remote repository—rather than the root
problem of having two commits with the same release version number. With
this scheme, any time you build a commit from the history including the
"install" phase (e.g., if testing something with "git bisect"), you may end
up overwriting the release version in your local repository cache with
something which is _not_ actually the release build of the component. So I
think it is dangerous to lean on exists-maven-plugin in this way. I
actually _want_ the build to fail in the CI at the deploy step, to give me
a heads up that there are two commits like this, so that the problem can be
fixed before even more commits are made at that same version number.

Regards,
Curtis

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


On Mon, Apr 24, 2017 at 9:09 PM, Charles Honton  wrote:

> To prevent SNAPSHOT churn you can use a plugin like exists-maven-plugin (
> https://chonton.github.io/exists-maven-plugin/0.0.2/plugin-info.html <
> https://chonton.github.io/exists-maven-plugin/0.0.2/plugin-info.html>) to
> prevent re-releasing unchanged artifacts.
>
> chas
>
> > On Apr 24, 2017, at 1:52 PM, Curtis Rueden  wrote:
> >
> > because every release concludes
> > with a "bump to next development cycle" commit
>
>

Re: Please officially support RELEASE and LATEST (was: Re: dependency question)

[Charles Honton]

To prevent SNAPSHOT churn you can use a plugin like exists-maven-plugin 
(https://chonton.github.io/exists-maven-plugin/0.0.2/plugin-info.html 
) to 
prevent re-releasing unchanged artifacts.

chas

> On Apr 24, 2017, at 1:52 PM, Curtis Rueden  wrote:
> 
> because every release concludes
> with a "bump to next development cycle" commit

Re: Please officially support RELEASE and LATEST (was: Re: dependency question)

[mike digioia]

SUBMIT ME

On Mon, Apr 24, 2017 at 1:52 PM, Curtis Rueden  wrote:

> Hi Karl,
>
> Thanks very much for your reply!
>
> > Not only for displaying...you can also use it to update them...
>
> Understood. But I actually don't want to always auto-update everything to
> latest releases. The point of the BOM is that the versions it references
> have been tested to work together. Especially for things like major
> breaking releases of third party components, we need to do those updates
> manually and carefully.
>
> > Maybe I misunderstand a thing here but the first part can be answered
> > by using your version control? Make a diff between latest release tag
> > and the current trunk/master ? If a component needs a release is
> > something which only can being answered by a human...
>
> Right. That is actually what our tooling was doing until now. However, the
> process is laborious and slow. For each of our ~200 first-party components
> whose GAVs are listed in the BOM, the tooling needs to:
>
> - Fetch the POM for the GAV in question.
> - Extract the  section from the (effective) POM.
> - Clone the indicated SCM locally (in our case: always a Git repository
> from GitHub).
> - Do the relevant git command(s) to decide whether master has really
> changed since the last release.
>
> It's the cloning step that is especially expensive here, even if you limit
> cloning depth.
>
> I came up with a (I hope) much simpler solution which does not rely on the
> SCM at all, but only on Maven and our remote repository manager:
>
> 1) Extract the component's versions/release tag from maven-metadata.xml of
> the relevant GA in the remote MRM.
> 2) Check the timestamp of that release's POM artifact in the remote MRM.
> 3) Extract the versions/lastUpdated tag from maven-metadata.xml of the
> relevant GA in the remote MRM.
> 4) Compare the release timestamp vs. the lastUpdated timestamp; if >30min
> different, real changes have occurred since the last release.
>
> In this way, I no longer have to clone 200 repositories just to confirm
> what the MRM already stores in its metadata. I also do not rely on the
>  tag being correct, nor even that the artifact's sources reside in
> public SCM anywhere. So I can now report on third-party components as well.
>
> Furthermore, I am in the process of updating step 1 above to lean on "mvn
> -U -s settings.xml -Dverbose=true versions:display-dependency-updates"
> instead, since that also rolls in an update of our MRM's public content
> group including everything it proxies. (The settings.xml here defines our
> MRM as the sole mirror.) So then, the MRM metadata is (fingers crossed!)
> guaranteed to be up-to-date during steps 2-4.
>
> > But might it be a good idea for a plugin ? If we could get more
> > concrete I'm willing to implement such things if this will help...
>
> I am writing a shell script right now, but may be willing to contribute
> code to a plugin if this sort of thing is useful enough to a sufficient
> number of people.
>
> > What is the problem with that? Your repository manager should be
> > configured in that way that SNAPSHOT's will automatically being
> > removed after a time ?
>
> My point is that if I run "mvn -U -DallowSnapshots=true
> versions:display-dependency-updates" it will always tell me that
> everything
> has a newer snapshot version available, because every release concludes
> with a "bump to next development cycle" commit, which triggers a CI build
> that deploys a newer artifact than the release artifact. What I need to
> know is whether a new version (snapshot or otherwise) has been pushed
> _after some reasonable grace period_ since the last release version was
> cut. The lastUpdated tag of the maven-metadata.xml is actually perfect for
> this, as described above.
>
> > Can you list some of those use cases please which you are believe in ?
>
> Sure! My two most major ones right now are:
>
> - My jrun script (https://github.com/ctrueden/jrun) bootstraps a runtime
> environment for a given "endpoint" which is defined as a GAV, or even
> simply a GA with V defaulting to RELEASE. If RELEASE were to stop working,
> I would have to implement special code to discern the latest release in
> some other way—I guess by checking the remote's maven-metadata.xml and
> looking at the versions/release tag myself.
>
> - We use LATEST to override the version of components—including whole
> sub-collections of components at a time—for easier SNAPSHOT coupling for
> local development between components. E.g., in Eclipse, the dependency will
> automatically switch from being a library/JAR dependency to being a project
> dependency. See this profile for an example: https://github.com/
> scijava/pom-scijava/blob/pom-scijava-14.0.0/pom.xml#L2634-L2683. See also
> http://imagej.net/Architecture#Using_snapshot_couplings_during_development
> .
> If LATEST goes away, I guess I can use [0,) everywhere, but that is pretty
> non-intuitive by comparison.
>
> My intuition 

Re: Please officially support RELEASE and LATEST (was: Re: dependency question)

[Curtis Rueden]

Hi Karl,

Thanks very much for your reply!

> Not only for displaying...you can also use it to update them...

Understood. But I actually don't want to always auto-update everything to
latest releases. The point of the BOM is that the versions it references
have been tested to work together. Especially for things like major
breaking releases of third party components, we need to do those updates
manually and carefully.

> Maybe I misunderstand a thing here but the first part can be answered
> by using your version control? Make a diff between latest release tag
> and the current trunk/master ? If a component needs a release is
> something which only can being answered by a human...

Right. That is actually what our tooling was doing until now. However, the
process is laborious and slow. For each of our ~200 first-party components
whose GAVs are listed in the BOM, the tooling needs to:

- Fetch the POM for the GAV in question.
- Extract the  section from the (effective) POM.
- Clone the indicated SCM locally (in our case: always a Git repository
from GitHub).
- Do the relevant git command(s) to decide whether master has really
changed since the last release.

It's the cloning step that is especially expensive here, even if you limit
cloning depth.

I came up with a (I hope) much simpler solution which does not rely on the
SCM at all, but only on Maven and our remote repository manager:

1) Extract the component's versions/release tag from maven-metadata.xml of
the relevant GA in the remote MRM.
2) Check the timestamp of that release's POM artifact in the remote MRM.
3) Extract the versions/lastUpdated tag from maven-metadata.xml of the
relevant GA in the remote MRM.
4) Compare the release timestamp vs. the lastUpdated timestamp; if >30min
different, real changes have occurred since the last release.

In this way, I no longer have to clone 200 repositories just to confirm
what the MRM already stores in its metadata. I also do not rely on the
 tag being correct, nor even that the artifact's sources reside in
public SCM anywhere. So I can now report on third-party components as well.

Furthermore, I am in the process of updating step 1 above to lean on "mvn
-U -s settings.xml -Dverbose=true versions:display-dependency-updates"
instead, since that also rolls in an update of our MRM's public content
group including everything it proxies. (The settings.xml here defines our
MRM as the sole mirror.) So then, the MRM metadata is (fingers crossed!)
guaranteed to be up-to-date during steps 2-4.

> But might it be a good idea for a plugin ? If we could get more
> concrete I'm willing to implement such things if this will help...

I am writing a shell script right now, but may be willing to contribute
code to a plugin if this sort of thing is useful enough to a sufficient
number of people.

> What is the problem with that? Your repository manager should be
> configured in that way that SNAPSHOT's will automatically being
> removed after a time ?

My point is that if I run "mvn -U -DallowSnapshots=true
versions:display-dependency-updates" it will always tell me that everything
has a newer snapshot version available, because every release concludes
with a "bump to next development cycle" commit, which triggers a CI build
that deploys a newer artifact than the release artifact. What I need to
know is whether a new version (snapshot or otherwise) has been pushed
_after some reasonable grace period_ since the last release version was
cut. The lastUpdated tag of the maven-metadata.xml is actually perfect for
this, as described above.

> Can you list some of those use cases please which you are believe in ?

Sure! My two most major ones right now are:

- My jrun script (https://github.com/ctrueden/jrun) bootstraps a runtime
environment for a given "endpoint" which is defined as a GAV, or even
simply a GA with V defaulting to RELEASE. If RELEASE were to stop working,
I would have to implement special code to discern the latest release in
some other way—I guess by checking the remote's maven-metadata.xml and
looking at the versions/release tag myself.

- We use LATEST to override the version of components—including whole
sub-collections of components at a time—for easier SNAPSHOT coupling for
local development between components. E.g., in Eclipse, the dependency will
automatically switch from being a library/JAR dependency to being a project
dependency. See this profile for an example: https://github.com/
scijava/pom-scijava/blob/pom-scijava-14.0.0/pom.xml#L2634-L2683. See also
http://imagej.net/Architecture#Using_snapshot_couplings_during_development.
If LATEST goes away, I guess I can use [0,) everywhere, but that is pretty
non-intuitive by comparison.

My intuition also strongly tells me that there are other valid use cases
here; I can think harder about it if you are still not convinced. Maybe
others here can respond as well with their use cases?

Moreover, I don't see the value of discontinuing these special keywords. It

Re: Please officially support RELEASE and LATEST (was: Re: dependency question)

[Karl Heinz Marbaise]

Hi,

On 24/04/17 19:46, Curtis Rueden wrote:

Hi Jesse,


Prefer to harden the version # in a corporate pom. Then use
versions-m-p to detect and update bulk dependencies across all our
projects. We manage about 350 dependencies in the corporate pom


Definitely agreed. I am managing a similar number, and indeed versions-m-p
is super nice for displaying which dependencies have new versions
available. (Must remember to feed -U to mvn, though!)



Not only for displaying...you can also use it to update them...

Yes I know there are issues in that plugin (I'm currently working on an 
larger update 
https://github.com/mojohaus/versions-maven-plugin/commits/master)...


Also updating to newer release versions can be done with that and 
correctly checked in into version control.



I am still looking for an easy way to answer the other question: "Have
there been changes to this component since the last release" -- i.e. "Does
this component need a new release"


Maybe I misunderstand a thing here but the first part can be answered by 
using your version control? Make a diff between latest release tag and 
the current trunk/master ? If a component needs a release is something 
which only can being answered by a human...


But might it be a good idea for a plugin ? If we could get more concrete 
I'm willing to implement such things if this will help...



> -- since we use release-ready master

branches.


> I think the allowSnapshots property is not sufficient in my case,

since the CI will always deploy a new SNAPSHOT in response to the "Bump to
next development cycle" commit which does nothing else besides bump the
version on master after each release.


What is the problem with that? Your repository manager should be 
configured in that way that SNAPSHOT's will automatically being removed 
after a time ?






And even if somehow the versions-m-p had a magicallySolveAllMyProblems flag
here,



I still believe there are other use cases where RELEASE and LATEST
are useful -- and that deprecating/removing them does not do anything
constructive to address the problem of irreproducible builds.


Can you list some of those use cases please which you are believe in ?

And what do you think is constructive to address the problem of 
reproducibility ?






Regards,
Curtis

P.S. to Rick Huff: Thanks for taking the time to reply. :-)

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


On Mon, Apr 24, 2017 at 12:37 PM, jieryn  wrote:


Prefer to harden the version # in a corporate pom. Then use
versions-m-p to detect and update bulk dependencies across all our
projects. We manage about 350 dependencies in the corporate pom, and
that doesn't even include the huge number that are scope=import for
Arquillian and Selenium, etc.

On Mon, Apr 24, 2017 at 12:58 PM, Curtis Rueden  wrote:

I would like to argue for the inclusion / restoration / continued
support of the RELEASE and LATEST tags.


Really? No one else cares enough to respond?

I am very often running into use cases where the easiest solution seems

to

be LATEST and/or RELEASE. I have to manage a large Bill of Materials POM
and I need to know things like "which components have new releases
available" and "which components have SNAPSHOT builds since the last
release." How do other people answer these questions without custom
tooling, and without using LATEST or RELEASE tags?


You can simply let run versions-maven-plugin get a report about updates 
or just let update versions-maven-plugin the pom and if you checkin the 
pom the version control will find out if something has changed or not ?


Apart from that maybe I misunderstand a thing here, but using the 
versions-maven-plugin is custom tooling for you?






Regards,
Curtis

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


On Thu, Apr 13, 2017 at 10:51 AM, Curtis Rueden 

wrote:



Hi Maven developers,

I would like to argue for the inclusion / restoration / continued

support

of the RELEASE and LATEST tags.

Reasons:

1) There are many valid use cases for them. For example, my script jrun
[1] uses RELEASE right now to make it easier to launch a Maven GAV.
Launching e.g. the Jython REPL is as easy as "jrun
org.python:jython-standalone" from the CLI. But this relies on RELEASE
working. I know that Maven is traditionally viewed as primarily a
build-time tool, but it is also extremely useful for synthesizing

runtime

environments, and IMHO underutilized in this regard.

2) For LATEST, you can achieve basically the same behavior using a

version

range like [0,). There is no other way (that I know of) to achieve what

the

RELEASE tag does.

3) The argument that they harm reproducibility is totally valid. But so

do

SNAPSHOTs, and so do version ranges. And those have not been

Re: Please officially support RELEASE and LATEST (was: Re: dependency question)

[Richard Sand]

Are you using the versions plugin? I can't live without it, I've got it 
in my corporate master base POM


http://www.mojohaus.org/versions-maven-plugin/

-Richard


-- Original Message --
From: "Curtis Rueden" <ctrue...@wisc.edu>
To: "Maven Users List" <users@maven.apache.org>
Sent: 4/24/2017 1:46:59 PM
Subject: Re: Please officially support RELEASE and LATEST (was: Re: 
dependency question)



Hi Jesse,


 Prefer to harden the version # in a corporate pom. Then use
 versions-m-p to detect and update bulk dependencies across all our
 projects. We manage about 350 dependencies in the corporate pom


Definitely agreed. I am managing a similar number, and indeed 
versions-m-p

is super nice for displaying which dependencies have new versions
available. (Must remember to feed -U to mvn, though!)

I am still looking for an easy way to answer the other question: "Have
there been changes to this component since the last release" -- i.e. 
"Does

this component need a new release" -- since we use release-ready master
branches. I think the allowSnapshots property is not sufficient in my 
case,
since the CI will always deploy a new SNAPSHOT in response to the "Bump 
to

next development cycle" commit which does nothing else besides bump the
version on master after each release.

And even if somehow the versions-m-p had a magicallySolveAllMyProblems 
flag
here, I still believe there are other use cases where RELEASE and 
LATEST

are useful -- and that deprecating/removing them does not do anything
constructive to address the problem of irreproducible builds.

Regards,
Curtis

P.S. to Rick Huff: Thanks for taking the time to reply. :-)

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


On Mon, Apr 24, 2017 at 12:37 PM, jieryn <jie...@gmail.com> wrote:


 Prefer to harden the version # in a corporate pom. Then use
 versions-m-p to detect and update bulk dependencies across all our
 projects. We manage about 350 dependencies in the corporate pom, and
 that doesn't even include the huge number that are scope=import for
 Arquillian and Selenium, etc.

 On Mon, Apr 24, 2017 at 12:58 PM, Curtis Rueden <ctrue...@wisc.edu> 
wrote:

 >> I would like to argue for the inclusion / restoration / continued
 >> support of the RELEASE and LATEST tags.
 >
 > Really? No one else cares enough to respond?
 >
 > I am very often running into use cases where the easiest solution 
seems

 to
 > be LATEST and/or RELEASE. I have to manage a large Bill of 
Materials POM

 > and I need to know things like "which components have new releases
 > available" and "which components have SNAPSHOT builds since the 
last

 > release." How do other people answer these questions without custom
 > tooling, and without using LATEST or RELEASE tags?
 >
 > Regards,
 > Curtis
 >
 > --
 > Curtis Rueden
 > LOCI software architect - https://loci.wisc.edu/software
 > ImageJ2 lead, Fiji maintainer - https://imagej.net/User:Rueden
 >
 >
 > On Thu, Apr 13, 2017 at 10:51 AM, Curtis Rueden <ctrue...@wisc.edu>
 wrote:
 >
 >> Hi Maven developers,
 >>
 >> I would like to argue for the inclusion / restoration / continued
 support
 >> of the RELEASE and LATEST tags.
 >>
 >> Reasons:
 >>
 >> 1) There are many valid use cases for them. For example, my script 
jrun
 >> [1] uses RELEASE right now to make it easier to launch a Maven 
GAV.

 >> Launching e.g. the Jython REPL is as easy as "jrun
 >> org.python:jython-standalone" from the CLI. But this relies on 
RELEASE

 >> working. I know that Maven is traditionally viewed as primarily a
 >> build-time tool, but it is also extremely useful for synthesizing
 runtime
 >> environments, and IMHO underutilized in this regard.
 >>
 >> 2) For LATEST, you can achieve basically the same behavior using a
 version
 >> range like [0,). There is no other way (that I know of) to achieve 
what

 the
 >> RELEASE tag does.
 >>
 >> 3) The argument that they harm reproducibility is totally valid. 
But so

 do
 >> SNAPSHOTs, and so do version ranges. And those have not been
 deprecated. So
 >> why are RELEASE and LATEST eschewed so heavily?
 >>
 >> Orthogonally: I think it would be awesome to warn about 
irreproducible

 >> builds, be they from SNAPSHOTs, version ranges, or these special
 keywords.
 >> People need to know when their builds are vulnerable. But there 
should
 >> probably also be a property to disable this warning, for the cases 
when

 the
 >> developer intentionally wants/needs to use them, and knows what 
they are

 >> doing. If the issue is just that no ones has time to work on e.g.

Re: Please officially support RELEASE and LATEST (was: Re: dependency question)

[Curtis Rueden]

Hi Jesse,

> Prefer to harden the version # in a corporate pom. Then use
> versions-m-p to detect and update bulk dependencies across all our
> projects. We manage about 350 dependencies in the corporate pom

Definitely agreed. I am managing a similar number, and indeed versions-m-p
is super nice for displaying which dependencies have new versions
available. (Must remember to feed -U to mvn, though!)

I am still looking for an easy way to answer the other question: "Have
there been changes to this component since the last release" -- i.e. "Does
this component need a new release" -- since we use release-ready master
branches. I think the allowSnapshots property is not sufficient in my case,
since the CI will always deploy a new SNAPSHOT in response to the "Bump to
next development cycle" commit which does nothing else besides bump the
version on master after each release.

And even if somehow the versions-m-p had a magicallySolveAllMyProblems flag
here, I still believe there are other use cases where RELEASE and LATEST
are useful -- and that deprecating/removing them does not do anything
constructive to address the problem of irreproducible builds.

Regards,
Curtis

P.S. to Rick Huff: Thanks for taking the time to reply. :-)

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


On Mon, Apr 24, 2017 at 12:37 PM, jieryn  wrote:

> Prefer to harden the version # in a corporate pom. Then use
> versions-m-p to detect and update bulk dependencies across all our
> projects. We manage about 350 dependencies in the corporate pom, and
> that doesn't even include the huge number that are scope=import for
> Arquillian and Selenium, etc.
>
> On Mon, Apr 24, 2017 at 12:58 PM, Curtis Rueden  wrote:
> >> I would like to argue for the inclusion / restoration / continued
> >> support of the RELEASE and LATEST tags.
> >
> > Really? No one else cares enough to respond?
> >
> > I am very often running into use cases where the easiest solution seems
> to
> > be LATEST and/or RELEASE. I have to manage a large Bill of Materials POM
> > and I need to know things like "which components have new releases
> > available" and "which components have SNAPSHOT builds since the last
> > release." How do other people answer these questions without custom
> > tooling, and without using LATEST or RELEASE tags?
> >
> > Regards,
> > Curtis
> >
> > --
> > Curtis Rueden
> > LOCI software architect - https://loci.wisc.edu/software
> > ImageJ2 lead, Fiji maintainer - https://imagej.net/User:Rueden
> >
> >
> > On Thu, Apr 13, 2017 at 10:51 AM, Curtis Rueden 
> wrote:
> >
> >> Hi Maven developers,
> >>
> >> I would like to argue for the inclusion / restoration / continued
> support
> >> of the RELEASE and LATEST tags.
> >>
> >> Reasons:
> >>
> >> 1) There are many valid use cases for them. For example, my script jrun
> >> [1] uses RELEASE right now to make it easier to launch a Maven GAV.
> >> Launching e.g. the Jython REPL is as easy as "jrun
> >> org.python:jython-standalone" from the CLI. But this relies on RELEASE
> >> working. I know that Maven is traditionally viewed as primarily a
> >> build-time tool, but it is also extremely useful for synthesizing
> runtime
> >> environments, and IMHO underutilized in this regard.
> >>
> >> 2) For LATEST, you can achieve basically the same behavior using a
> version
> >> range like [0,). There is no other way (that I know of) to achieve what
> the
> >> RELEASE tag does.
> >>
> >> 3) The argument that they harm reproducibility is totally valid. But so
> do
> >> SNAPSHOTs, and so do version ranges. And those have not been
> deprecated. So
> >> why are RELEASE and LATEST eschewed so heavily?
> >>
> >> Orthogonally: I think it would be awesome to warn about irreproducible
> >> builds, be they from SNAPSHOTs, version ranges, or these special
> keywords.
> >> People need to know when their builds are vulnerable. But there should
> >> probably also be a property to disable this warning, for the cases when
> the
> >> developer intentionally wants/needs to use them, and knows what they are
> >> doing. If the issue is just that no ones has time to work on e.g.
> MNG-6206,
> >> I could try to make some time for it—I feel strongly enough about this
> >> issue.
> >>
> >> Thanks for any insight, workarounds, counterarguments, agreement.
> >> (Especially if you agree: please speak up, so the core Maven devs know
> I'm
> >> not just an outlier here!)
> >>
> >> Regards,
> >> Curtis
> >>
> >> [1] https://github.com/ctrueden/jrun
> >>
> >> --
> >> Curtis Rueden
> >> LOCI software architect - https://loci.wisc.edu/software
> >> ImageJ2 lead, Fiji maintainer - https://imagej.net/User:Rueden
> >>
>
> -
> To unsubscribe, e-mail: users-unsubscr...@maven.apache.org
> For additional commands, e-mail: 

Re: Please officially support RELEASE and LATEST (was: Re: dependency question)

[jieryn]

Prefer to harden the version # in a corporate pom. Then use
versions-m-p to detect and update bulk dependencies across all our
projects. We manage about 350 dependencies in the corporate pom, and
that doesn't even include the huge number that are scope=import for
Arquillian and Selenium, etc.

On Mon, Apr 24, 2017 at 12:58 PM, Curtis Rueden  wrote:
>> I would like to argue for the inclusion / restoration / continued
>> support of the RELEASE and LATEST tags.
>
> Really? No one else cares enough to respond?
>
> I am very often running into use cases where the easiest solution seems to
> be LATEST and/or RELEASE. I have to manage a large Bill of Materials POM
> and I need to know things like "which components have new releases
> available" and "which components have SNAPSHOT builds since the last
> release." How do other people answer these questions without custom
> tooling, and without using LATEST or RELEASE tags?
>
> Regards,
> Curtis
>
> --
> Curtis Rueden
> LOCI software architect - https://loci.wisc.edu/software
> ImageJ2 lead, Fiji maintainer - https://imagej.net/User:Rueden
>
>
> On Thu, Apr 13, 2017 at 10:51 AM, Curtis Rueden  wrote:
>
>> Hi Maven developers,
>>
>> I would like to argue for the inclusion / restoration / continued support
>> of the RELEASE and LATEST tags.
>>
>> Reasons:
>>
>> 1) There are many valid use cases for them. For example, my script jrun
>> [1] uses RELEASE right now to make it easier to launch a Maven GAV.
>> Launching e.g. the Jython REPL is as easy as "jrun
>> org.python:jython-standalone" from the CLI. But this relies on RELEASE
>> working. I know that Maven is traditionally viewed as primarily a
>> build-time tool, but it is also extremely useful for synthesizing runtime
>> environments, and IMHO underutilized in this regard.
>>
>> 2) For LATEST, you can achieve basically the same behavior using a version
>> range like [0,). There is no other way (that I know of) to achieve what the
>> RELEASE tag does.
>>
>> 3) The argument that they harm reproducibility is totally valid. But so do
>> SNAPSHOTs, and so do version ranges. And those have not been deprecated. So
>> why are RELEASE and LATEST eschewed so heavily?
>>
>> Orthogonally: I think it would be awesome to warn about irreproducible
>> builds, be they from SNAPSHOTs, version ranges, or these special keywords.
>> People need to know when their builds are vulnerable. But there should
>> probably also be a property to disable this warning, for the cases when the
>> developer intentionally wants/needs to use them, and knows what they are
>> doing. If the issue is just that no ones has time to work on e.g. MNG-6206,
>> I could try to make some time for it—I feel strongly enough about this
>> issue.
>>
>> Thanks for any insight, workarounds, counterarguments, agreement.
>> (Especially if you agree: please speak up, so the core Maven devs know I'm
>> not just an outlier here!)
>>
>> Regards,
>> Curtis
>>
>> [1] https://github.com/ctrueden/jrun
>>
>> --
>> Curtis Rueden
>> LOCI software architect - https://loci.wisc.edu/software
>> ImageJ2 lead, Fiji maintainer - https://imagej.net/User:Rueden
>>

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

Re: Please officially support RELEASE and LATEST (was: Re: dependency question)

[Curtis Rueden]

> I would like to argue for the inclusion / restoration / continued
> support of the RELEASE and LATEST tags.

Really? No one else cares enough to respond?

I am very often running into use cases where the easiest solution seems to
be LATEST and/or RELEASE. I have to manage a large Bill of Materials POM
and I need to know things like "which components have new releases
available" and "which components have SNAPSHOT builds since the last
release." How do other people answer these questions without custom
tooling, and without using LATEST or RELEASE tags?

Regards,
Curtis

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


On Thu, Apr 13, 2017 at 10:51 AM, Curtis Rueden  wrote:

> Hi Maven developers,
>
> I would like to argue for the inclusion / restoration / continued support
> of the RELEASE and LATEST tags.
>
> Reasons:
>
> 1) There are many valid use cases for them. For example, my script jrun
> [1] uses RELEASE right now to make it easier to launch a Maven GAV.
> Launching e.g. the Jython REPL is as easy as "jrun
> org.python:jython-standalone" from the CLI. But this relies on RELEASE
> working. I know that Maven is traditionally viewed as primarily a
> build-time tool, but it is also extremely useful for synthesizing runtime
> environments, and IMHO underutilized in this regard.
>
> 2) For LATEST, you can achieve basically the same behavior using a version
> range like [0,). There is no other way (that I know of) to achieve what the
> RELEASE tag does.
>
> 3) The argument that they harm reproducibility is totally valid. But so do
> SNAPSHOTs, and so do version ranges. And those have not been deprecated. So
> why are RELEASE and LATEST eschewed so heavily?
>
> Orthogonally: I think it would be awesome to warn about irreproducible
> builds, be they from SNAPSHOTs, version ranges, or these special keywords.
> People need to know when their builds are vulnerable. But there should
> probably also be a property to disable this warning, for the cases when the
> developer intentionally wants/needs to use them, and knows what they are
> doing. If the issue is just that no ones has time to work on e.g. MNG-6206,
> I could try to make some time for it—I feel strongly enough about this
> issue.
>
> Thanks for any insight, workarounds, counterarguments, agreement.
> (Especially if you agree: please speak up, so the core Maven devs know I'm
> not just an outlier here!)
>
> Regards,
> Curtis
>
> [1] https://github.com/ctrueden/jrun
>
> --
> Curtis Rueden
> LOCI software architect - https://loci.wisc.edu/software
> ImageJ2 lead, Fiji maintainer - https://imagej.net/User:Rueden
>

Please officially support RELEASE and LATEST (was: Re: dependency question)

[Curtis Rueden]

;>>>>
>>>>> Similar to version ranges, Maven will have to ask the remote repository
>>>>> about the latest known version in these cases, and will then use that.
>>>>>
>>>>> I want to emphasize, as others have mentioned, that using any of these
>>>>> strategies will result in _irreproducible builds_. That is, your code
>>>>>
>>>> might
>>>>
>>>>> build today, and then the same code will fail to build in the future,
>>>>> because the versions will resolve differently. The only way (I know of)
>>>>>
>>>> to
>>>>
>>>>> achieve reproducible builds is to use fixed release versions, always.
>>>>>
>>>>> Regards,
>>>>> Curtis
>>>>>
>>>>> --
>>>>> Curtis Rueden
>>>>> LOCI software architect - https://loci.wisc.edu/software
>>>>> ImageJ2 lead, Fiji maintainer - https://imagej.net/User:Rueden
>>>>>
>>>>>
>>>>> On Tue, Apr 11, 2017 at 9:57 AM, Magnanao, Hector <
>>>>>
>>>> hector.magna...@sap.com
>>>>
>>>>>
>>>>>> wrote:
>>>>>
>>>>> This is fine as long as the dependency is always set to
>>>>>>
>>>>> x.y.z-Snapshot
>>>
>>>> and
>>>>>
>>>>>> the dependency is always overwritten this way.  What if the producer
>>>>>> produces x.y.z.1-Snapshot, x.y.z.2-Snapshot, x.y.z.3-Snapshot and I
>>>>>>
>>>>> want
>>>>
>>>>> the dependent build to always get the latest in this case,
>>>>>> x.y.z.3-Snapshot ? The difference with this scenario is that the
>>>>>>
>>>>> producer
>>>>
>>>>> will always have a new build number.
>>>>>> As for your solution of using the range,  do I always have to change
>>>>>>
>>>>> the
>>>>
>>>>> pom file in the dependent build whenever a new build is produced by
>>>>>>
>>>>> the
>>>
>>>> producer ?
>>>>>>
>>>>>> -Original Message-
>>>>>> From: Benson Margulies [mailto:bimargul...@gmail.com]
>>>>>> Sent: Monday, April 10, 2017 10:39 AM
>>>>>> To: Maven Users List <users@maven.apache.org>
>>>>>> Subject: Re: dependency question
>>>>>>
>>>>>> On Mon, Apr 10, 2017 at 8:18 AM, Magnanao, Hector
>>>>>> <hector.magna...@sap.com> wrote:
>>>>>>
>>>>>>> I'm still a little confused about the answers I'm getting.  So, if
>>>>>>>
>>>>>> build
>>>>>
>>>>>> A is being updated with a new build number(even for a snapshot), and
>>>>>>
>>>>> build
>>>>>
>>>>>> B has it as a dependency in it's pom.file, how does the pom file in
>>>>>>
>>>>> Build B
>>>>>
>>>>>> need to look like in the dependency section so that it does get the
>>>>>>
>>>>> latest
>>>>>
>>>>>> snapshot build of build A ?
>>>>>>
>>>>>> This conversation seems to keep mixing up SNAPSHOT version processing
>>>>>> with various conventions for using version ranges.
>>>>>>
>>>>>> If the producer produces x.y.z-SNAPSHOT, and the consumer declares a
>>>>>> dependency on x.y.z-SNAPSHOT, every build of the consumer will go out
>>>>>> to the repositories to look for the latest snapshot build.
>>>>>>
>>>>>> Snapshots have risks and do not provide a repeatable build. Then
>>>>>> again, neither do ranges.
>>>>>>
>>>>>> If you don't want to use snapshots, then you write the dependency in
>>>>>> the consumer with a range
>>>>>>
>>>>>> (1.0-2.0]
>>>>>>
>>>>>> or whatever makes sense. This will cause builds of the consumer to go
>>>>>> out to repositories and try to find the newest version within the
>>>>>> range. it's up to you to bump the version in the producer, manually
>>>>>>
>>>&g

Stale wiki link question [was: Re: dependency question]

[Robert Kielty]

Hi,

I was interested in the below thread wrt to the deprecation of LATEST , RELEASE 
etc.

There is a ref http://docs.codehaus.org/display/MAVEN/Versioning on 
https://cwiki.apache.org/confluence/display/MAVEN/Maven+3.x+Compatibility+Notes#Maven3.xCompatibilityNotes-VersionComparison

I registered myself on the wiki and did a bit of digging and found the 
following page  https://cwiki.apache.org/confluence/display/MAVENOLD/Versioning

Would it be correct and or useful to update the above codehaus ref on 
https://cwiki.apache.org/confluence/display/MAVEN/Maven+3.x+Compatibility+Notes#Maven3.xCompatibilityNotes-VersionComparison
 to point to https://cwiki.apache.org/confluence/display/MAVENOLD/Versioning ?

Kind regards,
Robert Kielty
-Original Message-
From: Karl Heinz Marbaise [mailto:khmarba...@gmx.de]
Sent: 11 April 2017 22:57
To: Maven Users List
Subject: Re: dependency question

Hi,


On 11/04/17 23:38, Stephen Connolly wrote:
> On Tue 11 Apr 2017 at 20:55, Curtis Rueden <ctrue...@wisc.edu> wrote:
>
>> Hi Stephen,
>>
>>>> There is a special version keyword LATEST which means the very
>>>> newest version, snapshot or otherwise. And RELEASE means the newest
>>>> release
>>>> (non-SNAPSHOT) version.
>>>
>>> Support for those were dropped in Maven 3
>>
>> By "support" do you mean "social support" as opposed to technical
>> functionality?
>
>
> They were supposed to be removed.
>
> If they are working now, that's a bug

Unfortunately they are working ;-(..

https://issues.apache.org/jira/browse/MNG-6206

Kind regards
Karl Heinz Marbaise

>
>
>>
>> Because they are still present in the codebase, and they still work
>> technically:
>>https://github.com/apache/maven/blob/master/maven-
>> resolver-provider/src/main/java/org/apache/maven/repository/internal/
>> DefaultVersionResolver.java#L188-L197
>>
>> Regards,
>> Curtis
>>
>> --
>> Curtis Rueden
>> LOCI software architect - https://loci.wisc.edu/software
>> ImageJ2 lead, Fiji maintainer - https://imagej.net/User:Rueden
>>
>>
>> On Tue, Apr 11, 2017 at 2:44 PM, Stephen Connolly <
>> stephen.alan.conno...@gmail.com> wrote:
>>
>>> On Tue 11 Apr 2017 at 16:02, Curtis Rueden <ctrue...@wisc.edu> wrote:
>>>
>>>> Hi Hector,
>>>>
>>>>> This is fine as long as the dependency is always set to
>> x.y.z-Snapshot
>>>>> and the dependency is always overwritten this way.  What if the
>>>>> producer produces x.y.z.1-Snapshot, x.y.z.2-Snapshot,
>> x.y.z.3-Snapshot
>>>>> and I want the dependent build to always get the latest in this
>>>>> case, x.y.z.3-Snapshot ?
>>>>
>>>> There is a special version keyword LATEST which means the very
>>>> newest version, snapshot or otherwise. And RELEASE means the newest
>>>> release
>>>> (non-SNAPSHOT) version.
>>>
>>>
>>> Support for those were dropped in Maven 3
>>>
>>> *and* anyway they were only for *plugin* versions because the plugin
>>> version does not support ranges.
>>>
>>> For dependency versions, define a range
>>>
>>>>
>>>>
>>>> Similar to version ranges, Maven will have to ask the remote
>>>> repository about the latest known version in these cases, and will then 
>>>> use that.
>>>>
>>>> I want to emphasize, as others have mentioned, that using any of
>>>> these strategies will result in _irreproducible builds_. That is,
>>>> your code
>>> might
>>>> build today, and then the same code will fail to build in the
>>>> future, because the versions will resolve differently. The only way
>>>> (I know of)
>>> to
>>>> achieve reproducible builds is to use fixed release versions, always.
>>>>
>>>> Regards,
>>>> Curtis
>>>>
>>>> --
>>>> Curtis Rueden
>>>> LOCI software architect - https://loci.wisc.edu/software
>>>> ImageJ2 lead, Fiji maintainer - https://imagej.net/User:Rueden
>>>>
>>>>
>>>> On Tue, Apr 11, 2017 at 9:57 AM, Magnanao, Hector <
>>> hector.magna...@sap.com
>>>>>
>>>> wrote:
>>>>
>>>>> This is fine as long as the dependency is always set to
>> x.y.z-Snapshot
>>>> and
>>>>> the dependency is always overwritten this way.  What if the
>>>>> produce

Re: dependency question

[Karl Heinz Marbaise]

Hi,


On 11/04/17 23:38, Stephen Connolly wrote:

On Tue 11 Apr 2017 at 20:55, Curtis Rueden <ctrue...@wisc.edu> wrote:


Hi Stephen,


There is a special version keyword LATEST which means the very newest
version, snapshot or otherwise. And RELEASE means the newest release
(non-SNAPSHOT) version.


Support for those were dropped in Maven 3


By "support" do you mean "social support" as opposed to technical
functionality?



They were supposed to be removed.

If they are working now, that's a bug


Unfortunately they are working ;-(..

https://issues.apache.org/jira/browse/MNG-6206

Kind regards
Karl Heinz Marbaise






Because they are still present in the codebase, and they still work
technically:
   https://github.com/apache/maven/blob/master/maven-
resolver-provider/src/main/java/org/apache/maven/repository/internal/
DefaultVersionResolver.java#L188-L197

Regards,
Curtis

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


On Tue, Apr 11, 2017 at 2:44 PM, Stephen Connolly <
stephen.alan.conno...@gmail.com> wrote:


On Tue 11 Apr 2017 at 16:02, Curtis Rueden <ctrue...@wisc.edu> wrote:


Hi Hector,


This is fine as long as the dependency is always set to

x.y.z-Snapshot

and the dependency is always overwritten this way.  What if the
producer produces x.y.z.1-Snapshot, x.y.z.2-Snapshot,

x.y.z.3-Snapshot

and I want the dependent build to always get the latest in this case,
x.y.z.3-Snapshot ?


There is a special version keyword LATEST which means the very newest
version, snapshot or otherwise. And RELEASE means the newest release
(non-SNAPSHOT) version.



Support for those were dropped in Maven 3

*and* anyway they were only for *plugin* versions because the plugin
version does not support ranges.

For dependency versions, define a range




Similar to version ranges, Maven will have to ask the remote repository
about the latest known version in these cases, and will then use that.

I want to emphasize, as others have mentioned, that using any of these
strategies will result in _irreproducible builds_. That is, your code

might

build today, and then the same code will fail to build in the future,
because the versions will resolve differently. The only way (I know of)

to

achieve reproducible builds is to use fixed release versions, always.

Regards,
Curtis

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


On Tue, Apr 11, 2017 at 9:57 AM, Magnanao, Hector <

hector.magna...@sap.com



wrote:


This is fine as long as the dependency is always set to

x.y.z-Snapshot

and

the dependency is always overwritten this way.  What if the producer
produces x.y.z.1-Snapshot, x.y.z.2-Snapshot, x.y.z.3-Snapshot and I

want

the dependent build to always get the latest in this case,
x.y.z.3-Snapshot ? The difference with this scenario is that the

producer

will always have a new build number.
As for your solution of using the range,  do I always have to change

the

pom file in the dependent build whenever a new build is produced by

the

producer ?

-Original Message-
From: Benson Margulies [mailto:bimargul...@gmail.com]
Sent: Monday, April 10, 2017 10:39 AM
To: Maven Users List <users@maven.apache.org>
Subject: Re: dependency question

On Mon, Apr 10, 2017 at 8:18 AM, Magnanao, Hector
<hector.magna...@sap.com> wrote:

I'm still a little confused about the answers I'm getting.  So, if

build

A is being updated with a new build number(even for a snapshot), and

build

B has it as a dependency in it's pom.file, how does the pom file in

Build B

need to look like in the dependency section so that it does get the

latest

snapshot build of build A ?

This conversation seems to keep mixing up SNAPSHOT version processing
with various conventions for using version ranges.

If the producer produces x.y.z-SNAPSHOT, and the consumer declares a
dependency on x.y.z-SNAPSHOT, every build of the consumer will go out
to the repositories to look for the latest snapshot build.

Snapshots have risks and do not provide a repeatable build. Then
again, neither do ranges.

If you don't want to use snapshots, then you write the dependency in
the consumer with a range

(1.0-2.0]

or whatever makes sense. This will cause builds of the consumer to go
out to repositories and try to find the newest version within the
range. it's up to you to bump the version in the producer, manually

or

with the maven-release-plugin.






Scenario:

Build A has 3 builds in it with names 1-Snapshot, 2-snapshot,

3-snapshot

and they are all being uploaded to a repository.


What will the pom file in build B look like so that the next time

build

B is executed,  3-snapshot for build A will be picked up ?


-Original Message-
From: Karl Heinz Marbaise [mailto:khmarba...@gmx.de]
Sent: Frida

Re: dependency question

[Stephen Connolly]

On Tue 11 Apr 2017 at 20:55, Curtis Rueden <ctrue...@wisc.edu> wrote:

> Hi Stephen,
>
> > > There is a special version keyword LATEST which means the very newest
> > > version, snapshot or otherwise. And RELEASE means the newest release
> > > (non-SNAPSHOT) version.
> >
> > Support for those were dropped in Maven 3
>
> By "support" do you mean "social support" as opposed to technical
> functionality?


They were supposed to be removed.

If they are working now, that's a bug


>
> Because they are still present in the codebase, and they still work
> technically:
>https://github.com/apache/maven/blob/master/maven-
> resolver-provider/src/main/java/org/apache/maven/repository/internal/
> DefaultVersionResolver.java#L188-L197
>
> Regards,
> Curtis
>
> --
> Curtis Rueden
> LOCI software architect - https://loci.wisc.edu/software
> ImageJ2 lead, Fiji maintainer - https://imagej.net/User:Rueden
>
>
> On Tue, Apr 11, 2017 at 2:44 PM, Stephen Connolly <
> stephen.alan.conno...@gmail.com> wrote:
>
> > On Tue 11 Apr 2017 at 16:02, Curtis Rueden <ctrue...@wisc.edu> wrote:
> >
> > > Hi Hector,
> > >
> > > > This is fine as long as the dependency is always set to
> x.y.z-Snapshot
> > > > and the dependency is always overwritten this way.  What if the
> > > > producer produces x.y.z.1-Snapshot, x.y.z.2-Snapshot,
> x.y.z.3-Snapshot
> > > > and I want the dependent build to always get the latest in this case,
> > > > x.y.z.3-Snapshot ?
> > >
> > > There is a special version keyword LATEST which means the very newest
> > > version, snapshot or otherwise. And RELEASE means the newest release
> > > (non-SNAPSHOT) version.
> >
> >
> > Support for those were dropped in Maven 3
> >
> > *and* anyway they were only for *plugin* versions because the plugin
> > version does not support ranges.
> >
> > For dependency versions, define a range
> >
> > >
> > >
> > > Similar to version ranges, Maven will have to ask the remote repository
> > > about the latest known version in these cases, and will then use that.
> > >
> > > I want to emphasize, as others have mentioned, that using any of these
> > > strategies will result in _irreproducible builds_. That is, your code
> > might
> > > build today, and then the same code will fail to build in the future,
> > > because the versions will resolve differently. The only way (I know of)
> > to
> > > achieve reproducible builds is to use fixed release versions, always.
> > >
> > > Regards,
> > > Curtis
> > >
> > > --
> > > Curtis Rueden
> > > LOCI software architect - https://loci.wisc.edu/software
> > > ImageJ2 lead, Fiji maintainer - https://imagej.net/User:Rueden
> > >
> > >
> > > On Tue, Apr 11, 2017 at 9:57 AM, Magnanao, Hector <
> > hector.magna...@sap.com
> > > >
> > > wrote:
> > >
> > > > This is fine as long as the dependency is always set to
> x.y.z-Snapshot
> > > and
> > > > the dependency is always overwritten this way.  What if the producer
> > > > produces x.y.z.1-Snapshot, x.y.z.2-Snapshot, x.y.z.3-Snapshot and I
> > want
> > > > the dependent build to always get the latest in this case,
> > > > x.y.z.3-Snapshot ? The difference with this scenario is that the
> > producer
> > > > will always have a new build number.
> > > > As for your solution of using the range,  do I always have to change
> > the
> > > > pom file in the dependent build whenever a new build is produced by
> the
> > > > producer ?
> > > >
> > > > -Original Message-
> > > > From: Benson Margulies [mailto:bimargul...@gmail.com]
> > > > Sent: Monday, April 10, 2017 10:39 AM
> > > > To: Maven Users List <users@maven.apache.org>
> > > > Subject: Re: dependency question
> > > >
> > > > On Mon, Apr 10, 2017 at 8:18 AM, Magnanao, Hector
> > > > <hector.magna...@sap.com> wrote:
> > > > > I'm still a little confused about the answers I'm getting.  So, if
> > > build
> > > > A is being updated with a new build number(even for a snapshot), and
> > > build
> > > > B has it as a dependency in it's pom.file, how does the pom file in
> > > Build B
> > > > need to look like in the dependency section so that

Re: dependency question

[Curtis Rueden]

Hi Stephen,

> > There is a special version keyword LATEST which means the very newest
> > version, snapshot or otherwise. And RELEASE means the newest release
> > (non-SNAPSHOT) version.
>
> Support for those were dropped in Maven 3

By "support" do you mean "social support" as opposed to technical
functionality?

Because they are still present in the codebase, and they still work
technically:
   https://github.com/apache/maven/blob/master/maven-
resolver-provider/src/main/java/org/apache/maven/repository/internal/
DefaultVersionResolver.java#L188-L197

Regards,
Curtis

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


On Tue, Apr 11, 2017 at 2:44 PM, Stephen Connolly <
stephen.alan.conno...@gmail.com> wrote:

> On Tue 11 Apr 2017 at 16:02, Curtis Rueden <ctrue...@wisc.edu> wrote:
>
> > Hi Hector,
> >
> > > This is fine as long as the dependency is always set to x.y.z-Snapshot
> > > and the dependency is always overwritten this way.  What if the
> > > producer produces x.y.z.1-Snapshot, x.y.z.2-Snapshot, x.y.z.3-Snapshot
> > > and I want the dependent build to always get the latest in this case,
> > > x.y.z.3-Snapshot ?
> >
> > There is a special version keyword LATEST which means the very newest
> > version, snapshot or otherwise. And RELEASE means the newest release
> > (non-SNAPSHOT) version.
>
>
> Support for those were dropped in Maven 3
>
> *and* anyway they were only for *plugin* versions because the plugin
> version does not support ranges.
>
> For dependency versions, define a range
>
> >
> >
> > Similar to version ranges, Maven will have to ask the remote repository
> > about the latest known version in these cases, and will then use that.
> >
> > I want to emphasize, as others have mentioned, that using any of these
> > strategies will result in _irreproducible builds_. That is, your code
> might
> > build today, and then the same code will fail to build in the future,
> > because the versions will resolve differently. The only way (I know of)
> to
> > achieve reproducible builds is to use fixed release versions, always.
> >
> > Regards,
> > Curtis
> >
> > --
> > Curtis Rueden
> > LOCI software architect - https://loci.wisc.edu/software
> > ImageJ2 lead, Fiji maintainer - https://imagej.net/User:Rueden
> >
> >
> > On Tue, Apr 11, 2017 at 9:57 AM, Magnanao, Hector <
> hector.magna...@sap.com
> > >
> > wrote:
> >
> > > This is fine as long as the dependency is always set to x.y.z-Snapshot
> > and
> > > the dependency is always overwritten this way.  What if the producer
> > > produces x.y.z.1-Snapshot, x.y.z.2-Snapshot, x.y.z.3-Snapshot and I
> want
> > > the dependent build to always get the latest in this case,
> > > x.y.z.3-Snapshot ? The difference with this scenario is that the
> producer
> > > will always have a new build number.
> > > As for your solution of using the range,  do I always have to change
> the
> > > pom file in the dependent build whenever a new build is produced by the
> > > producer ?
> > >
> > > -Original Message-
> > > From: Benson Margulies [mailto:bimargul...@gmail.com]
> > > Sent: Monday, April 10, 2017 10:39 AM
> > > To: Maven Users List <users@maven.apache.org>
> > > Subject: Re: dependency question
> > >
> > > On Mon, Apr 10, 2017 at 8:18 AM, Magnanao, Hector
> > > <hector.magna...@sap.com> wrote:
> > > > I'm still a little confused about the answers I'm getting.  So, if
> > build
> > > A is being updated with a new build number(even for a snapshot), and
> > build
> > > B has it as a dependency in it's pom.file, how does the pom file in
> > Build B
> > > need to look like in the dependency section so that it does get the
> > latest
> > > snapshot build of build A ?
> > >
> > > This conversation seems to keep mixing up SNAPSHOT version processing
> > > with various conventions for using version ranges.
> > >
> > > If the producer produces x.y.z-SNAPSHOT, and the consumer declares a
> > > dependency on x.y.z-SNAPSHOT, every build of the consumer will go out
> > > to the repositories to look for the latest snapshot build.
> > >
> > > Snapshots have risks and do not provide a repeatable build. Then
> > > again, neither do ranges.
> > >
> > > If you don't want to use snapshots, then you wr

Re: dependency question

[Stephen Connolly]

On Tue 11 Apr 2017 at 16:02, Curtis Rueden <ctrue...@wisc.edu> wrote:

> Hi Hector,
>
> > This is fine as long as the dependency is always set to x.y.z-Snapshot
> > and the dependency is always overwritten this way.  What if the
> > producer produces x.y.z.1-Snapshot, x.y.z.2-Snapshot, x.y.z.3-Snapshot
> > and I want the dependent build to always get the latest in this case,
> > x.y.z.3-Snapshot ?
>
> There is a special version keyword LATEST which means the very newest
> version, snapshot or otherwise. And RELEASE means the newest release
> (non-SNAPSHOT) version.


Support for those were dropped in Maven 3

*and* anyway they were only for *plugin* versions because the plugin
version does not support ranges.

For dependency versions, define a range

>
>
> Similar to version ranges, Maven will have to ask the remote repository
> about the latest known version in these cases, and will then use that.
>
> I want to emphasize, as others have mentioned, that using any of these
> strategies will result in _irreproducible builds_. That is, your code might
> build today, and then the same code will fail to build in the future,
> because the versions will resolve differently. The only way (I know of) to
> achieve reproducible builds is to use fixed release versions, always.
>
> Regards,
> Curtis
>
> --
> Curtis Rueden
> LOCI software architect - https://loci.wisc.edu/software
> ImageJ2 lead, Fiji maintainer - https://imagej.net/User:Rueden
>
>
> On Tue, Apr 11, 2017 at 9:57 AM, Magnanao, Hector <hector.magna...@sap.com
> >
> wrote:
>
> > This is fine as long as the dependency is always set to x.y.z-Snapshot
> and
> > the dependency is always overwritten this way.  What if the producer
> > produces x.y.z.1-Snapshot, x.y.z.2-Snapshot, x.y.z.3-Snapshot and I want
> > the dependent build to always get the latest in this case,
> > x.y.z.3-Snapshot ? The difference with this scenario is that the producer
> > will always have a new build number.
> > As for your solution of using the range,  do I always have to change the
> > pom file in the dependent build whenever a new build is produced by the
> > producer ?
> >
> > -----Original Message-
> > From: Benson Margulies [mailto:bimargul...@gmail.com]
> > Sent: Monday, April 10, 2017 10:39 AM
> > To: Maven Users List <users@maven.apache.org>
> > Subject: Re: dependency question
> >
> > On Mon, Apr 10, 2017 at 8:18 AM, Magnanao, Hector
> > <hector.magna...@sap.com> wrote:
> > > I'm still a little confused about the answers I'm getting.  So, if
> build
> > A is being updated with a new build number(even for a snapshot), and
> build
> > B has it as a dependency in it's pom.file, how does the pom file in
> Build B
> > need to look like in the dependency section so that it does get the
> latest
> > snapshot build of build A ?
> >
> > This conversation seems to keep mixing up SNAPSHOT version processing
> > with various conventions for using version ranges.
> >
> > If the producer produces x.y.z-SNAPSHOT, and the consumer declares a
> > dependency on x.y.z-SNAPSHOT, every build of the consumer will go out
> > to the repositories to look for the latest snapshot build.
> >
> > Snapshots have risks and do not provide a repeatable build. Then
> > again, neither do ranges.
> >
> > If you don't want to use snapshots, then you write the dependency in
> > the consumer with a range
> >
> > (1.0-2.0]
> >
> > or whatever makes sense. This will cause builds of the consumer to go
> > out to repositories and try to find the newest version within the
> > range. it's up to you to bump the version in the producer, manually or
> > with the maven-release-plugin.
> >
> >
> >
> >
> > >
> > > Scenario:
> > >
> > > Build A has 3 builds in it with names 1-Snapshot, 2-snapshot,
> 3-snapshot
> > and they are all being uploaded to a repository.
> > >
> > > What will the pom file in build B look like so that the next time build
> > B is executed,  3-snapshot for build A will be picked up ?
> > >
> > > -Original Message-
> > > From: Karl Heinz Marbaise [mailto:khmarba...@gmx.de]
> > > Sent: Friday, April 7, 2017 10:50 AM
> > > To: Maven Users List <users@maven.apache.org>
> > > Subject: Re: dependency question
> > >
> > > Hi Russlel,
> > > On 07/04/17 17:29, Russell Gold wrote:
> > >
> > >> That’s the way it works: when you specify a snapshot, it takes the
> > latest.
>

Re: dependency question

[Curtis Rueden]

Hi Hector,

> This is fine as long as the dependency is always set to x.y.z-Snapshot
> and the dependency is always overwritten this way.  What if the
> producer produces x.y.z.1-Snapshot, x.y.z.2-Snapshot, x.y.z.3-Snapshot
> and I want the dependent build to always get the latest in this case,
> x.y.z.3-Snapshot ?

There is a special version keyword LATEST which means the very newest
version, snapshot or otherwise. And RELEASE means the newest release
(non-SNAPSHOT) version.

Similar to version ranges, Maven will have to ask the remote repository
about the latest known version in these cases, and will then use that.

I want to emphasize, as others have mentioned, that using any of these
strategies will result in _irreproducible builds_. That is, your code might
build today, and then the same code will fail to build in the future,
because the versions will resolve differently. The only way (I know of) to
achieve reproducible builds is to use fixed release versions, always.

Regards,
Curtis

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


On Tue, Apr 11, 2017 at 9:57 AM, Magnanao, Hector <hector.magna...@sap.com>
wrote:

> This is fine as long as the dependency is always set to x.y.z-Snapshot and
> the dependency is always overwritten this way.  What if the producer
> produces x.y.z.1-Snapshot, x.y.z.2-Snapshot, x.y.z.3-Snapshot and I want
> the dependent build to always get the latest in this case,
> x.y.z.3-Snapshot ? The difference with this scenario is that the producer
> will always have a new build number.
> As for your solution of using the range,  do I always have to change the
> pom file in the dependent build whenever a new build is produced by the
> producer ?
>
> -Original Message-
> From: Benson Margulies [mailto:bimargul...@gmail.com]
> Sent: Monday, April 10, 2017 10:39 AM
> To: Maven Users List <users@maven.apache.org>
> Subject: Re: dependency question
>
> On Mon, Apr 10, 2017 at 8:18 AM, Magnanao, Hector
> <hector.magna...@sap.com> wrote:
> > I'm still a little confused about the answers I'm getting.  So, if build
> A is being updated with a new build number(even for a snapshot), and build
> B has it as a dependency in it's pom.file, how does the pom file in Build B
> need to look like in the dependency section so that it does get the latest
> snapshot build of build A ?
>
> This conversation seems to keep mixing up SNAPSHOT version processing
> with various conventions for using version ranges.
>
> If the producer produces x.y.z-SNAPSHOT, and the consumer declares a
> dependency on x.y.z-SNAPSHOT, every build of the consumer will go out
> to the repositories to look for the latest snapshot build.
>
> Snapshots have risks and do not provide a repeatable build. Then
> again, neither do ranges.
>
> If you don't want to use snapshots, then you write the dependency in
> the consumer with a range
>
> (1.0-2.0]
>
> or whatever makes sense. This will cause builds of the consumer to go
> out to repositories and try to find the newest version within the
> range. it's up to you to bump the version in the producer, manually or
> with the maven-release-plugin.
>
>
>
>
> >
> > Scenario:
> >
> > Build A has 3 builds in it with names 1-Snapshot, 2-snapshot, 3-snapshot
> and they are all being uploaded to a repository.
> >
> > What will the pom file in build B look like so that the next time build
> B is executed,  3-snapshot for build A will be picked up ?
> >
> > -Original Message-
> > From: Karl Heinz Marbaise [mailto:khmarba...@gmx.de]
> > Sent: Friday, April 7, 2017 10:50 AM
> > To: Maven Users List <users@maven.apache.org>
> > Subject: Re: dependency question
> >
> > Hi Russlel,
> > On 07/04/17 17:29, Russell Gold wrote:
> >
> >> That’s the way it works: when you specify a snapshot, it takes the
> latest.
> >
> > This is not 100% true, cause it depends on the update policy you have
> > defined in your settings either explicit or by default the updates will
> > be checked every 24 hours...
> >
> > If you like to force this you can use mvn -U ...or define a different
> > updatePolicy in your settings.xml for the appropriate repository.
> >
> > By using mvn -U you make sure for running this build Maven will check if
> > there are newer SNAPSHOT version available for dependencies which have
> > defined a SNAPSHOT version
> >
> > This is working for a single module project...but if you have a multi
> > module build (Project C: A1 build before A2) which takes for example 5
> > minutes to build ...this is no lo

RE: dependency question

[Magnanao, Hector]

This is fine as long as the dependency is always set to x.y.z-Snapshot and the 
dependency is always overwritten this way.  What if the producer produces 
x.y.z.1-Snapshot, x.y.z.2-Snapshot, x.y.z.3-Snapshot and I want the dependent 
build to always get the latest in this case,  x.y.z.3-Snapshot ? The difference 
with this scenario is that the producer will always have a new build number.
As for your solution of using the range,  do I always have to change the pom 
file in the dependent build whenever a new build is produced by the producer ?

-Original Message-
From: Benson Margulies [mailto:bimargul...@gmail.com] 
Sent: Monday, April 10, 2017 10:39 AM
To: Maven Users List <users@maven.apache.org>
Subject: Re: dependency question

On Mon, Apr 10, 2017 at 8:18 AM, Magnanao, Hector
<hector.magna...@sap.com> wrote:
> I'm still a little confused about the answers I'm getting.  So, if build A is 
> being updated with a new build number(even for a snapshot), and build B has 
> it as a dependency in it's pom.file, how does the pom file in Build B need to 
> look like in the dependency section so that it does get the latest snapshot 
> build of build A ?

This conversation seems to keep mixing up SNAPSHOT version processing
with various conventions for using version ranges.

If the producer produces x.y.z-SNAPSHOT, and the consumer declares a
dependency on x.y.z-SNAPSHOT, every build of the consumer will go out
to the repositories to look for the latest snapshot build.

Snapshots have risks and do not provide a repeatable build. Then
again, neither do ranges.

If you don't want to use snapshots, then you write the dependency in
the consumer with a range

(1.0-2.0]

or whatever makes sense. This will cause builds of the consumer to go
out to repositories and try to find the newest version within the
range. it's up to you to bump the version in the producer, manually or
with the maven-release-plugin.




>
> Scenario:
>
> Build A has 3 builds in it with names 1-Snapshot, 2-snapshot, 3-snapshot and 
> they are all being uploaded to a repository.
>
> What will the pom file in build B look like so that the next time build B is 
> executed,  3-snapshot for build A will be picked up ?
>
> -Original Message-
> From: Karl Heinz Marbaise [mailto:khmarba...@gmx.de]
> Sent: Friday, April 7, 2017 10:50 AM
> To: Maven Users List <users@maven.apache.org>
> Subject: Re: dependency question
>
> Hi Russlel,
> On 07/04/17 17:29, Russell Gold wrote:
>
>> That’s the way it works: when you specify a snapshot, it takes the latest.
>
> This is not 100% true, cause it depends on the update policy you have
> defined in your settings either explicit or by default the updates will
> be checked every 24 hours...
>
> If you like to force this you can use mvn -U ...or define a different
> updatePolicy in your settings.xml for the appropriate repository.
>
> By using mvn -U you make sure for running this build Maven will check if
> there are newer SNAPSHOT version available for dependencies which have
> defined a SNAPSHOT version
>
> This is working for a single module project...but if you have a multi
> module build (Project C: A1 build before A2) which takes for example 5
> minutes to build ...this is no longer 100% true...
>
> Now let us assume you have another project B which dependends on two
> different artifacts (A1, A2) of Project C ...this means in consequence
> those artifacts are build at two different times...
>
> This means it could happen that your build of Project B consumes A2 from
> build #10 but A1 from build #9 ...
>
>
> In practical it usually works without any issue using the mvn -U ...but
> you should be aware of this issue...
>
>
> The only solution which I have found to make 100% sure is to use the
> output during the build of the project A and use those parsed
> informations about the SNAPSHOT versions and inject them into my current
> build ...(https://github.com/khmarbaise/deployment-recorder-extension
> not ready yet)...
>
> Kind regards
> Karl Heinz Marbaise
>
>
>>
>> There are some corner cases where it won’t. I think it only checks for a new 
>> snapshot every few hours or so, so if you are putting out a lot you might 
>> conceivably miss one. You can reset that if you need to
>> .
>>> On Apr 7, 2017, at 11:27 AM, Magnanao, Hector <hector.magna...@sap.com> 
>>> wrote:
>>>
>>> If the builds for A are always getting a unique build number as a snapshot 
>>> build,  how am I sure that B will always get the latest snapshot of A ?  Is 
>>> there a way to name the A snapshot builds with a unique build number each 
>>> time for this scenario.
>>>
>>> -Original Message---

Re: dependency question

[Benson Margulies]

On Mon, Apr 10, 2017 at 8:18 AM, Magnanao, Hector
<hector.magna...@sap.com> wrote:
> I'm still a little confused about the answers I'm getting.  So, if build A is 
> being updated with a new build number(even for a snapshot), and build B has 
> it as a dependency in it's pom.file, how does the pom file in Build B need to 
> look like in the dependency section so that it does get the latest snapshot 
> build of build A ?

This conversation seems to keep mixing up SNAPSHOT version processing
with various conventions for using version ranges.

If the producer produces x.y.z-SNAPSHOT, and the consumer declares a
dependency on x.y.z-SNAPSHOT, every build of the consumer will go out
to the repositories to look for the latest snapshot build.

Snapshots have risks and do not provide a repeatable build. Then
again, neither do ranges.

If you don't want to use snapshots, then you write the dependency in
the consumer with a range

(1.0-2.0]

or whatever makes sense. This will cause builds of the consumer to go
out to repositories and try to find the newest version within the
range. it's up to you to bump the version in the producer, manually or
with the maven-release-plugin.




>
> Scenario:
>
> Build A has 3 builds in it with names 1-Snapshot, 2-snapshot, 3-snapshot and 
> they are all being uploaded to a repository.
>
> What will the pom file in build B look like so that the next time build B is 
> executed,  3-snapshot for build A will be picked up ?
>
> -Original Message-
> From: Karl Heinz Marbaise [mailto:khmarba...@gmx.de]
> Sent: Friday, April 7, 2017 10:50 AM
> To: Maven Users List <users@maven.apache.org>
> Subject: Re: dependency question
>
> Hi Russlel,
> On 07/04/17 17:29, Russell Gold wrote:
>
>> That’s the way it works: when you specify a snapshot, it takes the latest.
>
> This is not 100% true, cause it depends on the update policy you have
> defined in your settings either explicit or by default the updates will
> be checked every 24 hours...
>
> If you like to force this you can use mvn -U ...or define a different
> updatePolicy in your settings.xml for the appropriate repository.
>
> By using mvn -U you make sure for running this build Maven will check if
> there are newer SNAPSHOT version available for dependencies which have
> defined a SNAPSHOT version
>
> This is working for a single module project...but if you have a multi
> module build (Project C: A1 build before A2) which takes for example 5
> minutes to build ...this is no longer 100% true...
>
> Now let us assume you have another project B which dependends on two
> different artifacts (A1, A2) of Project C ...this means in consequence
> those artifacts are build at two different times...
>
> This means it could happen that your build of Project B consumes A2 from
> build #10 but A1 from build #9 ...
>
>
> In practical it usually works without any issue using the mvn -U ...but
> you should be aware of this issue...
>
>
> The only solution which I have found to make 100% sure is to use the
> output during the build of the project A and use those parsed
> informations about the SNAPSHOT versions and inject them into my current
> build ...(https://github.com/khmarbaise/deployment-recorder-extension
> not ready yet)...
>
> Kind regards
> Karl Heinz Marbaise
>
>
>>
>> There are some corner cases where it won’t. I think it only checks for a new 
>> snapshot every few hours or so, so if you are putting out a lot you might 
>> conceivably miss one. You can reset that if you need to
>> .
>>> On Apr 7, 2017, at 11:27 AM, Magnanao, Hector <hector.magna...@sap.com> 
>>> wrote:
>>>
>>> If the builds for A are always getting a unique build number as a snapshot 
>>> build,  how am I sure that B will always get the latest snapshot of A ?  Is 
>>> there a way to name the A snapshot builds with a unique build number each 
>>> time for this scenario.
>>>
>>> -Original Message-
>>> From: Russell Gold [mailto:russell.g...@oracle.com]
>>> Sent: Thursday, April 6, 2017 2:27 PM
>>> To: Maven Users List <users@maven.apache.org>
>>> Subject: Re: dependency question
>>>
>>> The simplest way is simply to use a snapshot version of A. That way B will 
>>> always use the latest snapshot. When you finally release A, you can have B 
>>> point to the released version instead of the snapshot.
>>>
>>>> On Apr 6, 2017, at 2:52 PM, Magnanao, Hector <hector.magna...@sap.com> 
>>>> wrote:
>>>>
>>>> I have to 2 java projects a and b in maven.  The B project uses the A 
>>>> build as a de

RE: dependency question

[Magnanao, Hector]

I'm still a little confused about the answers I'm getting.  So, if build A is 
being updated with a new build number(even for a snapshot), and build B has it 
as a dependency in it's pom.file, how does the pom file in Build B need to look 
like in the dependency section so that it does get the latest snapshot build of 
build A ?

Scenario:

Build A has 3 builds in it with names 1-Snapshot, 2-snapshot, 3-snapshot and 
they are all being uploaded to a repository.

What will the pom file in build B look like so that the next time build B is 
executed,  3-snapshot for build A will be picked up ?

-Original Message-
From: Karl Heinz Marbaise [mailto:khmarba...@gmx.de] 
Sent: Friday, April 7, 2017 10:50 AM
To: Maven Users List <users@maven.apache.org>
Subject: Re: dependency question

Hi Russlel,
On 07/04/17 17:29, Russell Gold wrote:

> That’s the way it works: when you specify a snapshot, it takes the latest.

This is not 100% true, cause it depends on the update policy you have 
defined in your settings either explicit or by default the updates will 
be checked every 24 hours...

If you like to force this you can use mvn -U ...or define a different 
updatePolicy in your settings.xml for the appropriate repository.

By using mvn -U you make sure for running this build Maven will check if 
there are newer SNAPSHOT version available for dependencies which have 
defined a SNAPSHOT version

This is working for a single module project...but if you have a multi 
module build (Project C: A1 build before A2) which takes for example 5 
minutes to build ...this is no longer 100% true...

Now let us assume you have another project B which dependends on two 
different artifacts (A1, A2) of Project C ...this means in consequence 
those artifacts are build at two different times...

This means it could happen that your build of Project B consumes A2 from 
build #10 but A1 from build #9 ...


In practical it usually works without any issue using the mvn -U ...but 
you should be aware of this issue...


The only solution which I have found to make 100% sure is to use the 
output during the build of the project A and use those parsed 
informations about the SNAPSHOT versions and inject them into my current 
build ...(https://github.com/khmarbaise/deployment-recorder-extension 
not ready yet)...

Kind regards
Karl Heinz Marbaise


>
> There are some corner cases where it won’t. I think it only checks for a new 
> snapshot every few hours or so, so if you are putting out a lot you might 
> conceivably miss one. You can reset that if you need to
> .
>> On Apr 7, 2017, at 11:27 AM, Magnanao, Hector <hector.magna...@sap.com> 
>> wrote:
>>
>> If the builds for A are always getting a unique build number as a snapshot 
>> build,  how am I sure that B will always get the latest snapshot of A ?  Is 
>> there a way to name the A snapshot builds with a unique build number each 
>> time for this scenario.
>>
>> -Original Message-
>> From: Russell Gold [mailto:russell.g...@oracle.com]
>> Sent: Thursday, April 6, 2017 2:27 PM
>> To: Maven Users List <users@maven.apache.org>
>> Subject: Re: dependency question
>>
>> The simplest way is simply to use a snapshot version of A. That way B will 
>> always use the latest snapshot. When you finally release A, you can have B 
>> point to the released version instead of the snapshot.
>>
>>> On Apr 6, 2017, at 2:52 PM, Magnanao, Hector <hector.magna...@sap.com> 
>>> wrote:
>>>
>>> I have to 2 java projects a and b in maven.  The B project uses the A build 
>>> as a dependency.  How do I ensure the whenever the A project has a new 
>>> build,  the B project will always use that latest build in A.  A is being 
>>> built with a unique build number each time it gets built.  So is A has 
>>> build # 10 as the newest build,  the B project has to use build #10 of A.
>>>
>>>
>>> Hector Magnanao Jr.
>>> SCM Analyst
>>> SAP Fieldglass
>>> Skype:  (331) 702-6142
>>> Mobile:  (847) 857-8401
>>> Email: hector.magna...@sap.com
>>>
>>
>>

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

RE: dependency question

[Robert Patrick]

For example, if I want to depend on the latest version of the artifact un the 
1.1.x version range, I would put:


test
myartifact
[1.1,1.1.9]


This says give me the latest version whose number is greater than or equal to 
1.1 and less than or equal to 1.1. 9 (where I randomly chose 9 
to be greater than any incremental version I will ever create.  

This version range can also be written [1.1, 1.2) where the close parent 
indicates a non-inclusive range end (i.e., less than 1.2).  The thing to be 
aware of with this syntax is that it also includes any pre-release versions of 
1.2 (e.g., 1.2-alpha-1 is included).  For more information, please see section 
3.4.3 of 
http://books.sonatype.com/mvnref-book/reference/pom-relationships-sect-project-dependencies.html
 and http://maven.apache.org/enforcer/enforcer-rules/versionRanges.html 


--
Robert Patrick <robert.patr...@oracle.com>
VP, OPC Development, Oracle Corporation
7460 Warren Pkwy, Ste. 300  Office: +1.972.963.2872
Frisco, TX 75034, USA   Mobile: +1.469.556.9450

Professional Oracle WebLogic Server
by Robert Patrick, Gregory Nyberg, and Philip Aston
with Josh Bregman and Paul Done
Book Home Page: http://www.wrox.com/
Kindle Version: http://www.amazon.com/


-Original Message-
From: Magnanao, Hector [mailto:hector.magna...@sap.com] 
Sent: Friday, April 07, 2017 10:28 AM
To: Maven Users List
Subject: RE: dependency question

Can you give me an example of using a range in the pom file as a dependency ?

-Original Message-
From: Robert Patrick [mailto:robert.patr...@oracle.com] 
Sent: Thursday, April 6, 2017 2:34 PM
To: Maven Users List <users@maven.apache.org>
Subject: RE: dependency question

The other way is to use a version range in your dependency, which gives you a 
similar behavior as using a snapshot dependency.  Both approaches have their 
advantages and drawbacks...

-Original Message-
From: Russell Gold 
Sent: Thursday, April 06, 2017 2:27 PM
To: Maven Users List
Subject: Re: dependency question

The simplest way is simply to use a snapshot version of A. That way B will 
always use the latest snapshot. When you finally release A, you can have B 
point to the released version instead of the snapshot.

> On Apr 6, 2017, at 2:52 PM, Magnanao, Hector <hector.magna...@sap.com> wrote:
> 
> I have to 2 java projects a and b in maven.  The B project uses the A build 
> as a dependency.  How do I ensure the whenever the A project has a new build, 
>  the B project will always use that latest build in A.  A is being built with 
> a unique build number each time it gets built.  So is A has build # 10 as the 
> newest build,  the B project has to use build #10 of A.
> 
> 
> Hector Magnanao Jr.
> SCM Analyst
> SAP Fieldglass
> Skype:  (331) 702-6142
> Mobile:  (847) 857-8401
> Email: hector.magna...@sap.com
> 


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


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


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


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

Re: dependency question

[Karl Heinz Marbaise]

Hi Russlel,
On 07/04/17 17:29, Russell Gold wrote:


That’s the way it works: when you specify a snapshot, it takes the latest.


This is not 100% true, cause it depends on the update policy you have 
defined in your settings either explicit or by default the updates will 
be checked every 24 hours...


If you like to force this you can use mvn -U ...or define a different 
updatePolicy in your settings.xml for the appropriate repository.


By using mvn -U you make sure for running this build Maven will check if 
there are newer SNAPSHOT version available for dependencies which have 
defined a SNAPSHOT version


This is working for a single module project...but if you have a multi 
module build (Project C: A1 build before A2) which takes for example 5 
minutes to build ...this is no longer 100% true...


Now let us assume you have another project B which dependends on two 
different artifacts (A1, A2) of Project C ...this means in consequence 
those artifacts are build at two different times...


This means it could happen that your build of Project B consumes A2 from 
build #10 but A1 from build #9 ...



In practical it usually works without any issue using the mvn -U ...but 
you should be aware of this issue...



The only solution which I have found to make 100% sure is to use the 
output during the build of the project A and use those parsed 
informations about the SNAPSHOT versions and inject them into my current 
build ...(https://github.com/khmarbaise/deployment-recorder-extension 
not ready yet)...


Kind regards
Karl Heinz Marbaise




There are some corner cases where it won’t. I think it only checks for a new 
snapshot every few hours or so, so if you are putting out a lot you might 
conceivably miss one. You can reset that if you need to
.

On Apr 7, 2017, at 11:27 AM, Magnanao, Hector <hector.magna...@sap.com> wrote:

If the builds for A are always getting a unique build number as a snapshot 
build,  how am I sure that B will always get the latest snapshot of A ?  Is 
there a way to name the A snapshot builds with a unique build number each time 
for this scenario.

-Original Message-
From: Russell Gold [mailto:russell.g...@oracle.com]
Sent: Thursday, April 6, 2017 2:27 PM
To: Maven Users List <users@maven.apache.org>
Subject: Re: dependency question

The simplest way is simply to use a snapshot version of A. That way B will 
always use the latest snapshot. When you finally release A, you can have B 
point to the released version instead of the snapshot.


On Apr 6, 2017, at 2:52 PM, Magnanao, Hector <hector.magna...@sap.com> wrote:

I have to 2 java projects a and b in maven.  The B project uses the A build as 
a dependency.  How do I ensure the whenever the A project has a new build,  the 
B project will always use that latest build in A.  A is being built with a 
unique build number each time it gets built.  So is A has build # 10 as the 
newest build,  the B project has to use build #10 of A.


Hector Magnanao Jr.
SCM Analyst
SAP Fieldglass
Skype:  (331) 702-6142
Mobile:  (847) 857-8401
Email: hector.magna...@sap.com






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

RE: dependency question

[Robert Patrick]

Typically, whenever you run a build that includes a snapshot dependency, Maven 
will go out to the remote repository(ies), if any, and download the 
maven-metadata.xml file for that dependency to compare it against the snapshot 
stored in your local Maven repository to see if there is a newer version that 
needs to be downloaded.  For example, when I run one of our builds, I see this 
in the build output when there is a newer snapshot version:

Downloading: 
http://myrepomanager.example.com/artifactory/my-repo/test/artifact/2.2-SNAPSHOT/maven-metadata.xml
Downloaded: 
http://myrepomanager.example.com/artifactory/my-repo/test/artifact/2.2-SNAPSHOT/maven-metadata.xml
 (766 B at 1.4 KB/sec)
Downloading: 
http://myrepomanager.example.com/artifactory/my-repo/test/artifact/2.2-SNAPSHOT/artifact-2.2-20170406.205529-591.pom
Downloaded: 
http://myrepomanager.example.com/artifactory/my-repo/test/artifact/2.2-SNAPSHOT/artifact-2.2-20170406.205529-591.pom
 (3 KB at 12.5 KB/sec)
Downloading: 
http://myrepomanager.example.com/artifactory/my-repo/test/artifact/2.2-SNAPSHOT/artifact-2.2-20170406.205529-591.jar
Downloaded: 
http://myrepomanager.example.com/artifactory/my-repo/test/artifact/2.2-SNAPSHOT/artifact-2.2-20170406.205529-591.jar
 (43 KB at 25.3 KB/sec)

And this output when there is not:

Downloading: 
http://myrepomanager.example.com/artifactory/my-repo/test/artifact/2.2-SNAPSHOT/maven-metadata.xml
Downloaded: 
http://myrepomanager.example.com/artifactory/my-repo/test/artifact/2.2-SNAPSHOT/maven-metadata.xml
 (766 B at 1.7 KB/sec)

Whether it downloads and checks the maven-metadata.xml file every time or 
periodically is (at least somewhat) controlled by the repository declaration in 
your POM/settings.xml for the repository's updatePolicy.  For example, this is 
what one of our builds uses:


false
always
fail



-Original Message-
From: Russell Gold 
Sent: Friday, April 07, 2017 10:30 AM
To: Maven Users List
Subject: Re: dependency question

That’s the way it works: when you specify a snapshot, it takes the latest. 

There are some corner cases where it won’t. I think it only checks for a new 
snapshot every few hours or so, so if you are putting out a lot you might 
conceivably miss one. You can reset that if you need to .
> On Apr 7, 2017, at 11:27 AM, Magnanao, Hector <hector.magna...@sap.com> wrote:
> 
> If the builds for A are always getting a unique build number as a snapshot 
> build,  how am I sure that B will always get the latest snapshot of A ?  Is 
> there a way to name the A snapshot builds with a unique build number each 
> time for this scenario.
> 
> -Original Message-
> From: Russell Gold [mailto:russell.g...@oracle.com]
> Sent: Thursday, April 6, 2017 2:27 PM
> To: Maven Users List <users@maven.apache.org>
> Subject: Re: dependency question
> 
> The simplest way is simply to use a snapshot version of A. That way B will 
> always use the latest snapshot. When you finally release A, you can have B 
> point to the released version instead of the snapshot.
> 
>> On Apr 6, 2017, at 2:52 PM, Magnanao, Hector <hector.magna...@sap.com> wrote:
>> 
>> I have to 2 java projects a and b in maven.  The B project uses the A build 
>> as a dependency.  How do I ensure the whenever the A project has a new 
>> build,  the B project will always use that latest build in A.  A is being 
>> built with a unique build number each time it gets built.  So is A has build 
>> # 10 as the newest build,  the B project has to use build #10 of A.
>> 
>> 
>> Hector Magnanao Jr.
>> SCM Analyst
>> SAP Fieldglass
>> Skype:  (331) 702-6142
>> Mobile:  (847) 857-8401
>> Email: hector.magna...@sap.com
>> 
> 
> 
> -
> To unsubscribe, e-mail: users-unsubscr...@maven.apache.org
> For additional commands, e-mail: users-h...@maven.apache.org
> 
> 
> -
> To unsubscribe, e-mail: users-unsubscr...@maven.apache.org
> For additional commands, e-mail: users-h...@maven.apache.org
> 


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


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

Re: dependency question

[Russell Gold]

That’s the way it works: when you specify a snapshot, it takes the latest. 

There are some corner cases where it won’t. I think it only checks for a new 
snapshot every few hours or so, so if you are putting out a lot you might 
conceivably miss one. You can reset that if you need to
.
> On Apr 7, 2017, at 11:27 AM, Magnanao, Hector <hector.magna...@sap.com> wrote:
> 
> If the builds for A are always getting a unique build number as a snapshot 
> build,  how am I sure that B will always get the latest snapshot of A ?  Is 
> there a way to name the A snapshot builds with a unique build number each 
> time for this scenario.
> 
> -Original Message-
> From: Russell Gold [mailto:russell.g...@oracle.com] 
> Sent: Thursday, April 6, 2017 2:27 PM
> To: Maven Users List <users@maven.apache.org>
> Subject: Re: dependency question
> 
> The simplest way is simply to use a snapshot version of A. That way B will 
> always use the latest snapshot. When you finally release A, you can have B 
> point to the released version instead of the snapshot.
> 
>> On Apr 6, 2017, at 2:52 PM, Magnanao, Hector <hector.magna...@sap.com> wrote:
>> 
>> I have to 2 java projects a and b in maven.  The B project uses the A build 
>> as a dependency.  How do I ensure the whenever the A project has a new 
>> build,  the B project will always use that latest build in A.  A is being 
>> built with a unique build number each time it gets built.  So is A has build 
>> # 10 as the newest build,  the B project has to use build #10 of A.
>> 
>> 
>> Hector Magnanao Jr.
>> SCM Analyst
>> SAP Fieldglass
>> Skype:  (331) 702-6142
>> Mobile:  (847) 857-8401
>> Email: hector.magna...@sap.com
>> 
> 
> 
> -
> To unsubscribe, e-mail: users-unsubscr...@maven.apache.org
> For additional commands, e-mail: users-h...@maven.apache.org
> 
> 
> -
> To unsubscribe, e-mail: users-unsubscr...@maven.apache.org
> For additional commands, e-mail: users-h...@maven.apache.org
> 


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

RE: dependency question

[Magnanao, Hector]

Can you give me an example of using a range in the pom file as a dependency ?

-Original Message-
From: Robert Patrick [mailto:robert.patr...@oracle.com] 
Sent: Thursday, April 6, 2017 2:34 PM
To: Maven Users List <users@maven.apache.org>
Subject: RE: dependency question

The other way is to use a version range in your dependency, which gives you a 
similar behavior as using a snapshot dependency.  Both approaches have their 
advantages and drawbacks...

-Original Message-
From: Russell Gold 
Sent: Thursday, April 06, 2017 2:27 PM
To: Maven Users List
Subject: Re: dependency question

The simplest way is simply to use a snapshot version of A. That way B will 
always use the latest snapshot. When you finally release A, you can have B 
point to the released version instead of the snapshot.

> On Apr 6, 2017, at 2:52 PM, Magnanao, Hector <hector.magna...@sap.com> wrote:
> 
> I have to 2 java projects a and b in maven.  The B project uses the A build 
> as a dependency.  How do I ensure the whenever the A project has a new build, 
>  the B project will always use that latest build in A.  A is being built with 
> a unique build number each time it gets built.  So is A has build # 10 as the 
> newest build,  the B project has to use build #10 of A.
> 
> 
> Hector Magnanao Jr.
> SCM Analyst
> SAP Fieldglass
> Skype:  (331) 702-6142
> Mobile:  (847) 857-8401
> Email: hector.magna...@sap.com
> 


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


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


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

RE: dependency question

[Magnanao, Hector]

If the builds for A are always getting a unique build number as a snapshot 
build,  how am I sure that B will always get the latest snapshot of A ?  Is 
there a way to name the A snapshot builds with a unique build number each time 
for this scenario.

-Original Message-
From: Russell Gold [mailto:russell.g...@oracle.com] 
Sent: Thursday, April 6, 2017 2:27 PM
To: Maven Users List <users@maven.apache.org>
Subject: Re: dependency question

The simplest way is simply to use a snapshot version of A. That way B will 
always use the latest snapshot. When you finally release A, you can have B 
point to the released version instead of the snapshot.

> On Apr 6, 2017, at 2:52 PM, Magnanao, Hector <hector.magna...@sap.com> wrote:
> 
> I have to 2 java projects a and b in maven.  The B project uses the A build 
> as a dependency.  How do I ensure the whenever the A project has a new build, 
>  the B project will always use that latest build in A.  A is being built with 
> a unique build number each time it gets built.  So is A has build # 10 as the 
> newest build,  the B project has to use build #10 of A.
> 
> 
> Hector Magnanao Jr.
> SCM Analyst
> SAP Fieldglass
> Skype:  (331) 702-6142
> Mobile:  (847) 857-8401
> Email: hector.magna...@sap.com
> 


-
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 question

[Robert Patrick]

The other way is to use a version range in your dependency, which gives you a 
similar behavior as using a snapshot dependency.  Both approaches have their 
advantages and drawbacks...

-Original Message-
From: Russell Gold 
Sent: Thursday, April 06, 2017 2:27 PM
To: Maven Users List
Subject: Re: dependency question

The simplest way is simply to use a snapshot version of A. That way B will 
always use the latest snapshot. When you finally release A, you can have B 
point to the released version instead of the snapshot.

> On Apr 6, 2017, at 2:52 PM, Magnanao, Hector <hector.magna...@sap.com> wrote:
> 
> I have to 2 java projects a and b in maven.  The B project uses the A build 
> as a dependency.  How do I ensure the whenever the A project has a new build, 
>  the B project will always use that latest build in A.  A is being built with 
> a unique build number each time it gets built.  So is A has build # 10 as the 
> newest build,  the B project has to use build #10 of A.
> 
> 
> Hector Magnanao Jr.
> SCM Analyst
> SAP Fieldglass
> Skype:  (331) 702-6142
> Mobile:  (847) 857-8401
> Email: hector.magna...@sap.com
> 


-
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 question

[Russell Gold]

The simplest way is simply to use a snapshot version of A. That way B will 
always use the latest snapshot. When you finally release A, you can have B 
point to the released version instead of the snapshot.

> On Apr 6, 2017, at 2:52 PM, Magnanao, Hector  wrote:
> 
> I have to 2 java projects a and b in maven.  The B project uses the A build 
> as a dependency.  How do I ensure the whenever the A project has a new build, 
>  the B project will always use that latest build in A.  A is being built with 
> a unique build number each time it gets built.  So is A has build # 10 as the 
> newest build,  the B project has to use build #10 of A.
> 
> 
> Hector Magnanao Jr.
> SCM Analyst
> SAP Fieldglass
> Skype:  (331) 702-6142
> Mobile:  (847) 857-8401
> Email: hector.magna...@sap.com
> 


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

Re: Dependency convergence errors - how to resolve?

[Curtis Rueden]

Hi Niranjan,

> We do set this because we have been burned many times where wrong
> classes from older jar files were getting loaded.
...
> This caused all sort of interesting crashes at runtime.

Runtime... of your application? That would be caused by your deployment
mechanism, which is past where Maven is involved. How do you generate your
final application? How is it decided what gets included on your classpath?

Or do you mean that the wrong dependency JAR(s) are selected at compile
time by Maven?

Personally, I do not see the value in enforcing dependency convergence. In
practice you are going to continually run into problems where you depend on
components A and B and they each depend on a different version of C... and
then what? Lots of exclusions? Much easier if you can just let Maven pick
the newest.

My strong suggestion would be to understand exactly the root cause of your
previous issue, and find out how to solve it without using this enforcer
rule.

Or maybe someone else who uses this rule can comment further on its
intended use, and a way to achieve what you want.

Regards,
Curtis

--
Curtis Rueden
LOCI software architect - http://loci.wisc.edu/software


On Wed, Nov 23, 2016 at 6:25 PM, Niranjan Rao  wrote:

> Hi Curtis,
>
> Sorry for the late reply.
>
> We do set this because we have been burned many times where wrong classes
> from older jar files were getting loaded. For most part this is ok, but if
> memory serves right, we faced few problems with spring/hibernate where it's
> internal dependencies conflicted with some other dependencies. This caused
> all sort of interesting crashes at runtime.
>
> I am not sure and it was long time (couple of years) back, but I think
> root cause was wrong type of proxy class getting created and dependencies
> not getting injected correctly.
>
> Regards,
>
> Niranjan
>
> On 11/19/2016 01:09 PM, Curtis Rueden wrote:
>
>> Hi Niranjan,
>>
>> I have set maven enforcer plugin with dependency convergence.
>>>
>> Naive question: why do this? One of the (IMHO) great things about Maven is
>> that it resolves conflicting dependency versions in a generally desirable
>> way. As long as the newer version of the dependency is backwards
>> compatible
>> with the old at runtime, there should be no problem. The only issue is
>> when
>> there are backwards incompatibilities, no? But in the case of
>> websocket-client 9.2.18 vs. 9.2.15, I am assuming that is a SemVer
>> version,
>> which means it should be backwards compatible, right?
>>
>> Regards,
>> Curtis
>>
>> --
>> Curtis Rueden
>> LOCI software architect - http://loci.wisc.edu/software
>> ImageJ2 lead, Fiji maintainer - http://imagej.net/User:Rueden
>>
>>
>> On Fri, Nov 18, 2016 at 12:32 PM, Niranjan Rao  wrote:
>>
>> Greetings,
>>>
>>> I have set maven enforcer plugin with dependency convergence. Usually I
>>> solve these errors with exclusion entries.
>>>
>>> With recent upgrade to selenium 3.0.1 I am getting dependency convergence
>>> error that I am not sure how to resolve. It's selenium-java that has two
>>> conflicting dependencies. If I add exclusion entry, I'll have most
>>> probably
>>> will have to add the required dependencies myself and might break future
>>> upgrades and/or increase maintenance work.
>>>
>>>
>>> Dependency convergence error for org.eclipse.jetty.websocket:we
>>> bsocket-client:9.2.18.v20160721 paths to dependency are:
>>> +-mygroupId:artifact:4.0-SNAPSHOT
>>>+-org.seleniumhq.selenium:selenium-java:3.0.1
>>>  +-net.sourceforge.htmlunit:htmlunit:2.23
>>> +-org.eclipse.jetty.websocket:websocket-client:9.2.18.v20160721
>>> and
>>> +-mygroupId:artifact:4.0-SNAPSHOT
>>>+-org.seleniumhq.selenium:selenium-java:3.0.1
>>> +-org.eclipse.jetty.websocket:websocket-client:9.2.15.v20160210
>>>
>>> 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: Dependency convergence errors - how to resolve?

[Niranjan Rao]

Hi Curtis,

Sorry for the late reply.

We do set this because we have been burned many times where wrong 
classes from older jar files were getting loaded. For most part this is 
ok, but if memory serves right, we faced few problems with 
spring/hibernate where it's internal dependencies conflicted with some 
other dependencies. This caused all sort of interesting crashes at runtime.


I am not sure and it was long time (couple of years) back, but I think 
root cause was wrong type of proxy class getting created and 
dependencies not getting injected correctly.


Regards,

Niranjan
On 11/19/2016 01:09 PM, Curtis Rueden wrote:

Hi Niranjan,


I have set maven enforcer plugin with dependency convergence.

Naive question: why do this? One of the (IMHO) great things about Maven is
that it resolves conflicting dependency versions in a generally desirable
way. As long as the newer version of the dependency is backwards compatible
with the old at runtime, there should be no problem. The only issue is when
there are backwards incompatibilities, no? But in the case of
websocket-client 9.2.18 vs. 9.2.15, I am assuming that is a SemVer version,
which means it should be backwards compatible, right?

Regards,
Curtis

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


On Fri, Nov 18, 2016 at 12:32 PM, Niranjan Rao  wrote:


Greetings,

I have set maven enforcer plugin with dependency convergence. Usually I
solve these errors with exclusion entries.

With recent upgrade to selenium 3.0.1 I am getting dependency convergence
error that I am not sure how to resolve. It's selenium-java that has two
conflicting dependencies. If I add exclusion entry, I'll have most probably
will have to add the required dependencies myself and might break future
upgrades and/or increase maintenance work.


Dependency convergence error for org.eclipse.jetty.websocket:we
bsocket-client:9.2.18.v20160721 paths to dependency are:
+-mygroupId:artifact:4.0-SNAPSHOT
   +-org.seleniumhq.selenium:selenium-java:3.0.1
 +-net.sourceforge.htmlunit:htmlunit:2.23
+-org.eclipse.jetty.websocket:websocket-client:9.2.18.v20160721
and
+-mygroupId:artifact:4.0-SNAPSHOT
   +-org.seleniumhq.selenium:selenium-java:3.0.1
+-org.eclipse.jetty.websocket:websocket-client:9.2.15.v20160210

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: Dependency convergence errors - how to resolve?

[Curtis Rueden]

Hi Niranjan,

> I have set maven enforcer plugin with dependency convergence.

Naive question: why do this? One of the (IMHO) great things about Maven is
that it resolves conflicting dependency versions in a generally desirable
way. As long as the newer version of the dependency is backwards compatible
with the old at runtime, there should be no problem. The only issue is when
there are backwards incompatibilities, no? But in the case of
websocket-client 9.2.18 vs. 9.2.15, I am assuming that is a SemVer version,
which means it should be backwards compatible, right?

Regards,
Curtis

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


On Fri, Nov 18, 2016 at 12:32 PM, Niranjan Rao  wrote:

> Greetings,
>
> I have set maven enforcer plugin with dependency convergence. Usually I
> solve these errors with exclusion entries.
>
> With recent upgrade to selenium 3.0.1 I am getting dependency convergence
> error that I am not sure how to resolve. It's selenium-java that has two
> conflicting dependencies. If I add exclusion entry, I'll have most probably
> will have to add the required dependencies myself and might break future
> upgrades and/or increase maintenance work.
>
>
> Dependency convergence error for org.eclipse.jetty.websocket:we
> bsocket-client:9.2.18.v20160721 paths to dependency are:
> +-mygroupId:artifact:4.0-SNAPSHOT
>   +-org.seleniumhq.selenium:selenium-java:3.0.1
> +-net.sourceforge.htmlunit:htmlunit:2.23
> +-org.eclipse.jetty.websocket:websocket-client:9.2.18.v20160721
> and
> +-mygroupId:artifact:4.0-SNAPSHOT
>   +-org.seleniumhq.selenium:selenium-java:3.0.1
> +-org.eclipse.jetty.websocket:websocket-client:9.2.15.v20160210
>
> Regards,
>
> Niranjan
>
>
> -
> To unsubscribe, e-mail: users-unsubscr...@maven.apache.org
> For additional commands, e-mail: users-h...@maven.apache.org
>
>

RE: Dependency error with javadoc:aggregate, and confused about overall javadoc aggregate setup

[KARR, DAVID]

> -Original Message-
> From: Jochum Jesko [mailto:j.joc...@elettronica.de]
> Sent: Thursday, October 27, 2016 11:41 PM
> To: Maven Users List 
> Subject: AW: Dependency error with javadoc:aggregate, and confused about
> overall javadoc aggregate setup
> 
> I had some problems with the javadoc:aggregate goal myself and have
> written an e-mail concerning this topic to the iss...@maven.apache.org
> list two days ago. But my problems seems different to yours, still this
> might be of use to you.
> Essentially my solution was to use the javadoc:aggregate-jar goal. Here
> is an excerpt of my parent pom to generate one aggregated javadoc in the
> parent project and individual javadocs in each module during the
> 'package' phase.

Thanks.  I incorporated some of this.  I'm still not sure exactly how some of 
this is working.

One thing I notice is that although the "javadoc:aggregate-jar" goal works as 
expected, I find that when I just run "mvn clean install", it also runs the 
"aggregate-jar" task.  Considering it's now in the "package" phase, I guess I 
can understand that.  What would I have to do to make it so that this only runs 
when I manually run the "javadoc:aggregate-jar" goal?

For reference, what I've added to my top-level POM is the following:
-

org.apache.maven.plugins
maven-javadoc-plugin
2.10.4


-Xdoclint:none



module-javadoc-jar
package

jar


protected

true



aggregated-documentation
package
false

aggregate-jar


protected
true






> 
> 
>   4.0.0
>   my-group-id
>   my-artifact-id
>   1.0
>   ...
> 
>   pom
>   
>   module-1
>   module-2
>   module-3
>   ...
>   
> 
>   
>   
>   ...
> 
>   
>   
>   org.apache.maven.plugins
>   maven-javadoc-plugin
>   2.10.4
>   
>   
>   -
> Xdoclint:none
>   
>   
> 
>   
>   
>   module-javadoc-jar
>   package
>   
>   jar
>   
>   
>   private
>   
> true
> 
>   *.temp.*
>   
>   
> 
>   
>   
>   
> aggregated-documentation
>   package
>   
>   false
>   
>   
> aggregate-jar
>   
>   
>   private
>   
> true
> 
>   *.temp.*
>   
>   
>   
>   
>   ...
> 
>   
>   
> 
> 
> Hope I could help.
> 
> -Ursprüngliche Nachricht-
> Von: KARR, DAVID 

Re: Dependency cycle?

[manojkokane]

Sha Jiang,
 
  As maven does not support circular dependency, you can try this to
resolve this.
 
  Let's say you have module 'A' and module 'B', where both depends on
other one.
  You can add one more module say 'C' which will be packaged to jar
consisting common classes required for module A and B. Then add dependency
of module 'C' in both 'A' and 'B'. 

 Hope this helps... :)
  




-
Thanks, 
ManojK
--
View this message in context: 
http://maven.40175.n5.nabble.com/Dependency-cycle-tp55414p5875098.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 error

[Wayne Fay]

Click the url.
urlhttp://maven.aspose.com/artifactory/simple/ext-release-local//url

There appears to be no artifacts with groupId javax in this repo. Only
stuff under com.

Wayne

On Mon, Aug 24, 2015 at 3:21 PM, Magnanao, Hector
hector.magna...@sap.com wrote:
 Can someone help me with this error ? It can't seem to get to this url.

 [ERROR] Failed to execute goal on project foundation: Could not resolve 
 dependencies for project com.mycompany.app:foundation:jar:1.0-SNAPSHOT: 
 Failure to find javax.sql:jdbc-stdext:jar:2.0 in 
 http://maven.aspose.com/artifactory/simple/ext-release-local/ was cached in 
 the local repository, resolution will not be reattempted until the update 
 interval of AsposeJavaAPI has elapsed or updates are forc
 ed - [Help 1]
 [ERROR]

 I have this url setup in my pom file as below:

   repositories
repository
idAsposeJavaAPI/id
nameAspose Java API/name

 urlhttp://maven.aspose.com/artifactory/simple/ext-release-local//url
/repository
   /repositories

 Hector Magnanao Jr.
 SCM Analyst

 Fieldglass, Inc.
 O: (331) 702-6142
 M: (773) 474-3051
 hector.magna...@sap.com
 www.fieldglass.com

 Fieldglass is now part of SAP

 This email contains confidential information.  If you are not the intended 
 recipient, do not read, distribute or reproduce this transmission (including 
 any attachments). If you have received this email in error, please notify the 
 sender by email reply.


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

Re: Dependency Best Practices

[Ron Wheeler]

It is hard to understand your example.
Can you define child and grandchild and clarify where the 
dependencies are coming from (Third parties? Other children?)


In general, you use the parent to define properties and define the exact 
versions of dependencies in a dependency management section.

Children define the dependencies that they require but not the versions.

What is the choice that you are trying to make that you think needs to 
follow a best practice?
You might want to mention what kind of application you are building 
(language, type of app, target platform).


Ron

On 21/08/2015 5:37 AM, aalok singhvi wrote:

Hello,

Any best practices on how to arrange dependency in multi module maven
project.

Let me give an example

Parent Project
   Child1
   GrandChild1 ( Depedency1, Dependency2, Dependency3)
   GrandChild2 ( Depedency1, Dependency2, Dependency, 4)
   GrandChild3  (Depedency1, Dependency2, Dependency, 5)
   GrandChild4
 (Depedency1, Dependency2, Dependency3, Dependency4, Dependency,
5)
   Child2
   GrandChild1 ( Depedency1, Dependency2, Dependency3)
   GrandChild2 ( Depedency1, Dependency2, Dependency, 4)
   GrandChild3  (Depedency1, Dependency2, Dependency, 5)
   GrandChild4
 (Depedency1, Dependency2, Dependency3, Dependency4, Dependency,
5)

How can you set dependency properly so that it will available to
GrandChild4 as well.

Looking forward to your reply.

Thanks




--
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 resolves strange...

[Sören Daniel Krum]

Hello Anton!

Thank you for your help! That explain some things, i was a bit confused, 
because i just opened one of the locations in my browser
 (namely 
https://repository.mulesoft.org/nexus/content/repositories/public/javax/script/jruby-engine/1.1/) 
and there, oh wonder, i find the following listing:


Index of /nexus/content/repositories/public/javax/script/jruby-engine/1.1/

NameLast ModifiedSizeDescription
Parent Directory
jruby-engine-1.1-jdk14.jarFri May 23 18:44:23 UTC 2014 11276
jruby-engine-1.1-jdk14.jar.md5Mon May 26 20:32:39 UTC 2014 32
jruby-engine-1.1-jdk14.jar.sha1Mon May 26 20:32:39 UTC 2014 40
jruby-engine-1.1-jdk14.pomFri May 23 18:44:28 UTC 2014190
jruby-engine-1.1-jdk14.pom.sha1Mon May 26 20:32:39 UTC 2014 40

But if i understand you correctly, the pom file placed there should be 
named jruby-engine-1.1.pom, is that correct?


So, i would have to talk to mulesoft to clean their repository... Sorry 
for disturbing the mailing list


Am 24.06.2015 um 15:30 schrieb Anton Tanasenko:

Hi,
If you remove all traces of jruby-engine from your local repo, you will see
that in second case maven will try to download both pom (which is missing,
more on that below) and the classified jar.
It does not try to download the jar in the first case because it is
referred to from a dependency that is marked as provided (your snippet).
Please consult [1] and note where it says that provided scope is not
transitive.

As for classifiers, those are only used on artifacts themselves, not on
pom. So the pom at [2] is completely wrong and will never be picked up by
maven.
Typical use case is a single project pom and several artifacts with
different classifiers.

[1]
https://maven.apache.org/guides/introduction/introduction-to-dependency-mechanism.html#Dependency_Scope
[2]
https://repository.mulesoft.org/nexus/content/repositories/public/javax/script/jruby-engine/1.1/jruby-engine-1.1-jdk14.pom


2015-06-24 13:55 GMT+03:00 Sören Daniel Krum soren.k...@uninett.no:


Hi!

I found a strange behaviour when having a referring to a dependency
dependency with classifier in my pom:

Let us say, my pom holds the following snippet:

   dependencies
 dependency
   groupIdorg.mule.modules/groupId
artifactIdmule-module-scripting/artifactId
   version3.6.0/version
   scopeprovided/scope
 /dependency

This strange mule thingy has a pom of its own, and in there is a
classified reference to javax.script:jruby-engine.
Then when calling

# mvn dependency:resolve -U | grep jruby-engine

i see the following log lines:

Downloading:
https://repository.mulesoft.org/nexus-ee/content/repositories/releases-ee/javax/script/jruby-engine/1.1/jruby-engine-1.1.pom
Downloading:
https://repository.mulesoft.org/releases/javax/script/jruby-engine/1.1/jruby-engine-1.1.pom
Downloading:
https://repository.mulesoft.org/nexus/content/repositories/public/javax/script/jruby-engine/1.1/jruby-engine-1.1.pom
Downloading:
https://repo.maven.apache.org/maven2/javax/script/jruby-engine/1.1/jruby-engine-1.1.pom
Downloading:
https://repository.mulesoft.org/nexus/content/repositories/public/javax/script/jruby-engine/1.1/jruby-engine-1.1.pom
[WARNING] The POM for javax.script:jruby-engine:jar:jdk14:1.1 is missing,
no dependency information available

So, even if the warning says that they searched for the classified (jdk14)
version, the debugging says they tried a download without classifier.

But when i add a direct dependency in my pom file like that:

dependency
   groupIdjavax.script/groupId
   artifactIdjruby-engine/artifactId
   version1.1/version
   classifierjdk14/classifier
 /dependency

The log looks like that:

Downloading:
https://repository.mulesoft.org/nexus-ee/content/repositories/releases-ee/javax/script/jruby-engine/1.1/jruby-engine-1.1-jdk14.jar
Downloading:
https://repository.mulesoft.org/releases/javax/script/jruby-engine/1.1/jruby-engine-1.1-jdk14.jar
Downloading:
https://repository.mulesoft.org/nexus/content/repositories/public/javax/script/jruby-engine/1.1/jruby-engine-1.1-jdk14.jar
Downloaded:
https://repository.mulesoft.org/nexus/content/repositories/public/javax/script/jruby-engine/1.1/jruby-engine-1.1-jdk14.jar
(0 B at 0.0 KB/sec)
[INFO]javax.script:jruby-engine:jar:jdk14:1.1:compile

Then they are really resolving the classifier and they really search for
the classified version. I attach a stripped down pom file, if someone wants
to give it a try...

Am i missing something? Or is that considered to work like that?

--
Med vennlig hilsen / Mit freundlichem Gruß / Kind regards

Sören Krum
System Ingeniør - System
UNINETT AS
www.uninett.no



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






--
Med vennlig hilsen / Mit freundlichem Gruß / Kind regards

Sören Krum
System Ingeniør - System
UNINETT AS
www.uninett.no

Re: dependency resolves strange...

[Anton Tanasenko]

Hi,
If you remove all traces of jruby-engine from your local repo, you will see
that in second case maven will try to download both pom (which is missing,
more on that below) and the classified jar.
It does not try to download the jar in the first case because it is
referred to from a dependency that is marked as provided (your snippet).
Please consult [1] and note where it says that provided scope is not
transitive.

As for classifiers, those are only used on artifacts themselves, not on
pom. So the pom at [2] is completely wrong and will never be picked up by
maven.
Typical use case is a single project pom and several artifacts with
different classifiers.

[1]
https://maven.apache.org/guides/introduction/introduction-to-dependency-mechanism.html#Dependency_Scope
[2]
https://repository.mulesoft.org/nexus/content/repositories/public/javax/script/jruby-engine/1.1/jruby-engine-1.1-jdk14.pom


2015-06-24 13:55 GMT+03:00 Sören Daniel Krum soren.k...@uninett.no:

 Hi!

 I found a strange behaviour when having a referring to a dependency
 dependency with classifier in my pom:

 Let us say, my pom holds the following snippet:

   dependencies
 dependency
   groupIdorg.mule.modules/groupId
 artifactIdmule-module-scripting/artifactId
   version3.6.0/version
   scopeprovided/scope
 /dependency

 This strange mule thingy has a pom of its own, and in there is a
 classified reference to javax.script:jruby-engine.
 Then when calling

 # mvn dependency:resolve -U | grep jruby-engine

 i see the following log lines:

 Downloading:
 https://repository.mulesoft.org/nexus-ee/content/repositories/releases-ee/javax/script/jruby-engine/1.1/jruby-engine-1.1.pom
 Downloading:
 https://repository.mulesoft.org/releases/javax/script/jruby-engine/1.1/jruby-engine-1.1.pom
 Downloading:
 https://repository.mulesoft.org/nexus/content/repositories/public/javax/script/jruby-engine/1.1/jruby-engine-1.1.pom
 Downloading:
 https://repo.maven.apache.org/maven2/javax/script/jruby-engine/1.1/jruby-engine-1.1.pom
 Downloading:
 https://repository.mulesoft.org/nexus/content/repositories/public/javax/script/jruby-engine/1.1/jruby-engine-1.1.pom
 [WARNING] The POM for javax.script:jruby-engine:jar:jdk14:1.1 is missing,
 no dependency information available

 So, even if the warning says that they searched for the classified (jdk14)
 version, the debugging says they tried a download without classifier.

 But when i add a direct dependency in my pom file like that:

 dependency
   groupIdjavax.script/groupId
   artifactIdjruby-engine/artifactId
   version1.1/version
   classifierjdk14/classifier
 /dependency

 The log looks like that:

 Downloading:
 https://repository.mulesoft.org/nexus-ee/content/repositories/releases-ee/javax/script/jruby-engine/1.1/jruby-engine-1.1-jdk14.jar
 Downloading:
 https://repository.mulesoft.org/releases/javax/script/jruby-engine/1.1/jruby-engine-1.1-jdk14.jar
 Downloading:
 https://repository.mulesoft.org/nexus/content/repositories/public/javax/script/jruby-engine/1.1/jruby-engine-1.1-jdk14.jar
 Downloaded:
 https://repository.mulesoft.org/nexus/content/repositories/public/javax/script/jruby-engine/1.1/jruby-engine-1.1-jdk14.jar
 (0 B at 0.0 KB/sec)
 [INFO]javax.script:jruby-engine:jar:jdk14:1.1:compile

 Then they are really resolving the classifier and they really search for
 the classified version. I attach a stripped down pom file, if someone wants
 to give it a try...

 Am i missing something? Or is that considered to work like that?

 --
 Med vennlig hilsen / Mit freundlichem Gruß / Kind regards

 Sören Krum
 System Ingeniør - System
 UNINETT AS
 www.uninett.no



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




-- 
Regards,
Anton.

Re: dependency resolves strange...

[Anton Tanasenko]

Yes, pom should always be named artifactId-version.pom and maven model
does not define a classifier project element.
Since this particular pom does not have anything beside GAV inside, apart
from making that warning disappear and getting rid of any potential
confusion in general, it wouldn't change anything. Maven assumes such
content when it cannot find the pom file.
Glad to help.

2015-06-24 16:46 GMT+03:00 Sören Daniel Krum soren.k...@uninett.no:

 Hello Anton!

 Thank you for your help! That explain some things, i was a bit confused,
 because i just opened one of the locations in my browser
  (namely
 https://repository.mulesoft.org/nexus/content/repositories/public/javax/script/jruby-engine/1.1/)
 and there, oh wonder, i find the following listing:

 Index of /nexus/content/repositories/public/javax/script/jruby-engine/1.1/

 NameLast ModifiedSizeDescription
 Parent Directory
 jruby-engine-1.1-jdk14.jarFri May 23 18:44:23 UTC 2014 11276
 jruby-engine-1.1-jdk14.jar.md5Mon May 26 20:32:39 UTC 2014 32
 jruby-engine-1.1-jdk14.jar.sha1Mon May 26 20:32:39 UTC 2014 40
 jruby-engine-1.1-jdk14.pomFri May 23 18:44:28 UTC 2014190
 jruby-engine-1.1-jdk14.pom.sha1Mon May 26 20:32:39 UTC 2014 40

 But if i understand you correctly, the pom file placed there should be
 named jruby-engine-1.1.pom, is that correct?

 So, i would have to talk to mulesoft to clean their repository... Sorry
 for disturbing the mailing list


 Am 24.06.2015 um 15:30 schrieb Anton Tanasenko:

 Hi,
 If you remove all traces of jruby-engine from your local repo, you will
 see
 that in second case maven will try to download both pom (which is missing,
 more on that below) and the classified jar.
 It does not try to download the jar in the first case because it is
 referred to from a dependency that is marked as provided (your snippet).
 Please consult [1] and note where it says that provided scope is not
 transitive.

 As for classifiers, those are only used on artifacts themselves, not on
 pom. So the pom at [2] is completely wrong and will never be picked up by
 maven.
 Typical use case is a single project pom and several artifacts with
 different classifiers.

 [1]

 https://maven.apache.org/guides/introduction/introduction-to-dependency-mechanism.html#Dependency_Scope
 [2]

 https://repository.mulesoft.org/nexus/content/repositories/public/javax/script/jruby-engine/1.1/jruby-engine-1.1-jdk14.pom


 2015-06-24 13:55 GMT+03:00 Sören Daniel Krum soren.k...@uninett.no:

  Hi!

 I found a strange behaviour when having a referring to a dependency
 dependency with classifier in my pom:

 Let us say, my pom holds the following snippet:

dependencies
  dependency
groupIdorg.mule.modules/groupId
 artifactIdmule-module-scripting/artifactId
version3.6.0/version
scopeprovided/scope
  /dependency

 This strange mule thingy has a pom of its own, and in there is a
 classified reference to javax.script:jruby-engine.
 Then when calling

 # mvn dependency:resolve -U | grep jruby-engine

 i see the following log lines:

 Downloading:

 https://repository.mulesoft.org/nexus-ee/content/repositories/releases-ee/javax/script/jruby-engine/1.1/jruby-engine-1.1.pom
 Downloading:

 https://repository.mulesoft.org/releases/javax/script/jruby-engine/1.1/jruby-engine-1.1.pom
 Downloading:

 https://repository.mulesoft.org/nexus/content/repositories/public/javax/script/jruby-engine/1.1/jruby-engine-1.1.pom
 Downloading:

 https://repo.maven.apache.org/maven2/javax/script/jruby-engine/1.1/jruby-engine-1.1.pom
 Downloading:

 https://repository.mulesoft.org/nexus/content/repositories/public/javax/script/jruby-engine/1.1/jruby-engine-1.1.pom
 [WARNING] The POM for javax.script:jruby-engine:jar:jdk14:1.1 is missing,
 no dependency information available

 So, even if the warning says that they searched for the classified
 (jdk14)
 version, the debugging says they tried a download without classifier.

 But when i add a direct dependency in my pom file like that:

 dependency
groupIdjavax.script/groupId
artifactIdjruby-engine/artifactId
version1.1/version
classifierjdk14/classifier
  /dependency

 The log looks like that:

 Downloading:

 https://repository.mulesoft.org/nexus-ee/content/repositories/releases-ee/javax/script/jruby-engine/1.1/jruby-engine-1.1-jdk14.jar
 Downloading:

 https://repository.mulesoft.org/releases/javax/script/jruby-engine/1.1/jruby-engine-1.1-jdk14.jar
 Downloading:

 https://repository.mulesoft.org/nexus/content/repositories/public/javax/script/jruby-engine/1.1/jruby-engine-1.1-jdk14.jar
 Downloaded:

 https://repository.mulesoft.org/nexus/content/repositories/public/javax/script/jruby-engine/1.1/jruby-engine-1.1-jdk14.jar
 (0 B at 0.0 KB/sec)
 [INFO]javax.script:jruby-engine:jar:jdk14:1.1:compile

 Then they are really resolving the classifier and they really search for
 the classified version. I attach a stripped down pom file, if 

RE: Dependency plugin: tree, CLI substitution error

[Dan Rollo]

Hi Sander,

That was a big help! Thanks. And yes, surrounding the property in single quotes 
solved the problem. For example: -Dexcludes='${project.groupId}’ 

FWIW, the ${groupId} form did work (so I don’t think BASH was substituting the 
empty string because no such environment variable existed).

Mystery solved, not a maven issue, just my misuse of bash.

Dan


From: Sander Verhagen san...@sanderverhagen.net 
mailto:san...@sanderverhagen.net
Subject: RE: Dependency plugin: tree, CLI substitution error
Date: May 30, 2015 at 2:28:11 AM EDT
To: Maven Users List users@maven.apache.org mailto:users@maven.apache.org


Hi,


Seems like your property is interpreted by BASH, which I don't think is what 
you want.

${BLAH} is a BASH variable, mostly equivalent to $BASH. I think what you meant 
is '${BLAH}', i.e. not substituted by BASH, giving Maven a chance to 
substitute. FYI, you wouldn't want ${BLAH} either (with double quotes BASH 
will still substitute).

${BLAH.BLAH} is an invalid BASH variable, due to the period, hence its balking.

Your ${groupId} probably works in the sense that BASH doesn't complain. I 
don't think that it works in the sense that Maven substitutes it for the actual 
groupId. I don't think that it'll get the chance for that, because likely BASH 
already substitutes it for an empty string (assuming it doesn't know a groupId 
variable in your environment; not entirely sure on basis of the limited 
information given).

Hope this helps.



Sander Verhagen
[  san...@sanderverhagen.net mailto:san...@sanderverhagen.net  ]

RE: Dependency plugin: tree, CLI substitution error

[Sander Verhagen]

Hi,


Seems like your property is interpreted by BASH, which I don't think is what 
you want.

${BLAH} is a BASH variable, mostly equivalent to $BASH. I think what you meant 
is '${BLAH}', i.e. not substituted by BASH, giving Maven a chance to 
substitute. FYI, you wouldn't want ${BLAH} either (with double quotes BASH 
will still substitute).

${BLAH.BLAH} is an invalid BASH variable, due to the period, hence its balking.

Your ${groupId} probably works in the sense that BASH doesn't complain. I 
don't think that it works in the sense that Maven substitutes it for the actual 
groupId. I don't think that it'll get the chance for that, because likely BASH 
already substitutes it for an empty string (assuming it doesn't know a groupId 
variable in your environment; not entirely sure on basis of the limited 
information given).

Hope this helps.



Sander Verhagen
[  san...@sanderverhagen.net  ]

NOTICE: my e-mail address has changed. You may still e-mail me at 
verha...@sander.com but you will see me using san...@sanderverhagen.net from 
now on. Feel free to update your address book.

 -Original Message-
 From: Dan Rollo [mailto:danro...@gmail.com]
 Sent: Friday, May 29, 2015 13:32
 To: users@maven.apache.org
 Subject: Dependency plugin: tree, CLI substitution error
 
 I’m using the maven-dependency-plugin to search for SNAPSHOT
 dependencies in a multi-module project. I am filtering out dependencies
 having the same groupId as the maven project. Here’s the command I use:
 
 mvn dependency:tree -Dincludes=:::*-SNAPSHOT -
 Dexcludes=${project.groupId}
 
 Unfortunately, this command produces the error below:
 
 -bash: -Dexcludes=${project.groupId}: bad substitution
 
 
 If I use the “old”, non-prefixed property name as shown below, the command
 works fine:
 
 mvn dependency:tree -Dincludes=:::*-SNAPSHOT -Dexcludes=${groupId}
 
 
 Is this a known issue? I would expect the ${project.groupId}” to work (and I
 think this is the “preferred” property syntax, no?)
 
 The effective pom shows maven-dependency-plugin version 2.8.
 
 More info:
 mvn -version
 Apache Maven 3.2.5 (12a6b3acb947671f09b81f49094c53f426d8cea1; 2014-
 12-14T12:29:23-05:00) Maven home: /Users/bhamail/devtools/apache-
 maven-3.2.5
 Java version: 1.8.0_40, vendor: Oracle Corporation Java home:
 /Library/Java/JavaVirtualMachines/jdk1.8.0_40.jdk/Contents/Home/jre
 Default locale: en_US, platform encoding: UTF-8 OS name: mac os x,
 version: 10.10.3, arch: x86_64, family: “mac
 
 Thanks!
 Dan
 
 
 -
 To unsubscribe, e-mail: users-unsubscr...@maven.apache.org
 For additional commands, e-mail: users-h...@maven.apache.org

Re: dependency management with ant quick question

[Zk W]

Hi Chris

Thanks for replying. We like to use ant as our main build process, not
maven so the maven-antrun wouldnt apply here.



On Wed, May 13, 2015 at 8:14 PM, Christopher ctubb...@apache.org wrote:

 One maven plugin which might help is the
 https://maven.apache.org/plugins/maven-antrun-plugin/ , which allows
 you to execute ant tasks within maven. I've seen some projects do this
 to mavenize an ant project a bit (though, usually they end up
 transitioning completely... eventually).

 Another option is to have a small maven project inside your project
 which has all your dependencies, and which executes the
 copy-dependencies goal of the maven-dependency-plugin to copy all your
 dependencies to a specified directory
 (
 https://maven.apache.org/plugins/maven-dependency-plugin/copy-dependencies-mojo.html
 )
 to make them available for ant.

 --
 Christopher L Tubbs II
 http://gravatar.com/ctubbsii


 On Wed, May 13, 2015 at 11:00 PM, Zk W mpc8...@gmail.com wrote:
  Hi All
 
  We are new to Maven and we are an ant shop.
  We like to use Maven's dependency management feature, not ivy.
 
  1- Can we just use Maven's dependency management feature to work with our
  ant build script ?
 
  2- Since .m2 is the default folder for all the jars, do we use ant copy
  task to copy jars from .m2 folder to different project folders to compile
  properly ?
 
  3. Are there examples out there that use ant for build purpose in
  conjunction with maven's dependency management ?
 
  Thank you.

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

Re: dependency management with ant quick question

[Christopher]

One maven plugin which might help is the
https://maven.apache.org/plugins/maven-antrun-plugin/ , which allows
you to execute ant tasks within maven. I've seen some projects do this
to mavenize an ant project a bit (though, usually they end up
transitioning completely... eventually).

Another option is to have a small maven project inside your project
which has all your dependencies, and which executes the
copy-dependencies goal of the maven-dependency-plugin to copy all your
dependencies to a specified directory
(https://maven.apache.org/plugins/maven-dependency-plugin/copy-dependencies-mojo.html)
to make them available for ant.

--
Christopher L Tubbs II
http://gravatar.com/ctubbsii


On Wed, May 13, 2015 at 11:00 PM, Zk W mpc8...@gmail.com wrote:
 Hi All

 We are new to Maven and we are an ant shop.
 We like to use Maven's dependency management feature, not ivy.

 1- Can we just use Maven's dependency management feature to work with our
 ant build script ?

 2- Since .m2 is the default folder for all the jars, do we use ant copy
 task to copy jars from .m2 folder to different project folders to compile
 properly ?

 3. Are there examples out there that use ant for build purpose in
 conjunction with maven's dependency management ?

 Thank you.

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

Re: dependency plug-in docs wrong or misleading.

[Curtis Rueden]

Hi Ron,

 This should be added as a configuration and explanation to the main
 examples page

IIUC, we can submit patches for this sort of change. The repo on GitHub is:

https://github.com/apache/maven-plugins/blob/trunk/maven-dependency-plugin/src/site/apt/examples/copying-artifacts.apt.vm

As of this writing, the lines in question are:

https://github.com/apache/maven-plugins/blob/a2943b37832f8787147b1bfd292e1a13be2ec672/maven-dependency-plugin/src/site/apt/examples/copying-artifacts.apt.vm#L43-L67

And looking at the repo, it seems that PRs are being accepted. So I filed
one:
https://github.com/apache/maven-plugins/pull/52

Cheers,
Curtis

On Thu, May 7, 2015 at 10:56 PM, Ron Wheeler rwhee...@artifact-software.com
 wrote:

 In
 http://maven.40175.n5.nabble.com/copy-libraries-to-classpath-td110698.html,
 Brian Fox wrote a key response with a reference to an obscure reference in
 the dependency FAQ athttps://
 maven.apache.org/plugins/maven-dependency-plugin/examples/copying-artifacts.html

 Buried in the FAQ under copying from the command line it states you must
 not put the configuration inside the/executions/tag.

 This should be added as a configuration and explanation to the main
 examples page  at
 https://maven.apache.org/plugins/maven-dependency-plugin/examples/copying-project-dependencies.html

 project
   [...]
   build
 plugins
   plugin
 groupIdorg.apache.maven.plugins/groupId
 artifactIdmaven-dependency-plugin/artifactId
 version2.10/version
 executions
   execution
 idcopy-dependencies/id
 phasepackage/phase
 goals
   goalcopy-dependencies/goal
 /goals
 configuration

 outputDirectory${project.build.directory}/alternateLocation/outputDirectory
   overWriteReleasesfalse/overWriteReleases
   overWriteSnapshotsfalse/overWriteSnapshots
   overWriteIfNewertrue/overWriteIfNewer
 /configuration
   /execution
 /executions
   /plugin
 /plugins
   /build
   [...]
 /project

 If you are running from the command line of from an IDE, you need to
 change the position of the configuration section to be a sibling of the
 executions element

 project
   [...]
   build
 plugins
   plugin
 groupIdorg.apache.maven.plugins/groupId
 artifactIdmaven-dependency-plugin/artifactId
 version2.10/version
 configuration

 outputDirectory${project.build.directory}/alternateLocation/outputDirectory
 overWriteReleasesfalse/overWriteReleases
 overWriteSnapshotsfalse/overWriteSnapshots
 overWriteIfNewertrue/overWriteIfNewer
 /configuration
 executions
   execution
 idcopy-dependencies/id
 phasepackage/phase
 goals
   goalcopy-dependencies/goal
 /goals
   /execution
 /executions
   /plugin
 /plugins
   /build
   [...]
 /project



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

Re: Dependency Management versus Dependencies

[David Hoffer]

dependencyManagement does not create dependencies like the dependencies
section does.  Rather what dependencyManagement does is specify the version
and/or other configuration of actual dependencies specified in dependencies
sections or transitive dependencies.

-Dave

On Sun, Feb 22, 2015 at 12:17 PM, Dishant Anand 
dishant.an...@techblue.co.uk wrote:

 Hi Team,

 Can somebody please explain me what is the difference between using a
 dependency in dependency management and dependency in dependencies .?
 We have one project where some dependencies in parent pom are defined
 under the dependency management while other are defined under the
 dependencies.

 Thanks for your answer in advance.

 Regards,
 Dishant Anand

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

Re: Dependency Management versus Dependencies

[Dishant Anand]

That was really very helpful.Thanks Dave
On 22/02/2015 19:56, David Hoffer wrote:

dependencyManagement does not create dependencies like the dependencies
section does.  Rather what dependencyManagement does is specify the version
and/or other configuration of actual dependencies specified in dependencies
sections or transitive dependencies.

-Dave

On Sun, Feb 22, 2015 at 12:17 PM, Dishant Anand 
dishant.an...@techblue.co.uk wrote:


Hi Team,

Can somebody please explain me what is the difference between using a
dependency in dependency management and dependency in dependencies .?
We have one project where some dependencies in parent pom are defined
under the dependency management while other are defined under the
dependencies.

Thanks for your answer in advance.

Regards,
Dishant Anand

-
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 conflict resolution

[Baptiste Mathus]

Do you use dependencyManagement ?

And Jason is right: providing a test project is quicker to help you. Might
be even quicker for you than explaining it by mail.
Push it for example on your github account and post the link here.

Cheers
Le 13 févr. 2015 21:21, Jason van Zyl ja...@takari.io a écrit :

 Provide a sample project with what you expect as the result for a given
 project.

 The dependency plugin does its own weird resolution and M2Eclipse also has
 its own resolver (which is closer to what Maven actually does vs the
 dependency plugin) and I don't really want to think about your description
 of a project. Just give us a sample project.

 On Feb 13, 2015, at 3:05 PM, Endo Alejandro 
 alejandro.e...@grassvalley.com wrote:

  Hello everyone
 
  I thought I knew how maven did dependency conflict resolution: always go
 with the version that's closest to the base pom
 
  However, it seems that is not the case. Here is my scenario
 
  I have a pom of packaging=pom, call it A, which is the base where I
 execute maven.
 
  So this is my simplified graph where - denotes a maven normal
 dependency. All poms of packaging pom will be represented with upper case
 and poms of packaging jar with lowercase
 
  A - b:1.0-SNAPSHOT
  A - C - d - b:1.0-RC2
 
  When I look at the dependency hierarchy in eclipse, or at the
 dependency:tree or dependency:copy-dependencies, maven is always choosing
 b:1.0-RC-2, which means that my understanding of shortest path is not the
 full story since in the graph b:1.0-SNAPSHOT is a direct dependency. Could
 someone clear this for me? Is it related to RC vs snapshot?
 
  Thank you,
 
  Alejandro
 
  DISCLAIMER:
  Privileged and/or Confidential information may be contained in this
  message. If you are not the addressee of this message, you may not
  copy, use or deliver this message to anyone. In such event, you
  should destroy the message and kindly notify the sender by reply
  e-mail. It is understood that opinions or conclusions that do not
  relate to the official business of the company are neither given
  nor endorsed by the company.
  Thank You.

 Thanks,

 Jason

 --
 Jason van Zyl
 Founder, Takari and Apache Maven
 http://twitter.com/jvanzyl
 http://twitter.com/takari_io
 -

 the course of true love never did run smooth ...

  -- Shakespeare













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

Re: Dependency conflict resolution

[Jason van Zyl]

Provide a sample project with what you expect as the result for a given project.

The dependency plugin does its own weird resolution and M2Eclipse also has its 
own resolver (which is closer to what Maven actually does vs the dependency 
plugin) and I don't really want to think about your description of a project. 
Just give us a sample project.

On Feb 13, 2015, at 3:05 PM, Endo Alejandro alejandro.e...@grassvalley.com 
wrote:

 Hello everyone
 
 I thought I knew how maven did dependency conflict resolution: always go with 
 the version that's closest to the base pom
 
 However, it seems that is not the case. Here is my scenario
 
 I have a pom of packaging=pom, call it A, which is the base where I execute 
 maven.
 
 So this is my simplified graph where - denotes a maven normal dependency. 
 All poms of packaging pom will be represented with upper case and poms of 
 packaging jar with lowercase
 
 A - b:1.0-SNAPSHOT
 A - C - d - b:1.0-RC2
 
 When I look at the dependency hierarchy in eclipse, or at the dependency:tree 
 or dependency:copy-dependencies, maven is always choosing b:1.0-RC-2, which 
 means that my understanding of shortest path is not the full story since in 
 the graph b:1.0-SNAPSHOT is a direct dependency. Could someone clear this for 
 me? Is it related to RC vs snapshot?
 
 Thank you,
 
 Alejandro
 
 DISCLAIMER:
 Privileged and/or Confidential information may be contained in this
 message. If you are not the addressee of this message, you may not
 copy, use or deliver this message to anyone. In such event, you
 should destroy the message and kindly notify the sender by reply
 e-mail. It is understood that opinions or conclusions that do not
 relate to the official business of the company are neither given
 nor endorsed by the company.
 Thank You.

Thanks,

Jason

--
Jason van Zyl
Founder, Takari and Apache Maven
http://twitter.com/jvanzyl
http://twitter.com/takari_io
-

the course of true love never did run smooth ...

 -- Shakespeare













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

RE: dependency exclusion with wildward does not work

[Martin Gainty]

 From: jackie.x...@ebaotech.com
 To: users@maven.apache.org
 Subject: dependency exclusion with wildward does not work
 Date: Mon, 15 Sep 2014 11:19:33 +
 
 Dear
 
 I just started using maven ant task, and one issue I found today was, when 
 the pom contains wildward exclusion, seems the artifacts won't be excluded.
 
 My script snippet below:
 
 Ant:
 artifact:dependencies filesetId=ls.jar.all
   pom file=ls-jar-all.pom.xml /
 /artifact:dependencies
 
 Ls-jar-all.pom.xml:
 dependency
   groupIdorg.apache.cxf/groupId
   artifactIdcxf-bundle/artifactId
   version2.1/version
   exclusions
 exclusion
 groupIdorg.apache.abdera/groupId
 artifactId*/artifactId
 /exclusion
 exclusion
 groupIdorg.apache.geronimo.specs/groupId
   artifactId*/artifactId
   /exclusion
 /exclusions
 
 While changing wildcard to individual artifactIds, the exclusion works. (the 
 wildward pom works when using maven)

MGsince your problem is manifested in ANT only and not maven you will need to 
post this email to u...@ant.apache.org
MGhttp://ant.apache.org/mail.html
MGRegards
 
 Any suggestions, thanks
 
 Thanks
 Best Regards
 
 Jackie Xiao | eAS-CM | eBaoTech | Cell: (+86) 136 4185 4318
 
 This e-mail and any attachments thereto are intended for the sole use of the 
 recipient(s) named above and may contain confidential and/or privileged 
 material. Any use of the information contained herein (including, but not 
 limited to, total or partial reproduction, communication, or dissemination in 
 any form) by persons other than the intended recipient(s) is prohibited. If 
 you received this in error, please contact the sender immediately and delete 
 the material from any computer.
  

Re: Dependency in profile in pom.xml

[Deng Ching-Mallete]

Hi,

The ! at the beginning of the hadoop.profile property in hadoop-1.0 profile
indicates that if the hadoop.profile property is not specified or absent,
then the profile will be activated. So if you didn't specify it as a system
property (e.g. -Dhadoop.profile=), it would be used by default.

Given what I explained above, for your second question, you need to specify
-Dhadoop.profile=2 and just omit -Phadoop-2 to activate the hadoop-2
profile in your build.

Thanks,
Deng


On Thu, Jul 31, 2014 at 7:29 PM, 李响 wate...@gmail.com wrote:

 Dear maven user and developers,

 Attached is pom.xml of Flume. I have some questions as follow, really
 appreciate your help or guide, thanks !!

 1. Why profile id = hadoop-1.0 is the default profile ?
 If not specifying -Px for mvn command, I found hadoop-1.0 is the
 default one to use. why is it the default one ? is it
 because name!hadoop.profile/name is specified in its activation and
 hadoop.profile is not specified in properties ? Seems not... I tried with
 adding hadoop.profile2/hadoop.profile into properties, but hadoop-1.0
 is still used. This can be proven by the version of dependencies downloaded
 into .m2 repository

 2. hadoop-test- is needed for profile id = hadoop-2 ?
 when I issued mvn  -Phadoop-2, the following errors came out:

 [ERROR] Failed to execute goal
 org.apache.maven.plugins:maven-remote-resources-plugin:1.1:process
 (default) on project flume-hdfs-sink: Failed to resolve dependencies for
 one or more projects in the reactor. Reason: Missing:
 [ERROR] --
 [ERROR] 1) org.apache.hadoop:hadoop-test:jar:2.4.0
 [ERROR]
 [ERROR] Try downloading the file manually from the project website.
 [ERROR]
 [ERROR] Then, install it using the command:
 [ERROR] mvn install:install-file -DgroupId=org.apache.hadoop
 -DartifactId=hadoop-test -Dversion=2.4.0 -Dpackaging=jar
 -Dfile=/path/to/file
 [ERROR]
 [ERROR] Alternatively, if you host your own repository you can deploy the
 file there:
 [ERROR] mvn deploy:deploy-file -DgroupId=org.apache.hadoop
 -DartifactId=hadoop-test -Dversion=2.4.0 -Dpackaging=jar
 -Dfile=/path/to/file -Durl=[url] -DrepositoryId=[id]
 [ERROR]
 [ERROR] Path to dependency:
 [ERROR] 1) org.apache.flume.flume-ng-sinks:flume-hdfs-sink:jar:1.5.0.1
 [ERROR] 2) org.apache.hadoop:hadoop-test:jar:2.4.0
 [ERROR]
 [ERROR] --
 [ERROR] 1 required artifact is missing.
 [ERROR]
 [ERROR] for artifact:
 [ERROR] org.apache.flume.flume-ng-sinks:flume-hdfs-sink:jar:1.5.0.1
 [ERROR]
 [ERROR] from the specified remote repositories:
 [ERROR] repo1.maven.org (http://repo1.maven.org/maven2, releases=true,
 snapshots=false),
 [ERROR] repository.jboss.org (
 http://repository.jboss.org/nexus/content/groups/public/, releases=true,
 snapshots=false),
 [ERROR] apache.snapshots (http://repository.apache.org/snapshots,
 releases=false, snapshots=true),
 [ERROR] central (http://repo.maven.apache.org/maven2, releases=true,
 snapshots=false)
 [ERROR] - [Help 1]
 [ERROR]
 [ERROR] To see the full stack trace of the errors, re-run Maven with the
 -e switch.
 [ERROR] Re-run Maven using the -X switch to enable full debug logging.
 [ERROR]
 [ERROR] For more information about the errors and possible solutions,
 please read the following articles:
 [ERROR] [Help 1]
 http://cwiki.apache.org/confluence/display/MAVEN/MojoExecutionException

 I just wonder and be confused why org.apache.hadoop:hadoop-test:jar:2.4.0
 is requested. Because the following statements only appear in profile id =
 hadoop-1.0
   dependency
 groupIdorg.apache.hadoop/groupId
 artifactIdhadoop-test/artifactId
 version${hadoop.version}/version
   /dependency

 The pom.xml for flume-hdfs-sink is also attached as pom-1.xml. Thanks !

 --

李响

 手机 cellphone ：+86-1368-113-8972
 E-mail ：wate...@gmail.com
 MSN   ：wate...@hotmail.com


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




-- 
Maria Odea Deng Ching-Mallete | och...@apache.org |
http://www.linkedin.com/in/oching

Re: dependency plugin fails with 9 threads

[Kristian Rosenvold]

It turns out dependency plugin is using an old version of doxia (version
1.0, latest released is 1.4) that has known thread safety issues. You
*might* be able to work around this by adding the following dependencies to
the dependency-plugin in your pom:

dependency
  groupIdorg.apache.maven.doxia/groupId
  artifactIddoxia-sink-api/artifactId
  version1.4/version
/dependency
dependency
  groupIdorg.apache.maven.doxia/groupId
  artifactIddoxia-site-renderer/artifactId
  version1.4/version
/dependency

See
http://blog.sonatype.com/2008/04/how-to-override-a-plugins-dependency-in-mavenif
you're unfamiliar about how to do this. this might work, but might
also
bug out due to some incompatibility between 1.0 and 1.4 of doxia, I did not
try.



Please file an issue under http://jira.codehaus.org/browse/MDEP


Kristian



2014-05-01 16:00 GMT+02:00 Anthony Clark anthonyclar...@gmail.com:

 Hi All,

 I'm trying to improve our build by using parallel threads (i.e. mvn -T #)

 Unfortunately I'm running into an error when I try to use more than 9
 threads on this 24 core server:

 [ERROR] Failed to execute goal
 org.apache.maven.plugins:maven-dependency-plugin:2.8:analyze-report
 (analyze-report)
  on project enterprise-provided: An error has occurred in Dependency
 Analysis report generation. Could not find the
  template 'org/apache/maven/doxia/siterenderer/resources/default-site.vm -
 [Help 1]
 org.apache.maven.lifecycle.LifecycleExecutionException: Failed to execute
 goal org.apache.maven.plugins:maven-depen
 dency-plugin:2.8:analyze-report (analyze-report) on project
 enterprise-provided: An error has occurred in Dependenc
 y Analysis report generation.
 at

 org.apache.maven.lifecycle.internal.MojoExecutor.execute(MojoExecutor.java:216)
 at

 org.apache.maven.lifecycle.internal.MojoExecutor.execute(MojoExecutor.java:153)
 at

 org.apache.maven.lifecycle.internal.MojoExecutor.execute(MojoExecutor.java:145)
 at

 org.apache.maven.lifecycle.internal.LifecycleModuleBuilder.buildProject(LifecycleModuleBuilder.java:108)
 at

 org.apache.maven.lifecycle.internal.builder.multithreaded.MultiThreadedBuilder$1.call(MultiThreadedBuild
 er.java:188)
 at

 org.apache.maven.lifecycle.internal.builder.multithreaded.MultiThreadedBuilder$1.call(MultiThreadedBuild
 er.java:184)
 at java.util.concurrent.FutureTask.run(FutureTask.java:262)
 at
 java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:471)
 at java.util.concurrent.FutureTask.run(FutureTask.java:262)
 at

 java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1145)
 at

 java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:615)
 at java.lang.Thread.run(Thread.java:745)
 Caused by: org.apache.maven.plugin.MojoExecutionException: An error has
 occurred in Dependency Analysis report gene
 ration.
 at

 org.apache.maven.reporting.AbstractMavenReport.execute(AbstractMavenReport.java:106)
 at

 org.apache.maven.plugin.DefaultBuildPluginManager.executeMojo(DefaultBuildPluginManager.java:133)
 at

 org.apache.maven.lifecycle.internal.MojoExecutor.execute(MojoExecutor.java:208)
 ... 11 more
 Caused by: org.apache.maven.doxia.siterenderer.RendererException: Could not
 find the template
 'org/apache/maven/doxia/siterenderer/resources/default-site.vm
 at

 org.apache.maven.doxia.siterenderer.DefaultSiteRenderer.processTemplate(DefaultSiteRenderer.java:537)
 at

 org.apache.maven.doxia.siterenderer.DefaultSiteRenderer.writeTemplate(DefaultSiteRenderer.java:508)
 at

 org.apache.maven.doxia.siterenderer.DefaultSiteRenderer.generateDocument(DefaultSiteRenderer.java:485)
 at

 org.apache.maven.reporting.AbstractMavenReport.execute(AbstractMavenReport.java:97)
 ... 13 more
 [INFO] No sources to compile

 Has anyone run into this before?  I searched the JIRA for the dependency
 plugin and didn't find anything related to this.

 Thanks,

 Anthony Clark (sysadmin tasked with improving a build!)

Re: dependency plugin fails with 9 threads

[Kristian Rosenvold]

I fixed the problem on trunk in dependency plugin.

You should be able to modify the deps in your current version to work
around this,
but you need to mimic what I did in the actual fix:

http://svn.apache.org/viewvc?view=revisionrevision=1591759

Kristian



2014-05-01 21:25 GMT+02:00 Kristian Rosenvold kristian.rosenv...@gmail.com
:

 It turns out dependency plugin is using an old version of doxia (version
 1.0, latest released is 1.4) that has known thread safety issues. You
 *might* be able to work around this by adding the following dependencies to
 the dependency-plugin in your pom:

 dependency
   groupIdorg.apache.maven.doxia/groupId
   artifactIddoxia-sink-api/artifactId
   version1.4/version
 /dependency
 dependency
   groupIdorg.apache.maven.doxia/groupId
   artifactIddoxia-site-renderer/artifactId
   version1.4/version
 /dependency

 See
 http://blog.sonatype.com/2008/04/how-to-override-a-plugins-dependency-in-mavenif
  you're unfamiliar about how to do this. this might work, but might also
 bug out due to some incompatibility between 1.0 and 1.4 of doxia, I did not
 try.



 Please file an issue under http://jira.codehaus.org/browse/MDEP


 Kristian



 2014-05-01 16:00 GMT+02:00 Anthony Clark anthonyclar...@gmail.com:

 Hi All,

 I'm trying to improve our build by using parallel threads (i.e. mvn -T #)

 Unfortunately I'm running into an error when I try to use more than 9
 threads on this 24 core server:

 [ERROR] Failed to execute goal
 org.apache.maven.plugins:maven-dependency-plugin:2.8:analyze-report
 (analyze-report)
  on project enterprise-provided: An error has occurred in Dependency
 Analysis report generation. Could not find the
  template 'org/apache/maven/doxia/siterenderer/resources/default-site.vm
 -
 [Help 1]
 org.apache.maven.lifecycle.LifecycleExecutionException: Failed to execute
 goal org.apache.maven.plugins:maven-depen
 dency-plugin:2.8:analyze-report (analyze-report) on project
 enterprise-provided: An error has occurred in Dependenc
 y Analysis report generation.
 at

 org.apache.maven.lifecycle.internal.MojoExecutor.execute(MojoExecutor.java:216)
 at

 org.apache.maven.lifecycle.internal.MojoExecutor.execute(MojoExecutor.java:153)
 at

 org.apache.maven.lifecycle.internal.MojoExecutor.execute(MojoExecutor.java:145)
 at

 org.apache.maven.lifecycle.internal.LifecycleModuleBuilder.buildProject(LifecycleModuleBuilder.java:108)
 at

 org.apache.maven.lifecycle.internal.builder.multithreaded.MultiThreadedBuilder$1.call(MultiThreadedBuild
 er.java:188)
 at

 org.apache.maven.lifecycle.internal.builder.multithreaded.MultiThreadedBuilder$1.call(MultiThreadedBuild
 er.java:184)
 at java.util.concurrent.FutureTask.run(FutureTask.java:262)
 at
 java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:471)
 at java.util.concurrent.FutureTask.run(FutureTask.java:262)
 at

 java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1145)
 at

 java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:615)
 at java.lang.Thread.run(Thread.java:745)
 Caused by: org.apache.maven.plugin.MojoExecutionException: An error has
 occurred in Dependency Analysis report gene
 ration.
 at

 org.apache.maven.reporting.AbstractMavenReport.execute(AbstractMavenReport.java:106)
 at

 org.apache.maven.plugin.DefaultBuildPluginManager.executeMojo(DefaultBuildPluginManager.java:133)
 at

 org.apache.maven.lifecycle.internal.MojoExecutor.execute(MojoExecutor.java:208)
 ... 11 more
 Caused by: org.apache.maven.doxia.siterenderer.RendererException: Could
 not
 find the template
 'org/apache/maven/doxia/siterenderer/resources/default-site.vm
 at

 org.apache.maven.doxia.siterenderer.DefaultSiteRenderer.processTemplate(DefaultSiteRenderer.java:537)
 at

 org.apache.maven.doxia.siterenderer.DefaultSiteRenderer.writeTemplate(DefaultSiteRenderer.java:508)
 at

 org.apache.maven.doxia.siterenderer.DefaultSiteRenderer.generateDocument(DefaultSiteRenderer.java:485)
 at

 org.apache.maven.reporting.AbstractMavenReport.execute(AbstractMavenReport.java:97)
 ... 13 more
 [INFO] No sources to compile

 Has anyone run into this before?  I searched the JIRA for the dependency
 plugin and didn't find anything related to this.

 Thanks,

 Anthony Clark (sysadmin tasked with improving a build!)

Re: dependency plugin fails with 9 threads

[Anthony Clark]

Many thanks Kristian!

I am currently dealing with another emergency but as soon as that is over I
will track down the maven plugins directory and make the change.

I'll add the bug in JIRA as soon as I am able.

Thanks again!

Anthony


On Thu, May 1, 2014 at 4:08 PM, Kristian Rosenvold 
kristian.rosenv...@gmail.com wrote:

 I fixed the problem on trunk in dependency plugin.

 You should be able to modify the deps in your current version to work
 around this,
 but you need to mimic what I did in the actual fix:

 http://svn.apache.org/viewvc?view=revisionrevision=1591759

 Kristian



 2014-05-01 21:25 GMT+02:00 Kristian Rosenvold 
 kristian.rosenv...@gmail.com
 :

  It turns out dependency plugin is using an old version of doxia (version
  1.0, latest released is 1.4) that has known thread safety issues. You
  *might* be able to work around this by adding the following dependencies
 to
  the dependency-plugin in your pom:
 
  dependency
groupIdorg.apache.maven.doxia/groupId
artifactIddoxia-sink-api/artifactId
version1.4/version
  /dependency
  dependency
groupIdorg.apache.maven.doxia/groupId
artifactIddoxia-site-renderer/artifactId
version1.4/version
  /dependency
 
  See
 
 http://blog.sonatype.com/2008/04/how-to-override-a-plugins-dependency-in-mavenifyou're
  unfamiliar about how to do this. this might work, but might also
  bug out due to some incompatibility between 1.0 and 1.4 of doxia, I did
 not
  try.
 
 
 
  Please file an issue under http://jira.codehaus.org/browse/MDEP
 
 
  Kristian
 
 
 
  2014-05-01 16:00 GMT+02:00 Anthony Clark anthonyclar...@gmail.com:
 
  Hi All,
 
  I'm trying to improve our build by using parallel threads (i.e. mvn -T
 #)
 
  Unfortunately I'm running into an error when I try to use more than 9
  threads on this 24 core server:
 
  [ERROR] Failed to execute goal
  org.apache.maven.plugins:maven-dependency-plugin:2.8:analyze-report
  (analyze-report)
   on project enterprise-provided: An error has occurred in Dependency
  Analysis report generation. Could not find the
   template 'org/apache/maven/doxia/siterenderer/resources/default-site.vm
  -
  [Help 1]
  org.apache.maven.lifecycle.LifecycleExecutionException: Failed to
 execute
  goal org.apache.maven.plugins:maven-depen
  dency-plugin:2.8:analyze-report (analyze-report) on project
  enterprise-provided: An error has occurred in Dependenc
  y Analysis report generation.
  at
 
 
 org.apache.maven.lifecycle.internal.MojoExecutor.execute(MojoExecutor.java:216)
  at
 
 
 org.apache.maven.lifecycle.internal.MojoExecutor.execute(MojoExecutor.java:153)
  at
 
 
 org.apache.maven.lifecycle.internal.MojoExecutor.execute(MojoExecutor.java:145)
  at
 
 
 org.apache.maven.lifecycle.internal.LifecycleModuleBuilder.buildProject(LifecycleModuleBuilder.java:108)
  at
 
 
 org.apache.maven.lifecycle.internal.builder.multithreaded.MultiThreadedBuilder$1.call(MultiThreadedBuild
  er.java:188)
  at
 
 
 org.apache.maven.lifecycle.internal.builder.multithreaded.MultiThreadedBuilder$1.call(MultiThreadedBuild
  er.java:184)
  at java.util.concurrent.FutureTask.run(FutureTask.java:262)
  at
  java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:471)
  at java.util.concurrent.FutureTask.run(FutureTask.java:262)
  at
 
 
 java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1145)
  at
 
 
 java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:615)
  at java.lang.Thread.run(Thread.java:745)
  Caused by: org.apache.maven.plugin.MojoExecutionException: An error has
  occurred in Dependency Analysis report gene
  ration.
  at
 
 
 org.apache.maven.reporting.AbstractMavenReport.execute(AbstractMavenReport.java:106)
  at
 
 
 org.apache.maven.plugin.DefaultBuildPluginManager.executeMojo(DefaultBuildPluginManager.java:133)
  at
 
 
 org.apache.maven.lifecycle.internal.MojoExecutor.execute(MojoExecutor.java:208)
  ... 11 more
  Caused by: org.apache.maven.doxia.siterenderer.RendererException: Could
  not
  find the template
  'org/apache/maven/doxia/siterenderer/resources/default-site.vm
  at
 
 
 org.apache.maven.doxia.siterenderer.DefaultSiteRenderer.processTemplate(DefaultSiteRenderer.java:537)
  at
 
 
 org.apache.maven.doxia.siterenderer.DefaultSiteRenderer.writeTemplate(DefaultSiteRenderer.java:508)
  at
 
 
 org.apache.maven.doxia.siterenderer.DefaultSiteRenderer.generateDocument(DefaultSiteRenderer.java:485)
  at
 
 
 org.apache.maven.reporting.AbstractMavenReport.execute(AbstractMavenReport.java:97)
  ... 13 more
  [INFO] No sources to compile
 
  Has anyone run into this before?  I searched the JIRA for the dependency
  plugin and didn't find anything related to this.
 
  Thanks,
 
  Anthony Clark (sysadmin tasked with improving a build!)
 
 
 

Re: dependency plugin automatic version resolution

[MK Tan]

Maven will use the dependency plugin from the super pom.
Which you can found at
http://maven.apache.org/ref/3.2.1/maven-model-builder/super-pom.html



On Fri, Apr 18, 2014 at 5:09 PM, Cintia Del Rio miladyarte...@gmail.comwrote:

 Hi,


 I was reading

 http://maven.apache.org/guides/introduction/introduction-to-plugin-resolution.html
 and

 https://cwiki.apache.org/confluence/display/MAVEN/Maven+3.x+Compatibility+Notes#Maven3.xCompatibilityNotes-AutomaticPluginVersionResolution


 Based on that, I understood that if I call a plugin from CLI without a
 version, maven will try to get the latest (and released for maven 3.x)
 version available for the running maven.

 I understand as well that some plugins are already bind in a certain
 versionlifecycle phases.
 http://maven.apache.org/ref/3.0.5/maven-core/lifecycles.html


 What I don't understand is why dependency:tree is always running version
 2.0 (for maven 2.1.0), version 2.1 (for maven 3.0.5) when I don't specify a
 version. Maven 3.2.1 will run the latest version, 2.8.
 You can see that even the latest version of the plugin requires only maven
  2.0.9 (

 http://svn.apache.org/viewvc/maven/plugins/tags/maven-dependency-plugin-2.8/pom.xml
 ).
 I've checked the metadata as well, it looks fine (

 http://repo.maven.apache.org/maven2/org/apache/maven/plugins/maven-dependency-plugin/maven-metadata.xml
 ).


 What lead me to think that some other plugins have the versions hardcoded
 in maven. Is that correct? Where can I get the list of those plugins?


 Steps to test:
  mvn archetype:generate -DgroupId=com.mycompany.app -DartifactId=my-app
 -DarchetypeArtifactId=maven-archetype-quickstart -DinteractiveMode=false
  cd my-app
  mvn dependency:tree

 I removed my maven settings.xml files before testing, so I don't think it's
 something local.

 Cheers,

 --

 Cintia Del Rio

Re: dependency plugin automatic version resolution

[Cintia Del Rio]

It makes a lot of sense.

Cheers,


On 18 April 2014 19:20, MK Tan mktan...@gmail.com wrote:

 Maven will use the dependency plugin from the super pom.
 Which you can found at
 http://maven.apache.org/ref/3.2.1/maven-model-builder/super-pom.html



 On Fri, Apr 18, 2014 at 5:09 PM, Cintia Del Rio miladyarte...@gmail.com
 wrote:

  Hi,
 
 
  I was reading
 
 
 http://maven.apache.org/guides/introduction/introduction-to-plugin-resolution.html
  and
 
 
 https://cwiki.apache.org/confluence/display/MAVEN/Maven+3.x+Compatibility+Notes#Maven3.xCompatibilityNotes-AutomaticPluginVersionResolution
 
 
  Based on that, I understood that if I call a plugin from CLI without a
  version, maven will try to get the latest (and released for maven 3.x)
  version available for the running maven.
 
  I understand as well that some plugins are already bind in a certain
  versionlifecycle phases.
  http://maven.apache.org/ref/3.0.5/maven-core/lifecycles.html
 
 
  What I don't understand is why dependency:tree is always running version
  2.0 (for maven 2.1.0), version 2.1 (for maven 3.0.5) when I don't
 specify a
  version. Maven 3.2.1 will run the latest version, 2.8.
  You can see that even the latest version of the plugin requires only
 maven
   2.0.9 (
 
 
 http://svn.apache.org/viewvc/maven/plugins/tags/maven-dependency-plugin-2.8/pom.xml
  ).
  I've checked the metadata as well, it looks fine (
 
 
 http://repo.maven.apache.org/maven2/org/apache/maven/plugins/maven-dependency-plugin/maven-metadata.xml
  ).
 
 
  What lead me to think that some other plugins have the versions
 hardcoded
  in maven. Is that correct? Where can I get the list of those plugins?
 
 
  Steps to test:
   mvn archetype:generate -DgroupId=com.mycompany.app -DartifactId=my-app
  -DarchetypeArtifactId=maven-archetype-quickstart -DinteractiveMode=false
   cd my-app
   mvn dependency:tree
 
  I removed my maven settings.xml files before testing, so I don't think
 it's
  something local.
 
  Cheers,
 
  --
 
  Cintia Del Rio
 




-- 
---
Sent from TARDIS. Typos might be a timey whyney thingy.
Enviado da TARDIS, podem existir erros devido à diferenças de espaço-tempo.

Cintia Del Rio

Re: dependency management across projects

[Curtis Rueden]

Hi Jörg,

 What do you mean with irreproducible builds?

I mean that you may build the same source code today, and then again next
week, and the two build results may differ.

With our projects we wanted the certainty that if you checked out *any*
revision from the SCM history, you would still be able to build it in, say,
5 years... at least as long as you use the same versions of the tooling
(Java version etc.).

With a SNAPSHOT parent, that is not guaranteed. You may introduce a change
in the parent that causes a build to fail when it used to succeed, which
makes bisect style debugging no longer feasible. That is, if old SCM
revisions no longer build properly due to changes in the parent, you will
no longer be able to perform a binary search through the SCM history to
determine the exact commit which introduced a bug.

 This scheme works well for us now for several years.

Sure, and I'm not dissing it, just pointing out the pros and cons. We
wanted fully reproducible builds, which meant that even our SNAPSHOT
revisions have only release dependencies, including the parent POM
reference. This indeed has some negative consequences, such as needing that
script to bump things for us, rather than everything Just Working with no
changes. And you're right that *release* version builds are still
reproducible either way.

Regards,
Curtis


On Wed, Feb 5, 2014 at 1:54 AM, Jörg Schaible
joerg.schai...@swisspost.comwrote:

 Hi Curtis,

 Curtis Rueden wrote:

  Hi Jörg,
 
  We use simply x-SNAPSHOT for the parent version. That way no
  unreleased project has to be touched, it simply uses the lastest
  SNAPSHOT of the parent. No script required.
 
  Yeah, that is very convenient, if you are willing to accept the two-edged
  sword of irreproducible builds.

 What do you mean with irreproducible builds? Definitely, if you project
 relies on a SNAPSHOT parent, it does not matter if you call it 1-SNAPSHOT
 or
 x-SNAPSHOT.

  A breaking change in the parent will break
  all builds that consume it... but can be fixed just as easily too without
  touching the downstream projects.

 Well, somebody obviously made the choice for the SNAPSHOT parent ... with
 all consequences.

  Of course, it's a decision every project has to make for themselves. My
  projects opted for build reproducibility by using only release linkages
  (for parent POMs, dependencies and plugins). This has many advantages:
  e.g., git bisect fully works as one might hope, allowing you to
  resurrect the state of the code even from years prior and still build
  successfully. The downside is that you must make releases in order to be
  able to pin to them.

 Once a project is released, you also have a released parent. No surprises
 anymore. And the project can then make its own decision if it creates also
 a
 branch for the parent and rely on e.g. 254.x-SNAPSHOT either for
 maintenance
 releases or further development.

 This scheme works well for us now for several years.

 Cheers,
 Jörg


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

Re: dependency management across projects

[Stephane Nicoll]

On Mon, Feb 3, 2014 at 8:21 AM, Anders Hammar and...@hammar.net wrote:

 I believe so, yes. The key thing in my solution is the BOM. And the BOM
 will keep the appropriate version of the the sub-products together.


Right!


 There is no automatic solution for this that I know of. I suppose that
 tolls could be created, but keep in mind that in the end, for backward
 compatibility reason SP2 has to use 1.8.0 is normally a human decision.


It is. The tool I aim to create is more report-based. Something that would
gather the dependencies on each sub-projects and report inconsistencies: a
dependency unknown to the product has been added or removed, etc.

Thanks for brainstorming this with me. It feels that we're indeed lacking
for a standard solution for this in the Maven land. Will look into that and
report here my progress

S.



 /Anders


 
  Creating manually the first BOM for P v1.0.0 isn't a problem: i've
 created
  a set of tools that I am happy to share once they are fully ready. But
  maintaining that BOM in the long run is more of a challenge (because we
  can't force the sub-projects to use those versions so we have to monitor
  what happens in each sub-project to take the appropriate version at the
  product level).
 
  Thanks again for the feedback!
 
  S.
 
 
  
   /Anders
  
  
   
   


 There is also the possibility of creating a grouping pom, which
  lists
all
 artifacts as dependencies. You would then declare a dependency to
  that
 grouping pom and get all deps magically sucked in. However, this is
  not
 really the Maven way in my opinion as you wouldn't specify your
   direct
 deps bu sort of relly on transitive deps. There are some fans of
 this
 approach though here on this list.


  2. Build configs that *force* each sub-project to run with the
 list
   of
  dependencies for the project (to ensure all tests pass, etc).
 This
  is
to
 be
  used alongside the regular build job for validation purpose
 

 Maybe some enforcer rule?

   
Like I said, this is to be used alongside the regular build job. So
 my
   SP4
1.2.0-SNAPSHOT is building with a set of dependencies on its own and
 I
   want
to validate that with the dependencies of the target release for P,
 it
  is
also working just fine. It may just be the same ideally or slightly
different (or not slightly at all which requires an explicit
  validation).
   
So I need to be able to swap those versions for validation purposes
 and
   run
the build with that.
   
S.
   
   
   

 /Anders


 
  I started to look at this and my first trial was to generate a
  report
 with
  all the dependencies of each project and build a consolidated
  report
 that I
  can match against the candidates. This would help manage the
 first
   goal
 as
  if a dependency gets added, removed or updated, the global
  dependencyManagement has to be impacted manually (do we upgrade
 or
   not,
  etc).
 
  For the second part, it's not easy to force a dependency change
 in
Maven,
  especially if the version has been specified at the project
 level.
 
  Thanks for reading that far. If you have any idea or know any
 organisation
  that tried to implement that, I'd be interested
 
  Thanks!
  S.
 

   
  
 

Re: dependency management across projects

[Stephane Nicoll]

Thanks for the feedback. This looks like something that the
versions-maven-plugin could do. There's something similar that is
advertised by the plugin documentation but it's not implemented. I'll have
a look to that too.

Thanks!
S.


On Mon, Feb 3, 2014 at 6:39 PM, Curtis Rueden ctrue...@wisc.edu wrote:

 Hi everyone,

   The very point I am trying to make here is
   how do you manage that manual BOM on a daily basis.
 
  There is no automatic solution for this that I know of.

 Maybe not exactly what you are looking for, but sort of similar:

 My group uses a script [1] to automatically bump the version of our parent
 POM [2].

 In that parent POM, we declare many version properties, plugin
 configuration in pluginManagement, etc., and we like to keep all our
 projects across various Git repositories using the newest available version
 of the parent, to minimize version clashes when mixing and matching
 libraries.

 We set up a parameterized Jenkins job [3] to run the parent bump for us,
 which provides checkboxes for all the downstream projects so the bump can
 be controlled individually.

 It's not perfect but it does save a lot of manual maintenance.

 Regards,
 Curtis

 [1]

 https://github.com/scijava/scijava-scripts/blob/a0fc8006741e0216c74c82866fd1bb1a7d364d55/bump-pom-scijava.sh
 [2]

 https://github.com/scijava/pom-scijava/blob/0de0676f7731b98baa89379dc8b92f8b26a5d086/pom.xml
 [3] http://jenkins.imagej.net/view/SciJava/job/Bump-POM-SciJava/


 On Mon, Feb 3, 2014 at 1:21 AM, Anders Hammar and...@hammar.net wrote:

  
The release of the BOM would be that release of a single coherent
  unit
then. It would specify the (marketing) version of the platform P.
For example, P v1.0.0 will include v1.2.3 of SP1 (sub-product 1),
  v1.4.3
   of
SP2, etc.
  
   Isn't it what I just write in my original post? (without mentioning the
   BOM)
  
 
  I believe so, yes. The key thing in my solution is the BOM. And the BOM
  will keep the appropriate version of the the sub-products together.
 
 
 
   The very point I am trying to make here is
   how do you manage that manual BOM on a daily basis. Each sub-project
  has
   its own release cycle and we cannot force the versions it has to use
 for
  a
   specific branch. For instance, the product might state that the
  dependency
   D should be 2.2.0 (because that's the latest or the one that people
   generally use) but for backward compatibility reason SP2 has to use
  1.8.0.
  
 
  There is no automatic solution for this that I know of. I suppose that
  tolls could be created, but keep in mind that in the end, for backward
  compatibility reason SP2 has to use 1.8.0 is normally a human decision.
 
  /Anders
 
 
  
   Creating manually the first BOM for P v1.0.0 isn't a problem: i've
  created
   a set of tools that I am happy to share once they are fully ready. But
   maintaining that BOM in the long run is more of a challenge (because we
   can't force the sub-projects to use those versions so we have to
 monitor
   what happens in each sub-project to take the appropriate version at the
   product level).
  
   Thanks again for the feedback!
  
   S.
  
  
   
/Anders
   
   


 
 
  There is also the possibility of creating a grouping pom, which
   lists
 all
  artifacts as dependencies. You would then declare a dependency to
   that
  grouping pom and get all deps magically sucked in. However, this
 is
   not
  really the Maven way in my opinion as you wouldn't specify your
direct
  deps bu sort of relly on transitive deps. There are some fans of
  this
  approach though here on this list.
 
 
   2. Build configs that *force* each sub-project to run with the
  list
of
   dependencies for the project (to ensure all tests pass, etc).
  This
   is
 to
  be
   used alongside the regular build job for validation purpose
  
 
  Maybe some enforcer rule?
 

 Like I said, this is to be used alongside the regular build job. So
  my
SP4
 1.2.0-SNAPSHOT is building with a set of dependencies on its own
 and
  I
want
 to validate that with the dependencies of the target release for P,
  it
   is
 also working just fine. It may just be the same ideally or slightly
 different (or not slightly at all which requires an explicit
   validation).

 So I need to be able to swap those versions for validation purposes
  and
run
 the build with that.

 S.



 
  /Anders
 
 
  
   I started to look at this and my first trial was to generate a
   report
  with
   all the dependencies of each project and build a consolidated
   report
  that I
   can match against the candidates. This would help manage the
  first
goal
  as
   if a dependency gets added, removed or updated, the global
   dependencyManagement has to be impacted manually (do we upgrade

Re: dependency management across projects

[Jörg Schaible]

Curtis Rueden wrote:

 Hi everyone,
 
  The very point I am trying to make here is
  how do you manage that manual BOM on a daily basis.

 There is no automatic solution for this that I know of.
 
 Maybe not exactly what you are looking for, but sort of similar:
 
 My group uses a script [1] to automatically bump the version of our parent
 POM [2].

We use simply x-SNAPSHOT for the parent version. That way no unreleased 
project has to be touched, it simply uses the lastest SNAPSHOT of the 
parent. No script required.

[snip]

- Jörg


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

Re: dependency management across projects

[Curtis Rueden]

Hi Jörg,

 We use simply x-SNAPSHOT for the parent version. That way no
 unreleased project has to be touched, it simply uses the lastest
 SNAPSHOT of the parent. No script required.

Yeah, that is very convenient, if you are willing to accept the two-edged
sword of irreproducible builds. A breaking change in the parent will break
all builds that consume it... but can be fixed just as easily too without
touching the downstream projects.

Of course, it's a decision every project has to make for themselves. My
projects opted for build reproducibility by using only release linkages
(for parent POMs, dependencies and plugins). This has many advantages:
e.g., git bisect fully works as one might hope, allowing you to resurrect
the state of the code even from years prior and still build successfully.
The downside is that you must make releases in order to be able to pin to
them.

Regards,
Curtis


On Tue, Feb 4, 2014 at 4:38 AM, Jörg Schaible
joerg.schai...@swisspost.comwrote:

 Curtis Rueden wrote:

  Hi everyone,
 
   The very point I am trying to make here is
   how do you manage that manual BOM on a daily basis.
 
  There is no automatic solution for this that I know of.
 
  Maybe not exactly what you are looking for, but sort of similar:
 
  My group uses a script [1] to automatically bump the version of our
 parent
  POM [2].

 We use simply x-SNAPSHOT for the parent version. That way no unreleased
 project has to be touched, it simply uses the lastest SNAPSHOT of the
 parent. No script required.

 [snip]

 - Jörg


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

Re: dependency management across projects

[Jörg Schaible]

Hi Curtis,

Curtis Rueden wrote:

 Hi Jörg,
 
 We use simply x-SNAPSHOT for the parent version. That way no
 unreleased project has to be touched, it simply uses the lastest
 SNAPSHOT of the parent. No script required.
 
 Yeah, that is very convenient, if you are willing to accept the two-edged
 sword of irreproducible builds.

What do you mean with irreproducible builds? Definitely, if you project 
relies on a SNAPSHOT parent, it does not matter if you call it 1-SNAPSHOT or 
x-SNAPSHOT.

 A breaking change in the parent will break
 all builds that consume it... but can be fixed just as easily too without
 touching the downstream projects.

Well, somebody obviously made the choice for the SNAPSHOT parent ... with 
all consequences.

 Of course, it's a decision every project has to make for themselves. My
 projects opted for build reproducibility by using only release linkages
 (for parent POMs, dependencies and plugins). This has many advantages:
 e.g., git bisect fully works as one might hope, allowing you to
 resurrect the state of the code even from years prior and still build
 successfully. The downside is that you must make releases in order to be
 able to pin to them.

Once a project is released, you also have a released parent. No surprises 
anymore. And the project can then make its own decision if it creates also a 
branch for the parent and rely on e.g. 254.x-SNAPSHOT either for maintenance 
releases or further development.

This scheme works well for us now for several years.

Cheers,
Jörg


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

Re: dependency management across projects

[Curtis Rueden]

Hi everyone,

  The very point I am trying to make here is
  how do you manage that manual BOM on a daily basis.

 There is no automatic solution for this that I know of.

Maybe not exactly what you are looking for, but sort of similar:

My group uses a script [1] to automatically bump the version of our parent
POM [2].

In that parent POM, we declare many version properties, plugin
configuration in pluginManagement, etc., and we like to keep all our
projects across various Git repositories using the newest available version
of the parent, to minimize version clashes when mixing and matching
libraries.

We set up a parameterized Jenkins job [3] to run the parent bump for us,
which provides checkboxes for all the downstream projects so the bump can
be controlled individually.

It's not perfect but it does save a lot of manual maintenance.

Regards,
Curtis

[1]
https://github.com/scijava/scijava-scripts/blob/a0fc8006741e0216c74c82866fd1bb1a7d364d55/bump-pom-scijava.sh
[2]
https://github.com/scijava/pom-scijava/blob/0de0676f7731b98baa89379dc8b92f8b26a5d086/pom.xml
[3] http://jenkins.imagej.net/view/SciJava/job/Bump-POM-SciJava/


On Mon, Feb 3, 2014 at 1:21 AM, Anders Hammar and...@hammar.net wrote:

 
   The release of the BOM would be that release of a single coherent
 unit
   then. It would specify the (marketing) version of the platform P.
   For example, P v1.0.0 will include v1.2.3 of SP1 (sub-product 1),
 v1.4.3
  of
   SP2, etc.
 
  Isn't it what I just write in my original post? (without mentioning the
  BOM)
 

 I believe so, yes. The key thing in my solution is the BOM. And the BOM
 will keep the appropriate version of the the sub-products together.



  The very point I am trying to make here is
  how do you manage that manual BOM on a daily basis. Each sub-project
 has
  its own release cycle and we cannot force the versions it has to use for
 a
  specific branch. For instance, the product might state that the
 dependency
  D should be 2.2.0 (because that's the latest or the one that people
  generally use) but for backward compatibility reason SP2 has to use
 1.8.0.
 

 There is no automatic solution for this that I know of. I suppose that
 tolls could be created, but keep in mind that in the end, for backward
 compatibility reason SP2 has to use 1.8.0 is normally a human decision.

 /Anders


 
  Creating manually the first BOM for P v1.0.0 isn't a problem: i've
 created
  a set of tools that I am happy to share once they are fully ready. But
  maintaining that BOM in the long run is more of a challenge (because we
  can't force the sub-projects to use those versions so we have to monitor
  what happens in each sub-project to take the appropriate version at the
  product level).
 
  Thanks again for the feedback!
 
  S.
 
 
  
   /Anders
  
  
   
   


 There is also the possibility of creating a grouping pom, which
  lists
all
 artifacts as dependencies. You would then declare a dependency to
  that
 grouping pom and get all deps magically sucked in. However, this is
  not
 really the Maven way in my opinion as you wouldn't specify your
   direct
 deps bu sort of relly on transitive deps. There are some fans of
 this
 approach though here on this list.


  2. Build configs that *force* each sub-project to run with the
 list
   of
  dependencies for the project (to ensure all tests pass, etc).
 This
  is
to
 be
  used alongside the regular build job for validation purpose
 

 Maybe some enforcer rule?

   
Like I said, this is to be used alongside the regular build job. So
 my
   SP4
1.2.0-SNAPSHOT is building with a set of dependencies on its own and
 I
   want
to validate that with the dependencies of the target release for P,
 it
  is
also working just fine. It may just be the same ideally or slightly
different (or not slightly at all which requires an explicit
  validation).
   
So I need to be able to swap those versions for validation purposes
 and
   run
the build with that.
   
S.
   
   
   

 /Anders


 
  I started to look at this and my first trial was to generate a
  report
 with
  all the dependencies of each project and build a consolidated
  report
 that I
  can match against the candidates. This would help manage the
 first
   goal
 as
  if a dependency gets added, removed or updated, the global
  dependencyManagement has to be impacted manually (do we upgrade
 or
   not,
  etc).
 
  For the second part, it's not easy to force a dependency change
 in
Maven,
  especially if the version has been specified at the project
 level.
 
  Thanks for reading that far. If you have any idea or know any
 organisation
  that tried to implement that, I'd be interested
 
  Thanks!
  S.
 

   
  
 

Re: dependency management across projects

[Stephane Nicoll]

On Fri, Jan 31, 2014 at 1:16 PM, Anders Hammar and...@hammar.net wrote:

 The release of the BOM would be that release of a single coherent unit
 then. It would specify the (marketing) version of the platform P.
 For example, P v1.0.0 will include v1.2.3 of SP1 (sub-product 1), v1.4.3 of
 SP2, etc.


Isn't it what I just write in my original post? (without mentioning the BOM)



 Creating the BOM would be a manual work I think, as you want to make sure
 that exactly the correct versions are included (might not be the latest
 releases).


Yes, this is already what I do. The very point I am trying to make here is
how do you manage that manual BOM on a daily basis. Each sub-project has
its own release cycle and we cannot force the versions it has to use for a
specific branch. For instance, the product might state that the dependency
D should be 2.2.0 (because that's the latest or the one that people
generally use) but for backward compatibility reason SP2 has to use 1.8.0.

Creating manually the first BOM for P v1.0.0 isn't a problem: i've created
a set of tools that I am happy to share once they are fully ready. But
maintaining that BOM in the long run is more of a challenge (because we
can't force the sub-projects to use those versions so we have to monitor
what happens in each sub-project to take the appropriate version at the
product level).

Thanks again for the feedback!

S.



 /Anders


 
 
  
  
   There is also the possibility of creating a grouping pom, which lists
  all
   artifacts as dependencies. You would then declare a dependency to that
   grouping pom and get all deps magically sucked in. However, this is not
   really the Maven way in my opinion as you wouldn't specify your
 direct
   deps bu sort of relly on transitive deps. There are some fans of this
   approach though here on this list.
  
  
2. Build configs that *force* each sub-project to run with the list
 of
dependencies for the project (to ensure all tests pass, etc). This is
  to
   be
used alongside the regular build job for validation purpose
   
  
   Maybe some enforcer rule?
  
 
  Like I said, this is to be used alongside the regular build job. So my
 SP4
  1.2.0-SNAPSHOT is building with a set of dependencies on its own and I
 want
  to validate that with the dependencies of the target release for P, it is
  also working just fine. It may just be the same ideally or slightly
  different (or not slightly at all which requires an explicit validation).
 
  So I need to be able to swap those versions for validation purposes and
 run
  the build with that.
 
  S.
 
 
 
  
   /Anders
  
  
   
I started to look at this and my first trial was to generate a report
   with
all the dependencies of each project and build a consolidated report
   that I
can match against the candidates. This would help manage the first
 goal
   as
if a dependency gets added, removed or updated, the global
dependencyManagement has to be impacted manually (do we upgrade or
 not,
etc).
   
For the second part, it's not easy to force a dependency change in
  Maven,
especially if the version has been specified at the project level.
   
Thanks for reading that far. If you have any idea or know any
   organisation
that tried to implement that, I'd be interested
   
Thanks!
S.
   
  
 

Re: dependency management across projects

[Anders Hammar]

  The release of the BOM would be that release of a single coherent unit
  then. It would specify the (marketing) version of the platform P.
  For example, P v1.0.0 will include v1.2.3 of SP1 (sub-product 1), v1.4.3
 of
  SP2, etc.

 Isn't it what I just write in my original post? (without mentioning the
 BOM)


I believe so, yes. The key thing in my solution is the BOM. And the BOM
will keep the appropriate version of the the sub-products together.



 The very point I am trying to make here is
 how do you manage that manual BOM on a daily basis. Each sub-project has
 its own release cycle and we cannot force the versions it has to use for a
 specific branch. For instance, the product might state that the dependency
 D should be 2.2.0 (because that's the latest or the one that people
 generally use) but for backward compatibility reason SP2 has to use 1.8.0.


There is no automatic solution for this that I know of. I suppose that
tolls could be created, but keep in mind that in the end, for backward
compatibility reason SP2 has to use 1.8.0 is normally a human decision.

/Anders



 Creating manually the first BOM for P v1.0.0 isn't a problem: i've created
 a set of tools that I am happy to share once they are fully ready. But
 maintaining that BOM in the long run is more of a challenge (because we
 can't force the sub-projects to use those versions so we have to monitor
 what happens in each sub-project to take the appropriate version at the
 product level).

 Thanks again for the feedback!

 S.


 
  /Anders
 
 
  
  
   
   
There is also the possibility of creating a grouping pom, which
 lists
   all
artifacts as dependencies. You would then declare a dependency to
 that
grouping pom and get all deps magically sucked in. However, this is
 not
really the Maven way in my opinion as you wouldn't specify your
  direct
deps bu sort of relly on transitive deps. There are some fans of this
approach though here on this list.
   
   
 2. Build configs that *force* each sub-project to run with the list
  of
 dependencies for the project (to ensure all tests pass, etc). This
 is
   to
be
 used alongside the regular build job for validation purpose

   
Maybe some enforcer rule?
   
  
   Like I said, this is to be used alongside the regular build job. So my
  SP4
   1.2.0-SNAPSHOT is building with a set of dependencies on its own and I
  want
   to validate that with the dependencies of the target release for P, it
 is
   also working just fine. It may just be the same ideally or slightly
   different (or not slightly at all which requires an explicit
 validation).
  
   So I need to be able to swap those versions for validation purposes and
  run
   the build with that.
  
   S.
  
  
  
   
/Anders
   
   

 I started to look at this and my first trial was to generate a
 report
with
 all the dependencies of each project and build a consolidated
 report
that I
 can match against the candidates. This would help manage the first
  goal
as
 if a dependency gets added, removed or updated, the global
 dependencyManagement has to be impacted manually (do we upgrade or
  not,
 etc).

 For the second part, it's not easy to force a dependency change in
   Maven,
 especially if the version has been specified at the project level.

 Thanks for reading that far. If you have any idea or know any
organisation
 that tried to implement that, I'd be interested

 Thanks!
 S.

   
  
 

Re: dependency management across projects

[Anders Hammar]

 1. Provide a single/coherent dependencyManagement section so that users
 using P do not have to care about the different versions of the
 sub-projects: they use P and all the required dependencies are pulled
 automatically


Some confusion here. You're talking about depMgmt and then say that the
required deps should be pulled in autoamtically. That will not happen. You
still need to specify the deps you have.
In any case, this is ok if you want to stay on the Maven way. This
depMgmt could be handled/provided in a separate pom which is then included
in those projects that want to use the platform/product. Sometimes this is
called a BOM (Bill of Material). JBoss provides such a BOM for their app
server for example. A quick Google gave this page talking about that:
http://www.mastertheboss.com/jboss-maven/maven-and-jboss-how-to-use-boms

There is also the possibility of creating a grouping pom, which lists all
artifacts as dependencies. You would then declare a dependency to that
grouping pom and get all deps magically sucked in. However, this is not
really the Maven way in my opinion as you wouldn't specify your direct
deps bu sort of relly on transitive deps. There are some fans of this
approach though here on this list.


 2. Build configs that *force* each sub-project to run with the list of
 dependencies for the project (to ensure all tests pass, etc). This is to be
 used alongside the regular build job for validation purpose


Maybe some enforcer rule?

/Anders



 I started to look at this and my first trial was to generate a report with
 all the dependencies of each project and build a consolidated report that I
 can match against the candidates. This would help manage the first goal as
 if a dependency gets added, removed or updated, the global
 dependencyManagement has to be impacted manually (do we upgrade or not,
 etc).

 For the second part, it's not easy to force a dependency change in Maven,
 especially if the version has been specified at the project level.

 Thanks for reading that far. If you have any idea or know any organisation
 that tried to implement that, I'd be interested

 Thanks!
 S.

Re: dependency management across projects

[Stephane Nicoll]

Thanks for the response.

On Fri, Jan 31, 2014 at 11:33 AM, Anders Hammar and...@hammar.net wrote:

 
  1. Provide a single/coherent dependencyManagement section so that users
  using P do not have to care about the different versions of the
  sub-projects: they use P and all the required dependencies are pulled
  automatically
 

 Some confusion here. You're talking about depMgmt and then say that the
 required deps should be pulled in autoamtically. That will not happen. You
 still need to specify the deps you have.


Yes, but not the versions. The users will have to add the dependency they
want to use, yes. The point here is that they don't have to care about the
versions (but I do, which is why I need some tooling)



 In any case, this is ok if you want to stay on the Maven way. This
 depMgmt could be handled/provided in a separate pom which is then included
 in those projects that want to use the platform/product. Sometimes this is
 called a BOM (Bill of Material). JBoss provides such a BOM for their app
 server for example. A quick Google gave this page talking about that:
 http://www.mastertheboss.com/jboss-maven/maven-and-jboss-how-to-use-boms



BOM is exactly what I want to do, yes. What may not be clear in my original
post is that I am looking at this problem as the release manager of P who
wants to release P 1.0.0 with SP1 1.2.3, SP2 1.4.3, SP3 4.3.0, etc. I want
to have an overview of where the different sub-projects stands with regards
to the target for P.

Assume that each sub-project has its own release cycle (and is released as
a project on its own actually) and at some point those different projects
have to be released as a single coherent unit.




 There is also the possibility of creating a grouping pom, which lists all
 artifacts as dependencies. You would then declare a dependency to that
 grouping pom and get all deps magically sucked in. However, this is not
 really the Maven way in my opinion as you wouldn't specify your direct
 deps bu sort of relly on transitive deps. There are some fans of this
 approach though here on this list.


  2. Build configs that *force* each sub-project to run with the list of
  dependencies for the project (to ensure all tests pass, etc). This is to
 be
  used alongside the regular build job for validation purpose
 

 Maybe some enforcer rule?


Like I said, this is to be used alongside the regular build job. So my SP4
1.2.0-SNAPSHOT is building with a set of dependencies on its own and I want
to validate that with the dependencies of the target release for P, it is
also working just fine. It may just be the same ideally or slightly
different (or not slightly at all which requires an explicit validation).

So I need to be able to swap those versions for validation purposes and run
the build with that.

S.




 /Anders


 
  I started to look at this and my first trial was to generate a report
 with
  all the dependencies of each project and build a consolidated report
 that I
  can match against the candidates. This would help manage the first goal
 as
  if a dependency gets added, removed or updated, the global
  dependencyManagement has to be impacted manually (do we upgrade or not,
  etc).
 
  For the second part, it's not easy to force a dependency change in Maven,
  especially if the version has been specified at the project level.
 
  Thanks for reading that far. If you have any idea or know any
 organisation
  that tried to implement that, I'd be interested
 
  Thanks!
  S.
 

Re: dependency management across projects

[Anders Hammar]

 Some confusion here. You're talking about depMgmt and then say that the
  required deps should be pulled in autoamtically. That will not happen.
 You
  still need to specify the deps you have.

 Yes, but not the versions. The users will have to add the dependency they
 want to use, yes. The point here is that they don't have to care about the
 versions (but I do, which is why I need some tooling)


  In any case, this is ok if you want to stay on the Maven way. This
  depMgmt could be handled/provided in a separate pom which is then
 included
  in those projects that want to use the platform/product. Sometimes this
 is
  called a BOM (Bill of Material). JBoss provides such a BOM for their app
  server for example. A quick Google gave this page talking about that:
  http://www.mastertheboss.com/jboss-maven/maven-and-jboss-how-to-use-boms

 BOM is exactly what I want to do, yes. What may not be clear in my original
 post is that I am looking at this problem as the release manager of P who
 wants to release P 1.0.0 with SP1 1.2.3, SP2 1.4.3, SP3 4.3.0, etc. I want
 to have an overview of where the different sub-projects stands with regards
 to the target for P.

 Assume that each sub-project has its own release cycle (and is released as
 a project on its own actually) and at some point those different projects
 have to be released as a single coherent unit.


The release of the BOM would be that release of a single coherent unit
then. It would specify the (marketing) version of the platform P.
For example, P v1.0.0 will include v1.2.3 of SP1 (sub-product 1), v1.4.3 of
SP2, etc.

Creating the BOM would be a manual work I think, as you want to make sure
that exactly the correct versions are included (might not be the latest
releases).

/Anders




 
 
  There is also the possibility of creating a grouping pom, which lists
 all
  artifacts as dependencies. You would then declare a dependency to that
  grouping pom and get all deps magically sucked in. However, this is not
  really the Maven way in my opinion as you wouldn't specify your direct
  deps bu sort of relly on transitive deps. There are some fans of this
  approach though here on this list.
 
 
   2. Build configs that *force* each sub-project to run with the list of
   dependencies for the project (to ensure all tests pass, etc). This is
 to
  be
   used alongside the regular build job for validation purpose
  
 
  Maybe some enforcer rule?
 

 Like I said, this is to be used alongside the regular build job. So my SP4
 1.2.0-SNAPSHOT is building with a set of dependencies on its own and I want
 to validate that with the dependencies of the target release for P, it is
 also working just fine. It may just be the same ideally or slightly
 different (or not slightly at all which requires an explicit validation).

 So I need to be able to swap those versions for validation purposes and run
 the build with that.

 S.



 
  /Anders
 
 
  
   I started to look at this and my first trial was to generate a report
  with
   all the dependencies of each project and build a consolidated report
  that I
   can match against the candidates. This would help manage the first goal
  as
   if a dependency gets added, removed or updated, the global
   dependencyManagement has to be impacted manually (do we upgrade or not,
   etc).
  
   For the second part, it's not easy to force a dependency change in
 Maven,
   especially if the version has been specified at the project level.
  
   Thanks for reading that far. If you have any idea or know any
  organisation
   that tried to implement that, I'd be interested
  
   Thanks!
   S.
  
 

Re: dependency management across projects

[Ron Wheeler]

As one of the fans of a non-Maven way to deal with this, I will point 
you to some documentation on the approach.


http://blog.artifact-software.com/tech/?tag=maven
This should get you 4 articles that discuss our approach to Maven.

http://blog.artifact-software.com/tech/?p=121
Specifically addresses the problem that you are working through.

It works well for us.
Our big project had over 30 independent modules that depended on more 
than 70 third party modules - Tomcat, Jetspeed, Apache Commons, Spring, 
Hibernate, Mysql JSF, CXF, Jasper Reports, etc.


We are currently actively developing 2 projects each with about 10 
modules (Maven Projects) with the same technology stack (Jackrabbit 
replacing MySQL and adding Spring-Data) and have continued the same 
approach.


It works well and makes the war files very small and cuts the build time 
dramatically.
It relieves the developer from dealing with versions and dependency 
configurations.
The individual shared libraries have the right versions with the 
required exclusions already fixed up so inter-library conflicts are 
resolved.

The developer just have to make sure that their code works.

If they want to add a third party library that is not included in the 
corporate utility libraries, this is supposed to be discussed at the 
project level to see if it should be shared or not.
We don't make a big deal about this now that we have a really good core 
stack settled.


At the beginning of each release cycle we review the approved versions 
and upgrade as appropriate. This lets us review and test dependency 
changes as a team.


We use the STS version of Eclipse so we have full support for Maven and 
can easily see where dependencies are coming from and where potential 
dependency conflicts occur between third party software so exclusions 
can be adjusted.



Ron

On 31/01/2014 5:33 AM, Anders Hammar wrote:

1. Provide a single/coherent dependencyManagement section so that users
using P do not have to care about the different versions of the
sub-projects: they use P and all the required dependencies are pulled
automatically


Some confusion here. You're talking about depMgmt and then say that the
required deps should be pulled in autoamtically. That will not happen. You
still need to specify the deps you have.
In any case, this is ok if you want to stay on the Maven way. This
depMgmt could be handled/provided in a separate pom which is then included
in those projects that want to use the platform/product. Sometimes this is
called a BOM (Bill of Material). JBoss provides such a BOM for their app
server for example. A quick Google gave this page talking about that:
http://www.mastertheboss.com/jboss-maven/maven-and-jboss-how-to-use-boms

There is also the possibility of creating a grouping pom, which lists all
artifacts as dependencies. You would then declare a dependency to that
grouping pom and get all deps magically sucked in. However, this is not
really the Maven way in my opinion as you wouldn't specify your direct
deps bu sort of relly on transitive deps. There are some fans of this
approach though here on this list.



2. Build configs that *force* each sub-project to run with the list of
dependencies for the project (to ensure all tests pass, etc). This is to be
used alongside the regular build job for validation purpose


Maybe some enforcer rule?

/Anders



I started to look at this and my first trial was to generate a report with
all the dependencies of each project and build a consolidated report that I
can match against the candidates. This would help manage the first goal as
if a dependency gets added, removed or updated, the global
dependencyManagement has to be impacted manually (do we upgrade or not,
etc).

For the second part, it's not easy to force a dependency change in Maven,
especially if the version has been specified at the project level.

Thanks for reading that far. If you have any idea or know any organisation
that tried to implement that, I'd be interested

Thanks!
S.




--
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 plugin strangeness

[Stephen Connolly]

The crucial detail was omitted... what version of Maven?

I suspect it could be a transitive dependency with system scope causing a
bug of some sort.

Most likely if you switch to a different version of Maven the command will
work... in which case you might be able to construct a test case to prove a
regression.

Touchstone versions of Maven to try are: 2.2.1, 3.0.4/3.0.5 and 3.1.1

If you see the error on all three then it is something different... but
still an important data point.

More of the stack trace would help... ideally include a line or two above
and below... there is often crucial details therein... if you need to hide
GAV details, change the groupId's to something gibberish, e.g.
com.foobar:foo-manchu:1.0-SNAPSHOT and other dummy GAVs


On 28 January 2014 22:55, Lyons, Roy roy.ly...@cmegroup.com wrote:

 So, I tried my google-fu first - and in general my google-fu is very very
 strong...

 I've been fighting with this multi-module plan for some time now with the
 developer who is reporting the issue to me.  The issue manifested itself as
 part of a Sonar failure...  the funny thing is, that the failure was on a
 dependenct tree resolution that Sonar was doing - so I had him try the
 dependency plugin and perform a dependency:tree

 dependency tree failed us...  well, it probably isn't dependency plugin's
 fault but I am at a loss as to what it is really dying on or why.

 I would absolutely love it if someone saw this and said Oh yeah, I know
 that issue.  Its a real pain.  They have XXX defined incorrectly in their
 multimodule build so the dependency plugin is in a circular dependency
 loop (or something like that).  I have no idea if its a dependency loop,
 was just an example.

 I can't share the poms because its all proprietary closed source stuff
 (and I have to be careful about what is shared).  If this means that I dont
 have enough info to help, I can live with that - and will continue to plow
 forwards...  I just wanted to see if theres someone on the list who knows
 exactly what I should be looking for to help shorten my investigation time.

 Here's an example of what dependency:tree is complaining about.


  mvn dependency:tree -Dverbose=true -DoutputFile=dependencies.txt -e -X

 urls[38] =
 file:/C:/Users/thisguysuserid/.m2/repository/commons-collections/commons-collections/3.2.1/commons-collections-3.2.1.jar
 Number of foreign imports: 1
 import: Entry[import  from realm ClassRealm[maven.api, parent: null]]
 -

 at
 org.apache.maven.plugin.DefaultBuildPluginManager.executeMojo(DefaultBuildPluginManager.java:139)
 at
 org.apache.maven.lifecycle.internal.MojoExecutor.execute(MojoExecutor.java:209)
 ... 19 more
 Caused by: org.apache.maven.plugin.PluginContainerException: An API
 incompatibility was encountered while executing
 org.apache.maven.plugins:maven-dependency-plugin:2.8:tree:
 java.lang.AbstractMethodError:
 org.apache.maven.shared.dependency.tree.DependencyTreeResolutionListener.manageArtifactSystemPath(Lorg/apache/maven/artifact/Artifact;Lorg/apache/maven/artifact/Artifact;)V






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

Re: dependency plugin strangeness

[Vincent Latombe]

Hi,

I have already seen such error.
It is caused by the combination of a managed dependency (through
dependencyManagement) defining a dependency with system scope + Maven 3 +
Sonar. The same with Maven 2.2.1 should work.
Though, I have never seen it directly in a dependency:tree execution; only
through a sonar analysis.

On my side, I got rid of the system scope usages.

Vincent


2014-01-29 Stephen Connolly stephen.alan.conno...@gmail.com

 The crucial detail was omitted... what version of Maven?

 I suspect it could be a transitive dependency with system scope causing a
 bug of some sort.

 Most likely if you switch to a different version of Maven the command will
 work... in which case you might be able to construct a test case to prove a
 regression.

 Touchstone versions of Maven to try are: 2.2.1, 3.0.4/3.0.5 and 3.1.1

 If you see the error on all three then it is something different... but
 still an important data point.

 More of the stack trace would help... ideally include a line or two above
 and below... there is often crucial details therein... if you need to hide
 GAV details, change the groupId's to something gibberish, e.g.
 com.foobar:foo-manchu:1.0-SNAPSHOT and other dummy GAVs


 On 28 January 2014 22:55, Lyons, Roy roy.ly...@cmegroup.com wrote:

  So, I tried my google-fu first - and in general my google-fu is very very
  strong...
 
  I've been fighting with this multi-module plan for some time now with the
  developer who is reporting the issue to me.  The issue manifested itself
 as
  part of a Sonar failure...  the funny thing is, that the failure was on a
  dependenct tree resolution that Sonar was doing - so I had him try the
  dependency plugin and perform a dependency:tree
 
  dependency tree failed us...  well, it probably isn't dependency plugin's
  fault but I am at a loss as to what it is really dying on or why.
 
  I would absolutely love it if someone saw this and said Oh yeah, I know
  that issue.  Its a real pain.  They have XXX defined incorrectly in their
  multimodule build so the dependency plugin is in a circular dependency
  loop (or something like that).  I have no idea if its a dependency loop,
  was just an example.
 
  I can't share the poms because its all proprietary closed source stuff
  (and I have to be careful about what is shared).  If this means that I
 dont
  have enough info to help, I can live with that - and will continue to
 plow
  forwards...  I just wanted to see if theres someone on the list who knows
  exactly what I should be looking for to help shorten my investigation
 time.
 
  Here's an example of what dependency:tree is complaining about.
 
 
   mvn dependency:tree -Dverbose=true -DoutputFile=dependencies.txt -e -X
 
  urls[38] =
 
 file:/C:/Users/thisguysuserid/.m2/repository/commons-collections/commons-collections/3.2.1/commons-collections-3.2.1.jar
  Number of foreign imports: 1
  import: Entry[import  from realm ClassRealm[maven.api, parent: null]]
  -
 
  at
 
 org.apache.maven.plugin.DefaultBuildPluginManager.executeMojo(DefaultBuildPluginManager.java:139)
  at
 
 org.apache.maven.lifecycle.internal.MojoExecutor.execute(MojoExecutor.java:209)
  ... 19 more
  Caused by: org.apache.maven.plugin.PluginContainerException: An API
  incompatibility was encountered while executing
  org.apache.maven.plugins:maven-dependency-plugin:2.8:tree:
  java.lang.AbstractMethodError:
 
 org.apache.maven.shared.dependency.tree.DependencyTreeResolutionListener.manageArtifactSystemPath(Lorg/apache/maven/artifact/Artifact;Lorg/apache/maven/artifact/Artifact;)V
 
 
 
 
 
 
  -
  To unsubscribe, e-mail: users-unsubscr...@maven.apache.org
  For additional commands, e-mail: users-h...@maven.apache.org
 
 

Re: dependency plugin strangeness

[Lyons, Roy]

After Stephen mentioned trying different versions, I had the developer try
out maven 2.2.1.  I was about to report back that this worked and how
strange it was -- but before sending I saw this email from Vincent.

I'll pass along the system scope issue - perhaps that is the nail in the
coffin.  We reverted with 2.2.1, with instructions to work on making it
3.x compliant in the background.

Thank you for all the input on this issue.  It is very much appreciated.

Thanks,

Roy

On 1/29/14 12:33 PM, Vincent Latombe vincent.lato...@gmail.com wrote:

Hi,

I have already seen such error.
It is caused by the combination of a managed dependency (through
dependencyManagement) defining a dependency with system scope + Maven 3 +
Sonar. The same with Maven 2.2.1 should work.
Though, I have never seen it directly in a dependency:tree execution; only
through a sonar analysis.

On my side, I got rid of the system scope usages.

Vincent


2014-01-29 Stephen Connolly stephen.alan.conno...@gmail.com

 The crucial detail was omitted... what version of Maven?

 I suspect it could be a transitive dependency with system scope causing
a
 bug of some sort.

 Most likely if you switch to a different version of Maven the command
will
 work... in which case you might be able to construct a test case to
prove a
 regression.

 Touchstone versions of Maven to try are: 2.2.1, 3.0.4/3.0.5 and 3.1.1

 If you see the error on all three then it is something different... but
 still an important data point.

 More of the stack trace would help... ideally include a line or two
above
 and below... there is often crucial details therein... if you need to
hide
 GAV details, change the groupId's to something gibberish, e.g.
 com.foobar:foo-manchu:1.0-SNAPSHOT and other dummy GAVs


 On 28 January 2014 22:55, Lyons, Roy roy.ly...@cmegroup.com wrote:

  So, I tried my google-fu first - and in general my google-fu is very
very
  strong...
 
  I've been fighting with this multi-module plan for some time now with
the
  developer who is reporting the issue to me.  The issue manifested
itself
 as
  part of a Sonar failure...  the funny thing is, that the failure was
on a
  dependenct tree resolution that Sonar was doing - so I had him try the
  dependency plugin and perform a dependency:tree
 
  dependency tree failed us...  well, it probably isn't dependency
plugin's
  fault but I am at a loss as to what it is really dying on or why.
 
  I would absolutely love it if someone saw this and said Oh yeah, I
know
  that issue.  Its a real pain.  They have XXX defined incorrectly in
their
  multimodule build so the dependency plugin is in a circular dependency
  loop (or something like that).  I have no idea if its a dependency
loop,
  was just an example.
 
  I can't share the poms because its all proprietary closed source stuff
  (and I have to be careful about what is shared).  If this means that I
 dont
  have enough info to help, I can live with that - and will continue to
 plow
  forwards...  I just wanted to see if theres someone on the list who
knows
  exactly what I should be looking for to help shorten my investigation
 time.
 
  Here's an example of what dependency:tree is complaining about.
 
 
   mvn dependency:tree -Dverbose=true -DoutputFile=dependencies.txt -e
-X
 
  urls[38] =
 
 
file:/C:/Users/thisguysuserid/.m2/repository/commons-collections/commons-
collections/3.2.1/commons-collections-3.2.1.jar
  Number of foreign imports: 1
  import: Entry[import  from realm ClassRealm[maven.api, parent: null]]
  -
 
  at
 
 
org.apache.maven.plugin.DefaultBuildPluginManager.executeMojo(DefaultBuil
dPluginManager.java:139)
  at
 
 
org.apache.maven.lifecycle.internal.MojoExecutor.execute(MojoExecutor.jav
a:209)
  ... 19 more
  Caused by: org.apache.maven.plugin.PluginContainerException: An API
  incompatibility was encountered while executing
  org.apache.maven.plugins:maven-dependency-plugin:2.8:tree:
  java.lang.AbstractMethodError:
 
 
org.apache.maven.shared.dependency.tree.DependencyTreeResolutionListener.
manageArtifactSystemPath(Lorg/apache/maven/artifact/Artifact;Lorg/apache/
maven/artifact/Artifact;)V
 
 
 
 
 
 
  -
  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 plugin strangeness

[Curtis Rueden]

Hi Roy,

Can you use a bisect-style debugging approach? Remove half of the modules
from the build and run dependency:tree again. If it works, add half back in
again; if not, remove half of what remains. Etc. Then at least you might
isolate the problem a bit more. It also might make it easier to create a
minimal test case for bug reporting purposes.

Regards,
Curtis
On Jan 28, 2014 4:56 PM, Lyons, Roy roy.ly...@cmegroup.com wrote:

 So, I tried my google-fu first - and in general my google-fu is very very
 strong...

 I've been fighting with this multi-module plan for some time now with the
 developer who is reporting the issue to me.  The issue manifested itself as
 part of a Sonar failure...  the funny thing is, that the failure was on a
 dependenct tree resolution that Sonar was doing - so I had him try the
 dependency plugin and perform a dependency:tree

 dependency tree failed us...  well, it probably isn't dependency plugin's
 fault but I am at a loss as to what it is really dying on or why.

 I would absolutely love it if someone saw this and said Oh yeah, I know
 that issue.  Its a real pain.  They have XXX defined incorrectly in their
 multimodule build so the dependency plugin is in a circular dependency
 loop (or something like that).  I have no idea if its a dependency loop,
 was just an example.

 I can't share the poms because its all proprietary closed source stuff
 (and I have to be careful about what is shared).  If this means that I dont
 have enough info to help, I can live with that - and will continue to plow
 forwards...  I just wanted to see if theres someone on the list who knows
 exactly what I should be looking for to help shorten my investigation time.

 Here's an example of what dependency:tree is complaining about.


  mvn dependency:tree -Dverbose=true -DoutputFile=dependencies.txt -e -X

 urls[38] =
 file:/C:/Users/thisguysuserid/.m2/repository/commons-collections/commons-collections/3.2.1/commons-collections-3.2.1.jar
 Number of foreign imports: 1
 import: Entry[import  from realm ClassRealm[maven.api, parent: null]]
 -

 at
 org.apache.maven.plugin.DefaultBuildPluginManager.executeMojo(DefaultBuildPluginManager.java:139)
 at
 org.apache.maven.lifecycle.internal.MojoExecutor.execute(MojoExecutor.java:209)
 ... 19 more
 Caused by: org.apache.maven.plugin.PluginContainerException: An API
 incompatibility was encountered while executing
 org.apache.maven.plugins:maven-dependency-plugin:2.8:tree:
 java.lang.AbstractMethodError:
 org.apache.maven.shared.dependency.tree.DependencyTreeResolutionListener.manageArtifactSystemPath(Lorg/apache/maven/artifact/Artifact;Lorg/apache/maven/artifact/Artifact;)V






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

Re: Dependency exclusions being ignored

[Andy Glick]

Jason,

I believe that your 2nd pastebin output reflects a bug in the gradle 
mechanism for determining dependencies.


The problem that you have referred to is that you have marked 2 maven 
plugins to be excluded from the transitive dependencies of 
abdera-client, because you are seeing the plugins referenced as if they 
were members of its transitive dependency set. If you look at the gradle 
tree listing carefully you will see that the gradle has assigned jaxen 
the version range of jaxen:jaxen:1.1-beta-9 - 1.1.3, and the plugins 
are listed as dependencies of jaxen.


When I forget about gradle and use the maven-dependency-plugin:2.8 and 
execute mvn dependency:tree with a pom that I simplified to just the 
issue that you have reported and which you can find below, I don't see 
the plugins listed as dependencies of jaxen so they do not appear. And I 
see that the dependency plugin has chosen jaxen 1.1.1 rather than a 
version range. The pom of jaxen 1.1.1 doesn't list any plugins as its 
dependents, though I did find at least 1 reference to one of the plugins 
as a dependency of jaxen's in the pom for 1.1.3.  My sense is that you 
are seeing 1 or more gradle bugs at work here.


The pom dependencies look like the following when I trace them:

abdera-client has a dependency on abdera-parser

abdera-parser has a parent pom abdera in which the dependency-management 
section chooses jaxen 1.1.1, not a range


abdera-parser has a dependency on jaxen which is referenced without a 
version, so the parent (abdera pom) version of 1.1.1 ought to be in force


jaxen 1.1.1 pom has no transitive dependencies on any plugins. It does 
declare/use plugins within buildplugins but that doesn't count.


I did include the the 4 non-plugin dependencies of abdera-client in the 
exclusions list, and all of them have been excluded.



The results of the dependency:tree run appear 1st followed by the pom 
that I used. Please notice that I commented out the exclusions for the 
plugins and they are still not being listed.


As you can see from the dependency tree's graph below, the gradle report 
is simply in error.



Hope that this helps.


C:\java\simple-jpa\jpa-story-parentmvn dependency:tree -f ppom.xml
[INFO] Scanning for projects...
[INFO]
[INFO] 


[INFO] Building dotcms 2.5.1
[INFO] 


[INFO]
[INFO] --- maven-dependency-plugin:2.8:tree (default-cli) @ dotcms ---
[INFO] com.dotcms:dotcms:jar:2.5.1
[INFO] \- org.apache.abdera:abdera-client:jar:0.4.0-incubating:compile
[INFO]+- org.apache.abdera:abdera-core:jar:0.4.0-incubating:compile
[INFO]|  +- org.apache.abdera:abdera-i18n:jar:0.4.0-incubating:compile
[INFO]|  \- commons-codec:commons-codec:jar:1.3:compile
[INFO]+- org.apache.abdera:abdera-parser:jar:0.4.0-incubating:compile
[INFO]|  +- org.codehaus.woodstox:wstx-asl:jar:3.2.1:runtime
[INFO]|  +- jaxen:jaxen:jar:1.1.1:compile
[INFO]|  |  +- xml-apis:xml-apis:jar:1.3.02:compile
[INFO]|  |  \- xerces:xercesImpl:jar:2.6.2:compile
[INFO]|  \- commons-logging:commons-logging:jar:1.0.4:compile
[INFO]\- commons-httpclient:commons-httpclient:jar:3.1-rc1:compile
[INFO] 


[INFO] BUILD SUCCESS
[INFO] 


[INFO] Total time: 2.119s
[INFO] Finished at: Sat Nov 16 12:25:04 EST 2013
[INFO] Final Memory: 10M/121M
[INFO] 




the pom that I used:

?xml version=1.0 encoding=UTF-8?
project xsi:schemaLocation=http://maven.apache.org/POM/4.0.0 
http://maven.apache.org/xsd/maven-4.0.0.xsd;

  xmlns=http://maven.apache.org/POM/4.0.0;
  xmlns:xsi=http://www.w3.org/2001/XMLSchema-instance;
  modelVersion4.0.0/modelVersion
  groupIdcom.dotcms/groupId
  artifactIddotcms/artifactId
  namedotcms/name
  version2.5.1/version

  build
plugins
  plugin
groupIdorg.apache.maven.plugins/groupId
artifactIdmaven-dependency-plugin/artifactId
version2.8/version
  /plugin
/plugins
  /build
  dependencies
dependency
  groupIdorg.apache.abdera/groupId
  artifactIdabdera-client/artifactId
  version0.4.0-incubating/version
  exclusions
exclusion
  groupIdorg.apache.geronimo.specs/groupId
artifactIdgeronimo-activation_1.0.2_spec/artifactId
/exclusion
exclusion
  groupIdorg.apache.geronimo.specs/groupId
artifactIdgeronimo-activation_1.1_spec/artifactId
/exclusion
exclusion
  groupIdorg.apache.geronimo.specs/groupId
artifactIdgeronimo-stax-api_1.0_spec/artifactId
/exclusion
exclusion
groupIdorg.apache.ws.commons.axiom/groupId
  artifactIdaxiom-impl/artifactId
/exclusion
!--exclusion--

Re: Dependency exclusions being ignored

[Stuart McCulloch]

Try adding:

typeplugin/type

to those 2 dependency exclusions.

( the jaxen pom: 
http://search.maven.org/remotecontent?filepath=jaxen/jaxen/1.1.3/jaxen-1.1.3.pom
 declares those dependencies to be of type plugin )

On 14 Nov 2013, at 13:14, Jason Tesser wrote:

 I have the following POM http://pastebin.com/P4TvzqJn but my exclusion for
 artifactIdabdera-client/artifactId are not being respected.  Actually
 only 2 of them are not
 the 2 not working are maven-plugins and maven-plugins
 they are coming down anyways
 see http://pastebin.com/c59HM8Bj
 what am I missing
 I have altered the POM but I cleared my local cache and refreshed
 dependencies


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

Re: Dependency exclusions being ignored

[Jason Tesser]

you are referring to the maven-plugins I think

But what about the xml-api thing?


On Thu, Nov 14, 2013 at 9:29 AM, Stuart McCulloch mccu...@gmail.com wrote:

 Try adding:

 typeplugin/type

 to those 2 dependency exclusions.

 ( the jaxen pom:
 http://search.maven.org/remotecontent?filepath=jaxen/jaxen/1.1.3/jaxen-1.1.3.pomdeclares
  those dependencies to be of type plugin )

 On 14 Nov 2013, at 13:14, Jason Tesser wrote:

  I have the following POM http://pastebin.com/P4TvzqJn but my exclusion
 for
  artifactIdabdera-client/artifactId are not being respected.  Actually
  only 2 of them are not
  the 2 not working are maven-plugins and maven-plugins
  they are coming down anyways
  see http://pastebin.com/c59HM8Bj
  what am I missing
  I have altered the POM but I cleared my local cache and refreshed
  dependencies


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

Re: Dependency exclusions being ignored

[Jason Tesser]

Also that doesn't work. Invalid POM

cannot say
exclusion
groupIdmaven-plugins/groupId
 artifactIdmaven-cobertura-plugin/artifactId
typeplugin/type
/exclusion


On Thu, Nov 14, 2013 at 9:32 AM, Jason Tesser jasontes...@gmail.com wrote:

 you are referring to the maven-plugins I think

 But what about the xml-api thing?


 On Thu, Nov 14, 2013 at 9:29 AM, Stuart McCulloch mccu...@gmail.comwrote:

 Try adding:

 typeplugin/type

 to those 2 dependency exclusions.

 ( the jaxen pom:
 http://search.maven.org/remotecontent?filepath=jaxen/jaxen/1.1.3/jaxen-1.1.3.pomdeclares
  those dependencies to be of type plugin )

 On 14 Nov 2013, at 13:14, Jason Tesser wrote:

  I have the following POM http://pastebin.com/P4TvzqJn but my exclusion
 for
  artifactIdabdera-client/artifactId are not being respected.
  Actually
  only 2 of them are not
  the 2 not working are maven-plugins and maven-plugins
  they are coming down anyways
  see http://pastebin.com/c59HM8Bj
  what am I missing
  I have altered the POM but I cleared my local cache and refreshed
  dependencies


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

Re: Dependency exclusions being ignored

[Jörg Schaible]

Stuart McCulloch wrote:

 Try adding:
 
 typeplugin/type
 
 to those 2 dependency exclusions.

Nice try. Violates schema.

 
 ( the jaxen pom:
 
http://search.maven.org/remotecontent?filepath=jaxen/jaxen/1.1.3/jaxen-1.1.3.pom
 declares those dependencies to be of type plugin )
 
 On 14 Nov 2013, at 13:14, Jason Tesser wrote:
 
 I have the following POM http://pastebin.com/P4TvzqJn but my exclusion
 for
 artifactIdabdera-client/artifactId are not being respected.  Actually
 only 2 of them are not
 the 2 not working are maven-plugins and maven-plugins
 they are coming down anyways
 see http://pastebin.com/c59HM8Bj
 what am I missing
 I have altered the POM but I cleared my local cache and refreshed
 dependencies



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

Re: Dependency exclusions being ignored

[Stuart McCulloch]

You mean the POM relocation to an other version number is not fully supported 
in Gradle message?

If you look at the pom it has a relocation element (bit like a symbolic link):


http://search.maven.org/remotecontent?filepath=xml-apis/xml-apis/2.0.2/xml-apis-2.0.2.pom


http://maven.apache.org/guides/mini/guide-relocation.html#How_to_relocate_a_Maven_2_artifact_to_a_different_groupId

you'd have to ask the Gradle team why they don't fully support this.

As a workaround you could force the version to 1.0.b2 in your 
dependencyManagement section:

dependency
groupIdxml-apis/groupId
artifactIdxml-apis/artifactId
version1.0.b2/version
/dependency

http://maven.apache.org/guides/introduction/introduction-to-dependency-mechanism.html#Dependency_Management
  (see part about managing versions of transitive dependencies)

On 14 Nov 2013, at 14:32, Jason Tesser wrote:

 you are referring to the maven-plugins I think
 
 But what about the xml-api thing?
 
 On Thu, Nov 14, 2013 at 9:29 AM, Stuart McCulloch mccu...@gmail.com wrote:
 
 Try adding:
 
typeplugin/type
 
 to those 2 dependency exclusions.
 
 ( the jaxen pom:
 http://search.maven.org/remotecontent?filepath=jaxen/jaxen/1.1.3/jaxen-1.1.3.pomdeclares
  those dependencies to be of type plugin )
 
 On 14 Nov 2013, at 13:14, Jason Tesser wrote:
 
 I have the following POM http://pastebin.com/P4TvzqJn but my exclusion
 for
 artifactIdabdera-client/artifactId are not being respected.  Actually
 only 2 of them are not
 the 2 not working are maven-plugins and maven-plugins
 they are coming down anyways
 see http://pastebin.com/c59HM8Bj
 what am I missing
 I have altered the POM but I cleared my local cache and refreshed
 dependencies
 
 
 -
 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 exclusions being ignored

[Stuart McCulloch]

Doh, sorry - worth a try :)

You could try forcing jaxen to 1.1.4 (using dependencyManagement) as that 
version doesn't have those odd plugin dependencies

On 14 Nov 2013, at 14:36, Jason Tesser wrote:

 Also that doesn't work. Invalid POM
 
 cannot say
 exclusion
 groupIdmaven-plugins/groupId
 artifactIdmaven-cobertura-plugin/artifactId
 typeplugin/type
 /exclusion
 
 
 On Thu, Nov 14, 2013 at 9:32 AM, Jason Tesser jasontes...@gmail.com wrote:
 
 you are referring to the maven-plugins I think
 
 But what about the xml-api thing?
 
 
 On Thu, Nov 14, 2013 at 9:29 AM, Stuart McCulloch mccu...@gmail.comwrote:
 
 Try adding:
 
typeplugin/type
 
 to those 2 dependency exclusions.
 
 ( the jaxen pom:
 http://search.maven.org/remotecontent?filepath=jaxen/jaxen/1.1.3/jaxen-1.1.3.pomdeclares
  those dependencies to be of type plugin )
 
 On 14 Nov 2013, at 13:14, Jason Tesser wrote:
 
 I have the following POM http://pastebin.com/P4TvzqJn but my exclusion
 for
 artifactIdabdera-client/artifactId are not being respected.
 Actually
 only 2 of them are not
 the 2 not working are maven-plugins and maven-plugins
 they are coming down anyways
 see http://pastebin.com/c59HM8Bj
 what am I missing
 I have altered the POM but I cleared my local cache and refreshed
 dependencies
 
 
 -
 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 exclusions being ignored

[Stuart McCulloch]

BTW, I ran your pom.xml through:

mvn dependency:tree

using Maven3 and the exclusions for those 2 maven-plugins were respected, which 
suggests your exclusion issue might also be specific to Gradle.

On 14 Nov 2013, at 14:53, Stuart McCulloch wrote:

 You mean the POM relocation to an other version number is not fully 
 supported in Gradle message?
 
 If you look at the pom it has a relocation element (bit like a symbolic link):
 
   
 http://search.maven.org/remotecontent?filepath=xml-apis/xml-apis/2.0.2/xml-apis-2.0.2.pom
 
   
 http://maven.apache.org/guides/mini/guide-relocation.html#How_to_relocate_a_Maven_2_artifact_to_a_different_groupId
 
 you'd have to ask the Gradle team why they don't fully support this.
 
 As a workaround you could force the version to 1.0.b2 in your 
 dependencyManagement section:
 
dependency
   groupIdxml-apis/groupId
   artifactIdxml-apis/artifactId
   version1.0.b2/version
/dependency
 
 http://maven.apache.org/guides/introduction/introduction-to-dependency-mechanism.html#Dependency_Management
   (see part about managing versions of transitive dependencies)
 
 On 14 Nov 2013, at 14:32, Jason Tesser wrote:
 
 you are referring to the maven-plugins I think
 
 But what about the xml-api thing?
 
 On Thu, Nov 14, 2013 at 9:29 AM, Stuart McCulloch mccu...@gmail.com wrote:
 
 Try adding:
 
   typeplugin/type
 
 to those 2 dependency exclusions.
 
 ( the jaxen pom:
 http://search.maven.org/remotecontent?filepath=jaxen/jaxen/1.1.3/jaxen-1.1.3.pomdeclares
  those dependencies to be of type plugin )
 
 On 14 Nov 2013, at 13:14, Jason Tesser wrote:
 
 I have the following POM http://pastebin.com/P4TvzqJn but my exclusion
 for
 artifactIdabdera-client/artifactId are not being respected.  Actually
 only 2 of them are not
 the 2 not working are maven-plugins and maven-plugins
 they are coming down anyways
 see http://pastebin.com/c59HM8Bj
 what am I missing
 I have altered the POM but I cleared my local cache and refreshed
 dependencies
 
 
 -
 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 build-classpath returns wrong order

[dsilve]

I have been able to understand where the issue is, but not how to solve it.
The wrong classpath is generated when I use the configuration property
excludeScope=provided.

So if I run:
mvn dependency:build-classpath 
I get the correct classpath, but if I run:
mvn dependency:build-classpath -DexcludeScope=provided
then the classpath has a weird order that doesn't correspond to the
dependency tree.

Is this a known bug of the dependency plugin?



--
View this message in context: 
http://maven.40175.n5.nabble.com/dependency-build-classpath-returns-wrong-order-tp5773306p5773488.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 mapping with the assembly plugin

[Wayne Fay]

 I have a situation where many of my projects need to produce an adjunct
 artifact (in addition to the primary JAR) for later collection into my
 distribution image.

What types of things are stored in your adjunct artifacts? How are
they created? Why can those things not live in the primary artifact
instead?

Wayne

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

Re: Dependency mapping with the assembly plugin

[Jeffrey E Care]

Wayne Fay wayne...@gmail.com wrote on 04/02/2013 03:23:03 PM:

  I have a situation where many of my projects need to produce an 
adjunct
  artifact (in addition to the primary JAR) for later collection into my
  distribution image.
 
 What types of things are stored in your adjunct artifacts? How are
 they created? Why can those things not live in the primary artifact
 instead?

Configuration fragments. Runtime support files that must be loaded from 
the file system instead of the classpath. Shell scripts. All of the files 
that end up in the adjunct artifacts are logically related to the runtime 
code that is hosted in their respective projects.

Re: Dependency resolution kicks in too early

[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

[Stephen Connolly]

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

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


Nor do I, except when it is necessary... the old advice was to do it that
way... the new advice is that it should be a last resort... this is largely
a result of the lack of a provides mechanism in pom v4.0.0, which forces
an almighty collection of excludes on people... when I do push things to
central under my group Id you will find that I have the source code public
and in my github repo, so in a sense I am maintaining a fork of the
project.

In the case of https://github.com/stephenc/redmine-java-api this is now a
complete fork as I disagree with how the forked project has implemented
some features, and at some point in time I will rejig the back end to be
based off of async-http-client, so there is a legitimate reason for the
alternate groupId (given that the two artifacts are not equivalent)

If you are going to publish something under your own groupId you should at
least be ensuring that the source repository of what you are publishing is
available as anonymous read and independent of the original project as
then it is clear that you are maintaining a fork.

One of the features I would like to get into POM v5.0.0 is the idea of a
provides mechanism...

Thus one could indicate that

dependency
  groupIdorg.apache.geronimo.specs/groupId
  artifactIdgeronimo-servlet_2.5_spec/artifactId
  version1.2/version
provides
provide
 groupIdorg.apache.tomcat/groupId
   artifactIdservlet-api/artifactId
provide
provide
 groupIdorg.mortbay.jetty/groupId
   artifactIdservlet-api/artifactId
provide
/provides
/dependency

And the org.apache.geronimo.specs:geronimo-servlet_2.5_spec pom itself may
indicate that it provides javax.servlet:servlet-api

Not that I am saying that is how it would work... but in essence some
feature like the above is required.

My thinking is that a POM would have a provides element equivalent to a
dependencies where it listed the apis that this module provides,
additionally you can add additional entries to the project's list when you
pull it in as a dependency, because there is no way for a project to know
up front all the GroupId:ArtifactIds that it provides... and this would
just be exclusions done right.

The harder part is mapping provides onto transitive consumers who are
using POM 4.0.0 parsers... but in a sense they are no worse off at the
moment, as long as the 4.0.0 compatible POM that we push to the repo as
part of the POM 5.0.0 deploy pins the dependency version (i.e. removing
ranges) it can add the necessary exclusions on its dependencies so that the
transitives injected into the consuming projects tree will be as clean as
it can inject them... IOW the consumer will be no worse off.




 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.connolly@gmail.**com 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, 

Re: Dependency resolution kicks in too early

[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

[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

[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

[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

[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

[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


   
  
 

Re: Dependency resolution kicks in too early

[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