maven-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Rafal Krzewski <Rafal.Krzew...@caltha.pl>
Subject Re: maven j2ee workflow
Date Wed, 04 Jun 2003 14:39:42 GMT
Dima Berastau wrote:

I think we have a bit of misunderstanding

> Hi,
>  I don't actually tend to think of maven's emphasis on singularity as a bad
> thing.
> 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.

Sorry but I'm unable to make out if you consider that 1-many
relationship right or wrong... Maybe I'm just tired. :-)

>  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. ${maven.final.name}.jar ${maven.final.name}.war
> ${maven.final.name}.ear (and ${maven.final.name}-uber.jar for that matter)
> should all be valid project artefacts. 

Amen. These should be valid target artifacts. At the same time, the
general principle is that if a projects generates a war it generates a
*single* war, and it does not generate any other type of artifact at the
same time.

> ejb, war and ear plugins would of
> course have to offer a bit more to be useful. 

Yeah, they are missing deploy/snapshot funcitonality at the moment.

> 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. 

You are mixing two things here - you are generating a war, but at the
same time you are compiling some java sources into a jar that you want
included into your war. You can solve it "the maven way" (declarative,
that is) by sprouting a jar project from the war project and depending
on it.
You can also solve it "the real world way", (imperative, programmatical)
by creating custom goals in maven.xml that use jar & war plugins to
build your project.

> 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.

I hope that at the time we combine Maven's capabilities with modern IDE
capabilities, doing things "the maven way" will be easy and straightforward.

>  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
> like:
> <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
> those.

That's been agreed on long time ago.

> I actually don't mind the fact that wars and ears cannot be defined as
> dependencies.

I'm not sure about the meaningfullness of ear dependencies, but war
dependencies are definetely going to be supported (to build your ears
declaratively!)

> 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).

Yes, the concept of dependenies is beyound that, but in the current
maven, the approximation of dependency=compilation classpath entry works
pretty well. Maven-new is very different in that respect.

> 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.

If they are proper artifacts, they should probably be distributed
through maven repositories, the download sections showing links to the
predefined repository available through http seems to be a good idea
though.
> P.S.
> 
> 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. 

Reactor is not really intended as a CI tool - Jason has an idea for a
separate Maven based project for that. Too bad he only so little free
time these days... (search list archives for 'Continuum')

> 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.

Email nagging was removed from reactor at some point, but I cannot
recall the rationale. Anyone?

> Correct me if I am wrong, but last time I checked there were
> still quite a few System.out.println() lurking around.

Very probable. They're not the only kind of ugly stuff that hangs on
around there... Patches wellcome :-)

R.



---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@maven.apache.org
For additional commands, e-mail: users-help@maven.apache.org


Mime
View raw message