Unfortunately what I suggested doesn't work because of http://jira.codehaus.org/browse/MDEPLOY-44 - setting uniqueVersion from the command line doesn't work together with deploy:deploy, only with deploy:deploy-file - of course you could use the latter but it gets even more cumbersome.
Kalle On 11/26/07, Kalle Korhonen <[EMAIL PROTECTED]> wrote: > > If you are releasing something, I think it's wrong to force your clients > to move onto the new versions. If the client modules using your module would > be in control of what they use, they'd update versions in their own > schedule, even skip some. I haven't tried, but I wonder if it'd work to use > both unique and non-unique versions. If you "release" for archiving > purposes, you could could just post a unique snapshot, otherwise you'd use > non-unique snapshots. You'd need to check if dependency resolution works > correctly in all cases with this approach. > > Kalle > > > On 11/25/07, Borut Bolčina <[EMAIL PROTECTED]> wrote: > > > > 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? > > > >
