Re: Transitive dependency question

[Stephen Connolly]

I think that is a bug that is in scope for 3.5.1 or 3.6.0

On 31 May 2017 at 22:30, Laird Nelson  wrote:

> (I've been working with Maven since at least 2004 and I think I *still*
> don't
> get transitive dependencies.)
>
> I have a pom.xml file of type pom that has some compile-scoped dependencies
> in it.  (P1 -> A(compile), B(compile))
>
> I have another project that depends on this pom in provided scope (I'm just
> playing around for now).  The intention is that I will "get" all the
> transitive compile-scoped dependencies of the pom artifact I'm depending
> on, but in provided scope.  (P2 -> P1(provided); result is effectively: P2
> -> P1(provided) -> A(provided), B(provided))
>
> If that's all I have, then indeed, that's the result I observe: when I run
> the maven-dependency-plugin's dependency-tree goal, I see these transitive
> dependencies and they are all marked as being in provided scope, not
> compile.  I see, in other words, the tree representation of P2 ->
> P1(provided) -> A(provided), B(provided).  So far so good.
>
> Now I pull in another (jar) dependency in runtime scope.  It has some
> transitive dependencies in compile scope.  Fine.  They don't include any of
> the dependencies mentioned in my second paragraph. (P2 -> (P1(provided) ->
> A(provided),B(provided)), (P3(runtime) -> C(compile),D(compile)))  Note
> that this pseudo-language is what I *expect* to see.
>
> When I run dependency:tree on this hairy mess, it does *not* show the
> representation of my pseudo-language above.  Instead, it shows the
> transitive dependencies from my third paragraph as direct "children" of the
> pom-type artifact I'm pulling in in provided scope (P1), but they all have
> a scope of runtime.  So, for just this part of the tree: P2 -> P1(provided)
> -> A(runtime(!)), B(runtime(!))
>
> What the…?  In other words, somebody in the tree is "promoting" my A and B
> dependencies to runtime scope.  But I can't tell from the tree output who
> it is, because A and B (that are now apparently runtime-scoped
> dependencies) are still showing as children of my pom artifact (P1,
> mentioned in my second paragraph).
>
> Is this all according to plan?  I'm using version 3.0.0 of the
> maven-dependency-plugin and version 3.5.0 of Maven itself.
>
> Best,
> Laird
>

Transitive dependency question

[Laird Nelson]

(I've been working with Maven since at least 2004 and I think I *still* don't
get transitive dependencies.)

I have a pom.xml file of type pom that has some compile-scoped dependencies
in it.  (P1 -> A(compile), B(compile))

I have another project that depends on this pom in provided scope (I'm just
playing around for now).  The intention is that I will "get" all the
transitive compile-scoped dependencies of the pom artifact I'm depending
on, but in provided scope.  (P2 -> P1(provided); result is effectively: P2
-> P1(provided) -> A(provided), B(provided))

If that's all I have, then indeed, that's the result I observe: when I run
the maven-dependency-plugin's dependency-tree goal, I see these transitive
dependencies and they are all marked as being in provided scope, not
compile.  I see, in other words, the tree representation of P2 ->
P1(provided) -> A(provided), B(provided).  So far so good.

Now I pull in another (jar) dependency in runtime scope.  It has some
transitive dependencies in compile scope.  Fine.  They don't include any of
the dependencies mentioned in my second paragraph. (P2 -> (P1(provided) ->
A(provided),B(provided)), (P3(runtime) -> C(compile),D(compile)))  Note
that this pseudo-language is what I *expect* to see.

When I run dependency:tree on this hairy mess, it does *not* show the
representation of my pseudo-language above.  Instead, it shows the
transitive dependencies from my third paragraph as direct "children" of the
pom-type artifact I'm pulling in in provided scope (P1), but they all have
a scope of runtime.  So, for just this part of the tree: P2 -> P1(provided)
-> A(runtime(!)), B(runtime(!))

What the…?  In other words, somebody in the tree is "promoting" my A and B
dependencies to runtime scope.  But I can't tell from the tree output who
it is, because A and B (that are now apparently runtime-scoped
dependencies) are still showing as children of my pom artifact (P1,
mentioned in my second paragraph).

Is this all according to plan?  I'm using version 3.0.0 of the
maven-dependency-plugin and version 3.5.0 of Maven itself.

Best,
Laird

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 also strongly tells

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
br

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

deprecated. So

why are RELEASE and LATEST eschewed so heavily?

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" 
To: "Maven Users List" 
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  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

 >> 

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: users-h...@maven.apache.org
>
>

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]

en 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 
>>>>>> Subject: Re: dependency question
>>>>>>
>>>>>> On Mon, Apr 10, 2017 at 8:18 AM, Magnanao, Hector
>>>>>>  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.
>>>>>>
>>

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  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  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,
>>>&g

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  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  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 
Subject: Re: dependency question

On Mon, Apr 10, 2017 at 8:18 AM, Magnanao, Hector
 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 
Subject: Re: dependency question

Hi Russlel,

Re: dependency question

[Stephen Connolly]

On Tue 11 Apr 2017 at 20:55, Curtis Rueden  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  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 
> > > > Subject: Re: dependency question
> > > >
> > > > On Mon, Apr 10, 2017 at 8:18 AM, Magnanao, Hector
> > > >  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

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  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 
> > > Subject: Re: dependency question
> > >
> > > On Mon, Apr 10, 2017 at 8:18 AM, Magnanao, Hector
> > >  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

Re: dependency question

[Stephen Connolly]

On Tue 11 Apr 2017 at 16:02, Curtis Rueden  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  >
> 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 
> > Subject: Re: dependency question
> >
> > On Mon, Apr 10, 2017 at 8:18 AM, Magnanao, Hector
> >  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 
> > > 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

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 
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 
> Subject: Re: dependency question
>
> On Mon, Apr 10, 2017 at 8:18 AM, Magnanao, Hector
>  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 
> > 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 dependend

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 
Subject: Re: dependency question

On Mon, Apr 10, 2017 at 8:18 AM, Magnanao, Hector
 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 
> 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  
>>> 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, 

Re: dependency question

[Benson Margulies]

On Mon, Apr 10, 2017 at 8:18 AM, Magnanao, Hector
 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 
> 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  
>>> 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 
>>> 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  
>>>> 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 b

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

dependency question

[Magnanao, Hector]

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

Re: Unmanaged dependency question

[Matt Whiteman]

Er hrm, I'm not sure why this sent again, but ignore it. Question already
answered, thanks!

Matt

On May 30, 2014 at 4:39 PM Matt Whiteman  wrote:
> Hi,
>
>
>
> This has probably been answered before, but I haven't been able to find the
> answer and I'm hoping someone knows.
>
>
>
> I'm writing several apps that talk to a Microsoft SQL database, so I'm using
> the Hibernate dependency. Since Microsoft doesn't make the sqljdbc4 jar
> available on Maven, I've downloaded it, and I'm trying to make it an
> unmanaged dependency in its own standalone project so that I can simply
> reference it in other projects' pom files without having to deploy the jar
> to each one individually.
>
>
>
> I've followed the instructions for deploying an unmanaged dependency. As I
> am the only developer at my company (at this time), I do not have a separate
> Maven server setup. I was hoping to simply deploy the dependency and then
> run 'maven install' so that it copies everything needed into my .m2 folder.
> This is my directory setup:
>
>
>
> (This is the project directory for the sqljdbc4 unmanaged dependency)
>
> C:\dev\Github-repos\addons\sqljdbc4
>
> +- pom.xml
>
> +-src
>
> +-repo
>
>
>
> I followed the instructions to use mvn deploy on the local sqljdbc4.jar
> file. I am using an artifactId of sqljdbc4, version 4.0, groupId of
> com.microsoft.sqlserver. After deployment, the repo directory does appear to
> be correctly populated:
>
>
>
> C:\dev\Github-repos\addons\sqljdbc4
>
> +- pom.xml
>
> +-src
>
> +-repo
>
> +-com
>
> +-microsoft
>
> +-sqlserver
>
> +-sqljdbc4
>
> +-maven-metadata
>
> +-4.0
>
> +-sqljdbc4-4.0.jar
>
> +-sqljdbc4-4.0.pom
>
>
>
> Next, following the instructions, I go back into the pom.xml file and add
> the repository tag, so my pom.xml for this now looks like:
>
>
>
> http://maven.apache.org/POM/4.0.0";
> xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance";
> xsi:schemaLocation="http://maven.apache.org/POM/4.0.0
> http://maven.apache.org/xsd/maven-4.0.0.xsd";>
>
> 4.0.0
>
> com.microsoft.sqlserver
>
> sqljdbc4
>
> 4.0
>
>
>
> 
>
> 
>
> 
>
> project.local
>
> project
>
> file:${project.basedir}/repo
>
> 
>
> 
>
> 
>
>
>
>
>
> Now, here is the problem. Since I want to use this as a dependency in other
> projects, I am trying to run 'maven install' so that it will push everything
> into my .m2 directory. The maven build is a success. However, the resulting
> sqljdbc4.jar file in the target directory and up in the m2 directory is only
> 2kb (whereas the original jar file is 571kb, none of the content made it
> in). As a result, projects that use this as a dependency build, but then
> throw a ClassNotFoundException at runtime, because the classes aren't there.
>
>
>
> I am building a separate project that uses this as a dependency:
>
>
>
> C:\dev\Github-repos\applications\myapp
>
>
>
> The pom.xml for this project uses the dependency correctly:
>
> 
>
> com.microsoft.sqlserver
>
> sqljdbc4
>
> 4.0
>
> 
>
>
>
> I'm even using the maven assembly plugin to ensure a jar is built with all
> dependencies packaged in:
>
>
>
> 
>
>
> maven-assembly-plugin
>
> 
>
> 
>
>
> jar-with-dependencies
>
> 
>
> 
>
> 
>
> true
>
>
> productfeeds.main.ProductFeedDriver
>
> 
>
> 
>
> 
>
> 
>
> 
>
> package
>
> 
>
> single
>
> 
>
> 
>
> 
>
> 
>
>
>
>
>
> Any ideas what I'm doing wrong? I'm sure it's something really simple I've
> overlooked. If I don't make this a standalone dependency, and simply use
> 'mvn install:install-file -Dfile=sqljdbc4.jar
> -DgroupId=com.microsoft.sqlserver -DartifactId=sqljdbc4 -Dversion=4.0
> -Dpackaging=jar ', then everything works fine.
>
>
>
> Thanks,
>
>
>
> Matt
>
>
>

Unmanaged dependency question

[Matt Whiteman]

Hi,

 

This has probably been answered before, but I haven't been able to find the
answer and I'm hoping someone knows.

 

I'm writing several apps that talk to a Microsoft SQL database, so I'm using
the Hibernate dependency. Since Microsoft doesn't make the sqljdbc4 jar
available on Maven, I've downloaded it, and I'm trying to make it an
unmanaged dependency in its own standalone project so that I can simply
reference it in other projects' pom files without having to deploy the jar
to each one individually.

 

I've followed the instructions for deploying an unmanaged dependency. As I
am the only developer at my company (at this time), I do not have a separate
Maven server setup. I was hoping to simply deploy the dependency and then
run 'maven install' so that it copies everything needed into my .m2 folder.
This is my directory setup:

 

(This is the project directory for the sqljdbc4 unmanaged dependency)

C:\dev\Github-repos\addons\sqljdbc4

  +- pom.xml

  +-src

  +-repo

 

I followed the instructions to use mvn deploy on the local sqljdbc4.jar
file. I am using an artifactId of sqljdbc4, version 4.0, groupId of
com.microsoft.sqlserver. After deployment, the repo directory does appear to
be correctly populated:

 

C:\dev\Github-repos\addons\sqljdbc4

  +- pom.xml

  +-src

  +-repo

   +-com

   +-microsoft

  +-sqlserver

   +-sqljdbc4

+-maven-metadata

+-4.0

  +-sqljdbc4-4.0.jar

  +-sqljdbc4-4.0.pom

 

Next, following the instructions, I go back into the pom.xml file and add
the repository tag, so my pom.xml for this now looks like:

 

http://maven.apache.org/POM/4.0.0";
xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance";
xsi:schemaLocation="http://maven.apache.org/POM/4.0.0
http://maven.apache.org/xsd/maven-4.0.0.xsd";>

  4.0.0

  com.microsoft.sqlserver

  sqljdbc4

  4.0

  







project.local

project

file:${project.basedir}/repo







 

 

Now, here is the problem. Since I want to use this as a dependency in other
projects, I am trying to run 'maven install' so that it will push everything
into my .m2 directory. The maven build is a success. However, the resulting
sqljdbc4.jar file in the target directory and up in the m2 directory is only
2kb (whereas the original jar file is 571kb, none of the content made it
in). As a result, projects that use this as a dependency build, but then
throw a ClassNotFoundException at runtime, because the classes aren't there.

 

I am building a separate project that uses this as a dependency:

 

C:\dev\Github-repos\applications\myapp

 

The pom.xml for this project uses the dependency correctly:



com.microsoft.sqlserver

sqljdbc4

4.0



 

I'm even using the maven assembly plugin to ensure a jar is built with all
dependencies packaged in:

 



 
maven-assembly-plugin

  



 
jar-with-dependencies





  

true

 
productfeeds.main.ProductFeedDriver

  



  



  

package



  single



  





 

 

Any ideas what I'm doing wrong? I'm sure it's something really simple I've
overlooked. If I don't make this a standalone dependency, and simply use
'mvn install:install-file -Dfile=sqljdbc4.jar
-DgroupId=com.microsoft.sqlserver -DartifactId=sqljdbc4 -Dversion=4.0
-Dpackaging=jar ', then everything works fine.

 

Thanks,

 

Matt

 

Re: Unmanaged dependency question

[Wayne Fay]

> so that I can do everything right. What I had been trying to do in the 
> meantime
> is having it set up
> so that when we set up a new development station, the user can simply clone 
> the
> Github repo that
> has these dependency projects and just do 'mvn install' on each one, then 
> build

Arguably if you insist on this "mvn install" approach, you could unzip
the jar contents into src/main/resources. Then when you "build" it
would copy everything into /target and build a "new" jar file which
would be installed.

But this is really not the right approach. You should be using
install:install-file.

Wayne

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

Re: Unmanaged dependency question

[Jeff MAURY]

The install-file is the way to go and it will be successful as soon as your
work on  your machine.
If you want to distributed setup, then you must upload the JAR to a
repository manager or install it on a shared maven repository and use that
remote maven repository in your POM files

Jeff


On Sat, May 31, 2014 at 4:21 AM, Paul Benedict  wrote:

