Hi Everyone,
First of all thanks for a great tool. Needless to say that even despite the
early stage of development, it has already eased a great deal of pain
frequently involved with managing java projects. I use it for just about
everything these days :).
Nevertheless, IMHO there are some things that could use some leveraging or
at least could benefit from further discussion. J2EE workflow being one I
was concerned with recently.
Having wasted quite a bit of time yesterday night trying to get maven to
produce a decent ear deployment, it became very clear that there wasn't much
on the table.
'Semi-official' version of the solution (published on IBM website and
advocated on this list from time to time) implies creating subprojects for
e.g. web-project, ejb-project, etc. plus a master
project to produce a final ear file. IMHO this approach spirals out of
control very quickly.
- For one thing, producing deliverables from those subprojects (e.g. war
file
or ejb jar) is useless for the master ear project because to the best of my
knowledge you cannot declare wars or ejbs as dependencies at the moment.
- Secondly, I have noticed that maven project file inheritance doesn't work
very well with
multi-level inheritance. If your 'master' project already
extends some other template then the subprojects of that master project are
going to have some trouble with things like finding sources. Plus xdoclet
plugin began doing some strange things I didn't have the time to look into.
This could be because of some not-so-correct statements in one of the parent
project.xml documents (hence of my own making). Has anyone done much
extending beyond simple 1 level type?
- Thirdly, you are going to end up with a maintenance nightmare. A stack of
project.xml files that add very little value or structure to the project.
As a result, I've ended up reworking several plugins to get around some of
this, but first a bit on the logic behind it.
>From what I managed to grasp out of using maven, the golden rule of maven
based project development seems to be:
IF YOUR PROJECT CAN PRODUCE A JAR (and that's more or less it) IT SHOULD.
1. If there is sufficient value-added in breaking the source base apart, it
is definitely worth doing it because it would automatically share that value
added with other projects via the repository.
2. Smaller projects are easier to maintain
Whether it's the jakarta.apache.org inheritance to blame for this is another
matter. I would generally agree with the above moto.
However, some projects (let's call them INTEGRATION projects) cannot follow
the above
golden rule because they need to put together all these jars possibly
package in some auxiliaries and produce a final deliverable that can be a
war
or an ear. Integration projects would then focus not so much on artefact
reuse, but on producing final deliverables. It is for such projects that
this discussion is intended.
Is there any use in drawing distinction between an integration project and a
standard project?
I think there is and here is an example.
Let's say I have a project called 'myproject', which would be very much a
standard J2EE project that would contain a jar of ejbs/something else and a
war. With the end result packaged into an ear.
such an integration project would contain all the usual stuff including
things like
<dependency>
<properties>
<ejb.bundle.jar>true</ejb.bundle.jar>
</properties>
</dependency>
or <war.bundle.jar> and <ear.bundle.jar> respectively.
What you would get as a result of running ejb:ejb, war:war and ear:ear is an
ejb jar (with dependent jars packaged in), a war file (with dependent jars
packaged in) and an ear file that (optionally) contains
${maven.final.name}.war file ${maven.final.name}.jar file and whatever
ear.bundle.jar dependencies.
Paths to descriptors like ejb-jar.xml, application.xml and web.xml could be
as usually overridden in project.properties or elsewhere. Combine that with
xdoclet and you get the whole J2EE project in no time at all. Combine that
with JBOSS goals and that's pretty much all you need to build/deploy your
EAR or WAR or EJB jar in one shot.
I've somewhat modified ejb, war and ear plugin to mimic functionality of the
existing jar plugin including ability to snapshot/install/deploy = the usual
stuff.
If anyone thinks there is some value in this approach I could submit patches
to the relevant plugins. It's not too much work in any case.
regards,
dima
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
