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 question

[stanlick]

I hear you pal, but the lawyers are concentrating on the fact that the
archives are on our machine following a download of the full zip.  So do you
think Maven might be able to report on them for the lawyers even though they
are not dependencies?  

Peace,
Scott



Stephen Connolly-2 wrote:
 
 Those dependencies are required to *test* struts they are not required
 by your project as struts has already been tested.
 
 -Stephen
 
 2009/3/3 stanlick stanl...@gmail.com
 

 Thanks guys --

 If you look at the POM for Struts 2.1.6 there are many more dependencies
 than what show up running
 dependency:resolve.  I verifies the default for scope because several of
 the
 dependencies are test.   It appears the default is all scopes, so I am
 wondering why I don't see them all when I run dependency:resolve.

 Peace,
 Scott
 - Show quoted text -


 
 

-- 
View this message in context: 
http://www.nabble.com/Dependency-question-tp22315314p22328900.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 question

[Stephen Connolly]

You could write a plugin... it's not that hard

2009/3/4 stanlick stanl...@gmail.com


 I hear you pal, but the lawyers are concentrating on the fact that the
 archives are on our machine following a download of the full zip.  So do
 you
 think Maven might be able to report on them for the lawyers even though
 they
 are not dependencies?

 Peace,
 Scott



 Stephen Connolly-2 wrote:
 
  Those dependencies are required to *test* struts they are not
 required
  by your project as struts has already been tested.
 
  -Stephen
 
  2009/3/3 stanlick stanl...@gmail.com
 
 
  Thanks guys --
 
  If you look at the POM for Struts 2.1.6 there are many more dependencies
  than what show up running
  dependency:resolve.  I verifies the default for scope because several of
  the
  dependencies are test.   It appears the default is all scopes, so I am
  wondering why I don't see them all when I run dependency:resolve.
 
  Peace,
  Scott
  - Show quoted text -
 
 
 
 

 --
 View this message in context:
 http://www.nabble.com/Dependency-question-tp22315314p22328900.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 question

[Brian E. Fox]

The dependency:tree goal does show test dependencies by default.

-Original Message-
From: stanlick [mailto:stanl...@gmail.com] 
Sent: Wednesday, March 04, 2009 7:16 AM
To: users@maven.apache.org
Subject: Re: Dependency question


I hear you pal, but the lawyers are concentrating on the fact that the
archives are on our machine following a download of the full zip.  So do
you
think Maven might be able to report on them for the lawyers even though
they
are not dependencies?  

Peace,
Scott



Stephen Connolly-2 wrote:
 
 Those dependencies are required to *test* struts they are not
required
 by your project as struts has already been tested.
 
 -Stephen
 
 2009/3/3 stanlick stanl...@gmail.com
 

 Thanks guys --

 If you look at the POM for Struts 2.1.6 there are many more
dependencies
 than what show up running
 dependency:resolve.  I verifies the default for scope because several
of
 the
 dependencies are test.   It appears the default is all scopes, so I
am
 wondering why I don't see them all when I run dependency:resolve.

 Peace,
 Scott
 - Show quoted text -


 
 

-- 
View this message in context:
http://www.nabble.com/Dependency-question-tp22315314p22328900.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


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

Re: Dependency question

[Wayne Fay]

 I am running mvn dependency:tree and expecting a large dependency tree, when
 in fact all I get is what you see below.  I *know* there are more
 dependencies than this!  Can someone help me out with this flags and
 switches please?

How do you *know* there are more dependencies? Have you tried with a
sample pom of your own creation that has very well defined first,
second, and third-level dependencies, to verify they all appear as you
expect? That would be my test -- not a random Struts2 artifact.

Wayne

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

RE: Dependency question

[Brian E. Fox]

If every jar present in dependency:resolve is shown in the tree, then that's 
all folks.

-Original Message-
From: Wayne Fay [mailto:wayne...@gmail.com] 
Sent: Tuesday, March 03, 2009 2:52 PM
To: Maven Users List
Subject: Re: Dependency question

 I am running mvn dependency:tree and expecting a large dependency tree, when
 in fact all I get is what you see below.  I *know* there are more
 dependencies than this!  Can someone help me out with this flags and
 switches please?

How do you *know* there are more dependencies? Have you tried with a
sample pom of your own creation that has very well defined first,
second, and third-level dependencies, to verify they all appear as you
expect? That would be my test -- not a random Struts2 artifact.

Wayne

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

RE: Dependency question

[stanlick]

Thanks guys -- 

