Hi Richard! You have to be online to pull in updates of third-party artifacts, but you don't want updates of your own artefacts?
Well, I'd say there is only one solution to this: use snapshot versions for the artifacts you want updates for and define non-snapshot versions for all others. Regarding reproducability: an artifact with a snapshot-dependency is never reproducable, that's the nature of snapshots. hth, - martin On Tuesday 20 January 2009 Richard Chamberlain wrote: > Apologies for not being clear. > > In my second mail i had thought of another situation where > interdependencies between artefacts you have built cause an > unpredictable build. > > Let me illustrate the problem clearer. > > Parent P > Project A > Project B > Project C -> depends on A > > mvn install > > My reactor build would do: > > - Build Project P > - Build Project A -> installed into local repo > - Build project B -> installed into local repo > > During the build of Project B, an updated Project A was put into the > remote repository by, say an automated build > > - Build Project C (during build of project C it would have downloaded > project A) > > Therefore project C would not build with my project A. I cannot use > offline with this multi-module project as I want A, B and C to pull in > any changes to third-party artefacts. > > I may have understood the way that maven works in this regards, please > could you let me know if this is an issue. > > Regards, > > Richard > > > > > -----Original Message----- > From: [email protected] [mailto:[email protected]] On Behalf Of Baptiste > MATHUS > Sent: 20 January 2009 15:43 > To: Maven Users List > Subject: Re: Interdependencies between modules > > What do you mean by "someone deployed to the repository". It has to be > you, > particularly if you're working offline. As the local maven repository is > "local", this should not be possible. You're not sharing your local > repository with others are you? > > Did you try with mvn -o? You're not very clear about it in your last > mail. > > Cheers > > 2009/1/20 Richard Chamberlain <[email protected]> > > > This is worse when incorporated into a multi-module build: > > > > When the reactor builds B it is not guaranteed to use locally built A. > > If someone deployed to the repository, then it would use that one. > > > > Is this an issue? Or have I missed something? > > > > > > -----Original Message----- > > From: [email protected] [mailto:[email protected]] On Behalf Of > > Baptiste > > > MATHUS > > Sent: 20 January 2009 12:56 > > To: Maven Users List > > Subject: Re: Interdependencies between modules > > > > Just a thought: use profile to disable your repository? Or simply work > > offline (mvn -o)? This way it will only use your local jar. > > > > Cheers. > > > > 2009/1/20 Richard Chamberlain <[email protected]> > > > > > Hi All, > > > > > > > > > > > > I've got a question about how maven works when there is a newer > > remote > > > > library than a locally installed artefact. > > > > > > > > > > > > Say I've got project A and project B. B depends on A. > > > > > > > > > > > > - I build A and install it, to test that B will work with > > the > > > > API changes in A. > > > > > > - If I build B it will use my locally built copy of A, > > > everything is fine > > > > > > > > > > > > UNLESS: The continuous integration tool builds a new copy of A after > > I > > > > build A and install locally. When I come to build B it pulls in the > > > remote copy of A and my local change in A is ignored. > > > > > > > > > > > > How can I stop this happening as it does not give a predicatable > > > > build? > > > > > I really need to tell B to update its dependencies except for A. > > > > > > > > > > > > Thanks in advance, > > > > > > > > > > > > Rich > > > > -- > > Baptiste <Batmat> MATHUS - http://batmat.net > > Sauvez un arbre, > > Mangez un castor ! > > > > --------------------------------------------------------------------- > > To unsubscribe, e-mail: [email protected] > > For additional commands, e-mail: [email protected]
signature.asc
Description: This is a digitally signed message part.
