Yes? :)
Perhaps this isn't the best example, because it's really a bad design due to
poor requirements gathering. However, a case study of a well-designed
3-client application would be useful.
In fact, this is not an uncommon problem for consulting companies. They get
a contract with one customer, and it's written as though it's a one off
project. Then marketing hears that one customer has this and it becomes a
product. Or, the president realizes that there's a small market for this
kind of application. However, each customer has a slightly different set of
requirements and suddenly the simple ant system that someone did in a day
isn't enough.
And the UIs are sort of the same, but they have some slightly different
requirements...
On 9/23/05, Brett Porter <[EMAIL PROTECTED]> 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!
> >
> > -- 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]
>
>