If you look at the POM for Struts 2.1.6 there are many more dependencies
than what show up running 
dependency:resolve.  I verifies the default for scope because several of the
dependencies are test.   It appears the default is all scopes, so I am
wondering why I don't see them all when I run dependency:resolve.

Peace,
Scott


Brian E Fox wrote:
 
 If every jar present in dependency:resolve is shown in the tree, then
 that's all folks.
 
 -Original Message-
 From: Wayne Fay [mailto:wayne...@gmail.com] 
 Sent: Tuesday, March 03, 2009 2:52 PM
 To: Maven Users List
 Subject: Re: Dependency question
 
 I am running mvn dependency:tree and expecting a large dependency tree,
 when
 in fact all I get is what you see below.  I *know* there are more
 dependencies than this!  Can someone help me out with this flags and
 switches please?
 
 How do you *know* there are more dependencies? Have you tried with a
 sample pom of your own creation that has very well defined first,
 second, and third-level dependencies, to verify they all appear as you
 expect? That would be my test -- not a random Struts2 artifact.
 
 Wayne
 
 -
 To unsubscribe, e-mail: users-unsubscr...@maven.apache.org
 For additional commands, e-mail: users-h...@maven.apache.org
 
 
 

-- 
View this message in context: 
http://www.nabble.com/Dependency-question-tp22315314p22317335.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 question

[Stephen Connolly]

Those dependencies are required to *test* struts they are not required
by your project as struts has already been tested.

-Stephen

2009/3/3 stanlick stanl...@gmail.com


 Thanks guys --

 If you look at the POM for Struts 2.1.6 there are many more dependencies
 than what show up running
 dependency:resolve.  I verifies the default for scope because several of
 the
 dependencies are test.   It appears the default is all scopes, so I am
 wondering why I don't see them all when I run dependency:resolve.

 Peace,
 Scott
 - Show quoted text -

Re: Dependency question

[stanlick]

Thanks bro -- 

I realize that, but shouldn't they show up as dependencies even though they
are only depended on during testing?

Peace,
Scott


Stephen Connolly-2 wrote:
 
 Those dependencies are required to *test* struts they are not required
 by your project as struts has already been tested.
 
 -Stephen
 
 2009/3/3 stanlick stanl...@gmail.com
 

 Thanks guys --

 If you look at the POM for Struts 2.1.6 there are many more dependencies
 than what show up running
 dependency:resolve.  I verifies the default for scope because several of
 the
 dependencies are test.   It appears the default is all scopes, so I am
 wondering why I don't see them all when I run dependency:resolve.

 Peace,
 Scott
 - Show quoted text -


 
 

-- 
View this message in context: 
http://www.nabble.com/Dependency-question-tp22315314p22323314.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 question

[Wayne Fay]

 I realize that, but shouldn't they show up as dependencies even though they
 are only depended on during testing?

If you aren't building and testing Struts but merely using it, then
they aren't used, so no.

Wayne

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

RE: Dependency question

[Brewster, Richard]

Declare the dependency as test scope:

dependency
groupId${jdbc.groupId}/groupId
artifactId${jdbc.artifactId}/artifactId
version${jdbc.version}/version
scopetest/scope 
/dependency

Richard Brewster
Senior Associate
Perrin Quarles Associates
[EMAIL PROTECTED]
(434) 817-2640


