Heya, > Howdy all > > I have been working a major change to the ejb plugin for better use > internally on my stuff and what to get your feedback and gauge your > interest in it. > > The current ejb plugin uses the jar task, with the main reasoning being > that the ejbjar task could not import additional files (at least thats > whats in the comments). This is not altogether correct. > > The version im working on is a direct usage of the ejbjar task and has > facilities for all of the vendor specific subtasks and all of thier > attributes. Its pretty much done and working I just need to message it > into the plugin framework (install and deploy to wrap the diffent jar > names that come out of the vendor plugins and the generic jar) and > figure out how to get bcel into the classpath used by the ejbjar task > (to support direct dependency bundling via the ejbjar depencency > attribute). > > So what ive got it doing at this point is > > -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. > -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.) > > > ok that being said I have several questions > > 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. I'm about to post a patch that creates a goal ejb:ejb-client. That creates a much smaller jar that should have only the classes a client of the EJB needs. I'd appreciate feedback on that. > > 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 :-) > > 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 for your feedback > > -=Brian > > > > > -- > Brian Towles <[EMAIL PROTECTED]> > > > --------------------------------------------------------------------- To > unsubscribe, e-mail: [EMAIL PROTECTED] > For additional commands, e-mail: [EMAIL PROTECTED] --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
