maven-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Dima Berastau" <>
Subject Re: maven j2ee workflow
Date Wed, 04 Jun 2003 13:21:46 GMT
 I don't actually tend to think of maven's emphasis on singularity as a bad
Taken in it's pure form producing *multiple* jars (or wars or ears for that
matter) from a *single* POM seems like a logical inconsistency. Think:
putting multiple <id> or <name> declarations into the POM.
 The point I was trying to drive home is that your single POM should be
capable of packaging (and hence distributing) your project in different
ways. ${}.jar ${}.war
${}.ear (and ${}-uber.jar for that matter)
should all be valid project artefacts. ejb, war and ear plugins would of
course have to offer a bit more to be useful. For example a war file could
contain a directory of jsps, etc and potentially some classes that would go
into WEB-INF/classes. I wouldn't want to create a whole new project/POM and
jar just to stick a utility XML-RPC servlet class which would give XML-RPC
clients access to my ejbs. I don't think any of these ideas are in conflict
with 'maven philosophy'. It's more a case of bringing maven philosophy and
the real world closer together.

 By and large what you can do with a jar you should be able to do with
war,ear and uber-jar (e.g. install/deploy/snapshot/etc).
 The project's workspace in the repository (remote or local) could then look
<id>/jars (could be deliverable and/or dependency)
<id>/wars (deliverable)
<id>/ears (deliverable)
<id>/uberjars (deliverable)

Some projects are best distributed as wars (web applications), some as ears
(j2ee applications), some as uberjars (e.g. command line
applications/background processes) and some as jars (for reuse in other
projects). Maven should be flexible enough to allow you to manage all of

I actually don't mind the fact that wars and ears cannot be defined as
In fact it seems to me they were not designed to be a dependency format to
start with (or maybe it's my outdated notion of dependency as something you
can stick on the classpath).

The next logical step (suggested by one of my friends) would be to tie these
results into the site generation plugin as links under 'downloads' section
for example.



I absolutely cannot envisage a situation that would make me go back to ant
:). In fact, I think that maven is capable of a lot more than it does ATM.
Maven's reactor is a great continuous integration tool for example. If only
maven was logging using a framework of some sort (e.g. log4j,
commons-logging), you could get nightlies with automatic email notification,
etc in no time. Correct me if I am wrong, but last time I checked there were
still quite a few System.out.println() lurking around.

> >
> > Many software projects are more complex than Jakarta Commons projects,
> > that "Jakarta Commons style" (which are projects typically producing
> > jar file) is currently where Maven shines best.
> I see this problem from a bit different perspective. Most, if not any
> single project - multiple jars concerns can be solved by structuring the
> codebase corectly. Two sample scenarios:
> 1) project that generates API jar and implemenation jar
> Move the interfaces that consitutute the API into a package of their
> own. Make implementation package depend on the API package. Optionally
> create a master project for buiding both of the above using reactor,
> plus common POM for extending
> 2) project that generates server classes and client stubs
> All of the codebase resides in the server side project. Client side
> project depends on the server side project, and generates the stubs (be
> it RMI/JRMP, RMI/IIOP or WSDL with JAXRPC) from binary classes, and
> packages them into a client jar
> It's not that maven is really lacking anything, it just encourages
> different approach to codebase management that is currently used by
> many projects. I'm aware that restructuring may be not a feasible option
> for many of them, so Maven provides support for 'incorrect' codebase
> sturcturing to some extent. Over time this support may be further
> improved, but this is not a high priority goal.
> R.
> ---------------------------------------------------------------------
> To unsubscribe, e-mail:
> For additional commands, e-mail:

To unsubscribe, e-mail:
For additional commands, e-mail:

View raw message