Re: new ear and ejb plugins

[Colin Sampaleanu <co...@exis.com>]

Thanks for doing these. I was attempting to use them in converting a 
multi-project (related) source set today. I have a few thoughts I wanted 
to get your feedback on.

- the ear plugin really assumes that all the artifacts it needs are 
produced by builds from other projects, in that it includes named 
dependencies in the ear, but can't really handle including artifacts 
produced in the current build. This is not necessarilly an issue when 
starting from scratch, but I see two disadvantages:
  - somebody converting from ant ant-based build will pretty likely have 
an ant build where source is compiled, jars are produced, wars are 
produced, ejbs are produced, and the ear is produced, all in the same 
project.  This seems to be a fairly typical setup, and switching over 
would require creating a whole new project just for the ear. In general, 
even when starting from scratch, when building a simple piece of 
software, it seems nasty to require two projects when one would have 
been enough, just so the ear can be built. I think it also makes logical 
sense; I can't think of a good reason, other than a bit of extra code, 
why one maven project shouldn't be able to build up all the artifacts to 
the level of the j2ee app (.ear).
  - on this basis, do you think it is worth it to improve the plugin so 
it can handle artifacts from the same build? The mechanism would have to 
allow a variable number of artifacts to be added. One easy way to do it 
would be if the dependency list could be dynamically updated (just 
before the goal is executed), but I presume maven can't do that, so a 
separate list of artifacts would work.

- the ejb plugin can only handle the concept of one ejb jar per project. 
This is somewhat problematic, since it is also normally wants to compile 
source, but it is relatively common for one set of source to produce 
multiple ejb jars, generally each jar relating to one logical area. I 
can't think of a way to handle this without some modification of the ejb 
plugin. One mechanism I can see working without too many changes is to 
have one project that compiles source and builds a jar which is 
installed in the local repo, then have x other projects which each build 
one ejb-jar, and they pull the needed classes from the code jar and 
others in the repo. What I do not like here is the sheer number of 
projects with this setup, and the amount of work to produce on ejb jar 
(build one project, then switch to another, and build that).

Any thoughts on any of this?

Regards, Colin

Nathan Coast wrote:

> Hi,
>
> The main objective of this work is to result in four plugins (ejb, jar,
> war, ear) that work in a consistent manner.  Where plugins perform 
> similar tasks, they should perform them in the same way configured by 
> similarly named properties.  I have followed as closely as possible 
> the existing processes for building jar and war files.  At the same 
> time I have incorporated the outcomes of these threads:
>
> http://www.mail-archive.com/turbine-maven-dev@jakarta.apache.org/msg04096.html
> http://www.mail-archive.com/turbine-maven-dev@jakarta.apache.org/msg04183.html
> and a few others threads that I cant find in mail archive :)
>
> four files attached
> ear.zip                   - the ear plugin source
> ejb.zip                   - the ejb plugin source
> exampleear-1.0-src.zip    - an example ejb project
> exampleejb-1.0-src.zip    - an example ejb project
>
> to install the plugins unzip the plugins beneath plugins-build and:
>
> jakarta-turbine-maven>maven maven:plugin -Dplugin.name=ear
> jakarta-turbine-maven>maven maven:plugin -Dplugin.name=ejb
>
>
> This is the pattern for each plugin:
>
> 1) if java sources are present, they are compiled using java:compile
>
> 2) Copying resources needed by the classfiles. the files defined by
> jarResources are copied to the maven.build.dest directory. ATM the
> maven.jarResources.basedir defaults to ${basedir} IMO this should 
> perhaps default to ${pom.build.SourceDirectory}
>
> 3) executing tests. if there are test sources, tests are compiled and
> executed using test:test
>
> 4) Additional sources / config files. there is a source directory which
> acts as the base directory for non-java sources to be included in the
> jar/war/ear file.
>
> properties and defaults:
> jar - (not implemented)
> ear - maven.ear.src         default src/application
> ejb - maven.ejb.src         default src/ejb
> war - maven.war.src         default src/webapp
>
> at present there is no mechanism for restricting the sets of files from
> this directory to be included in the assembled jar/ear/war file.
>
> 5) configuration files - e.g. web.xml, application.xml, ejb-jar.xml,
> MANIFEST.MF.
>
> by default, these all exist in the same location within the directories
> mentioned in point 4 as the final location within the assembled
> jar/ear/war files
>
> e.g.
> ear src/application/META-INF/application.xml
>     src/application/META-INF/MANIFEST.MF
>
> ejb src/ejb/META-INF/ejb-jar.xml
>     src/ejb/META-INF/MANIFEST.MF
>
> war src/webapp/META-INF/MANIFEST.MF
>     src/webapp/WEB-INF/web.xml
>
> 6) bundling of dependencies.  jar file dependencies can be included in 
> the
> assembled component by adding a property to the dependency within
> project.xml
> jar - <jar.bundle.jar>true</jar.bundle.jar>  - not implemented
> ear - <ear.bundle.jar>true</ear.bundle.jar>
> ejb - <ejb.bundle.jar>true</ejb.bundle.jar>
> war - <war.bundle.jar>true</war.bundle.jar>
>
> 7) creation of the manifest file
> as mentioned above, the location of manifest file defaults to the
> non-java-src-dir/META-INF/MANIFEST.MF file.  if this file exists, all of
> the
> standard manifest entries generated from the pom are merged with this 
> file
>
> 8) manifest Class-path: entries
> are generated by adding a property to the appropriate dependency within
> project.xml
> jar - <jar.manifest.classpath>true</jar.manifest.classpath> (not yet)
> ear - NA
> ejb - <ejb.manifest.classpath>true</ejb.manifest.classpath>
> war - NA
>
> 9) assembly of the component.  The component will be called:
> jar ${maven.build.dest}/${maven.final.name}.jar
> ear ${maven.build.dest}/${maven.final.name}.ear
> ejb ${maven.build.dest}/${maven.final.name}.jar
> war ${maven.build.dest}/${maven.final.name}.war
>
> 10) installation into local repo, each plugin has an 'install' goal
> which copies
> the assembled file into the repo.
>
> jar:install - copies to ${pom.id}/jars
> ear:install - copies to ${pom.id}/ears
> war:install - copies to ${pom.id}/wars
> ejb:install - copies to ${pom.id}/ejbs
>
> cheers
> Nathan
>
>------------------------------------------------------------------------
>
>--
>To unsubscribe, e-mail:   <ma...@jakarta.apache.org>
>For additional commands, e-mail: <ma...@jakarta.apache.org>
>