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!
-- Kenney
> I'm doing some research on migrating to Maven from our ant project
> structure, or just adding Ivy. The problem comes that I've never seen a
> project in Maven such as ours. We have a product for <10 clients, with a
> potential client base of about 20. Unfortunately, while it uses a base API,
> each project is highly customized. Currently, our (simplified) project
> structure looks like this.
>
> /
> /client
> /client/a
> /client/a/html
> /client/a/java
> /client/a/properties
> /client/a/sql
> /client/b
> ...
> /html
> /java
> /properties
> /sql
>
> (Close enough, anyway.)
>
> Now, in the build process, information from the base html, java, properties,
> and sql is used to build the base structure. (Ignore sql for now) We then
> compile the client java into the same target directory, and overlay the
> properties and html directories *over* the core files.
>
> Yes, this is not the best idea. No, it can't be changed. (Immediately,
> anyway.)
>
> How much pain are we talking about? We're trying to make this more modular,
> but the UI will initially still be a complete entity. I see how to
> incorporate the multiple jars in the project, but how do you fit this into
> the single artifact system?
>
> (Do you just have to zip/unzip or use ant tasks?)
>
--
Kenney Westerhof
http://www.neonics.com
GPG public key: http://www.gods.nl/~forge/kenneyw.key
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
