that only works for plugins, not for compile dependencies... I have the same problem, but I do my versioning slightly different. When I release my 1.0.0-SNAPSHOT, I'll make the release version 1.0.0.v20071126, and keep the development version at 1.0.0-SNAPSHOT...
Tom On Nov 26, 2007 5:32 PM, EJ Ciramella <[EMAIL PROTECTED]> wrote: > I don't remember exactly (and my list of mvn bookmarks aren't working as well > as they used to), but my recollection is if you put nothing for version > number, it depends on the metadata stored in your internal repository (as > long as that is kept up to date). Or was there a way to say "use the release > version", again, relying on your metadata.xml file in your internal > repository.... > > > -----Original Message----- > From: Borut Bolčina [mailto:[EMAIL PROTECTED] > Sent: Monday, November 26, 2007 2:32 AM > To: Maven > Subject: Version moving up fast > > Hello maven users, > > if one of our in-house jars (lets call it A.jar) is progressing fast in > terms of artifact version numbers (several times per week: 2.1 -> 2.2 > -> 2.3-> ... - > > 2.678 -> 2.679 -> ...), what is the best way for other artifacts which > depend on this "fast one" to always use the last one? All the artifacts > which depend on the A, would have to have their poms modified to > 2.1-SNAPSHOT, 2.2-SNAPSHOT etc. because the SNAPSHOT version is in the > trunk. This is error prone. I haven't looked into the release plugin yet, > but I don't think it addresses this issue. > > One solution might be to name the A's version to something like 999-SNAPSHOT > and then all the other jars would have their dependencies to this version. > This smells like a dead fish in the sewer to me. > > What do you say? > > --------------------------------------------------------------------- > To unsubscribe, e-mail: [EMAIL PROTECTED] > For additional commands, e-mail: [EMAIL PROTECTED] > >