-Original Message-
From: Jason Porter [mailto:[EMAIL PROTECTED] 
Sent: Friday, December 07, 2007 2:12 PM
To: users@maven.apache.org
Subject: Dependency question

Is there a way to specify a dependency to be available for compilation
and test running, but not have it packaged up?  

We have a situation where some older code that has been converted to
maven2 uses a library (SAP JCo if anyone is familiar with it) that must
be there to compile and also to run.  Some of the tests were written to
communicate with SAP, which requires the jar to be in the classpath at
runtime.  When the application is deployed the jar is provided via the
container, so we need it available to run the tests, but don't want it
packaged up with the application.

Jason Porter
O.C. Tanner
Information Services
Technical Specialist 


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


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

Re: Dependency question

[nicolas de loof]

As you said When the application is deployed the jar is provided via the
container. So simply try the provided scope !

provided dependencies are commonly used for java API (servlet, jta ...) taht
are part of the JEE server runtime BUT required to compile and test.

Nico.


2007/12/7, Jason Porter [EMAIL PROTECTED]:

 Is there a way to specify a dependency to be available for compilation
 and test running, but not have it packaged up?

 We have a situation where some older code that has been converted to
 maven2 uses a library (SAP JCo if anyone is familiar with it) that must
 be there to compile and also to run.  Some of the tests were written to
 communicate with SAP, which requires the jar to be in the classpath at
 runtime.  When the application is deployed the jar is provided via the
 container, so we need it available to run the tests, but don't want it
 packaged up with the application.

 Jason Porter
 O.C. Tanner
 Information Services
 Technical Specialist


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

Re: dependency question

[Wendy Smoak]

On 10/18/06, Chen, Anning [EMAIL PROTECTED] wrote:


thirdparty.sun.servlet.2.3 is a thirdparty jar from sun, which I
packaged and installed to the repository.  However, when I compile, I
get package javax.servlet does not exist.  Is there something else I
have to setup to add the classes in the jar to my compile time
classpath?


Try removing the surrounding dependencyManagement element.

(That element is used to control dependency versions from a top-level pom.)

If this is a 'released' jar, you'll probably want to make up some
version number for it, and not use -SNAPSHOT.

--
Wendy

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

RE: dependency question

[Chen, Anning]

Thx.  This worked.


-Original Message-
From: Wendy Smoak [mailto:[EMAIL PROTECTED] 
Sent: Wednesday, October 18, 2006 1:41 PM
To: Maven Users List
Subject: Re: dependency question

On 10/18/06, Chen, Anning [EMAIL PROTECTED] wrote:

 thirdparty.sun.servlet.2.3 is a thirdparty jar from sun, which I
 packaged and installed to the repository.  However, when I compile, I
 get package javax.servlet does not exist.  Is there something else I
 have to setup to add the classes in the jar to my compile time
 classpath?

Try removing the surrounding dependencyManagement element.

(That element is used to control dependency versions from a top-level
pom.)

If this is a 'released' jar, you'll probably want to make up some
version number for it, and not use -SNAPSHOT.

-- 
Wendy

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

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

Re: Dependency question: Designate class from jar instead of whole jar?

[Alex Shneyderman]

I do not think it is possible although wrting a plugin to do
just that should be a piece of cake.

On 7/8/06, Chris Wall [EMAIL PROTECTED] wrote:

This might be an odd request, but does Maven allow you to designate a
class or set of classes within a jar as a dependency?  The use case is
that I'd like to only pull in a class or two from a jar into my final
jar instead of the whole dependency jar.

Thanks.

-Chris

___
Notice:  This email message, together with any attachments, may contain
information  of  BEA Systems,  Inc.,  its subsidiaries  and  affiliated
entities,  that may be confidential,  proprietary,  copyrighted  and/or
legally privileged, and is intended solely for the use of the individual
or entity named in this message. If you are not the intended recipient,
and have received this message in error, please immediately return this
by email and then delete it.





--
Thanks,
Alex.

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

Re: Dependency question

[Craig S . Cottingham]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

All my answers assume you're using Maven 1.0.2.

On Aug 4, 2005, at 10:22, Jamie Bisotti wrote:


- I have two active, rapidly changing, projects, A  B, I'm going to
build and deploy to an in-house remote repository.
- B depends on A.
- Currently, A's currentVersion is 1.0
- Currently, B's dependency for A uses a version of 1.0
- A will get built and deployed with the 'jar:deploy goal, which will
place A-1.0.jar in the in-house remote repository.
- The first time B gets built, A-1.0.jar will get pulled from the
in-house remote repository to the users local repository.
- Each time thereafter, when B gets built, it will use that original
version of A-1.0.jar in the local repository, even though A-1.0.jar
have changed multiple times in the in-house remote repository.

To get around this, I need to:
- Change B's dependency on A to use a version of SNAPSHOT


While I think this will work, there's a better way to do it, at least 
in my opinion. See below.



Questions:
1. Do I need to use jar:deploy-snapshot when building A?  Or, is Maven
smart enough to just check the timestamp of A-1.0.jar in the local
repository against the one in the in-house remote repository and
download it again if it is newer?  I think the answers are Yes and
No, respectively.


No and No. If the version given for a dependency does not contain 
the word SNAPSHOT, Maven will not check the remote repository to see 
if it has been updated. The assumption is that version 1.0 is version 
1.0 is version 1.0, regardless of the timestamp. If the contents are 
different, the version string should be different -- with one 
exception. See below.



2. Do I need to change A's currentVersion to 1.0-SNAPSHOT?  Or is
jar:deploy-snapshot smart enough to name the snapshot JAR
appropriately?  I think the answers are No and Yes, respectively.


My personal for the first one is Yes. The second one is No.

What we do (this is just one possible way of doing things, but I can 
personally vouch that it works fairly well):


While project A is in active development, we set the currentVersion to 
the version it will be when it's released, appended with -SNAPSHOT. 
So, for instance, a brand-new project would likely have a 
currentVersion of 1.0-SNAPSHOT.


For any projects that depend on it, the version in the dependency is 
the same, e.g. 1.0-SNAPSHOT.


To deploy a new build of project A, use jar:deploy.

When building project B, Maven sees that the version string for A 
contains SNAPSHOT, so it downloads a new copy of A. (I think it does 
this regardless of timestamp, but I'm not sure of it.)


When we release project A, we remove -SNAPSHOT from currentVersion 
and deploy using jar:deploy again. Then, after tagging the release in 
our version control system, we usually bump currentVersion and append 
-SNAPSHOT again (e.g. from 1.0 to 1.0.1-SNAPSHOT) to safeguard 
against accidentally overwriting the released version.


Now, the tedious and unfortunate part: We have to go in to all of the 
dependent projects and remove -SNAPSHOT from the version strings for 
the dependency declarations for A to start using the released version. 
Similarly, we have to add -SNAPSHOT when we want to start using a 
development version again.


Keeping track of the most current versions of all of our projects, and 
the dependencies on them, can quickly get out of hand. I finally wrote 
a Ruby script to scan a POM and report if any of the dependencies are 
out of date, or are snapshots. I run this right before building a final 
release of a project, to ensure that it doesn't depend on any code 
still in development. It has the added benefit of making it easy to 
keep third-party dependencies up to date. For instance, if I see 
there's a new version of Spring available, I update my Ruby script and 
run it against all of our POMs to see which dependencies to update.


Hope this helps.

- --
Craig S. Cottingham
[EMAIL PROTECTED]
OpenPGP key available from:
http://pgp.mit.edu:11371/pks/lookup?op=getsearch=0x7977F79C
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.2.4 (Darwin)

iD8DBQFC8j06EJLQ3Hl395wRAlmhAJwMypVWEJUd5tooEXBo41/M2okPfwCeJFJR
mvxyY0nw6RXzv12e/KMv44w=
=/6ZV
-END PGP SIGNATURE-


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

Re: Dependency question

[Brett Porter]

Craig is spot on here - you use nextVersion-SNAPSHOT in both
currentVersion ad dependency versions until it is released.

Some extra things to note:
- jar:deploy-snapshot is deprecated. In the latest artifact plugin,
jar:deploy will behave that way if the version contains SNAPSHOT, or
behave like a release otherwise

- you can avoid multiple updates to dependencies by using inheritence.
For dependencies used everywhere, you can inherit the actual
dependency. For deps that just want the same version wherever used,
use a jar override with a version. If you use this feature, be sure to
use the latest Artifact plugin available for your version of Maven -
it will make better POMs in the repo that will help if converting to
m2 later.

- you also don't need to synchronize versions - there is no harm in
keeping to the minimum version required, and just updating to the
SNAPSHOT where used, or in assemblies such as WAR or executable
distributions (as they must meet the requirements of all dependencies)

- if you use the latter approach, the multiproject report will show
you what versions are out of sync.

- finally, scm:prepare-release eases the process of releasing a
component - however it doesn't look after SNAPSHOTs (something that is
improved in m2, just like all of the above :)

Hope this helps!

- Brett

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

Re: dependency question

[Gisbert Amm]

Janos Mucsi wrote:
I declare an ear artifact in my project.xml:
dependencies
 dependency
groupIdopcert/groupId
artifactIdUSOpcert/artifactId
version${pom.currentVersion}/version
typeear/type
 /dependency
In maven.xml I want to resolve its full path so that I
can pass it to an external script like this:
*${home.dir}*${maven.repo.local}/${dependency.groupId}/${dependency.artifactId}-${dependency.version}.${dependency.type}
My question is how do I get the home directory of the
current user?
Isn't an easier way in Maven to resolve the full path
of the dependency?
Probably this:
${pom.getDependencyPath('atifactId:groupId')
Regards,
Gisbert Amm
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Re: dependency question

[Gisbert Amm]

Gisbert Amm wrote:
Isn't an easier way in Maven to resolve the full path
of the dependency?

Probably this:
${pom.getDependencyPath('atifactId:groupId')
Missed the closing bracket:
${pom.getDependencyPath('atifactId:groupId')}
^
Gisbert
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Re: dependency question

[Gisbert Amm]

Gisbert Amm wrote:
Gisbert Amm wrote:
Isn't an easier way in Maven to resolve the full path
of the dependency?
Missed the closing bracket:
${pom.getDependencyPath('atifactId:groupId')}
Even worse: Wrong order of elements:
${pom.getDependencyPath('groupId:artifactId')}
Gisbert
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]