The buildnumber-maven-plugin is handy for this. There's some issues when issue git this Antony Stubbs has patched and fixed over on his github fork ( http://github.com/astubbs/buildnumber-maven-plugin ) which works great. Automatically pulls in the git branch name as a classifier for your artifacts.
No one upstream seemed interested in his patches tho apparently... -- Pull me down under... On Tue, Aug 17, 2010 at 10:04 PM, Nicola Musatti < [email protected]> wrote: > I'll try and provide a tentative answer to my own question. Feel free to > comment :-) > > As far as I can tell Maven doesn't provide a specific mechanism for what I > need. Ideally there would be a "variant" attribute that could be specified > along the GAV parameters, to be inserted between the artifactId in and the > version in the final name, but which would not be involved in version > ordering (i.e. project-a-0.0.1 would not necessarily come before > project-b-0.0.1). Such an attribute would allow keeping all variant > information in the dependencyManagement sections of my parent POM's, which > would be very nice. > > As it is I have different options, possibly combined together: I could > change the groupId for project variants, e.g. my.company.project.customer > and/or add a "-customer" suffix to my artifactId. > > I see no disadvantage in changing groupId's; on the contrary it would help > organize things in my Nexus repository. > > Changing artifactId's is certainly desirable in terms of traceability and > to help avoid delivery mistakes. On the other hand, while Maven doesn't seem > to require that a project directory be named as the artifactId, m2eclipse > imports Maven projects into Ecplise by artifactId rather than by directory. > I've yet to find out whether this may cause any problems. > > Cheers, > Nicola Musatti > > > Nicola Musatti wrote: > >> Hallo, >> I need advice on how to handle naming/versioning for artifacts built from >> separate branches of the same project, which evolve in parallel. >> >> Our product has a main, "standard" development line, but customers usually >> ask for customizations that make it necessary to spin off separate >> variants.When this happens each variant starts to follow its own time-line, >> with its own release schedule. >> >> From an SCM point of view - we use subversion - this translates to the >> standard product being developed on trunk while customer variants live in >> separate branches. Ideally the project's directory structure should be the >> same across variants, but resulting artifacts should be identifiable, e.g.: >> >> project-x.y.z for the standard product >> project-customer-m.n.o for a customer variants >> >> To further complicate things our product is actually made of several >> different Maven sub-projects and a customer variant is usually a combination >> of standard and customized sub-projects. We use an aggregator project to >> build the whole product. Different variants of this aggregator project >> combine the correct mix of standard and customized sub-projects. >> > > --------------------------------------------------------------------- > To unsubscribe, e-mail: [email protected] > For additional commands, e-mail: [email protected] > >
