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: users-unsubscr...@maven.apache.org
For additional commands, e-mail: users-h...@maven.apache.org