> I understand but you can't achieve this using a project to represent a
> pre-existing jar. Your attempt won't work. The "install-file" command is
> the correct solution; that is how you get it into your local repo without
> downloading it from a remote repo.
> On May 30, 2014 4:36 PM, "Matt Whiteman" 
> wrote:
>
> > Hi Curtis,
> >
> > I'll take a look at that, thanks! Ideally, I'll eventually be able to
> have
> > an
> > internal Maven repository
> > so that I can do everything right. What I had been trying to do in the
> > meantime
> > is having it set up
> > so that when we set up a new development station, the user can simply
> > clone the
> > Github repo that
> > has these dependency projects and just do 'mvn install' on each one, then
> > build
> > or develop the
> > standalone app(s). Kinda  crude I know, but we're basically just
> starting a
> > software development
> > department, so have to work  with what's available in the short-term. If
> it
> > doesn't work, I can just
> > keep a batch script with the jar  that runs the mvn:install I suppose.
> >
> > Yup Paul, that's exactly what was happening. The jar file deployed into a
> > local
> > repo within the
> > project directory, and put a reference pom file up in the .m2 directory.
> > But as
> > soon as I
> > ran 'mvn install', it built an empty jar file and put that up in the .m2
> > instead. I just wanted to try to
> > have it in a separate project so that from the user's perspective, it
> > would be
> > as close as possible
> > to what the process would be  if we had an actual internal maven repo.
> >
> > Thanks for the suggestions everyone!
> >
> > Matt
> >
> > On May 30, 2014 at 4:49 PM Curtis Rueden  wrote:
> > > Hi Matt,
> > >
> > > Have you seen this article?
> > >
> >
> http://developer-blog.cloudbees.com/2013/03/playing-trade-offs-with-maven.html
> > >
> > > If you cannot deploy the Microsoft JARs to your own internal Maven
> > > repository, then you could try the non-maven-jar-plugin approach. It is
> > > strongly recommended over the "basedir repository hack" approach that
> you
> > > are using (presumably from
> > > https://devcenter.heroku.com/articles/local-maven-dependencies).
> > >
> > > Regards,
> > > Curtis
> > >
> > >
> > > On Fri, May 30, 2014 at 3:42 PM, Matt Whiteman <
> > mwhite...@purelandsupply.com
> > > > wrote:
> > >
> > > > Hi,
> > > >
> > > >
> > > >
> > > > This has probably been answered before, but I haven't been able to
> > find the
> > > > answer and I'm hoping someone knows.
> > > >
> > > >
> > > >
> > > > I'm writing several apps that talk to a Microsoft SQL database, so
> I'm
> > > > using
> > > > the Hibernate dependency. Since Microsoft doesn't make the sqljdbc4
> jar
> > > > available on Maven, I've downloaded it, and I'm trying to make it an
> > > > unmanaged dependency in its own standalone project so that I can
> simply
> > > > reference it in other projects' pom files without having to deploy
> the
> > jar
> > > > to each one individually.
> > > >
> > > >
> > > >
> > > > I've followed the instructions for deploying an unmanaged dependency.
> > As I
> > > > am the only developer at my company (at this time), I do not have a
> > > > separate
> > > > Maven server setup. I was hoping to simply deploy the dependency and
> > then
> > > > run 'maven install' so that it copies everything needed into my .m2
> > folder.
> > > > This is my directory setup:
> > > >
> > > >
> > > >
> > > > (This is the project directory for the sqljdbc4 unmanaged dependency)
> > > >
> > > > C:\dev\Github-repos\addons\sqljdbc4
> > > >
> > > > +- pom.xml
> > > >
> > > > +-src
> > > >
> > > > +-repo
> > > >
> > > >
> > > >
> > > > I followed the instructions to use mvn deploy on the local
> sqljdbc4.jar
> > > > file. I am using an artifactId of sqljdbc4, version 4.0, groupId of
> > > > com.microsoft.sqlserver. After deployment, the repo directory does
> > appear
> > > > to
> > > > be correctly populated:
> > > >
> > > >
> > > >
> > > > C:\dev\Github-repos\addons\sqljdbc4
> > > >
> > > > +- pom.xml
> > > >
> > > > +-src
> > > >
> > > > +-repo
> > > >
> > > > +-com
> > > >
> > > > +-microsoft
> > > >
> > > > +-sqlserver
> > > >
> > > > +-sqljdbc4
> > > >
> > > > +-maven-metadata
> > > >
> > > > +-4.0
> > > >
> > > > +-sqljdbc4-4.0.jar
> > > >
> > > > +-sqljdbc4-4.0.pom
> > > >
> > > >
> > > >
> > > > Next, following the instructions, I go back into the pom.xml file and
> > add
> > > > the repository tag, so my pom.xml for this now looks like:
> > > >
> > > >
> > > >
> > > > http://maven.apache.org/POM/4.0.0";
> > > > xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance";
> > > > xsi:schemaLoca

Re: Unmanaged dependency question

[Paul Benedict]

I understand but you can't achieve this using a project to represent a
pre-existing jar. Your attempt won't work. The "install-file" command is
the correct solution; that is how you get it into your local repo without
downloading it from a remote repo.
On May 30, 2014 4:36 PM, "Matt Whiteman" 
wrote:

> Hi Curtis,
>
> I'll take a look at that, thanks! Ideally, I'll eventually be able to have
> an
> internal Maven repository
> so that I can do everything right. What I had been trying to do in the
> meantime
> is having it set up
> so that when we set up a new development station, the user can simply
> clone the
> Github repo that
> has these dependency projects and just do 'mvn install' on each one, then
> build
> or develop the
> standalone app(s). Kinda  crude I know, but we're basically just starting a
> software development
> department, so have to work  with what's available in the short-term. If it
> doesn't work, I can just
> keep a batch script with the jar  that runs the mvn:install I suppose.
>
> Yup Paul, that's exactly what was happening. The jar file deployed into a
> local
> repo within the
> project directory, and put a reference pom file up in the .m2 directory.
> But as
> soon as I
> ran 'mvn install', it built an empty jar file and put that up in the .m2
> instead. I just wanted to try to
> have it in a separate project so that from the user's perspective, it
> would be
> as close as possible
> to what the process would be  if we had an actual internal maven repo.
>
> Thanks for the suggestions everyone!
>
> Matt
>
> On May 30, 2014 at 4:49 PM Curtis Rueden  wrote:
> > Hi Matt,
> >
> > Have you seen this article?
> >
> http://developer-blog.cloudbees.com/2013/03/playing-trade-offs-with-maven.html
> >
> > If you cannot deploy the Microsoft JARs to your own internal Maven
> > repository, then you could try the non-maven-jar-plugin approach. It is
> > strongly recommended over the "basedir repository hack" approach that you
> > are using (presumably from
> > https://devcenter.heroku.com/articles/local-maven-dependencies).
> >
> > Regards,
> > Curtis
> >
> >
> > On Fri, May 30, 2014 at 3:42 PM, Matt Whiteman <
> mwhite...@purelandsupply.com
> > > wrote:
> >
> > > Hi,
> > >
> > >
> > >
> > > This has probably been answered before, but I haven't been able to
> find the
> > > answer and I'm hoping someone knows.
> > >
> > >
> > >
> > > I'm writing several apps that talk to a Microsoft SQL database, so I'm
> > > using
> > > the Hibernate dependency. Since Microsoft doesn't make the sqljdbc4 jar
> > > available on Maven, I've downloaded it, and I'm trying to make it an
> > > unmanaged dependency in its own standalone project so that I can simply
> > > reference it in other projects' pom files without having to deploy the
> jar
> > > to each one individually.
> > >
> > >
> > >
> > > I've followed the instructions for deploying an unmanaged dependency.
> As I
> > > am the only developer at my company (at this time), I do not have a
> > > separate
> > > Maven server setup. I was hoping to simply deploy the dependency and
> then
> > > run 'maven install' so that it copies everything needed into my .m2
> folder.
> > > This is my directory setup:
> > >
> > >
> > >
> > > (This is the project directory for the sqljdbc4 unmanaged dependency)
> > >
> > > C:\dev\Github-repos\addons\sqljdbc4
> > >
> > > +- pom.xml
> > >
> > > +-src
> > >
> > > +-repo
> > >
> > >
> > >
> > > I followed the instructions to use mvn deploy on the local sqljdbc4.jar
> > > file. I am using an artifactId of sqljdbc4, version 4.0, groupId of
> > > com.microsoft.sqlserver. After deployment, the repo directory does
> appear
> > > to
> > > be correctly populated:
> > >
> > >
> > >
> > > C:\dev\Github-repos\addons\sqljdbc4
> > >
> > > +- pom.xml
> > >
> > > +-src
> > >
> > > +-repo
> > >
> > > +-com
> > >
> > > +-microsoft
> > >
> > > +-sqlserver
> > >
> > > +-sqljdbc4
> > >
> > > +-maven-metadata
> > >
> > > +-4.0
> > >
> > > +-sqljdbc4-4.0.jar
> > >
> > > +-sqljdbc4-4.0.pom
> > >
> > >
> > >
> > > Next, following the instructions, I go back into the pom.xml file and
> add
> > > the repository tag, so my pom.xml for this now looks like:
> > >
> > >
> > >
> > > http://maven.apache.org/POM/4.0.0";
> > > xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance";
> > > xsi:schemaLocation="http://maven.apache.org/POM/4.0.0
> > > http://maven.apache.org/xsd/maven-4.0.0.xsd
> > > <
> > >
> http://maven.apache.org/POM/4.0.0%20http:/maven.apache.org/xsd/maven-4.0.0
> > > .
> > > xsd> ">
> > >
> > > 4.0.0
> > >
> > > com.microsoft.sqlserver
> > >
> > > sqljdbc4
> > >
> > > 4.0
> > >
> > >
> > >
> > > 
> > >
> > > 
> > >
> > > 
> > >
> > > project.local
> > >
> > > project
> > >
> > > file:${project.basedir}/repo
> > >
> > > 
> > >
> > > 
> > >
> > > 
> > >
> > >
> > >
> > >
> > >
> > > Now, here is the problem. Since I want to use this as a dependency in
> other
> > > projects, I am trying to run 'maven install' so that it will push
> > > everything
>

Re: Unmanaged dependency question

[Matt Whiteman]

Hi Curtis,

I'll take a look at that, thanks! Ideally, I'll eventually be able to have an
internal Maven repository
so that I can do everything right. What I had been trying to do in the meantime
is having it set up
so that when we set up a new development station, the user can simply clone the
Github repo that
has these dependency projects and just do 'mvn install' on each one, then build
or develop the
standalone app(s). Kinda  crude I know, but we're basically just starting a
software development
department, so have to work  with what's available in the short-term. If it
doesn't work, I can just
keep a batch script with the jar  that runs the mvn:install I suppose.

Yup Paul, that's exactly what was happening. The jar file deployed into a local
repo within the
project directory, and put a reference pom file up in the .m2 directory. But as
soon as I
ran 'mvn install', it built an empty jar file and put that up in the .m2
instead. I just wanted to try to
have it in a separate project so that from the user's perspective, it would be
as close as possible
to what the process would be  if we had an actual internal maven repo.

Thanks for the suggestions everyone!

Matt

On May 30, 2014 at 4:49 PM Curtis Rueden  wrote:
> Hi Matt,
>
> Have you seen this article?
> http://developer-blog.cloudbees.com/2013/03/playing-trade-offs-with-maven.html
>
> If you cannot deploy the Microsoft JARs to your own internal Maven
> repository, then you could try the non-maven-jar-plugin approach. It is
> strongly recommended over the "basedir repository hack" approach that you
> are using (presumably from
> https://devcenter.heroku.com/articles/local-maven-dependencies).
>
> Regards,
> Curtis
>
>
> On Fri, May 30, 2014 at 3:42 PM, Matt Whiteman  > wrote:
>
> > Hi,
> >
> >
> >
> > This has probably been answered before, but I haven't been able to find the
> > answer and I'm hoping someone knows.
> >
> >
> >
> > I'm writing several apps that talk to a Microsoft SQL database, so I'm
> > using
> > the Hibernate dependency. Since Microsoft doesn't make the sqljdbc4 jar
> > available on Maven, I've downloaded it, and I'm trying to make it an
> > unmanaged dependency in its own standalone project so that I can simply
> > reference it in other projects' pom files without having to deploy the jar
> > to each one individually.
> >
> >
> >
> > I've followed the instructions for deploying an unmanaged dependency. As I
> > am the only developer at my company (at this time), I do not have a
> > separate
> > Maven server setup. I was hoping to simply deploy the dependency and then
> > run 'maven install' so that it copies everything needed into my .m2 folder.
> > This is my directory setup:
> >
> >
> >
> > (This is the project directory for the sqljdbc4 unmanaged dependency)
> >
> > C:\dev\Github-repos\addons\sqljdbc4
> >
> > +- pom.xml
> >
> > +-src
> >
> > +-repo
> >
> >
> >
> > I followed the instructions to use mvn deploy on the local sqljdbc4.jar
> > file. I am using an artifactId of sqljdbc4, version 4.0, groupId of
> > com.microsoft.sqlserver. After deployment, the repo directory does appear
> > to
> > be correctly populated:
> >
> >
> >
> > C:\dev\Github-repos\addons\sqljdbc4
> >
> > +- pom.xml
> >
> > +-src
> >
> > +-repo
> >
> > +-com
> >
> > +-microsoft
> >
> > +-sqlserver
> >
> > +-sqljdbc4
> >
> > +-maven-metadata
> >
> > +-4.0
> >
> > +-sqljdbc4-4.0.jar
> >
> > +-sqljdbc4-4.0.pom
> >
> >
> >
> > Next, following the instructions, I go back into the pom.xml file and add
> > the repository tag, so my pom.xml for this now looks like:
> >
> >
> >
> > http://maven.apache.org/POM/4.0.0";
> > xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance";
> > xsi:schemaLocation="http://maven.apache.org/POM/4.0.0
> > http://maven.apache.org/xsd/maven-4.0.0.xsd
> > <
> > http://maven.apache.org/POM/4.0.0%20http:/maven.apache.org/xsd/maven-4.0.0
> > .
> > xsd> ">
> >
> > 4.0.0
> >
> > com.microsoft.sqlserver
> >
> > sqljdbc4
> >
> > 4.0
> >
> >
> >
> > 
> >
> > 
> >
> > 
> >
> > project.local
> >
> > project
> >
> > file:${project.basedir}/repo
> >
> > 
> >
> > 
> >
> > 
> >
> >
> >
> >
> >
> > Now, here is the problem. Since I want to use this as a dependency in other
> > projects, I am trying to run 'maven install' so that it will push
> > everything
> > into my .m2 directory. The maven build is a success. However, the resulting
> > sqljdbc4.jar file in the target directory and up in the m2 directory is
> > only
> > 2kb (whereas the original jar file is 571kb, none of the content made it
> > in). As a result, projects that use this as a dependency build, but then
> > throw a ClassNotFoundException at runtime, because the classes aren't
> > there.
> >
> >
> >
> > I am building a separate project that uses this as a dependency:
> >
> >
> >
> > C:\dev\Github-repos\applications\myapp
> >
> >
> >
> > The pom.xml for this project uses the dependency correctly:
> >
> > 
> >
> > com.microsoft.sqlserver
> >
> > sqljdbc4
> >
> > 4.0
> >
> > 
> >
> >
> >
> > 

Re: Unmanaged dependency question

[Paul Benedict]

I don't think you should make a project for your sql jar. My guess is when
you build+install that, you're creating an empty and useless jar file and
overwriting the good one you already placed in your local repo. The
mvn:install:install-file thing works and is what I would expect as the
answer.


Cheers,
Paul


On Fri, May 30, 2014 at 3:42 PM, Matt Whiteman  wrote:

> Hi,
>
>
>
> This has probably been answered before, but I haven't been able to find the
> answer and I'm hoping someone knows.
>
>
>
> I'm writing several apps that talk to a Microsoft SQL database, so I'm
> using
> the Hibernate dependency. Since Microsoft doesn't make the sqljdbc4 jar
> available on Maven, I've downloaded it, and I'm trying to make it an
> unmanaged dependency in its own standalone project so that I can simply
> reference it in other projects' pom files without having to deploy the jar
> to each one individually.
>
>
>
> I've followed the instructions for deploying an unmanaged dependency. As I
> am the only developer at my company (at this time), I do not have a
> separate
> Maven server setup. I was hoping to simply deploy the dependency and then
> run 'maven install' so that it copies everything needed into my .m2 folder.
> This is my directory setup:
>
>
>
> (This is the project directory for the sqljdbc4 unmanaged dependency)
>
> C:\dev\Github-repos\addons\sqljdbc4
>
>   +- pom.xml
>
>   +-src
>
>   +-repo
>
>
>
> I followed the instructions to use mvn deploy on the local sqljdbc4.jar
> file. I am using an artifactId of sqljdbc4, version 4.0, groupId of
> com.microsoft.sqlserver. After deployment, the repo directory does appear
> to
> be correctly populated:
>
>
>
> C:\dev\Github-repos\addons\sqljdbc4
>
>   +- pom.xml
>
>   +-src
>
>   +-repo
>
>+-com
>
>+-microsoft
>
>   +-sqlserver
>
>+-sqljdbc4
>
> +-maven-metadata
>
> +-4.0
>
>   +-sqljdbc4-4.0.jar
>
>   +-sqljdbc4-4.0.pom
>
>
>
> Next, following the instructions, I go back into the pom.xml file and add
> the repository tag, so my pom.xml for this now looks like:
>
>
>
> http://maven.apache.org/POM/4.0.0";
> xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance";
> xsi:schemaLocation="http://maven.apache.org/POM/4.0.0
> http://maven.apache.org/xsd/maven-4.0.0.xsd
> <
> http://maven.apache.org/POM/4.0.0%20http:/maven.apache.org/xsd/maven-4.0.0
> .
> xsd> ">
>
>   4.0.0
>
>   com.microsoft.sqlserver
>
>   sqljdbc4
>
>   4.0
>
>
>
> 
>
> 
>
> 
>
> project.local
>
> project
>
> file:${project.basedir}/repo
>
> 
>
> 
>
> 
>
>
>
>
>
> Now, here is the problem. Since I want to use this as a dependency in other
> projects, I am trying to run 'maven install' so that it will push
> everything
> into my .m2 directory. The maven build is a success. However, the resulting
> sqljdbc4.jar file in the target directory and up in the m2 directory is
> only
> 2kb (whereas the original jar file is 571kb, none of the content made it
> in). As a result, projects that use this as a dependency build, but then
> throw a ClassNotFoundException at runtime, because the classes aren't
> there.
>
>
>
> I am building a separate project that uses this as a dependency:
>
>
>
> C:\dev\Github-repos\applications\myapp
>
>
>
> The pom.xml for this project uses the dependency correctly:
>
> 
>
> com.microsoft.sqlserver
>
> sqljdbc4
>
> 4.0
>
> 
>
>
>
> I'm even using the maven assembly plugin to ensure a jar is built with all
> dependencies packaged in:
>
>
>
> 
>
>
> maven-assembly-plugin
>
>   
>
> 
>
>
> jar-with-dependencies
>
> 
>
> 
>
>   
>
> true
>
>
> productfeeds.main.ProductFeedDriver
>
>   
>
> 
>
>   
>
> 
>
>   
>
> package
>
> 
>
>   single
>
> 
>
>   
>
> 
>
> 
>
>
>
>
>
> Any ideas what I'm doing wrong? I'm sure it's something really simple I've
> overlooked. If I don't make this a standalone dependency, and simply use
> 'mvn install:install-file -Dfile=sqljdbc4.jar
> -DgroupId=com.microsoft.sqlserver -DartifactId=sqljdbc4 -Dversion=4.0
> -Dpackaging=jar ', then everything works fine.
>
>
>
> Thanks,
>
>
>
> Matt
>
>
>
>

Re: Unmanaged dependency question

[Curtis Rueden]

Hi Matt,

Have you seen this article?
http://developer-blog.cloudbees.com/2013/03/playing-trade-offs-with-maven.html

If you cannot deploy the Microsoft JARs to your own internal Maven
repository, then you could try the non-maven-jar-plugin approach. It is
strongly recommended over the "basedir repository hack" approach that you
are using (presumably from
https://devcenter.heroku.com/articles/local-maven-dependencies).

Regards,
Curtis


On Fri, May 30, 2014 at 3:42 PM, Matt Whiteman  wrote:

> Hi,
>
>
>
> This has probably been answered before, but I haven't been able to find the
> answer and I'm hoping someone knows.
>
>
>
> I'm writing several apps that talk to a Microsoft SQL database, so I'm
> using
> the Hibernate dependency. Since Microsoft doesn't make the sqljdbc4 jar
> available on Maven, I've downloaded it, and I'm trying to make it an
> unmanaged dependency in its own standalone project so that I can simply
> reference it in other projects' pom files without having to deploy the jar
> to each one individually.
>
>
>
> I've followed the instructions for deploying an unmanaged dependency. As I
> am the only developer at my company (at this time), I do not have a
> separate
> Maven server setup. I was hoping to simply deploy the dependency and then
> run 'maven install' so that it copies everything needed into my .m2 folder.
> This is my directory setup:
>
>
>
> (This is the project directory for the sqljdbc4 unmanaged dependency)
>
> C:\dev\Github-repos\addons\sqljdbc4
>
>   +- pom.xml
>
>   +-src
>
>   +-repo
>
>
>
> I followed the instructions to use mvn deploy on the local sqljdbc4.jar
> file. I am using an artifactId of sqljdbc4, version 4.0, groupId of
> com.microsoft.sqlserver. After deployment, the repo directory does appear
> to
> be correctly populated:
>
>
>
> C:\dev\Github-repos\addons\sqljdbc4
>
>   +- pom.xml
>
>   +-src
>
>   +-repo
>
>+-com
>
>+-microsoft
>
>   +-sqlserver
>
>+-sqljdbc4
>
> +-maven-metadata
>
> +-4.0
>
>   +-sqljdbc4-4.0.jar
>
>   +-sqljdbc4-4.0.pom
>
>
>
> Next, following the instructions, I go back into the pom.xml file and add
> the repository tag, so my pom.xml for this now looks like:
>
>
>
> http://maven.apache.org/POM/4.0.0";
> xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance";
> xsi:schemaLocation="http://maven.apache.org/POM/4.0.0
> http://maven.apache.org/xsd/maven-4.0.0.xsd
> <
> http://maven.apache.org/POM/4.0.0%20http:/maven.apache.org/xsd/maven-4.0.0
> .
> xsd> ">
>
>   4.0.0
>
>   com.microsoft.sqlserver
>
>   sqljdbc4
>
>   4.0
>
>
>
> 
>
> 
>
> 
>
> project.local
>
> project
>
> file:${project.basedir}/repo
>
> 
>
> 
>
> 
>
>
>
>
>
> Now, here is the problem. Since I want to use this as a dependency in other
> projects, I am trying to run 'maven install' so that it will push
> everything
> into my .m2 directory. The maven build is a success. However, the resulting
> sqljdbc4.jar file in the target directory and up in the m2 directory is
> only
> 2kb (whereas the original jar file is 571kb, none of the content made it
> in). As a result, projects that use this as a dependency build, but then
> throw a ClassNotFoundException at runtime, because the classes aren't
> there.
>
>
>
> I am building a separate project that uses this as a dependency:
>
>
>
> C:\dev\Github-repos\applications\myapp
>
>
>
> The pom.xml for this project uses the dependency correctly:
>
> 
>
> com.microsoft.sqlserver
>
> sqljdbc4
>
> 4.0
>
> 
>
>
>
> I'm even using the maven assembly plugin to ensure a jar is built with all
> dependencies packaged in:
>
>
>
> 
>
>
> maven-assembly-plugin
>
>   
>
> 
>
>
> jar-with-dependencies
>
> 
>
> 
>
>   
>
> true
>
>
> productfeeds.main.ProductFeedDriver
>
>   
>
> 
>
>   
>
> 
>
>   
>
> package
>
> 
>
>   single
>
> 
>
>   
>
> 
>
> 
>
>
>
>
>
> Any ideas what I'm doing wrong? I'm sure it's something really simple I've
> overlooked. If I don't make this a standalone dependency, and simply use
> 'mvn install:install-file -Dfile=sqljdbc4.jar
> -DgroupId=com.microsoft.sqlserver -DartifactId=sqljdbc4 -Dversion=4.0
> -Dpackaging=jar ', then everything works fine.
>
>
>
> Thanks,
>
>
>
> Matt
>
>
>
>

Unmanaged dependency question

[Matt Whiteman]

Hi,

 

This has probably been answered before, but I haven't been able to find the
answer and I'm hoping someone knows.

 

I'm writing several apps that talk to a Microsoft SQL database, so I'm using
the Hibernate dependency. Since Microsoft doesn't make the sqljdbc4 jar
available on Maven, I've downloaded it, and I'm trying to make it an
unmanaged dependency in its own standalone project so that I can simply
reference it in other projects' pom files without having to deploy the jar
to each one individually.

 

I've followed the instructions for deploying an unmanaged dependency. As I
am the only developer at my company (at this time), I do not have a separate
Maven server setup. I was hoping to simply deploy the dependency and then
run 'maven install' so that it copies everything needed into my .m2 folder.
This is my directory setup:

 

(This is the project directory for the sqljdbc4 unmanaged dependency)

C:\dev\Github-repos\addons\sqljdbc4

  +- pom.xml

  +-src

  +-repo

 

I followed the instructions to use mvn deploy on the local sqljdbc4.jar
file. I am using an artifactId of sqljdbc4, version 4.0, groupId of
com.microsoft.sqlserver. After deployment, the repo directory does appear to
be correctly populated:

 

C:\dev\Github-repos\addons\sqljdbc4

  +- pom.xml

  +-src

  +-repo

   +-com

   +-microsoft

  +-sqlserver

   +-sqljdbc4

+-maven-metadata

+-4.0

  +-sqljdbc4-4.0.jar

  +-sqljdbc4-4.0.pom

 

Next, following the instructions, I go back into the pom.xml file and add
the repository tag, so my pom.xml for this now looks like:

 

http://maven.apache.org/POM/4.0.0";
xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance";
xsi:schemaLocation="http://maven.apache.org/POM/4.0.0
http://maven.apache.org/xsd/maven-4.0.0.xsd
 ">

  4.0.0

  com.microsoft.sqlserver

  sqljdbc4

  4.0

  







project.local

project

file:${project.basedir}/repo







 

 

Now, here is the problem. Since I want to use this as a dependency in other
projects, I am trying to run 'maven install' so that it will push everything
into my .m2 directory. The maven build is a success. However, the resulting
sqljdbc4.jar file in the target directory and up in the m2 directory is only
2kb (whereas the original jar file is 571kb, none of the content made it
in). As a result, projects that use this as a dependency build, but then
throw a ClassNotFoundException at runtime, because the classes aren't there.

 

I am building a separate project that uses this as a dependency:

 

C:\dev\Github-repos\applications\myapp

 

The pom.xml for this project uses the dependency correctly:



com.microsoft.sqlserver

sqljdbc4

4.0



 

I'm even using the maven assembly plugin to ensure a jar is built with all
dependencies packaged in:

 



 
maven-assembly-plugin

  



 
jar-with-dependencies





  

true

 
productfeeds.main.ProductFeedDriver

  



  



  

package



  single



  





 

 

Any ideas what I'm doing wrong? I'm sure it's something really simple I've
overlooked. If I don't make this a standalone dependency, and simply use
'mvn install:install-file -Dfile=sqljdbc4.jar
-DgroupId=com.microsoft.sqlserver -DartifactId=sqljdbc4 -Dversion=4.0
-Dpackaging=jar ', then everything works fine.

 

Thanks,

 

Matt

 

Re: Transitive Dependency Question

[Jörg Schaible]

Hi Jamal,

Jamal B wrote:

> Interesting
> 
> Taking your suggestion, it looks like it is coming in from another compile
> dependency, and was "promoted" to compile.
> 
> [INFO] +- org.apache.maven.shared:maven-shared-jar:jar:1.1:compile
> [INFO] |  +- org.codehaus.plexus:plexus-digest:jar:1.0:compile
> [INFO] |  |  \-
> org.codehaus.plexus:plexus-container-default:jar:1.0-alpha-8:compile
> [INFO] |  | +- junit:junit:jar:3.8.1:compile
> 
> Is there a way to prevent this from happening without having to add
> exclude stanzas across projects where this is happening?

You can control this with a dependencyManagement section of a shared parent. 
Just define there junit:junit: and the scope.

The annoying part is nevertheless that the situation is no longer obvious in 
M3. Try this in M2 and you'll see that the dependency makes much more sense. 
Since the same plugin produces different output, I blame the new Aether 
backend here which favors now the "nearest" occurrence without taking the 
inherited scope into account. While this behavior has no impact on the 
resulting class path, it hides dependency problems like the one, you have 
encountered here.

- Jörg


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

Re: Transitive Dependency Question

[Jamal B]

Interesting

Taking your suggestion, it looks like it is coming in from another compile
dependency, and was "promoted" to compile.

[INFO] +- org.apache.maven.shared:maven-shared-jar:jar:1.1:compile
[INFO] |  +- org.codehaus.plexus:plexus-digest:jar:1.0:compile
[INFO] |  |  \-
org.codehaus.plexus:plexus-container-default:jar:1.0-alpha-8:compile
[INFO] |  | +- junit:junit:jar:3.8.1:compile

Is there a way to prevent this from happening without having to add exclude
stanzas across projects where this is happening?



On Mon, Jun 3, 2013 at 7:56 PM, Jörg Schaible  wrote:

> Hi Jamal,
>
> Jamal B wrote:
>
> > Hello, I have a question about transitive dependencies.  According to the
> > pom documentation here: http://maven.apache.org/pom.html#Dependencies
> >
> > project dependencies marked with test scope are not transitive.  I
> assumed
> > that this also applied to it's dependencies, so my question is if I
> > declare a dependency on a project at test scope, that project's
> > dependencies should
> > all be included at test scope.  For example, given the following
> > project(s)
> >
> > Project test-utils defines a junit dependency like such:
> >
> > 
> > junit
> > junit
> > 
> >
> > Project application defines a dependency on test-utils with a scope of
> > test like such
> > 
> > ${project.groupId}
> > test-utils
> > ${project.version}
> > test
> > 
> >
> > Now running mvn clean dependency:tree shows that the junit dependency is
> > being passed to the application project at compile scope which is not
> > expected.
> >
> > [INFO] --- maven-dependency-plugin:2.7:tree (default-cli) @ application
> > [--- INFO] org.sandbox:application:war:1.0.0-SNAPSHOT
> > 
> > [INFO] \- org.sandbox:test-utils:jar:1.0.0-SNAPSHOT:test
> > [INFO]+- junit:junit:jar:4.8.2:compile
> > [INFO]+- org.mockito:mockito-all:jar:1.8.5:test
> > [INFO]+- com.h2database:h2:jar:1.3.165:test
> > [INFO]\- log4j:log4j:jar:1.2.16:test
> >
> >
> > Is this a bug or was my interpretation of the transitive dependency logic
> > incorrect?
> >
> > Thank you for your time.
>
> Actually I was fooled by such an output with M3 in one of my projects at
> first sight also.
>
> So, please make a test: Comment out the org.sandbox:test-utils in your POM
> and print the tree again. I am quite sure that you will see that
> junit:junit
> is now introduced by a different dependency that is not of test scope. What
> you see above is only the result of the dependency resolver. It detected
> that it already has a junit:junit in its transitive deps in compile scope
> (maybe even in a different version), but the "nearest" path to junit was as
> direct child of org.sandbox:test-utils. Therefor it was "promoted" to
> compile scope in this place, but the overall result of the compilation
> classpath is still OK, it is only the displayed tree that is somewhat
> inconsistent (compared to M2).
>
> - Jörg
>
>
> -
> To unsubscribe, e-mail: users-unsubscr...@maven.apache.org
> For additional commands, e-mail: users-h...@maven.apache.org
>
>

Re: Transitive Dependency Question

[Jörg Schaible]

Hi Jamal,

Jamal B wrote:

> Hello, I have a question about transitive dependencies.  According to the
> pom documentation here: http://maven.apache.org/pom.html#Dependencies
> 
> project dependencies marked with test scope are not transitive.  I assumed
> that this also applied to it's dependencies, so my question is if I
> declare a dependency on a project at test scope, that project's
> dependencies should
> all be included at test scope.  For example, given the following
> project(s)
> 
> Project test-utils defines a junit dependency like such:
> 
> 
> junit
> junit
> 
> 
> Project application defines a dependency on test-utils with a scope of
> test like such
> 
> ${project.groupId}
> test-utils
> ${project.version}
> test
> 
> 
> Now running mvn clean dependency:tree shows that the junit dependency is
> being passed to the application project at compile scope which is not
> expected.
> 
> [INFO] --- maven-dependency-plugin:2.7:tree (default-cli) @ application
> [--- INFO] org.sandbox:application:war:1.0.0-SNAPSHOT
> 
> [INFO] \- org.sandbox:test-utils:jar:1.0.0-SNAPSHOT:test
> [INFO]+- junit:junit:jar:4.8.2:compile
> [INFO]+- org.mockito:mockito-all:jar:1.8.5:test
> [INFO]+- com.h2database:h2:jar:1.3.165:test
> [INFO]\- log4j:log4j:jar:1.2.16:test
> 
> 
> Is this a bug or was my interpretation of the transitive dependency logic
> incorrect?
> 
> Thank you for your time.

Actually I was fooled by such an output with M3 in one of my projects at 
first sight also.

So, please make a test: Comment out the org.sandbox:test-utils in your POM 
and print the tree again. I am quite sure that you will see that junit:junit 
is now introduced by a different dependency that is not of test scope. What 
you see above is only the result of the dependency resolver. It detected 
that it already has a junit:junit in its transitive deps in compile scope 
(maybe even in a different version), but the "nearest" path to junit was as 
direct child of org.sandbox:test-utils. Therefor it was "promoted" to 
compile scope in this place, but the overall result of the compilation 
classpath is still OK, it is only the displayed tree that is somewhat 
inconsistent (compared to M2).

- Jörg


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

Re: Transitive Dependency Question

[Jamal B]

Hi, thanks for your response.

Running dependency:list shows also shows that junit is at compile scope
which I expected to be at test scope.

[INFO] --- maven-dependency-plugin:2.7:list (default-cli) @ application ---
[INFO]
[INFO] The following files have been resolved:

[INFO]junit:junit:jar:4.8.2:compile

So is it a correct statement that the base scope of a dependency is fixed
regardless of the declared scope of the outer dependency?  This appears to
be the behavior, but I am not sure that this is correct.


On Mon, Jun 3, 2013 at 1:53 PM, Baptiste MATHUS  wrote:

> Hi,
> Tree is showing the tree. So it seems correct at first sight. Its showing
> you the dependency beetween your test-utils of the project and junit which
> is in fact scope compile.
>
> What you seem to actually want to have is the resolved list of dependencies
> for your application project.
> That goal is called dependency:list.
>
> Hope this helps.
>
> Cheers
>
> -- Baptiste
> Le 3 juin 2013 19:21, "Jamal B"  a écrit :
>
> > Hello, I have a question about transitive dependencies.  According to the
> > pom documentation here: http://maven.apache.org/pom.html#Dependencies
> >
> > project dependencies marked with test scope are not transitive.  I
> assumed
> > that this also applied to it's dependencies, so my question is if I
> declare
> > a dependency on a project at test scope, that project's dependencies
> should
> > all be included at test scope.  For example, given the following
> project(s)
> >
> > Project test-utils defines a junit dependency like such:
> >
> > 
> > junit
> > junit
> > 
> >
> > Project application defines a dependency on test-utils with a scope of
> test
> > like such
> > 
> > ${project.groupId}
> > test-utils
> > ${project.version}
> > test
> > 
> >
> > Now running mvn clean dependency:tree shows that the junit dependency is
> > being passed to the application project at compile scope which is not
> > expected.
> >
> > [INFO] --- maven-dependency-plugin:2.7:tree (default-cli) @ application
> ---
> > [INFO] org.sandbox:application:war:1.0.0-SNAPSHOT
> > 
> > [INFO] \- org.sandbox:test-utils:jar:1.0.0-SNAPSHOT:test
> > [INFO]+- junit:junit:jar:4.8.2:compile
> > [INFO]+- org.mockito:mockito-all:jar:1.8.5:test
> > [INFO]+- com.h2database:h2:jar:1.3.165:test
> > [INFO]\- log4j:log4j:jar:1.2.16:test
> >
> >
> > Is this a bug or was my interpretation of the transitive dependency logic
> > incorrect?
> >
> > Thank you for your time.
> >
>

Re: Transitive Dependency Question

[Baptiste MATHUS]

Hi,
Tree is showing the tree. So it seems correct at first sight. Its showing
you the dependency beetween your test-utils of the project and junit which
is in fact scope compile.

What you seem to actually want to have is the resolved list of dependencies
for your application project.
That goal is called dependency:list.

Hope this helps.

Cheers

-- Baptiste
Le 3 juin 2013 19:21, "Jamal B"  a écrit :

> Hello, I have a question about transitive dependencies.  According to the
> pom documentation here: http://maven.apache.org/pom.html#Dependencies
>
> project dependencies marked with test scope are not transitive.  I assumed
> that this also applied to it's dependencies, so my question is if I declare
> a dependency on a project at test scope, that project's dependencies should
> all be included at test scope.  For example, given the following project(s)
>
> Project test-utils defines a junit dependency like such:
>
> 
> junit
> junit
> 
>
> Project application defines a dependency on test-utils with a scope of test
> like such
> 
> ${project.groupId}
> test-utils
> ${project.version}
> test
> 
>
> Now running mvn clean dependency:tree shows that the junit dependency is
> being passed to the application project at compile scope which is not
> expected.
>
> [INFO] --- maven-dependency-plugin:2.7:tree (default-cli) @ application ---
> [INFO] org.sandbox:application:war:1.0.0-SNAPSHOT
> 
> [INFO] \- org.sandbox:test-utils:jar:1.0.0-SNAPSHOT:test
> [INFO]+- junit:junit:jar:4.8.2:compile
> [INFO]+- org.mockito:mockito-all:jar:1.8.5:test
> [INFO]+- com.h2database:h2:jar:1.3.165:test
> [INFO]\- log4j:log4j:jar:1.2.16:test
>
>
> Is this a bug or was my interpretation of the transitive dependency logic
> incorrect?
>
> Thank you for your time.
>

Transitive Dependency Question

[Jamal B]

Hello, I have a question about transitive dependencies.  According to the
pom documentation here: http://maven.apache.org/pom.html#Dependencies

project dependencies marked with test scope are not transitive.  I assumed
that this also applied to it's dependencies, so my question is if I declare
a dependency on a project at test scope, that project's dependencies should
all be included at test scope.  For example, given the following project(s)

Project test-utils defines a junit dependency like such:


junit
junit


Project application defines a dependency on test-utils with a scope of test
like such

${project.groupId}
test-utils
${project.version}
test


Now running mvn clean dependency:tree shows that the junit dependency is
being passed to the application project at compile scope which is not
expected.

[INFO] --- maven-dependency-plugin:2.7:tree (default-cli) @ application ---
[INFO] org.sandbox:application:war:1.0.0-SNAPSHOT

[INFO] \- org.sandbox:test-utils:jar:1.0.0-SNAPSHOT:test
[INFO]+- junit:junit:jar:4.8.2:compile
[INFO]+- org.mockito:mockito-all:jar:1.8.5:test
[INFO]+- com.h2database:h2:jar:1.3.165:test
[INFO]\- log4j:log4j:jar:1.2.16:test


Is this a bug or was my interpretation of the transitive dependency logic
incorrect?

Thank you for your time.

Re: A maven/nexus repos manager/missing dependency question

[Quintin Beukes]

>    
>        
>            
>                org.apache.maven.plugins
>                maven-javadoc-plugin
>            
>        
>    
> 
>
> That is the only plugin specified in my pom.  The plugin that looks to be
> causing the problem is a maven plugin (the maven-project-info-reports-plugin)
> that is being used by the site build phase, but I could be wrong in my
> interpretation of the error trace in my original message.  Is there a place
> (or even a reason) that I should be placing a dependency for such a plugin
> for the site build phase?

I'm not so sure that's the plugin causing the problem (at least not
directly). the javadoc-plugin has commons-lang as a dependency.

Have a look at:
http://maven.apache.org/plugins/maven-project-info-reports-plugin/dependencies.html
http://maven.apache.org/plugins/maven-javadoc-plugin/dependencies.html

Just try to add the  tag to the  tag in your
excerpt above.

It doesn't feel right, I know. I was under the impression maven would
have to manage these things itself, though I have seen those elements
being added. I'm farely new to maven myself so haven't done more
research on this since.

Q

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

Re: A maven/nexus repos manager/missing dependency question

[Sean Davis]

On Mon, Oct 19, 2009 at 6:46 AM, Quintin Beukes wrote:

> You should add it to the plugin's dependencies.
>
> Here is an example extract from one of my POMs (the irrelevant bits
> removed):
>
>  
>.
>
>  
>org.apache.maven.surefire
>surefire-api
>2.4.3
>  
>
>  
>
>
Thanks, Quentin.  Here is the extract from my pom.




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





That is the only plugin specified in my pom.  The plugin that looks to be
causing the problem is a maven plugin (the maven-project-info-reports-plugin)
that is being used by the site build phase, but I could be wrong in my
interpretation of the error trace in my original message.  Is there a place
(or even a reason) that I should be placing a dependency for such a plugin
for the site build phase?

Sean



> On Mon, Oct 19, 2009 at 12:43 PM, Sean Davis  wrote:
> > On Mon, Oct 19, 2009 at 5:15 AM, Quintin Beukes  >wrote:
> >
> >> Try adding the commons-lang dependency.
> >>
> >>
> > Thanks, Quintin.  However, it appears that this dependency is arising in
> a
> > maven plugin, if I understand things correctly?  So, adding the
> dependency
> > to my own pom won't have an effect on the build process, will it?
> >
> > Sean
> >
> >
> >
> >> On Sun, Oct 18, 2009 at 10:34 PM, Sean Davis 
> wrote:
> >> > I have been using maven pretty successfully for low-end java
> >> > programming--I'm not much of a developer.  I have finally convinced a
> few
> >> > folks to potentially work with me on some projects at work and thought
> >> > setting up a repository manager would be a good idea.  The nexus setup
> >> > pretty simple and I changed my settings.xml to include a mirror to the
> >> local
> >> > nexus installation (version 1.3.6, open source).  I can see artifacts
> >> moving
> >> > into the cache just fine as they are used in builds.
> >> >
> >> > I have a project that I have been building fine until the above
> process
> >> was
> >> > completed.  Now, during site building under m2eclipse, I get the error
> >> > below.  Any suggestions on what needs to change?  It appears that
> >> > commons-lang is not being picked up as a dependency?
> >> >
> >> > Thanks,
> >> > Sean
> >> >
> >> >
> >> >
> >> > [ERROR]
> >> >
> org.apache.maven.report.projectinfo.DependencyConvergenceReport#execute()
> >> > caused a linkage error (java.lang.NoClassDefFoundError). Check the
> >> realms:
> >> >
> >> > NOTE:
> >> > Plugin realm is:
> >> >
> >>
> /plugins/org.apache.maven.plugins:maven-project-info-reports-plugin:2@48
> >> > /thread:main
> >> > Container realm is: plexus.core
> >> >
> >> > Realm ID:
> >> >
> >>
> /plugins/org.apache.maven.plugins:maven-project-info-reports-plugin:2@48
> >> > /thread:main
> >> >  CUT 
> >> > java.lang.NoClassDefFoundError: org/apache/commons/lang/StringUtils
> >> >at
> >> >
> >>
> org.apache.velocity.runtime.resource.ResourceManagerImpl.initialize(ResourceManagerImpl.java:165)
> >> >at
> >> >
> >>
> org.apache.velocity.runtime.RuntimeInstance.initializeResourceManager(RuntimeInstance.java:594)
> >> >at
> >> >
> >>
> org.apache.velocity.runtime.RuntimeInstance.init(RuntimeInstance.java:241)
> >> >at
> >> org.apache.velocity.app.VelocityEngine.init(VelocityEngine.java:116)
> >> >at
> >> >
> >>
> org.codehaus.plexus.velocity.DefaultVelocityComponent.initialize(DefaultVelocityComponent.java:95)
> >> >at
> >> >
> >>
> org.codehaus.plexus.personality.plexus.lifecycle.phase.InitializePhase.execute(InitializePhase.java:33)
> >> >at
> >> >
> >>
> org.codehaus.plexus.lifecycle.AbstractLifecycleHandler.start(AbstractLifecycleHandler.java:97)
> >> >at
> >> >
> >>
> org.codehaus.plexus.component.manager.AbstractComponentManager.startComponentLifecycle(AbstractComponentManager.java:139)
> >> >at
> >> >
> >>
> org.codehaus.plexus.component.manager.AbstractComponentManager.createComponentInstance(AbstractComponentManager.java:129)
> >> >at
> >> >
> >>
> org.codehaus.plexus.component.manager.ClassicSingletonComponentManager.getComponent(ClassicSingletonComponentManager.java:96)
> >> >at
> >> >
> >>
> org.codehaus.plexus.DefaultComponentLookupManager.lookup(DefaultComponentLookupManager.java:147)
> >> >at
> >> >
> >>
> org.codehaus.plexus.DefaultPlexusContainer.lookup(DefaultPlexusContainer.java:491)
> >> >at
> >> >
> >>
> org.codehaus.plexus.component.composition.AbstractComponentComposer.findRequirement(AbstractComponentComposer.java:214)
> >> >at
> >> >
> >>
> org.codehaus.plexus.component.composition.FieldComponentComposer.assignRequirementToField(FieldComponentComposer.java:72)
> >> >at
> >> >
> >>
> org.codehaus.plexus.component.composition.FieldComponentComposer.assignRequirement(FieldComponentComposer.java:62)
> >> >at
> >> >
> >>
> org.codehaus.plexus.component.composition.AbstractComponentComposer.assem

Re: A maven/nexus repos manager/missing dependency question

[Quintin Beukes]

You should add it to the plugin's dependencies.

Here is an example extract from one of my POMs (the irrelevant bits removed):

  
.

  
org.apache.maven.surefire
surefire-api
2.4.3
  

  

Quintin Beukes



On Mon, Oct 19, 2009 at 12:43 PM, Sean Davis  wrote:
> On Mon, Oct 19, 2009 at 5:15 AM, Quintin Beukes wrote:
>
>> Try adding the commons-lang dependency.
>>
>>
> Thanks, Quintin.  However, it appears that this dependency is arising in a
> maven plugin, if I understand things correctly?  So, adding the dependency
> to my own pom won't have an effect on the build process, will it?
>
> Sean
>
>
>
>> On Sun, Oct 18, 2009 at 10:34 PM, Sean Davis  wrote:
>> > I have been using maven pretty successfully for low-end java
>> > programming--I'm not much of a developer.  I have finally convinced a few
>> > folks to potentially work with me on some projects at work and thought
>> > setting up a repository manager would be a good idea.  The nexus setup
>> > pretty simple and I changed my settings.xml to include a mirror to the
>> local
>> > nexus installation (version 1.3.6, open source).  I can see artifacts
>> moving
>> > into the cache just fine as they are used in builds.
>> >
>> > I have a project that I have been building fine until the above process
>> was
>> > completed.  Now, during site building under m2eclipse, I get the error
>> > below.  Any suggestions on what needs to change?  It appears that
>> > commons-lang is not being picked up as a dependency?
>> >
>> > Thanks,
>> > Sean
>> >
>> >
>> >
>> > [ERROR]
>> > org.apache.maven.report.projectinfo.DependencyConvergenceReport#execute()
>> > caused a linkage error (java.lang.NoClassDefFoundError). Check the
>> realms:
>> >
>> > NOTE:
>> > Plugin realm is:
>> >
>> /plugins/org.apache.maven.plugins:maven-project-info-reports-plugin:2@48
>> > /thread:main
>> > Container realm is: plexus.core
>> >
>> > Realm ID:
>> >
>> /plugins/org.apache.maven.plugins:maven-project-info-reports-plugin:2@48
>> > /thread:main
>> >  CUT 
>> > java.lang.NoClassDefFoundError: org/apache/commons/lang/StringUtils
>> >    at
>> >
>> org.apache.velocity.runtime.resource.ResourceManagerImpl.initialize(ResourceManagerImpl.java:165)
>> >    at
>> >
>> org.apache.velocity.runtime.RuntimeInstance.initializeResourceManager(RuntimeInstance.java:594)
>> >    at
>> >
>> org.apache.velocity.runtime.RuntimeInstance.init(RuntimeInstance.java:241)
>> >    at
>> org.apache.velocity.app.VelocityEngine.init(VelocityEngine.java:116)
>> >    at
>> >
>> org.codehaus.plexus.velocity.DefaultVelocityComponent.initialize(DefaultVelocityComponent.java:95)
>> >    at
>> >
>> org.codehaus.plexus.personality.plexus.lifecycle.phase.InitializePhase.execute(InitializePhase.java:33)
>> >    at
>> >
>> org.codehaus.plexus.lifecycle.AbstractLifecycleHandler.start(AbstractLifecycleHandler.java:97)
>> >    at
>> >
>> org.codehaus.plexus.component.manager.AbstractComponentManager.startComponentLifecycle(AbstractComponentManager.java:139)
>> >    at
>> >
>> org.codehaus.plexus.component.manager.AbstractComponentManager.createComponentInstance(AbstractComponentManager.java:129)
>> >    at
>> >
>> org.codehaus.plexus.component.manager.ClassicSingletonComponentManager.getComponent(ClassicSingletonComponentManager.java:96)
>> >    at
>> >
>> org.codehaus.plexus.DefaultComponentLookupManager.lookup(DefaultComponentLookupManager.java:147)
>> >    at
>> >
>> org.codehaus.plexus.DefaultPlexusContainer.lookup(DefaultPlexusContainer.java:491)
>> >    at
>> >
>> org.codehaus.plexus.component.composition.AbstractComponentComposer.findRequirement(AbstractComponentComposer.java:214)
>> >    at
>> >
>> org.codehaus.plexus.component.composition.FieldComponentComposer.assignRequirementToField(FieldComponentComposer.java:72)
>> >    at
>> >
>> org.codehaus.plexus.component.composition.FieldComponentComposer.assignRequirement(FieldComponentComposer.java:62)
>> >    at
>> >
>> org.codehaus.plexus.component.composition.AbstractComponentComposer.assembleComponent(AbstractComponentComposer.java:99)
>> >    at
>> >
>> org.codehaus.plexus.component.composition.DefaultComponentComposerManager.assembleComponent(DefaultComponentComposerManager.java:76)
>> >    at
>> >
>> org.codehaus.plexus.personality.plexus.lifecycle.phase.CompositionPhase.execute(CompositionPhase.java:46)
>> >    at
>> >
>> org.codehaus.plexus.lifecycle.AbstractLifecycleHandler.start(AbstractLifecycleHandler.java:97)
>> >    at
>> >
>> org.codehaus.plexus.component.manager.AbstractComponentManager.startComponentLifecycle(AbstractComponentManager.java:139)
>> >    at
>> >
>> org.codehaus.plexus.component.manager.AbstractComponentManager.createComponentInstance(AbstractComponentManager.java:129)
>> >    at
>> >
>> org.codehaus.plexus.component.manager.ClassicSingletonComponentManager.getComponent(ClassicSingletonComponentManager.java:96)
>> >    at
>> >
>> org.codehaus.plexus

Re: A maven/nexus repos manager/missing dependency question

[Sean Davis]

On Mon, Oct 19, 2009 at 5:15 AM, Quintin Beukes wrote:

> Try adding the commons-lang dependency.
>
>
Thanks, Quintin.  However, it appears that this dependency is arising in a
maven plugin, if I understand things correctly?  So, adding the dependency
to my own pom won't have an effect on the build process, will it?

Sean



> On Sun, Oct 18, 2009 at 10:34 PM, Sean Davis  wrote:
> > I have been using maven pretty successfully for low-end java
> > programming--I'm not much of a developer.  I have finally convinced a few
> > folks to potentially work with me on some projects at work and thought
> > setting up a repository manager would be a good idea.  The nexus setup
> > pretty simple and I changed my settings.xml to include a mirror to the
> local
> > nexus installation (version 1.3.6, open source).  I can see artifacts
> moving
> > into the cache just fine as they are used in builds.
> >
> > I have a project that I have been building fine until the above process
> was
> > completed.  Now, during site building under m2eclipse, I get the error
> > below.  Any suggestions on what needs to change?  It appears that
> > commons-lang is not being picked up as a dependency?
> >
> > Thanks,
> > Sean
> >
> >
> >
> > [ERROR]
> > org.apache.maven.report.projectinfo.DependencyConvergenceReport#execute()
> > caused a linkage error (java.lang.NoClassDefFoundError). Check the
> realms:
> >
> > NOTE:
> > Plugin realm is:
> >
> /plugins/org.apache.maven.plugins:maven-project-info-reports-plugin:2@48
> > /thread:main
> > Container realm is: plexus.core
> >
> > Realm ID:
> >
> /plugins/org.apache.maven.plugins:maven-project-info-reports-plugin:2@48
> > /thread:main
> >  CUT 
> > java.lang.NoClassDefFoundError: org/apache/commons/lang/StringUtils
> >at
> >
> org.apache.velocity.runtime.resource.ResourceManagerImpl.initialize(ResourceManagerImpl.java:165)
> >at
> >
> org.apache.velocity.runtime.RuntimeInstance.initializeResourceManager(RuntimeInstance.java:594)
> >at
> >
> org.apache.velocity.runtime.RuntimeInstance.init(RuntimeInstance.java:241)
> >at
> org.apache.velocity.app.VelocityEngine.init(VelocityEngine.java:116)
> >at
> >
> org.codehaus.plexus.velocity.DefaultVelocityComponent.initialize(DefaultVelocityComponent.java:95)
> >at
> >
> org.codehaus.plexus.personality.plexus.lifecycle.phase.InitializePhase.execute(InitializePhase.java:33)
> >at
> >
> org.codehaus.plexus.lifecycle.AbstractLifecycleHandler.start(AbstractLifecycleHandler.java:97)
> >at
> >
> org.codehaus.plexus.component.manager.AbstractComponentManager.startComponentLifecycle(AbstractComponentManager.java:139)
> >at
> >
> org.codehaus.plexus.component.manager.AbstractComponentManager.createComponentInstance(AbstractComponentManager.java:129)
> >at
> >
> org.codehaus.plexus.component.manager.ClassicSingletonComponentManager.getComponent(ClassicSingletonComponentManager.java:96)
> >at
> >
> org.codehaus.plexus.DefaultComponentLookupManager.lookup(DefaultComponentLookupManager.java:147)
> >at
> >
> org.codehaus.plexus.DefaultPlexusContainer.lookup(DefaultPlexusContainer.java:491)
> >at
> >
> org.codehaus.plexus.component.composition.AbstractComponentComposer.findRequirement(AbstractComponentComposer.java:214)
> >at
> >
> org.codehaus.plexus.component.composition.FieldComponentComposer.assignRequirementToField(FieldComponentComposer.java:72)
> >at
> >
> org.codehaus.plexus.component.composition.FieldComponentComposer.assignRequirement(FieldComponentComposer.java:62)
> >at
> >
> org.codehaus.plexus.component.composition.AbstractComponentComposer.assembleComponent(AbstractComponentComposer.java:99)
> >at
> >
> org.codehaus.plexus.component.composition.DefaultComponentComposerManager.assembleComponent(DefaultComponentComposerManager.java:76)
> >at
> >
> org.codehaus.plexus.personality.plexus.lifecycle.phase.CompositionPhase.execute(CompositionPhase.java:46)
> >at
> >
> org.codehaus.plexus.lifecycle.AbstractLifecycleHandler.start(AbstractLifecycleHandler.java:97)
> >at
> >
> org.codehaus.plexus.component.manager.AbstractComponentManager.startComponentLifecycle(AbstractComponentManager.java:139)
> >at
> >
> org.codehaus.plexus.component.manager.AbstractComponentManager.createComponentInstance(AbstractComponentManager.java:129)
> >at
> >
> org.codehaus.plexus.component.manager.ClassicSingletonComponentManager.getComponent(ClassicSingletonComponentManager.java:96)
> >at
> >
> org.codehaus.plexus.DefaultComponentLookupManager.lookup(DefaultComponentLookupManager.java:147)
> >at
> >
> org.codehaus.plexus.DefaultPlexusContainer.lookup(DefaultPlexusContainer.java:491)
> >at
> >
> org.codehaus.plexus.component.composition.AbstractComponentComposer.findRequirement(AbstractComponentComposer.java:214)
> >at
> >
> org.codehaus.plexus.component.composition.FieldComponentComposer.assignRequirementToField(FieldComponentComposer.java:72)
> >at
> >
> org.code

Re: A maven/nexus repos manager/missing dependency question

[Quintin Beukes]

Try adding the commons-lang dependency.

Quintin Beukes



On Sun, Oct 18, 2009 at 10:34 PM, Sean Davis  wrote:
> I have been using maven pretty successfully for low-end java
> programming--I'm not much of a developer.  I have finally convinced a few
> folks to potentially work with me on some projects at work and thought
> setting up a repository manager would be a good idea.  The nexus setup
> pretty simple and I changed my settings.xml to include a mirror to the local
> nexus installation (version 1.3.6, open source).  I can see artifacts moving
> into the cache just fine as they are used in builds.
>
> I have a project that I have been building fine until the above process was
> completed.  Now, during site building under m2eclipse, I get the error
> below.  Any suggestions on what needs to change?  It appears that
> commons-lang is not being picked up as a dependency?
>
> Thanks,
> Sean
>
>
>
> [ERROR]
> org.apache.maven.report.projectinfo.DependencyConvergenceReport#execute()
> caused a linkage error (java.lang.NoClassDefFoundError). Check the realms:
>
> NOTE:
> Plugin realm is:
> /plugins/org.apache.maven.plugins:maven-project-info-reports-plugin:2@48
> /thread:main
> Container realm is: plexus.core
>
> Realm ID:
> /plugins/org.apache.maven.plugins:maven-project-info-reports-plugin:2@48
> /thread:main
>  CUT 
> java.lang.NoClassDefFoundError: org/apache/commons/lang/StringUtils
>    at
> org.apache.velocity.runtime.resource.ResourceManagerImpl.initialize(ResourceManagerImpl.java:165)
>    at
> org.apache.velocity.runtime.RuntimeInstance.initializeResourceManager(RuntimeInstance.java:594)
>    at
> org.apache.velocity.runtime.RuntimeInstance.init(RuntimeInstance.java:241)
>    at org.apache.velocity.app.VelocityEngine.init(VelocityEngine.java:116)
>    at
> org.codehaus.plexus.velocity.DefaultVelocityComponent.initialize(DefaultVelocityComponent.java:95)
>    at
> org.codehaus.plexus.personality.plexus.lifecycle.phase.InitializePhase.execute(InitializePhase.java:33)
>    at
> org.codehaus.plexus.lifecycle.AbstractLifecycleHandler.start(AbstractLifecycleHandler.java:97)
>    at
> org.codehaus.plexus.component.manager.AbstractComponentManager.startComponentLifecycle(AbstractComponentManager.java:139)
>    at
> org.codehaus.plexus.component.manager.AbstractComponentManager.createComponentInstance(AbstractComponentManager.java:129)
>    at
> org.codehaus.plexus.component.manager.ClassicSingletonComponentManager.getComponent(ClassicSingletonComponentManager.java:96)
>    at
> org.codehaus.plexus.DefaultComponentLookupManager.lookup(DefaultComponentLookupManager.java:147)
>    at
> org.codehaus.plexus.DefaultPlexusContainer.lookup(DefaultPlexusContainer.java:491)
>    at
> org.codehaus.plexus.component.composition.AbstractComponentComposer.findRequirement(AbstractComponentComposer.java:214)
>    at
> org.codehaus.plexus.component.composition.FieldComponentComposer.assignRequirementToField(FieldComponentComposer.java:72)
>    at
> org.codehaus.plexus.component.composition.FieldComponentComposer.assignRequirement(FieldComponentComposer.java:62)
>    at
> org.codehaus.plexus.component.composition.AbstractComponentComposer.assembleComponent(AbstractComponentComposer.java:99)
>    at
> org.codehaus.plexus.component.composition.DefaultComponentComposerManager.assembleComponent(DefaultComponentComposerManager.java:76)
>    at
> org.codehaus.plexus.personality.plexus.lifecycle.phase.CompositionPhase.execute(CompositionPhase.java:46)
>    at
> org.codehaus.plexus.lifecycle.AbstractLifecycleHandler.start(AbstractLifecycleHandler.java:97)
>    at
> org.codehaus.plexus.component.manager.AbstractComponentManager.startComponentLifecycle(AbstractComponentManager.java:139)
>    at
> org.codehaus.plexus.component.manager.AbstractComponentManager.createComponentInstance(AbstractComponentManager.java:129)
>    at
> org.codehaus.plexus.component.manager.ClassicSingletonComponentManager.getComponent(ClassicSingletonComponentManager.java:96)
>    at
> org.codehaus.plexus.DefaultComponentLookupManager.lookup(DefaultComponentLookupManager.java:147)
>    at
> org.codehaus.plexus.DefaultPlexusContainer.lookup(DefaultPlexusContainer.java:491)
>    at
> org.codehaus.plexus.component.composition.AbstractComponentComposer.findRequirement(AbstractComponentComposer.java:214)
>    at
> org.codehaus.plexus.component.composition.FieldComponentComposer.assignRequirementToField(FieldComponentComposer.java:72)
>    at
> org.codehaus.plexus.component.composition.FieldComponentComposer.assignRequirement(FieldComponentComposer.java:62)
>    at
> org.codehaus.plexus.component.composition.AbstractComponentComposer.assembleComponent(AbstractComponentComposer.java:99)
>    at
> org.codehaus.plexus.component.composition.DefaultComponentComposerManager.assembleComponent(DefaultComponentComposerManager.java:76)
>    at
> org.codehaus.plexus.personality.plexus.lifecycle.phase.CompositionPhase.execute(CompositionPhase.java:46)
>    at
> o

A maven/nexus repos manager/missing dependency question

[Sean Davis]

I have been using maven pretty successfully for low-end java
programming--I'm not much of a developer.  I have finally convinced a few
folks to potentially work with me on some projects at work and thought
setting up a repository manager would be a good idea.  The nexus setup
pretty simple and I changed my settings.xml to include a mirror to the local
nexus installation (version 1.3.6, open source).  I can see artifacts moving
into the cache just fine as they are used in builds.

I have a project that I have been building fine until the above process was
completed.  Now, during site building under m2eclipse, I get the error
below.  Any suggestions on what needs to change?  It appears that
commons-lang is not being picked up as a dependency?

Thanks,
Sean



[ERROR]
org.apache.maven.report.projectinfo.DependencyConvergenceReport#execute()
caused a linkage error (java.lang.NoClassDefFoundError). Check the realms:

NOTE:
Plugin realm is:
/plugins/org.apache.maven.plugins:maven-project-info-reports-plugin:2@48
/thread:main
Container realm is: plexus.core

Realm ID:
/plugins/org.apache.maven.plugins:maven-project-info-reports-plugin:2@48
/thread:main
 CUT 
java.lang.NoClassDefFoundError: org/apache/commons/lang/StringUtils
at
org.apache.velocity.runtime.resource.ResourceManagerImpl.initialize(ResourceManagerImpl.java:165)
at
org.apache.velocity.runtime.RuntimeInstance.initializeResourceManager(RuntimeInstance.java:594)
at
org.apache.velocity.runtime.RuntimeInstance.init(RuntimeInstance.java:241)
at org.apache.velocity.app.VelocityEngine.init(VelocityEngine.java:116)
at
org.codehaus.plexus.velocity.DefaultVelocityComponent.initialize(DefaultVelocityComponent.java:95)
at
org.codehaus.plexus.personality.plexus.lifecycle.phase.InitializePhase.execute(InitializePhase.java:33)
at
org.codehaus.plexus.lifecycle.AbstractLifecycleHandler.start(AbstractLifecycleHandler.java:97)
at
org.codehaus.plexus.component.manager.AbstractComponentManager.startComponentLifecycle(AbstractComponentManager.java:139)
at
org.codehaus.plexus.component.manager.AbstractComponentManager.createComponentInstance(AbstractComponentManager.java:129)
at
org.codehaus.plexus.component.manager.ClassicSingletonComponentManager.getComponent(ClassicSingletonComponentManager.java:96)
at
org.codehaus.plexus.DefaultComponentLookupManager.lookup(DefaultComponentLookupManager.java:147)
at
org.codehaus.plexus.DefaultPlexusContainer.lookup(DefaultPlexusContainer.java:491)
at
org.codehaus.plexus.component.composition.AbstractComponentComposer.findRequirement(AbstractComponentComposer.java:214)
at
org.codehaus.plexus.component.composition.FieldComponentComposer.assignRequirementToField(FieldComponentComposer.java:72)
at
org.codehaus.plexus.component.composition.FieldComponentComposer.assignRequirement(FieldComponentComposer.java:62)
at
org.codehaus.plexus.component.composition.AbstractComponentComposer.assembleComponent(AbstractComponentComposer.java:99)
at
org.codehaus.plexus.component.composition.DefaultComponentComposerManager.assembleComponent(DefaultComponentComposerManager.java:76)
at
org.codehaus.plexus.personality.plexus.lifecycle.phase.CompositionPhase.execute(CompositionPhase.java:46)
at
org.codehaus.plexus.lifecycle.AbstractLifecycleHandler.start(AbstractLifecycleHandler.java:97)
at
org.codehaus.plexus.component.manager.AbstractComponentManager.startComponentLifecycle(AbstractComponentManager.java:139)
at
org.codehaus.plexus.component.manager.AbstractComponentManager.createComponentInstance(AbstractComponentManager.java:129)
at
org.codehaus.plexus.component.manager.ClassicSingletonComponentManager.getComponent(ClassicSingletonComponentManager.java:96)
at
org.codehaus.plexus.DefaultComponentLookupManager.lookup(DefaultComponentLookupManager.java:147)
at
org.codehaus.plexus.DefaultPlexusContainer.lookup(DefaultPlexusContainer.java:491)
at
org.codehaus.plexus.component.composition.AbstractComponentComposer.findRequirement(AbstractComponentComposer.java:214)
at
org.codehaus.plexus.component.composition.FieldComponentComposer.assignRequirementToField(FieldComponentComposer.java:72)
at
org.codehaus.plexus.component.composition.FieldComponentComposer.assignRequirement(FieldComponentComposer.java:62)
at
org.codehaus.plexus.component.composition.AbstractComponentComposer.assembleComponent(AbstractComponentComposer.java:99)
at
org.codehaus.plexus.component.composition.DefaultComponentComposerManager.assembleComponent(DefaultComponentComposerManager.java:76)
at
org.codehaus.plexus.personality.plexus.lifecycle.phase.CompositionPhase.execute(CompositionPhase.java:46)
at
org.codehaus.plexus.lifecycle.AbstractLifecycleHandler.start(AbstractLifecycleHandler.java:97)
at
org.codehaus.plexus.component.manager.AbstractComponentManager.startComponentLifecycle(AbstractComponentManager.java:139)
at
org.codehaus.plexus.component.ma

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

[Stephen Connolly]

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

2009/3/4 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 
> >
> >>
> >> 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

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

[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

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

[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 

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

[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

[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

Dependency question

[stanlick]

Hey guys -- 

I am trying to build a tool for the lawyers that will reveal a dependency
tree of all downstream products necessary when considering adoption of an
open source product.  For the sake of illustration, I have created a simple
project with a single dependency on Struts 2.




  org.apache.struts
  struts2-core
  2.1.6

  



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?

C:\Users\scott\MavenApps\appStats-app>mvn dependency:tree
[INFO] Scanning for projects...
[INFO] Searching repository for plugin with prefix: 'dependency'.
[INFO]

[INFO] Building appStats-app
[INFO]task-segment: [dependency:tree]
[INFO]

[INFO] [dependency:tree]
[INFO] com.acme.appStats:appStats-app:jar:1.0-SNAPSHOT
[INFO] +- junit:junit:jar:3.8.1:test (scope not updated to compile)
[INFO] \- org.apache.struts:struts2-core:jar:2.1.6:compile
[INFO]+- com.opensymphony:xwork:jar:2.1.2:compile
[INFO]|  \- org.springframework:spring-test:jar:2.5.6:compile
[INFO]| \- commons-logging:commons-logging:jar:1.1.1:compile
[INFO]+- org.freemarker:freemarker:jar:2.3.13:compile
[INFO]+- opensymphony:ognl:jar:2.6.11:compile
[INFO]+- commons-fileupload:commons-fileupload:jar:1.2.1:compile
[INFO]+- commons-io:commons-io:jar:1.3.2:compile
[INFO]\- com.sun:tools:jar:1.5.0:system
[INFO]

[INFO] BUILD SUCCESSFUL
[INFO]

[INFO] Total time: 6 seconds
[INFO] Finished at: Tue Mar 03 12:57:53 CST 2009
[INFO] Final Memory: 10M/20M
[INFO]


Peace,
Scott
-- 
View this message in context: 
http://www.nabble.com/Dependency-question-tp22315314p22315314.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: reporting plugin dependency question

[Mark Struberg]

And I apologies for obviously searching not good enough in Jira - so thank you 
for finding the bug for me :)

--- Adam Leggett  schrieb am Do, 8.1.2009:

> Von: Adam Leggett 
> Betreff: RE: reporting plugin dependency question
> An: "Maven Users List" 
> Datum: Donnerstag, 8. Januar 2009, 17:13
> Apologies Mark, I seem to have not read all the way to the
> bottom of
> your mail :).
> 
> Looks like this is an issue already -
> http://jira.codehaus.org/browse/MNG-1948, roadmapped for
> 3.x
> 
> Adam
> 
> 
> -Original Message-
> From: Mark Struberg [mailto:strub...@yahoo.de] 
> Sent: 08 January 2009 15:04
> To: Maven Users List
> Subject: RE: reporting plugin dependency question
> 
> Yup Adam, that's exactly what I'm doing currently.
> 
> I just wonder if not being able to specify dependencies in
> the reporting
> section is so by design (and there is a good reason for
> this), or if
> this is something we may improve in maven-3.0.
> 
> txs and LieGrue,
> strub
> 
> "Multiple exclamation marks are a sure sign of a
> diseased mind!" 
> (Sir Terry Pratchett)
> 
> 
> --- Adam Leggett  schrieb am
> Do, 8.1.2009:
> 
> > Von: Adam Leggett 
> > Betreff: RE: reporting plugin dependency question
> > An: "Maven Users List"
> 
> > Datum: Donnerstag, 8. Januar 2009, 15:56
> > I think you need to specify the dependency within the
> >  section of
> > the pom and then reference in the reporting section:
> > 
> > 
> > 
> >   
> >
> >
> org.apache.maven.plugins
> >
> >
> maven-checkstyle-plugin
> > 
> >   
> >
> > com.example.whizbang
> >
> > build-tools
> > 1.0
> >   
> > 
> >   
> > 
> >   
> >   
> > 
> >   
> >
> >
> org.apache.maven.plugins
> >
> >
> maven-checkstyle-plugin
> > 
> >  
> >
> whizbang/checkstyle.xml
> >  
> >
> whizbang/LICENSE.txt
> > 
> >   
> > 
> >   
> > 
> >
> http://maven.apache.org/plugins/maven-checkstyle-plugin/examples/multi-m
> > odule-config.html
> > 
> > -Original Message-
> > From: Mark Struberg [mailto:strub...@yahoo.de] 
> > Sent: 08 January 2009 14:46
> > To: users@maven.apache.org
> > Subject: reporting plugin dependency question
> > 
> > Hi!
> > 
> > I'm currently enabling the checkstyle plugin for
> the
> > OpenWebBeans build
> > and stumbled over an interesting problem:
> > 
> > I'd like to define the openwebbeans_checks.xml in
> an
> > own artifact for
> > being used in different modules. My first idea was to
> > simply define the
> > checkstyle plugin in the reporting section kind of:
> > 
> > 
> > 
> >  
> >
> > 
> >
> org.apache.maven.plugins
> > 
> >
> maven-checkstyle-plugin
> >  2.2
> >  
> >   
> >
> default/openwebbeans_checks.xml
> >  
> >  
> >
> > 
> > org.apache.openwebbeans
> > 
> checkstyle
> >  1.0-SNAPSHOT
> >
> >  
> >
> > ...
> > 
> > 
> > But there is no way to specify dependencies for a
> reporting
> > plugin,
> > isn't it? Is this intended?
> > 
> > The only thing I could do is to also specify the
> plugin
> > with its
> > dependency in the
> 
> > section, but that's not
> > really handsome.
> > 
> > WDYT? Should I create a Jira?
> > 
> > LieGrue,
> > strub
> >
> 
> > "Multiple exclamation marks are a sure sign of a
> > diseased mind!" 
> > (Sir Terry Pratchett)
> > 
> > 
> >   
> > 
> >
> -
> > 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




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

RE: reporting plugin dependency question

[Adam Leggett]

Apologies Mark, I seem to have not read all the way to the bottom of
your mail :).

Looks like this is an issue already -
http://jira.codehaus.org/browse/MNG-1948, roadmapped for 3.x

Adam


-Original Message-
From: Mark Struberg [mailto:strub...@yahoo.de] 
Sent: 08 January 2009 15:04
To: Maven Users List
Subject: RE: reporting plugin dependency question

Yup Adam, that's exactly what I'm doing currently.

I just wonder if not being able to specify dependencies in the reporting
section is so by design (and there is a good reason for this), or if
this is something we may improve in maven-3.0.

txs and LieGrue,
strub

"Multiple exclamation marks are a sure sign of a diseased mind!" 
(Sir Terry Pratchett)


--- Adam Leggett  schrieb am Do, 8.1.2009:

> Von: Adam Leggett 
> Betreff: RE: reporting plugin dependency question
> An: "Maven Users List" 
> Datum: Donnerstag, 8. Januar 2009, 15:56
> I think you need to specify the dependency within the
>  section of
> the pom and then reference in the reporting section:
> 
> 
> 
>   
>
> org.apache.maven.plugins
>
> maven-checkstyle-plugin
> 
>   
>
> com.example.whizbang
>
> build-tools
> 1.0
>   
> 
>   
> 
>   
>   
> 
>   
>
> org.apache.maven.plugins
>
> maven-checkstyle-plugin
> 
>  
> whizbang/checkstyle.xml
>  
> whizbang/LICENSE.txt
> 
>   
> 
>   
> 
>
http://maven.apache.org/plugins/maven-checkstyle-plugin/examples/multi-m
> odule-config.html
> 
> -Original Message-
> From: Mark Struberg [mailto:strub...@yahoo.de] 
> Sent: 08 January 2009 14:46
> To: users@maven.apache.org
> Subject: reporting plugin dependency question
> 
> Hi!
> 
> I'm currently enabling the checkstyle plugin for the
> OpenWebBeans build
> and stumbled over an interesting problem:
> 
> I'd like to define the openwebbeans_checks.xml in an
> own artifact for
> being used in different modules. My first idea was to
> simply define the
> checkstyle plugin in the reporting section kind of:
> 
> 
> 
>  
>
> 
> org.apache.maven.plugins
> 
> maven-checkstyle-plugin
>  2.2
>  
>   
> default/openwebbeans_checks.xml
>  
>  
>
> 
> org.apache.openwebbeans
>  checkstyle
>  1.0-SNAPSHOT
>
>  
>
> ...
> 
> 
> But there is no way to specify dependencies for a reporting
> plugin,
> isn't it? Is this intended?
> 
> The only thing I could do is to also specify the plugin
> with its
> dependency in the 
> section, but that's not
> really handsome.
> 
> WDYT? Should I create a Jira?
> 
> LieGrue,
> strub
> 
> "Multiple exclamation marks are a sure sign of a
> diseased mind!" 
> (Sir Terry Pratchett)
> 
> 
>   
> 
> -
> 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: reporting plugin dependency question

[Mark Struberg]

Yup Adam, that's exactly what I'm doing currently.

I just wonder if not being able to specify dependencies in the reporting 
section is so by design (and there is a good reason for this), or if this is 
something we may improve in maven-3.0.

txs and LieGrue,
strub

“Multiple exclamation marks are a sure sign of a diseased mind!” 
(Sir Terry Pratchett)


--- Adam Leggett  schrieb am Do, 8.1.2009:

> Von: Adam Leggett 
> Betreff: RE: reporting plugin dependency question
> An: "Maven Users List" 
> Datum: Donnerstag, 8. Januar 2009, 15:56
> I think you need to specify the dependency within the
>  section of
> the pom and then reference in the reporting section:
> 
> 
> 
>   
>
> org.apache.maven.plugins
>
> maven-checkstyle-plugin
> 
>   
>
> com.example.whizbang
>
> build-tools
> 1.0
>   
> 
>   
> 
>   
>   
> 
>   
>
> org.apache.maven.plugins
>
> maven-checkstyle-plugin
> 
>  
> whizbang/checkstyle.xml
>  
> whizbang/LICENSE.txt
> 
>   
> 
>   
> 
> http://maven.apache.org/plugins/maven-checkstyle-plugin/examples/multi-m
> odule-config.html
> 
> -Original Message-
> From: Mark Struberg [mailto:strub...@yahoo.de] 
> Sent: 08 January 2009 14:46
> To: users@maven.apache.org
> Subject: reporting plugin dependency question
> 
> Hi!
> 
> I'm currently enabling the checkstyle plugin for the
> OpenWebBeans build
> and stumbled over an interesting problem:
> 
> I'd like to define the openwebbeans_checks.xml in an
> own artifact for
> being used in different modules. My first idea was to
> simply define the
> checkstyle plugin in the reporting section kind of:
> 
> 
> 
>  
>
> 
> org.apache.maven.plugins
> 
> maven-checkstyle-plugin
>  2.2
>  
>   
> default/openwebbeans_checks.xml
>  
>  
>
> 
> org.apache.openwebbeans
>  checkstyle
>  1.0-SNAPSHOT
>
>  
>
> ...
> 
> 
> But there is no way to specify dependencies for a reporting
> plugin,
> isn't it? Is this intended?
> 
> The only thing I could do is to also specify the plugin
> with its
> dependency in the 
> section, but that's not
> really handsome.
> 
> WDYT? Should I create a Jira?
> 
> LieGrue,
> strub
> 
> "Multiple exclamation marks are a sure sign of a
> diseased mind!" 
> (Sir Terry Pratchett)
> 
> 
>   
> 
> -
> 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: reporting plugin dependency question

[Adam Leggett]

I think you need to specify the dependency within the  section of
the pom and then reference in the reporting section:



  
org.apache.maven.plugins
maven-checkstyle-plugin

  
com.example.whizbang
build-tools
1.0
  

  

  
  

  
org.apache.maven.plugins
maven-checkstyle-plugin

  whizbang/checkstyle.xml
  whizbang/LICENSE.txt

  

  

http://maven.apache.org/plugins/maven-checkstyle-plugin/examples/multi-m
odule-config.html

-Original Message-
From: Mark Struberg [mailto:strub...@yahoo.de] 
Sent: 08 January 2009 14:46
To: users@maven.apache.org
Subject: reporting plugin dependency question

Hi!

I'm currently enabling the checkstyle plugin for the OpenWebBeans build
and stumbled over an interesting problem:

I'd like to define the openwebbeans_checks.xml in an own artifact for
being used in different modules. My first idea was to simply define the
checkstyle plugin in the reporting section kind of:



 
   
 org.apache.maven.plugins
 maven-checkstyle-plugin
 2.2
 
   default/openwebbeans_checks.xml
 
 
   
 org.apache.openwebbeans
 checkstyle
 1.0-SNAPSHOT
   
 
   
...


But there is no way to specify dependencies for a reporting plugin,
isn't it? Is this intended?

The only thing I could do is to also specify the plugin with its
dependency in the  section, but that's not
really handsome.

WDYT? Should I create a Jira?

LieGrue,
strub

"Multiple exclamation marks are a sure sign of a diseased mind!" 
(Sir Terry Pratchett)


  

-
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

reporting plugin dependency question

[Mark Struberg]

Hi!

I'm currently enabling the checkstyle plugin for the OpenWebBeans build and 
stumbled over an interesting problem:

I'd like to define the openwebbeans_checks.xml in an own artifact for being 
used in different modules. My first idea was to simply define the checkstyle 
plugin in the reporting section kind of:



 
   
 org.apache.maven.plugins
 maven-checkstyle-plugin
 2.2
 
   default/openwebbeans_checks.xml
 
 
   
 org.apache.openwebbeans
 checkstyle
 1.0-SNAPSHOT
   
 
   
...


But there is no way to specify dependencies for a reporting plugin, isn't it? 
Is this intended?

The only thing I could do is to also specify the plugin with its dependency in 
the  section, but that's not really handsome.

WDYT? Should I create a Jira?

LieGrue,
strub

“Multiple exclamation marks are a sure sign of a diseased mind!” 
(Sir Terry Pratchett)




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

Re: POM Dependency question

[Wayne Fay]

You really need to just read Better Builds With Maven (from
devzuz.com) or Maven: The Definitive Guide (from sonatype.com), they
have answers for all your questions.

Wayne

On 2/29/08, Maria Odea Ching <[EMAIL PROTECTED]> wrote:
> On Fri, Feb 29, 2008 at 2:46 PM, Muzammil <[EMAIL PROTECTED]> wrote:
>
> >
> > Hi All,
> > I am required to use Maven for my project.
> > My question is regarding the Jars I require for my project.
> > Is it necessary to add information of all the Jars required by ur project
> > in
> > the POM file as dependency.
>
>
> The required info are: groupId, artifactId and version
>
>
> > These dependency jars as I know are either in
> > the users local repository or if not available in the local repository are
> > then downloaded from the remote repository into the local repository.
> > But then what if the jars that I require or the versions of the jar that I
> > require are not even available in the remote repository. In that case what
> > to do?
>
>
> You could host an internal repository where you could deploy these missing
> jars and add this
> repo in your pom. In this case, everyone who builds the project won't have
> to install these
> jars in their local repositories.
>
> Check out these repo managers that you could use to host an internal repo
> (and create proxies as well):
> - Archiva
> - Proximity
> - Artifactory
>
>
> > My other question related to this is that if I already have the required
> > jars for my project on my system but not in the local repository then is
> > there a way to tell Maven to use the required Jars from those locations in
> > ur system.
>
>
> I believe this would answer your question:
> http://maven.apache.org/ref/current/maven-model/maven.html#class_dependency
>
>
> > If not then what is the exact way to put those jars in the local
> > repository?
>
>
> You could use the install-file goal of the maven-install-plugin to put jars
> in your local repository.
>
>
> > I hope I have made myself clear to everyone:-)
> > --
>
>
> HTH,
> Deng
>

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

Re: POM Dependency question

[Maria Odea Ching]

On Fri, Feb 29, 2008 at 2:46 PM, Muzammil <[EMAIL PROTECTED]> wrote:

>
> Hi All,
> I am required to use Maven for my project.
> My question is regarding the Jars I require for my project.
> Is it necessary to add information of all the Jars required by ur project
> in
> the POM file as dependency.


The required info are: groupId, artifactId and version


> These dependency jars as I know are either in
> the users local repository or if not available in the local repository are
> then downloaded from the remote repository into the local repository.
> But then what if the jars that I require or the versions of the jar that I
> require are not even available in the remote repository. In that case what
> to do?


You could host an internal repository where you could deploy these missing
jars and add this
repo in your pom. In this case, everyone who builds the project won't have
to install these
jars in their local repositories.

Check out these repo managers that you could use to host an internal repo
(and create proxies as well):
- Archiva
- Proximity
- Artifactory


> My other question related to this is that if I already have the required
> jars for my project on my system but not in the local repository then is
> there a way to tell Maven to use the required Jars from those locations in
> ur system.


I believe this would answer your question:
http://maven.apache.org/ref/current/maven-model/maven.html#class_dependency


> If not then what is the exact way to put those jars in the local
> repository?


You could use the install-file goal of the maven-install-plugin to put jars
in your local repository.


> I hope I have made myself clear to everyone:-)
> --


HTH,
Deng

POM Dependency question

[Muzammil]

Hi All,
I am required to use Maven for my project.
My question is regarding the Jars I require for my project.
Is it necessary to add information of all the Jars required by ur project in
the POM file as dependency. These dependency jars as I know are either in
the users local repository or if not available in the local repository are
then downloaded from the remote repository into the local repository.
But then what if the jars that I require or the versions of the jar that I
require are not even available in the remote repository. In that case what
to do?
My other question related to this is that if I already have the required
jars for my project on my system but not in the local repository then is
there a way to tell Maven to use the required Jars from those locations in
ur system. If not then what is the exact way to put those jars in the local
repository?
I hope I have made myself clear to everyone:-)
-- 
View this message in context: 
http://www.nabble.com/POM-Dependency-question-tp15753056s177p15753056.html
Sent from the Maven - Users mailing list archive at Nabble.com.


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

RE: Dependency question

[Brewster, Richard]

Declare the dependency as test scope:


${jdbc.groupId}
${jdbc.artifactId}
${jdbc.version}
test 


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

Dependency question

[Jason Porter]

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: File dependency question

[Chris Russell]

It always so obvious when someone tells you.

That worked great - Thanks Wayne.

Chris

Wayne Fay wrote:

I am assuming Deploy is your EAR project. If so, the file should go in
/src/main/application.

You can see this in the maven-ear-plugin documentation -- look at
"earSourceDirectory".
http://maven.apache.org/plugins/maven-ear-plugin/ear-mojo.html

Wayne

On 8/17/07, Chris Russell <[EMAIL PROTECTED]> wrote:
  

Hi All,

I have a really silly question. Currently I can build my EAR file via
JDeveloper and it deploys and runs just fine.
When I build and deploy via Maven, one file is missing from the EAR
file. This file should be found at the top level of the EAR (i.e. if you
open the EAR with winZip, its right there). Its an xml file that helps
determine if we are using SSO authentication or not (orion-application.xml).

I know what to do to make sure that jar file dependencies get brought
in, but I'm not sure what I put in the pom file to make it includes a
non-jar file (and one that doesn't have a version number or anything
like that)

Here is a quick layout of my project:

project pom
Deploy pom  <- orion-application.xml lives in this directory
(\Deploy\src\META-INF\orion-application.xml)
ViewController pom
Model pom
Web Services pom

I did some searching but all I've found is jar dependency information.
Also, if I deploy the EAR file and manually copy this file things work
great.
Is it because I don't have it in the correct directory structure that
its not getting picked up automatically (i.e. should be in
\Deploy\src\main\META-INF... or something like that)?

Thanks in advance,
Chris



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


  


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

Re: File dependency question

[Wayne Fay]

I am assuming Deploy is your EAR project. If so, the file should go in
/src/main/application.

You can see this in the maven-ear-plugin documentation -- look at
"earSourceDirectory".
http://maven.apache.org/plugins/maven-ear-plugin/ear-mojo.html

Wayne

On 8/17/07, Chris Russell <[EMAIL PROTECTED]> wrote:
> Hi All,
>
> I have a really silly question. Currently I can build my EAR file via
> JDeveloper and it deploys and runs just fine.
> When I build and deploy via Maven, one file is missing from the EAR
> file. This file should be found at the top level of the EAR (i.e. if you
> open the EAR with winZip, its right there). Its an xml file that helps
> determine if we are using SSO authentication or not (orion-application.xml).
>
> I know what to do to make sure that jar file dependencies get brought
> in, but I'm not sure what I put in the pom file to make it includes a
> non-jar file (and one that doesn't have a version number or anything
> like that)
>
> Here is a quick layout of my project:
>
> project pom
> Deploy pom  <- orion-application.xml lives in this directory
> (\Deploy\src\META-INF\orion-application.xml)
> ViewController pom
> Model pom
> Web Services pom
>
> I did some searching but all I've found is jar dependency information.
> Also, if I deploy the EAR file and manually copy this file things work
> great.
> Is it because I don't have it in the correct directory structure that
> its not getting picked up automatically (i.e. should be in
> \Deploy\src\main\META-INF... or something like that)?
>
> Thanks in advance,
> Chris
>
>
>
> -
> 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]

File dependency question

[Chris Russell]

Hi All,

I have a really silly question. Currently I can build my EAR file via 
JDeveloper and it deploys and runs just fine.
When I build and deploy via Maven, one file is missing from the EAR 
file. This file should be found at the top level of the EAR (i.e. if you 
open the EAR with winZip, its right there). Its an xml file that helps 
determine if we are using SSO authentication or not (orion-application.xml).


I know what to do to make sure that jar file dependencies get brought 
in, but I'm not sure what I put in the pom file to make it includes a 
non-jar file (and one that doesn't have a version number or anything 
like that)


Here is a quick layout of my project:

project pom
   Deploy pom  <- orion-application.xml lives in this directory 
(\Deploy\src\META-INF\orion-application.xml)

   ViewController pom
   Model pom
   Web Services pom

I did some searching but all I've found is jar dependency information. 
Also, if I deploy the EAR file and manually copy this file things work 
great.
Is it because I don't have it in the correct directory structure that 
its not getting picked up automatically (i.e. should be in 
\Deploy\src\main\META-INF... or something like that)?


Thanks in advance,
Chris



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

Re: Maven dependency question

[Enrique Gaona]

Thanks for the info, that helped a lot.

Enrique

[EMAIL PROTECTED] wrote on 11/14/2006 03:17:07 PM:

> What I do is put the utility jar in my dependency for the war as compile.
> Then I put an exclude in the pom for the war that tells it to leave out
the
> jar and not put it into the war. The classloader for your application
server
> should cause the war to have access to the jar since it is in the ejb
jar's
> classpath. This has to do with the nesting of the classloaders. Some app
> servers let you change the way that works though.
>
> -- Lee
>
> On 11/14/06, Enrique Gaona <[EMAIL PROTECTED]> wrote:
> >
> >
> >
> > Hi folks,
> >
> > We have a J2EE application project (ear) which contains one Web project
> > (war), one EJB project and one utilities java project.
> > The war and EJB jar projects depends from the same utilities project.
> > We included the WEB, EJB and utilities projects as dependencies into
the
> > ear pom file, so all three output files are included into ear file.
> > EJB project works as expected it only adds Class-Path: entry into its
> > Manifest.MF class
> >
> > The problem with the Web project, it adds the common utility jar file
into
> > its WEB-INF/lib directory. We tried to change the dependency scope from
> > "compile" to "provided". In this case neither the jar was  added nor
the
> > Class-Path: entry.
> >
> > How can we specify dependency from the common utility jar file in the
> > war's
> > pom file?
> >
> > Any help is appreciated.  Thanks
> >
> > Enrique
> >
>
>
>
> --
> -- Lee Meador
> Sent from gmail. My real email address is lee AT leemeador.com

Re: Maven dependency question

[Enrique Gaona]

Thanks for the detailed example.

Enrique

"Eric Helfrich" <[EMAIL PROTECTED]> wrote on 11/15/2006 12:02:27 PM:

> I did it this way.  The classpath gets generated with the jars for the
war
> but no jar files get added to the lib directory
> 
> org.apache.maven.plugins
> maven-war-plugin
> 2.0.1
> 
> 
> ${basedir}/../target/${artifactId}
> 
> 
> WEB-INF/lib/*.jar
> 
> 
> false
> 
> true
> 
> 
> 
> 
>
> On 11/15/06, Wayne Fay <[EMAIL PROTECTED]> wrote:
> >
> > Incorrect, Lee M. responded to you earlier...
> >
> > -- Forwarded message --
> > From: Lee Meador <[EMAIL PROTECTED]>
> > Date: Nov 14, 2006 3:17 PM
> > Subject: Re: Maven dependency question
> > To: Maven Users List 
> >
> >
> > What I do is put the utility jar in my dependency for the war as
compile.
> > Then I put an exclude in the pom for the war that tells it to leave out
> > the
> > jar and not put it into the war. The classloader for your application
> > server
> > should cause the war to have access to the jar since it is in the ejb
> > jar's
> > classpath. This has to do with the nesting of the classloaders. Some
app
> > servers let you change the way that works though.
> >
> > -- Lee
> >
> >
> > On 11/14/06, Enrique Gaona <[EMAIL PROTECTED]> wrote:
> > >
> > >
> > >
> > > I posted this message earlier and didnt get any replies. Anyone know
the
> > answer:) Thanks.
> > >
> > > Enrique
> > >
> > > Enrique Gaona/Austin/[EMAIL PROTECTED]
> > >
> > >
> > >
> > >
> > >
> > >
> > >
> > > Enrique Gaona/Austin/[EMAIL PROTECTED]
> > >
> > > 11/14/2006 01:33 PM
> > >
> > > Please respond to
> > > "Maven Users List" 
> > >
> > >
> > > To
> > > users@maven.apache.org
> > >
> > >
> > > cc
> > >
> > >
> > >
> > > Subject
> > > Maven dependency question
> > >
> > >
> > >
> > >
> > > Hi folks,
> > >
> > > We have a J2EE application project (ear) which contains one Web
project
> > > (war), one EJB project and one utilities java project.
> > > The war and EJB jar projects depends from the same utilities project.
> > > We included the WEB, EJB and utilities projects as dependencies into
the
> > > ear pom file, so all three output files are included into ear file.
> > > EJB project works as expected it only adds Class-Path: entry into its
> > > Manifest.MF class
> > >
> > > The problem with the Web project, it adds the common utility jar file
> > into
> > > its WEB-INF/lib directory. We tried to change the dependency scope
from
> > > "compile" to "provided". In this case neither the jar was  added nor
the
> > > Class-Path: entry.
> > >
> > > How can we specify dependency from the common utility jar file in the
> > war's
> > > pom file?
> > >
> > > Any help is appreciated.  Thanks
> > >
> > > Enrique
> > >
> > >
> > >
> >
> > -
> > To unsubscribe, e-mail: [EMAIL PROTECTED]
> > For additional commands, e-mail: [EMAIL PROTECTED]
> >
> >

Re: Maven dependency question

[Eric Helfrich]

I did it this way.  The classpath gets generated with the jars for the war
but no jar files get added to the lib directory
   
   org.apache.maven.plugins
   maven-war-plugin
   2.0.1
   
   
   ${basedir}/../target/${artifactId}
   
   
   WEB-INF/lib/*.jar
   
   
   false
   
   true
   
   
   
   

On 11/15/06, Wayne Fay <[EMAIL PROTECTED]> wrote:


Incorrect, Lee M. responded to you earlier...

-- Forwarded message --
From: Lee Meador <[EMAIL PROTECTED]>
Date: Nov 14, 2006 3:17 PM
Subject: Re: Maven dependency question
To: Maven Users List 


What I do is put the utility jar in my dependency for the war as compile.
Then I put an exclude in the pom for the war that tells it to leave out
the
jar and not put it into the war. The classloader for your application
server
should cause the war to have access to the jar since it is in the ejb
jar's
classpath. This has to do with the nesting of the classloaders. Some app
servers let you change the way that works though.

-- Lee


On 11/14/06, Enrique Gaona <[EMAIL PROTECTED]> wrote:
>
>
>
> I posted this message earlier and didnt get any replies. Anyone know the
answer:) Thanks.
>
> Enrique
>
> Enrique Gaona/Austin/[EMAIL PROTECTED]
>
>
>
>
>
>
>
> Enrique Gaona/Austin/[EMAIL PROTECTED]
>
> 11/14/2006 01:33 PM
>
> Please respond to
> "Maven Users List" 
>
>
> To
> users@maven.apache.org
>
>
> cc
>
>
>
> Subject
> Maven dependency question
>
>
>
>
> Hi folks,
>
> We have a J2EE application project (ear) which contains one Web project
> (war), one EJB project and one utilities java project.
> The war and EJB jar projects depends from the same utilities project.
> We included the WEB, EJB and utilities projects as dependencies into the
> ear pom file, so all three output files are included into ear file.
> EJB project works as expected it only adds Class-Path: entry into its
> Manifest.MF class
>
> The problem with the Web project, it adds the common utility jar file
into
> its WEB-INF/lib directory. We tried to change the dependency scope from
> "compile" to "provided". In this case neither the jar was  added nor the
> Class-Path: entry.
>
> How can we specify dependency from the common utility jar file in the
war's
> pom file?
>
> Any help is appreciated.  Thanks
>
> Enrique
>
>
>

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

Re: Maven dependency question

[Wayne Fay]

Incorrect, Lee M. responded to you earlier...

-- Forwarded message --
From: Lee Meador <[EMAIL PROTECTED]>
Date: Nov 14, 2006 3:17 PM
Subject: Re: Maven dependency question
To: Maven Users List 


What I do is put the utility jar in my dependency for the war as compile.
Then I put an exclude in the pom for the war that tells it to leave out the
jar and not put it into the war. The classloader for your application server
should cause the war to have access to the jar since it is in the ejb jar's
classpath. This has to do with the nesting of the classloaders. Some app
servers let you change the way that works though.

-- Lee


On 11/14/06, Enrique Gaona <[EMAIL PROTECTED]> wrote:




I posted this message earlier and didnt get any replies. Anyone know the 
answer:) Thanks.

Enrique

Enrique Gaona/Austin/[EMAIL PROTECTED]







Enrique Gaona/Austin/[EMAIL PROTECTED]

11/14/2006 01:33 PM

Please respond to
"Maven Users List" 


To
users@maven.apache.org


cc



Subject
Maven dependency question




Hi folks,

We have a J2EE application project (ear) which contains one Web project
(war), one EJB project and one utilities java project.
The war and EJB jar projects depends from the same utilities project.
We included the WEB, EJB and utilities projects as dependencies into the
ear pom file, so all three output files are included into ear file.
EJB project works as expected it only adds Class-Path: entry into its
Manifest.MF class

The problem with the Web project, it adds the common utility jar file into
its WEB-INF/lib directory. We tried to change the dependency scope from
"compile" to "provided". In this case neither the jar was  added nor the
Class-Path: entry.

How can we specify dependency from the common utility jar file in the war's
pom file?

Any help is appreciated.  Thanks

Enrique





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

Re: Maven dependency question

[Enrique Gaona]

I posted this message earlier and didnt get any replies.  Anyone know the answer:)  Thanks.

Enrique

Enrique Gaona/Austin/[EMAIL PROTECTED]








Enrique Gaona/Austin/[EMAIL PROTECTED] 
11/14/2006 01:33 PM

Please respond to
"Maven Users List" 








To
users@maven.apache.org


cc



Subject
Maven dependency question










Hi folks,

We have a J2EE application project (ear) which contains one Web project
(war), one EJB project and one utilities java project.
The war and EJB jar projects depends from the same utilities project.
We included the WEB, EJB and utilities projects as dependencies into the
ear pom file, so all three output files are included into ear file.
EJB project works as expected it only adds Class-Path: entry into its
Manifest.MF class

The problem with the Web project, it adds the common utility jar file into
its WEB-INF/lib directory. We tried to change the dependency scope from
"compile" to "provided". In this case neither the jar was  added nor the
Class-Path: entry.

How can we specify dependency from the common utility jar file in the war's
pom file?

Any help is appreciated.  Thanks

Enrique

Re: Maven dependency question

[Lee Meador]

What I do is put the utility jar in my dependency for the war as compile.
Then I put an exclude in the pom for the war that tells it to leave out the
jar and not put it into the war. The classloader for your application server
should cause the war to have access to the jar since it is in the ejb jar's
classpath. This has to do with the nesting of the classloaders. Some app
servers let you change the way that works though.

-- Lee

On 11/14/06, Enrique Gaona <[EMAIL PROTECTED]> wrote:




Hi folks,

We have a J2EE application project (ear) which contains one Web project
(war), one EJB project and one utilities java project.
The war and EJB jar projects depends from the same utilities project.
We included the WEB, EJB and utilities projects as dependencies into the
ear pom file, so all three output files are included into ear file.
EJB project works as expected it only adds Class-Path: entry into its
Manifest.MF class

The problem with the Web project, it adds the common utility jar file into
its WEB-INF/lib directory. We tried to change the dependency scope from
"compile" to "provided". In this case neither the jar was  added nor the
Class-Path: entry.

How can we specify dependency from the common utility jar file in the
war's
pom file?

Any help is appreciated.  Thanks

Enrique





--
-- Lee Meador
Sent from gmail. My real email address is lee AT leemeador.com

Maven dependency question

[Enrique Gaona]

Hi folks,

We have a J2EE application project (ear) which contains one Web project
(war), one EJB project and one utilities java project.
The war and EJB jar projects depends from the same utilities project.
We included the WEB, EJB and utilities projects as dependencies into the
ear pom file, so all three output files are included into ear file.
EJB project works as expected it only adds Class-Path: entry into its
Manifest.MF class

The problem with the Web project, it adds the common utility jar file into
its WEB-INF/lib directory. We tried to change the dependency scope from
"compile" to "provided". In this case neither the jar was  added nor the
Class-Path: entry.

How can we specify dependency from the common utility jar file in the war's
pom file?

Any help is appreciated.  Thanks

Enrique

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

[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  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]

dependency question

[Chen, Anning]

Hi,

I'm a newbie to Maven2 and have a simple question:

My pom.xml file for this package is here:


4.0.0
com.gs.fw.web.utils.uuid
util.uuidgenerator.servlet
jar
1.0-SNAPSHOT
UUID Generator Servlet
http://maven.apache.org


   
  com.gs.fw.web.lib
  thirdparty.sun.servlet.2.3
  1.0-SNAPSHOT
   




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?

 

Thanks


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

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

[Chris Wall]

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.

Re: RE : [m2] Inter-project dependency question - forced to package sub-module dependencies manually?

[Wayne Fay]

This is exactly correct.

If you want to build and package *only* your submodule, then Maven
needs to have the other dependencies already installed in your local
repo... it won't go find them, build, and use them even if they share
a parent.

This will work if executed from the top/parent pom. Then all artifacts
will be built "in order" and you don't need to install the various
module/submodules.

Wayne


On 3/29/06, Chris Wall <[EMAIL PROTECTED]> wrote:
> Thanks Gareth.
>
> It sounds as if Maven doesn't have the ability to determine and resolve
> inter-project dependencies when packaging a child.
>
> If a sub-module-A has a dependency on a module-B and module-B isn't
> package, Maven will not package module-B prior to packaging
> sub-module-A.  Again, this is if Maven is executed from sub-module-A.  I
> figured that since the pom.xmls were linked via parent, artifactIds, and
> module names, that Maven would have the information needed to resolve
> the dependency.
>
> Instead, from what I understand, you have to build all your dependency
> modules first, prior to packaging your sub-modules.  From the root
> pom.xml everything works well, but if I just want to work with a
> sub-module, than extra steps are required.
>
> -Chris
>
> -Original Message-
> From: Gareth Western [mailto:[EMAIL PROTECTED]
> Sent: March 28, 2006 2:50 PM
> To: Maven Users List
> Subject: Re: RE : [m2] Inter-project dependency question
>
> Hi Chris,
>
> I'm not sure if this is the BEST way to do it, but what I do is create a
> parent pom.xml in the root directory. Then add commons, web-app, and
> stand-alone app as modules in that parent POM. Maven should figure out
> that
> since webapp and standalone app are dependent on the commons module then
> that's what needs to be built first. Then when you call "mvn package"
> (or
> whatever your goal is) on the parent pom, maven will first do the
> commons
> module before anything else. You'll also need to add  tags to
> your
> sub-project (commons, web-app, and stand-alone app).
>
> See the example in the documentation at
> http://maven.apache.org/guides/getting-started/index.html#How%20do%20I%2
> 0build%20more%20than%20one%20project%20at%20once
> ?
> for more details
>
> Hope that helps!
>
> ~Gareth
>
> On 3/28/06, Chris Wall <[EMAIL PROTECTED]> wrote:
> >
> > Thanks Olivier.
> >
> > How do I represent this dependency in my webapp pom.xml?  I have the
> > following dependency declaration, but M2 tries to download the jar
> instead
> > of resolving that this is internally provided dependency.
> >
> >
> > 
> >   my-common
> >my-common
> >   1.0-SNAPSHOT
> > 
> >
> >
> ___
> 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.
>
> -
> To unsubscribe, e-mail: [EMAIL PROTECTED]
> For additional commands, e-mail: [EMAIL PROTECTED]
>
>

RE : [m2] Inter-project dependency question - forced to package sub-module dependencies manually?

[Chris Wall]

Thanks Gareth.

It sounds as if Maven doesn't have the ability to determine and resolve
inter-project dependencies when packaging a child.

If a sub-module-A has a dependency on a module-B and module-B isn't
package, Maven will not package module-B prior to packaging
sub-module-A.  Again, this is if Maven is executed from sub-module-A.  I
figured that since the pom.xmls were linked via parent, artifactIds, and
module names, that Maven would have the information needed to resolve
the dependency.

Instead, from what I understand, you have to build all your dependency
modules first, prior to packaging your sub-modules.  From the root
pom.xml everything works well, but if I just want to work with a
sub-module, than extra steps are required.

-Chris

-Original Message-
From: Gareth Western [mailto:[EMAIL PROTECTED] 
Sent: March 28, 2006 2:50 PM
To: Maven Users List
Subject: Re: RE : [m2] Inter-project dependency question

Hi Chris,

I'm not sure if this is the BEST way to do it, but what I do is create a
parent pom.xml in the root directory. Then add commons, web-app, and
stand-alone app as modules in that parent POM. Maven should figure out
that
since webapp and standalone app are dependent on the commons module then
that's what needs to be built first. Then when you call "mvn package"
(or
whatever your goal is) on the parent pom, maven will first do the
commons
module before anything else. You'll also need to add  tags to
your
sub-project (commons, web-app, and stand-alone app).

See the example in the documentation at
http://maven.apache.org/guides/getting-started/index.html#How%20do%20I%2
0build%20more%20than%20one%20project%20at%20once
?
for more details

Hope that helps!

~Gareth

On 3/28/06, Chris Wall <[EMAIL PROTECTED]> wrote:
>
> Thanks Olivier.
>
> How do I represent this dependency in my webapp pom.xml?  I have the
> following dependency declaration, but M2 tries to download the jar
instead
> of resolving that this is internally provided dependency.
>
>
> 
>   my-common
>my-common
>   1.0-SNAPSHOT
> 
>
>
___
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.

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

Re: RE : [m2] Inter-project dependency question

[Gareth Western]

Hi Chris,

I'm not sure if this is the BEST way to do it, but what I do is create a
parent pom.xml in the root directory. Then add commons, web-app, and
stand-alone app as modules in that parent POM. Maven should figure out that
since webapp and standalone app are dependent on the commons module then
that's what needs to be built first. Then when you call "mvn package" (or
whatever your goal is) on the parent pom, maven will first do the commons
module before anything else. You'll also need to add  tags to your
sub-project (commons, web-app, and stand-alone app).

See the example in the documentation at
http://maven.apache.org/guides/getting-started/index.html#How%20do%20I%20build%20more%20than%20one%20project%20at%20once
?
for more details

Hope that helps!

~Gareth

On 3/28/06, Chris Wall <[EMAIL PROTECTED]> wrote:
>
> Thanks Olivier.
>
> How do I represent this dependency in my webapp pom.xml?  I have the
> following dependency declaration, but M2 tries to download the jar instead
> of resolving that this is internally provided dependency.
>
>
> 
>   my-common
>my-common
>   1.0-SNAPSHOT
> 
>
>

RE: RE : [m2] Inter-project dependency question

[Chris Wall]

Thanks Olivier.

How do I represent this dependency in my webapp pom.xml?  I have the following 
dependency declaration, but M2 tries to download the jar instead of resolving 
that this is internally provided dependency.



  my-common
   my-common
  1.0-SNAPSHOT


-Original Message-
From: Olivier Lamy [mailto:[EMAIL PROTECTED] 
Sent: March 28, 2006 12:01 PM
To: 'Maven Users List'
Subject: RE : [m2] Inter-project dependency question

Perso I do as this.

root
  -- commons 1.0-SNAPSHOT
  -- webapp
-- sub module A (depends on commons 1.0-SNAPSHOT)
-- sub module B (depends on commons 1.0-SNAPSHOT)
  -- stand-alone app (depends on commons 1.0-SNAPSHOT)

In the root directory, mvn clean test-compile. (in order to verify all
is compatible).
When commons is released, changed the version dependency in others
modules.
And just work in sub module A.

- Olivier

-Message d'origine-
De : Chris Wall [mailto:[EMAIL PROTECTED] 
Envoyé : mardi 28 mars 2006 19:53
À : Maven Users List
Objet : [m2] Inter-project dependency question


This is probably a fundamental question for most of you...

Considering the following project structure...

root
  -- commons
  -- webapp
-- sub module A
-- sub module B
  -- stand-alone app

... since the webapp project has a dependency on commons (as does the
stand-alone app), how do I tell M2 to build commons, if it's not
already, from within the webapp module (webapp/pom.xml)?
 
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.

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



This e-mail, any attachments and the information contained therein ("this 
message") are confidential and intended solely for the use of the addressee(s). 
If you have received this message in error please send it back to the sender 
and delete it. Unauthorized publication, use, dissemination or disclosure of 
this message, either in whole or in part is strictly prohibited.
--
Ce message électronique et tous les fichiers joints ainsi que  les informations 
contenues dans ce message ( ci après "le message" ), sont confidentiels et 
destinés exclusivement à l'usage de la  personne à laquelle ils sont adressés. 
Si vous avez reçu ce message par erreur, merci  de le renvoyer à son émetteur 
et de le détruire. Toutes diffusion, publication, totale ou partielle ou 
divulgation sous quelque forme que se soit non expressément autorisées de ce 
message, sont interdites.
-


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

___
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.

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

RE : [m2] Inter-project dependency question

[Olivier Lamy]

Perso I do as this.

root
  -- commons 1.0-SNAPSHOT
  -- webapp
-- sub module A (depends on commons 1.0-SNAPSHOT)
-- sub module B (depends on commons 1.0-SNAPSHOT)
  -- stand-alone app (depends on commons 1.0-SNAPSHOT)

In the root directory, mvn clean test-compile. (in order to verify all
is compatible).
When commons is released, changed the version dependency in others
modules.
And just work in sub module A.

- Olivier

-Message d'origine-
De : Chris Wall [mailto:[EMAIL PROTECTED] 
Envoyé : mardi 28 mars 2006 19:53
À : Maven Users List
Objet : [m2] Inter-project dependency question


This is probably a fundamental question for most of you...

Considering the following project structure...

root
  -- commons
  -- webapp
-- sub module A
-- sub module B
  -- stand-alone app

... since the webapp project has a dependency on commons (as does the
stand-alone app), how do I tell M2 to build commons, if it's not
already, from within the webapp module (webapp/pom.xml)?
 
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.

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



This e-mail, any attachments and the information contained therein ("this 
message") are confidential and intended solely for the use of the addressee(s). 
If you have received this message in error please send it back to the sender 
and delete it. Unauthorized publication, use, dissemination or disclosure of 
this message, either in whole or in part is strictly prohibited.
--
Ce message électronique et tous les fichiers joints ainsi que  les informations 
contenues dans ce message ( ci après "le message" ), sont confidentiels et 
destinés exclusivement à l'usage de la  personne à laquelle ils sont adressés. 
Si vous avez reçu ce message par erreur, merci  de le renvoyer à son émetteur 
et de le détruire. Toutes diffusion, publication, totale ou partielle ou 
divulgation sous quelque forme que se soit non expressément autorisées de ce 
message, sont interdites.
-


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

[m2] Inter-project dependency question

[Chris Wall]

This is probably a fundamental question for most of you...

Considering the following project structure...

root
  -- commons
  -- webapp
-- sub module A
-- sub module B
  -- stand-alone app

... since the webapp project has a dependency on commons (as does the
stand-alone app), how do I tell M2 to build commons, if it's not
already, from within the webapp module (webapp/pom.xml)?
 
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.

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

Re: [m2] Newbie dependency question

[Alexandre Poitras]

whoops I pushed send by accident here the true email

On 2/22/06, Alexandre Poitras <[EMAIL PROTECTED]> wrote:
> On 2/21/06, Dave Hoffer <[EMAIL PROTECTED]> wrote:
> > Alexandre,
> >
> > I have some further questions below...
> >
> >
> > -Original Message-
> > From: Alexandre Poitras [mailto:[EMAIL PROTECTED]
> > Sent: Tuesday, February 21, 2006 9:52 PM
> > To: Maven Users List
> > Subject: Re: [m2] Newbie dependency question
> >
> > About the version, the best practices recommend to keep a separate
> > build for bug maintenance (using a separate SCM branch) and one for
> > adding new features (the trunk). You usually set some features
> > milestones and each time you complete one, you can release a new major
> > version, for instance 1.0, 2.0, ... The tricky part here is that you
> > have to merge your branch with the trunk often to resolve the bug
> > quickly and avoid big conflicts. When you do that, you usually ugrade
> > the minor version, for instance 1.0 to 1.0.1. I
> >
> > [dh] ok.
> >
> > In the mean time, you provide Snapshots in case some developpers need
> > the latest bug fixes. Maven2 handle Snapshot very well.  For instance,
> > today I was debugging some components and I was able to publish about
> > 10 snapshots to our repository. Each time I was deploying it, one of
> > my coworker was immediatly testing it in an application. Maven always
> > downloaded the lastest one without any problem, granted the dependency
> > was deployed in a snapshot repository and the lookup policy was set to
> > always check for a newer version (there is 3 suppported types of
> > repositories "release", "snaphot" and "plugins" but usually you use
> > the same location for the three).
> >
> > [dh] So you have 10 components each with versioned releases and Snapshots?  
> > The applications that use these 10 components specify their dependencies as 
> > needing the versioned releases but because 'the lookup policy was set to
> > always check for a newer version' it grabs the Snapshots instead?
>
 No sorry, I guess I wasn't clear enoug. We we're doing some
 performance testing so I deployed 10 versions of the same componet.
 The application always grabbed the snapshot because it declared a
 dependency on the component with a version 1.0-SNAPSHOT specified.
> >
> > [dh] How do you configure your applications to set 'the lookup policy was 
> > set to always check for a newer version'?
>
 In your pom.xml, you have to define your release and snapshot
 repositories. There you can add an "updatePolicy" element with it
value set to always.
> >
> > [dh] Can you configure your application to look for newer versioned 
> > components as well as Snapshots?
I don't know the answer to this question, I am still wondering the
same but I prefer to update the version number myself to test if my
build doesn't break with a new version.
> >
> > [dh] If this is true it seems you could ship your application with 
> > Snapshots if you forgot to turn off the policy to check for a newer version.
> >
No, if you use the release plugin when you make  a release, you will
an error if you have snapshot dependencies. Maven is pretty smart ;)

> >
> > So basically, the other developers you are working with can use one of
> > your components by declaring it as a dependency in their project pom.
> > What is really important is that they state the correct version
> > number, ie if they want the official version 1.0, they should just put
> > 1.0 but if they want always the latest build, they should put
> > something like 1.0-SNAPSHOT. Using an official version you are sure
> > your project will always build but you won't have your latest bug
> > fixes available. For internal components, I am usually comfortable to
> > use SNAPSHOT versions (until the release of course, not after) but not
> > when it is an external dependency.
> >
> > [dh] So you could go right up to app release using SNAPSHOT and then start 
> > changing to specifying versioned components?
Yes, if you want to but if in the mean time a new component release is
made, for instance 2.0, then you have to update your project to use
the version 2.0-SNAPSHOT instead of 1.0-SNAPSHOT.

> >
> > [dh] The problem I see is that since the (internal) components have been at 
> > SNAPSHOT for so long nobody would know what version to set it to.  You 
> > would have to look at the history of labels/branches, check the version 
> > number and increment the appropriate version (major/minor/sp) number b

Re: [m2] Newbie dependency question

[Alexandre Poitras]

On 2/21/06, Dave Hoffer <[EMAIL PROTECTED]> wrote:
> Alexandre,
>
> I have some further questions below...
>
>
> -Original Message-
> From: Alexandre Poitras [mailto:[EMAIL PROTECTED]
> Sent: Tuesday, February 21, 2006 9:52 PM
> To: Maven Users List
> Subject: Re: [m2] Newbie dependency question
>
> About the version, the best practices recommend to keep a separate
> build for bug maintenance (using a separate SCM branch) and one for
> adding new features (the trunk). You usually set some features
> milestones and each time you complete one, you can release a new major
> version, for instance 1.0, 2.0, ... The tricky part here is that you
> have to merge your branch with the trunk often to resolve the bug
> quickly and avoid big conflicts. When you do that, you usually ugrade
> the minor version, for instance 1.0 to 1.0.1. I
>
> [dh] ok.
>
> In the mean time, you provide Snapshots in case some developpers need
> the latest bug fixes. Maven2 handle Snapshot very well.  For instance,
> today I was debugging some components and I was able to publish about
> 10 snapshots to our repository. Each time I was deploying it, one of
> my coworker was immediatly testing it in an application. Maven always
> downloaded the lastest one without any problem, granted the dependency
> was deployed in a snapshot repository and the lookup policy was set to
> always check for a newer version (there is 3 suppported types of
> repositories "release", "snaphot" and "plugins" but usually you use
> the same location for the three).
>
> [dh] So you have 10 components each with versioned releases and Snapshots?  
> The applications that use these 10 components specify their dependencies as 
> needing the versioned releases but because 'the lookup policy was set to
> always check for a newer version' it grabs the Snapshots instead?

No sorry, I guess I wasn't clear enoug. We we're doing some
performance testing so I deployed 10 versions of the same componet.
The application always grabbed the snapshot because it declared a
dependency on the component with a version 1.0-SNAPSHOT specified.
>
> [dh] How do you configure your applications to set 'the lookup policy was set 
> to always check for a newer version'?

In your pom.xml, you have to define your release and snapshot
repositories. There you can add an "updatePolicy" element with it
>
> [dh] Can you configure your application to look for newer versioned 
> components as well as Snapshots?
>
> [dh] If this is true it seems you could ship your application with Snapshots 
> if you forgot to turn off the policy to check for a newer version.
>
>
> So basically, the other developers you are working with can use one of
> your components by declaring it as a dependency in their project pom.
> What is really important is that they state the correct version
> number, ie if they want the official version 1.0, they should just put
> 1.0 but if they want always the latest build, they should put
> something like 1.0-SNAPSHOT. Using an official version you are sure
> your project will always build but you won't have your latest bug
> fixes available. For internal components, I am usually comfortable to
> use SNAPSHOT versions (until the release of course, not after) but not
> when it is an external dependency.
>
> [dh] So you could go right up to app release using SNAPSHOT and then start 
> changing to specifying versioned components?
>
> [dh] The problem I see is that since the (internal) components have been at 
> SNAPSHOT for so long nobody would know what version to set it to.  You would 
> have to look at the history of labels/branches, check the version number and 
> increment the appropriate version (major/minor/sp) number by one.  This would 
> be entirely manual and subject to possible errors.
>
> [dh] It seems this approach eliminates any need for a build number. SNAPSHOT 
> becomes the build number and it's the same for all builds.  I'm not clear if 
> this is good or bad yet.
>
>
> Take a look there to have more details on the good practices Maven
> team suggest and that I just listed :
> http://maven.apache.org/development-process.html
>
> We don't use an automated build tool yet (I have to integrate it in
> our process first), but we plan to use Continuum (the last is 1.0.2)
> very soon. So I can't really help you there but I think you can tell
> him what projects to construct.
>
> [dh] Okay, I too would like to use Continuum but I didn't find many docs to 
> help with this.
>
> Well, I hope it's help. Hard to explain all of those concepts in a
> small mail. If you need more advice, don't be afraid to as

RE: [m2] Newbie dependency question

[Dave Hoffer]

Alexandre,

I have some further questions below...


-Original Message-
From: Alexandre Poitras [mailto:[EMAIL PROTECTED] 
Sent: Tuesday, February 21, 2006 9:52 PM
To: Maven Users List
Subject: Re: [m2] Newbie dependency question

About the version, the best practices recommend to keep a separate
build for bug maintenance (using a separate SCM branch) and one for
adding new features (the trunk). You usually set some features
milestones and each time you complete one, you can release a new major
version, for instance 1.0, 2.0, ... The tricky part here is that you
have to merge your branch with the trunk often to resolve the bug
quickly and avoid big conflicts. When you do that, you usually ugrade
the minor version, for instance 1.0 to 1.0.1. I

[dh] ok.

In the mean time, you provide Snapshots in case some developpers need
the latest bug fixes. Maven2 handle Snapshot very well.  For instance,
today I was debugging some components and I was able to publish about
10 snapshots to our repository. Each time I was deploying it, one of
my coworker was immediatly testing it in an application. Maven always
downloaded the lastest one without any problem, granted the dependency
was deployed in a snapshot repository and the lookup policy was set to
always check for a newer version (there is 3 suppported types of
repositories "release", "snaphot" and "plugins" but usually you use
the same location for the three).

[dh] So you have 10 components each with versioned releases and Snapshots?  The 
applications that use these 10 components specify their dependencies as needing 
the versioned releases but because 'the lookup policy was set to
always check for a newer version' it grabs the Snapshots instead?

[dh] How do you configure your applications to set 'the lookup policy was set 
to always check for a newer version'?

[dh] Can you configure your application to look for newer versioned components 
as well as Snapshots?

[dh] If this is true it seems you could ship your application with Snapshots if 
you forgot to turn off the policy to check for a newer version.


So basically, the other developers you are working with can use one of
your components by declaring it as a dependency in their project pom.
What is really important is that they state the correct version
number, ie if they want the official version 1.0, they should just put
1.0 but if they want always the latest build, they should put
something like 1.0-SNAPSHOT. Using an official version you are sure
your project will always build but you won't have your latest bug
fixes available. For internal components, I am usually comfortable to
use SNAPSHOT versions (until the release of course, not after) but not
when it is an external dependency.

[dh] So you could go right up to app release using SNAPSHOT and then start 
changing to specifying versioned components?

[dh] The problem I see is that since the (internal) components have been at 
SNAPSHOT for so long nobody would know what version to set it to.  You would 
have to look at the history of labels/branches, check the version number and 
increment the appropriate version (major/minor/sp) number by one.  This would 
be entirely manual and subject to possible errors.

[dh] It seems this approach eliminates any need for a build number. SNAPSHOT 
becomes the build number and it's the same for all builds.  I'm not clear if 
this is good or bad yet. 


Take a look there to have more details on the good practices Maven
team suggest and that I just listed :
http://maven.apache.org/development-process.html

We don't use an automated build tool yet (I have to integrate it in
our process first), but we plan to use Continuum (the last is 1.0.2)
very soon. So I can't really help you there but I think you can tell
him what projects to construct.

[dh] Okay, I too would like to use Continuum but I didn't find many docs to 
help with this.

Well, I hope it's help. Hard to explain all of those concepts in a
small mail. If you need more advice, don't be afraid to ask.

[dh] Thanks a lot!

-dh

On 2/21/06, Dave Hoffer <[EMAIL PROTECTED]> wrote:
> Alexandre,
>
> Let me see if I understand correctly by asking some questions, I am very new 
> to maven & ant so please excuse the newbie nature of these.
>
> Currently we have one ant script that builds all of our 
> components/applications synchronously every 15 minutes after a check in.  So 
> we create full builds often.  This works well as we always have the latest 
> build to test/release etc.  However we have poor version control to support 
> releases, service packs, etc and it doesn't scale well to using these same 
> components in parallel project builds.  So I am looking to maven2 to see if I 
> can get a better system & practice.
>
> So given your description, it seems I would need SNAPSHOT builds that build 
&g

Re: [m2] Newbie dependency question

[Alexandre Poitras]

nterprise snapshot repository; isn't this the same repository as 
> the versioned one?
>
> I think that if I get the big picture of how to use maven2 in an aggressive 
> continuous build system I can get going with it, right now I feel I don't 
> know how to begin.  (I have ordered a maven book but it isn't published yet.)
>
> Any ideas/suggestions are greatly appreciated.
>
> -dh
>
>
>
> -Original Message-
> From: Alexandre Poitras [mailto:[EMAIL PROTECTED]
> Sent: Monday, February 20, 2006 6:13 PM
> To: Maven Users List
> Subject: Re: [m2] Newbie dependency question
>
> From what I understand you want to use the fresh version of some
> components that are still in development, what is usually called a
> night build or a snapshot. You should declare their version as
> 1.0-SNAPSHOT or something like that. Then you just need to setup an
> enterprise snapshot repository wich always give you the lastest
> snapshot of your artefacts.
>
> When the components actually go throught a new release, I suggest you
> to update the dependencies version manually when new versions come out
> so you can test if everything still work ok.
>
> On 2/20/06, Dave Hoffer <[EMAIL PROTECTED]> wrote:
> > Being new to maven I have so basic questions regarding best practices in
> > maven.  Specifically, I want to know what the recommended practice is in
> > configuring projects that have dependencies which is all but the most
> > basic of applications.  In our company we develop applications that are
> > comprised of several components that we create.
> >
> > As I understand maven, all artifacts have the version in the jar name.
> > This is great in one sense as it lets your project(s) refer to the
> > specific jar version that you want.  However, it causes problems also
> > because ideally we want our applications to work with the 'latest'
> > version of all of our components.  It seems the default maven behavior
> > would encourage our applications and components to be created to
> > something other than the 'latest' version.
> >
> > I would like to setup our IntelliJ projects and our continuous
> > integration build system to generally use the 'latest' version of
> > components so that we attempt to minimize code that is written to old
> > components.
> >
> > How can this be accomplished in maven2?  What are the best practices?
> >
> > Thanks!
> >
> > -dh
> >
> > -
> > To unsubscribe, e-mail: [EMAIL PROTECTED]
> > For additional commands, e-mail: [EMAIL PROTECTED]
> >
> >
>
>
> --
> Alexandre Poitras
> Québec, Canada
>
> -
> 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]
>
>


--
Alexandre Poitras
Québec, Canada

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

RE: [m2] Newbie dependency question

[Dave Hoffer]

Alexandre,

Let me see if I understand correctly by asking some questions, I am very new to 
maven & ant so please excuse the newbie nature of these.

Currently we have one ant script that builds all of our components/applications 
synchronously every 15 minutes after a check in.  So we create full builds 
often.  This works well as we always have the latest build to test/release etc. 
 However we have poor version control to support releases, service packs, etc 
and it doesn't scale well to using these same components in parallel project 
builds.  So I am looking to maven2 to see if I can get a better system & 
practice.

So given your description, it seems I would need SNAPSHOT builds that build 
after each check in (with some delay) else I would not have my continuous 
builds.  (Waiting for a nightly build would be too long.  Our testers work 
right with developers and we often want to fix something and get them a build 
asap.  And it may be this build that we release if it has the quality they are 
looking for!)

In our case the big question is...when do we create component releases?  In 
reality we don't have 'official' releases of many internal components because 
who cares?  All each project cares about is two things; first if I am dependent 
on the new stuff being developed in a component I want the latest.  On the 
other hand, if I am satisfied with the content of a component the way it is, I 
don't want changes wrecking my build so a released versioned component that 
doesn't change is what I want.

How can I get this with maven?  I could do SNAPSHOTS as the norm and then 
specify versions once it surpasses a certain milestone.  However, it seems I 
would always be looking back applying a version once I already have released a 
product with a SNAPSHOT.  This doesn't seem like the way to use maven.

By the way, what do you use to do the continuous build part of the system?  Is 
Continuum ready?  How about QuickBuild or CruiseControl?  How do these 
integrate?  Do they label the source, apply the right value to the  
tag in the pom, and keep track of incrementing the build number?

Also, I assume in maven that each artifact/pom should be built in an autonomous 
manor, each with its own automation script.  Is this correct?

As for the enterprise snapshot repository; isn't this the same repository as 
the versioned one?

I think that if I get the big picture of how to use maven2 in an aggressive 
continuous build system I can get going with it, right now I feel I don't know 
how to begin.  (I have ordered a maven book but it isn't published yet.)

Any ideas/suggestions are greatly appreciated.  

-dh



-Original Message-
From: Alexandre Poitras [mailto:[EMAIL PROTECTED] 
Sent: Monday, February 20, 2006 6:13 PM
To: Maven Users List
Subject: Re: [m2] Newbie dependency question

>From what I understand you want to use the fresh version of some
components that are still in development, what is usually called a
night build or a snapshot. You should declare their version as
1.0-SNAPSHOT or something like that. Then you just need to setup an
enterprise snapshot repository wich always give you the lastest
snapshot of your artefacts.

When the components actually go throught a new release, I suggest you
to update the dependencies version manually when new versions come out
so you can test if everything still work ok.

On 2/20/06, Dave Hoffer <[EMAIL PROTECTED]> wrote:
> Being new to maven I have so basic questions regarding best practices in
> maven.  Specifically, I want to know what the recommended practice is in
> configuring projects that have dependencies which is all but the most
> basic of applications.  In our company we develop applications that are
> comprised of several components that we create.
>
> As I understand maven, all artifacts have the version in the jar name.
> This is great in one sense as it lets your project(s) refer to the
> specific jar version that you want.  However, it causes problems also
> because ideally we want our applications to work with the 'latest'
> version of all of our components.  It seems the default maven behavior
> would encourage our applications and components to be created to
> something other than the 'latest' version.
>
> I would like to setup our IntelliJ projects and our continuous
> integration build system to generally use the 'latest' version of
> components so that we attempt to minimize code that is written to old
> components.
>
> How can this be accomplished in maven2?  What are the best practices?
>
> Thanks!
>
> -dh
>
> -
> To unsubscribe, e-mail: [EMAIL PROTECTED]
> For additional commands, e-mail: [EMAIL PROTECTED]
>
>


--
Alexandr

Re: [m2] Newbie dependency question

[Alexandre Poitras]

>From what I understand you want to use the fresh version of some
components that are still in development, what is usually called a
night build or a snapshot. You should declare their version as
1.0-SNAPSHOT or something like that. Then you just need to setup an
enterprise snapshot repository wich always give you the lastest
snapshot of your artefacts.

When the components actually go throught a new release, I suggest you
to update the dependencies version manually when new versions come out
so you can test if everything still work ok.

On 2/20/06, Dave Hoffer <[EMAIL PROTECTED]> wrote:
> Being new to maven I have so basic questions regarding best practices in
> maven.  Specifically, I want to know what the recommended practice is in
> configuring projects that have dependencies which is all but the most
> basic of applications.  In our company we develop applications that are
> comprised of several components that we create.
>
> As I understand maven, all artifacts have the version in the jar name.
> This is great in one sense as it lets your project(s) refer to the
> specific jar version that you want.  However, it causes problems also
> because ideally we want our applications to work with the 'latest'
> version of all of our components.  It seems the default maven behavior
> would encourage our applications and components to be created to
> something other than the 'latest' version.
>
> I would like to setup our IntelliJ projects and our continuous
> integration build system to generally use the 'latest' version of
> components so that we attempt to minimize code that is written to old
> components.
>
> How can this be accomplished in maven2?  What are the best practices?
>
> Thanks!
>
> -dh
>
> -
> To unsubscribe, e-mail: [EMAIL PROTECTED]
> For additional commands, e-mail: [EMAIL PROTECTED]
>
>


--
Alexandre Poitras
Québec, Canada

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

[m2] Newbie dependency question

[Dave Hoffer]

Being new to maven I have so basic questions regarding best practices in
maven.  Specifically, I want to know what the recommended practice is in
configuring projects that have dependencies which is all but the most
basic of applications.  In our company we develop applications that are
comprised of several components that we create.

As I understand maven, all artifacts have the version in the jar name.
This is great in one sense as it lets your project(s) refer to the
specific jar version that you want.  However, it causes problems also
because ideally we want our applications to work with the 'latest'
version of all of our components.  It seems the default maven behavior
would encourage our applications and components to be created to
something other than the 'latest' version.  

I would like to setup our IntelliJ projects and our continuous
integration build system to generally use the 'latest' version of
components so that we attempt to minimize code that is written to old
components.

How can this be accomplished in maven2?  What are the best practices?

Thanks!

-dh 

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