On Wed, 2003-07-30 at 12:49, James CE Johnson wrote: > > > > -using the ejbjar task and all attributes > > -all attributes defineable via properties > > -ability to bundle pom defined ejb.bundle artifacts > > Don't forget ejb.manifest.classpath too.
Yeah its doing manifest generation with the manifest class path same code for that part thats in the current version. > > > -ability to bundle other files based on support file sets defined in > > properties > > -supports the dtd redirection of ejbjar > > That sounds cool. Be sure you have a mechanism for excluding files from > the final jarfile also. For instance, we have log4j.properties end up in > our target/classes (for good reasons) but, of course, we don't want that > to end up in the actual jarfile. (I posted a patch to jira earlier today > to enhance ejb:ejb to do exclusions.) The way the ant ejbjar tasks works it it pulls the nessesary files for the ejb by parsing a deployment descriptor (ejb-jar.xml) and only bundling the nessasary files and (configurably) the direct super classes/interfaces. The ability to add other files is provided by the <support> tag in the ejbjar task which is a fileset so you can pull in or exclude what ever you want. > > > First off is there any real interest in this as an enhancement to the > > ejb plugin? It is a fair departure from the original design is why im > > asking. > > We're using ejb:ejb quite happily as-is. My main issue with the current ejb:ejb goal was that a completly seperate class/directory structure had to be setup in order to pull in the appropriate deployment descriptors (ejb-jar.xml, jboss.xml, jaws.xml) as well as any other files. As well the current ejb:ejb goal has no support for the vendor specific subtasks which do things like run ejbc for weblogic, setup various DB tasks for web sphere, and run rmic to create the rmi interfaces for some app servers. The ant ejbjar task has a lot of work put into it to allow it to offload and automate a lot of the ejb generation tasks. I just feel that this work should be leverages easily. Kinda what Maven is all about to me. > > > > Secondly, ejbjar has the ability to support generation of multiple jars > > based off of diffrent deployment descriptors. It can do one per bean > > with each bean having its own descriptior. It can do one per bean from > > the main ejb-jar.xml file. It can do one jar with all the beans and a > > single descriptor. And it can even do one jar per bean based off of the > > name of the directory its in. > > That sounds like serious overkill. At least for the things we do here. Of > course, everybody has a different use-case :-) Yeah for me to. We only use jboss which has the simplest of cases for ejb generation, But one of the manin goals of Maven as I see it is to allow for virtually transparent usage of Ant without all of the build.xml. These capabilities are in Ant now, why not let the end user deside what level that want to take it to. > > > > > How should this sort of thing be supported under the deploy and install > > mechanism? Is there any other plugin which faces this port of problem i > > can use as a guide? Thanks -=Brian -- Brian Towles <[EMAIL PROTECTED]> --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
