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!
>
> -- 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]
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
