We're using Hudson to do our builds and Archiva to host our Maven remote repo, which I'm quite happy with.
The only resolution we can put on these version numbers is either once every three weeks, or once a day. "Once every 3 weeks" versioning is already happening; "once a day" is too much to saddle a person with (hence my attempt to automate). BUT, not only does it look like it's not possible to do this, I can always incorporate this build number into a display in the software, as opposed to changing the artifact version. That should definitely suffice, and will keep Archiva from getting overloaded with artifacts unnecessarily. Thanks everyone! I've been convinced to let it go. :-p - Scott ----- Original Message ---- From: "Gorham-Engard, Frank" <[email protected]> To: Maven Users List <[email protected]> Sent: Sat, April 3, 2010 7:26:39 AM Subject: RE: Using variables in POM's version field Would I be right in thinking that the entire purpose of a SNAPSHOT artifact is so that dependent modules don't have to be edited every time a new artifact is produced. This makes the developer's job easier as long as they are willing to accept the risk of having the dependee artifact change at any time. If so, what would be reason for making an artifact with a build number in the artifact version string that changes every time the artifact is deployed and calling it a SNAPSHOT? The dependent developers would have to adjust their dependencies each time a new dependee artifact is generated. But, that is the way a release artifact works. Any advantage gained by deploying as a SNAPSHOT is eliminated by having a different version string each time. Have I made it clear why doing this is misguided? Just go ahead and deploy a release artifact with the build number in the version. The result is the same. One artifact per version string. Also, the unresolved build number doesn't occur if you create the new build number before starting Maven and pass it into the build as a property on the command line. All build systems will support this need. I noticed everyone has mentioned their favorite build system so I will mention mine, QuickBuild2. A free version is available that will support a limited number of projects. Includes a promotion model and configuration inheritance as part of its design. No plugins needed. <!-- Frank Gorham-Engard → "It is a misnomer to label any practice 'a best practice'; a practice is only best in the specific context in which it performs well." -----Original Message----- From: Kathryn Huxtable [mailto:[email protected]] Sent: Friday, April 02, 2010 7:39 PM To: Maven Users List Subject: Re: Using variables in POM's version field Correct, and it's a bad idea. -K On Apr 2, 2010, at 6:15 PM, Scott Susslin wrote: > I figured something like this was why it wasn't working. So sounds like, > given Maven 2, it can't work. True? > > > > ----- Original Message ---- > From: Justin Edelson <[email protected]> > To: Maven Users List <[email protected]> > Sent: Fri, April 2, 2010 4:05:10 PM > Subject: Re: Using variables in POM's version field > > Amongst other reasons, allowing runtime variable interpolation in the > coordinates would prevent the reactor from properly calculating a > multi-module build plan. The coordinates at the start of the build > must remain the coordinates throughout the build. > > On Apr 2, 2010, at 5:14 PM, Scott Susslin <[email protected]> wrote: > >> Why? >> >> Also, is it possible? >> >> >> >> ----- Original Message ---- >> From: Justin Edelson <[email protected]> >> To: Maven Users List <[email protected]> >> Sent: Fri, April 2, 2010 12:05:32 PM >> Subject: Re: Using variables in POM's version field >> >> This is a bad idea. Don't do it. >> >> On Apr 2, 2010, at 2:21 PM, Scott Susslin <[email protected]> wrote: >> >>> I'm trying to use the buildnumber plugin to control the version >>> field of a POM. >>> >>> <version>1.0.${buildNumber}-SNAPSHOT</version> >>> >>> The "package" phase works fine, creating a file with the parsed >>> value in the filename. The "install" and "deploy" don't seem to >>> parse the variable. When they run, I get something like the >>> following: >>> >>> [INFO] Installing PROJECT/artifact-0.1.334-SNAPSHOT.swc to ~.m2/ >>> repository/PROJECT/artifact/0.1.${buildNumber}-SNAPSHOT/ >>> artifact-0.1.${buildNumber}-SNAPSHOT.swc >>> >>> Anyone have any experience with this? >>> >>> Thanks >>> - Scott >>> >>> >>> >>> >>> >>> --------------------------------------------------------------------- >>> 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] >> > > --------------------------------------------------------------------- > 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] --------------------------------------------------------------------- To unsubscribe, e-mail: [email protected] For additional commands, e-mail: [email protected]
