I think you're missing the whole point of Maven's dependency resolution here. You should never update a pom of a dependency. However, you can control which version of a dependency (or a transitive dependency) through dependencyManagement.
So, if A has been released using logging artifact C of v1.0 and B has been released using C v1.1, they declare this in their pom, respectively. The when you build/compose component P you either let Maven do the version resolution or you do it yourself (in P) through dependencyManagement. You still need to test P, don't you? If, for some reason, A only works with v1.0 of C, you can/should declare that in A's pom (by stating version as [1.0]). /Anders On Wed, Dec 16, 2009 at 10:50, Varwig, Britta <[email protected]> wrote: > Hello Anders > > The reason for using version ranges is to make product releasing easy and > avoid producing "unnecessary" versions. > > Eg. imaging you have a base functionality like as logging. > Logging is used from an artifact A and even from an artifact B. Both > artifact A and B have no dependencies and are developed in different > version-lifecyles. > > If you now want to compose a component P which depend on A and B you do not > have to change A's or B's pom if the version range of logging fits. But if > not, you either have to change A's pom or B's pom. And now you have > "unnecessary" Versions which you have to test, release and support. > If you use version ranges you can in many cases avoid those "unnecessary" > Versions. > > Regards Britta > > > > -----Original Message----- > > From: [email protected] [mailto:[email protected]] On > > Behalf Of Anders Hammar > > Sent: Mittwoch, 16. Dezember 2009 08:43 > > To: Maven Users List > > Subject: Re: Reproducing a former build with exact dependencies but > > version ranges in the POM > > > > I don't one exists for Maven 2. Possibly it would be possible to extend > > Maven 3 to alter the pom in runtime based on some other file. > > > > However, I would suggest you investigate the alternatives that do exist > > in > > Maven. Not many people use version ranges in their poms and for a > > reason. > > How will you be using your artifacts internally? If you release an > > artifact > > with a pom with version ranges, how would you make sure that other > > projects > > depending on this artifact use the "right" version of transitive > > dependencies? > > > > What's the reason for using version ranges in the first place? > > > > /Anders > > > > On Wed, Dec 16, 2009 at 08:36, Heix, Andreas <[email protected]> > > wrote: > > > > > Hi Anders, > > > > > > thanks - that's also the only thing I found. I just hoped for a more > > > flexible way to do it. So I'll have to dig deeper... > > > > > > Kind regards > > > Andreas > > > > > > -----Original Message----- > > > From: [email protected] [mailto:[email protected]] On > > > Behalf Of Anders Hammar > > > Sent: Mittwoch, 16. Dezember 2009 08:09 > > > To: Maven Users List > > > Subject: Re: Reproducing a former build with exact dependencies but > > version > > > ranges in the POM > > > > > > The only way (that I know of) to ensure a reproducable build is to > > lock > > > down > > > all versions in your pom. This includes plugins as well as > > dependencies. > > > > > > /Anders > > > > > > On Tue, Dec 15, 2009 at 10:48, Heix, Andreas <[email protected]> > > wrote: > > > > > > > Hi, > > > > > > > > for development we want to use dependency version ranges within our > > poms. > > > > As soon as we release a project for each artifact a certain version > > is > > > used > > > > in this build. At a later point in time we want to reproduce > > exactly the > > > > same build result without changing the poms which still contain > > version > > > > ranges. But very likely the content of our repositories will have > > > changed: > > > > meanwhile e.g. newer versions of certain artifacts are available. > > > > > > > > We can retrieve the list of used dependencies and plugins via mvn > > > > dependency:resolve & mvn dependency:resolve-plugins. > > > > Is there a chance to use this list as kind of 'whitelist'? It would > > > specify > > > > the exact versions of the dependencies instead of letting maven > > resolve > > > the > > > > "best fit" in future builds? > > > > > > > > Kind regards > > > > > > > > ------------------------------------------------------------------- > > -- > > > > 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] > >
