That sounds right.
As far as I know, Maven assumes that releases are immutable, but snapshots
are not. So I could just use {some version number}-SNAPSHOT for all of our
projects and they would depend on each others' snapshot versions.
As far as I remember, the reason why I've chosen version numbers instead of
SNAPSHOTs is that given a 'snapshot' (not in the Maven sense) of a project
and it's runtime dependencies, it is possible to go and find the sources he
artifacts were built from.
So in our current setup, a self-containing 'release' of project a contains
A-12.jar
B-19.jar
C-123.jar
D-111.jarThe version numbers are CI build numbers. Using snapshots (and without manual versioning), this would look like A-1-SNAPSHOT, B-1-SNAPSHOT, etc. However, this should not be a problem as there are hundred other ways of tying an artifact to a build / source revision... So you recommend just using a fixed version and SNAPSHOTs instead of 'RELEASE's? Sorry for being confusing, this is my first encounter with Maven (and even with these hacks it's much more convenient than Ant, at least for our purposes). Thanks, Mate On Tue, Feb 1, 2011 at 2:43 PM, Ron Wheeler <[email protected]>wrote: > It does seem that you are describing the way SNAPSHOTS work. > > Can you identify any particular problem in your environment that prevents > you from working according to the Best Practices that thousands of > organizations are following? > I can not see from anything that you have described so far that is > abnormal. > We have 70 projects that make up a large LMS and it depends on 60+ third > party libraries and most of the war files include dependencies on our > utilities and web services. > > We do not use CI but dozens of regulars here do and can help make that work > correctly. > > Can you give a short description of the issues that made you abandon > SNAPSHOTS? > > > Ron > > > On 01/02/2011 9:22 AM, Mate Varga wrote: > >> What assumptions do I break except the immutability of an artifact with a >> specific version? (Which is only broken locally, and mvn should not really >> know about it, and it should not affect anything as mvn does not copy >> local >> artifacts anywhere.) >> >> Well, then the easiest thing is to explain what I'd like to do -- and >> maybe >> there's some other way to achieve it. >> >> (let's assume we have 3 projects, A, B, C,D; A depends on B, B depends on >> C >> and A depends on D >> - we don't have major / minor versions at all -- we do not want and we do >> not need a separate release procedure. Every successful CI build is >> considered to be a new version. Obviously, successful CI builds should be >> handled as snapshots, but if project B has been successfully built in the >> CI, then each following build of A should be using that version. Therefore >> the version numbers should be incremented automatically (CI build number >> could be used for that) >> - developers should be able to modify and build project B locally, and >> then >> modify and build A (and A should use B which was built locally) >> >> Currently, what I do is >> - have two profiles, a 'local' and a 'CI', which are activated >> automatically >> depending on the environment >> - after successful CI builds, artifacts are deployed to the repo manager >> (this works perfectly) >> - locally built artifacts have version no. 99999999 >> - if an internal project references another internal project, then it >> refers >> to its 'LATEST' version >> >> Are there other ways to achieve similar results? Please do not criticize >> the >> way we do releases, as this is 'given', and it's the result of the >> environment we work in. We cannot have major/minor releases, nor can we >> manually version each release. I'd be very happy if there were a proper >> way >> to do what we're doing in a bit hacky way now. >> >> Thanks, >> Mate >> >> On Tue, Feb 1, 2011 at 1:22 PM, Stephen Connolly< >> [email protected]> wrote: >> >> ugh this is just so wrong I don't know where to start. >>> >>> please consider using SNAPSHOTS as they are the correct way >>> >>> LATEST and RELEASE do not mean what you think they mean, and they have >>> been >>> deprecated. their use is no longer supported. >>> >>> maven makes assumptions about non-SNAPSHOT versions which you are >>> breaking >>> behind its back. >>> >>> there be dragons here >>> >>> - Stephen >>> >>> --- >>> Sent from my Android phone, so random spelling mistakes, random nonsense >>> words and other nonsense are a direct result of using swype to type on >>> the >>> screen >>> On 1 Feb 2011 11:13, "Mate Varga"<[email protected]> wrote: >>> >>> > > --------------------------------------------------------------------- > To unsubscribe, e-mail: [email protected] > For additional commands, e-mail: [email protected] > >
