Hallo
both seems equally possible. you can inherit your pom from a prent pom
without defining modules in the parent.
you would need to release the parent on its own prior to its 'children'.
if you frequently release versions for every client a parent pom with
configured modules has some advantages. everything could be done on the
parent. if releases have a different cycle/roadmap from client to client
a would not use modules.
no matter what a parent pom is recommended (well from my side). the
common dependencies and profiles could all be defined in there. so a lot
of redundancy will be in there.
for very special clients which do not fit a maven profile i would
recommend a 'build' project which has the core project as a dependency.
either by using it as a parent (if profiles/assemblies are needed) or as
a dependency (for ex if only config files need to be added)
thats what i would do. others might have additional input? :)
regards
op
John Coleman schrieb:
Hi,
We have the fairly typical scenario where we want to build different
"flavours" of an application for our clients. Typically each client
requires a different set of properties files, for example, but there
might be further changes to the resources or classes.
How should we leverage Maven2 to achieve the best compromise between
repetition and reuse? At present we have Ant scripts with a lot of
repetition to do each customer build by packaging the common and unique
client files together.
My initial thought is to build a core JAR and have separate projects
that use this as a dependency, but it seems to make more sense to use
the subproject approach so we can at least inherit some of the common
POM properties like the company details and developer team. Perhaps the
core code could also go in a common project, but be used simply to graft
source code from rather than create an artefact?
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
