Brett Porter wrote:
Is it worthwhile publishing a few documents that show how various
project types would be set up for m2, like this?
- Brett
On 9/24/05, Kenney Westerhof <[EMAIL PROTECTED]> wrote:
On Fri, 23 Sep 2005, Eric Biesterfeld wrote:
You're pretty much set up for maven use, except for the 'overlay' system.
I'll demonstrate using maven2.
I see:
/base/pom.xml - base project
/base/client/pom.xml - grouping project for all clients, has parent ../pom.xml
/base/client/X/pom.xml - project for client X, has parent ../pom.xml
As you compile the client/a/java/* to the base/target/ I expect those
classes don't 'overlay' existing ones, because your build will break - the
base classes are always newer than the client/a sourcefiles.
So now you get 1 + count(clients) jars. For each client, that's 2 jars. If
you can live with that, then so far it's easy. If not, you can add
an 'assembly' goal to each client/a/pom.xml (ofcourse configuration
specified in client/pom.xml) to merge the two jars.
Btw, each client/a/pom.xml has a dependency on base/pom.xml.
For the property/html overlay: the property part (which is probably
going to end up in a jar /META-INF/ somewhere?) the assembly plugin
and/or the resources plugin could take care of that.
You need to use the unpack goal to unpack the base dependency
into client/a/target/classes/ (${project.build.outputDirectory}
(or another location if they shouldn't end up in the jar).
This goal is bound to the 'generate-resources' lifecycle phase.
Then maven2 will copy your client a's resources to the same location,
overwriting the other ones.
Or you could just specify a <resources> section in the client a pom
that has '../../html' in it. Be sure to specify that section
before the <resources> section that defines the client a resources.
That order will have the effect of client a's resources overwriting
the existing ones.
But it would ofcourse be best to have disjunct sets of resources
for base and the client projects, so that the client projects just 'add'
to the base project, not change it's behavior.
Maybe you can factor out the common features in the client projects,
and make projects for each of those features.
Then each client project just depends on the features that are appropriate
for that client. But it's probable that this won't work in your particular
case.
So, here are some ideas. Hope it helps!
I've worked at a number of shops that followed development practices similar to these, where they had "base" project contents and by customer customizations.
So, yes, I think that publishing documents, or even full or partial project mockups that demonstrated various strategies for the configuration of M2 projects would be really helpful to people. And a a feature of Maven Evangelism I believe that this would be particularly useful for teams that are interested in computing the "price" of migrating projects/project families from existing build systems to Maven.
And if the Maven use-case files were updated and kept in sync with the
examples, that would be even better.
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
