Thanks for your pointer, I will have a closer look at the maven-car-plugin. Last time I checked, however, I had to write the list of required dependencies by hand, a task that should be offloaded to maven/the maven-car-plugin, IMO.
As to your question: it is true that my solution for building an ear is not totally automatic, i.e. I have to decide up front which dependencies are to be shared between all modules. By putting those into a separate pom, however, and referencing that pom in scope "provided" from all jee modules, in scope "runtime" from my ear module maven more or less automatically produces a correctly packaged ear. Thx, Olaf djencks wrote: > > > On Mar 18, 2009, at 3:23 PM, Olaf Bergner wrote: > >> >> Obviously, adopting the Geronimo way of explicitly declaring a >> module's >> dependencies as references to jars contained in Geronimo's >> repository is the >> most explicit way of making that module's needs known to the world. >> On the >> other hand, it may be argued that packaging dependencies that are only >> needed by one module inside that module is still closer to the >> "truth" than >> throwing them all indifferently into the enclosing ear's lib >> directory. > > I tend to agree that the classloader structure of javaee applications > is not well defined and very likely it would be pretty handy to have > classloader-per-module for ejb apps and rars as well as the ear > classloader from the lib directory. In current geronimo, it's only > going to be a notation of what you'd prefer in a more ideal world. > > For wars in an ear, you can indeed specify geronimo dependencies for > the war alone referencing the g. repo rather than (and equivalent to) > including the jars in the war's WEB-INF/lib. > >> >> >> Moreover, it is precisely my use of maven and my meticulously >> managing my >> dependencies that led to this suggestion. I rely on maven's dependency >> management capabilities to automatically compute each module's >> classpath, >> leading to the scenario I described in my original post. >> >> Anyway: is there a maven plugin that allows me to convert my ear >> into a >> Geronimo plugin, using maven's knowledge about the required >> dependencies to >> automatically build the required environment entries? > > I don't entirely understand what you are asking for.... once you've > built an ear or war that includes some jars, you have to do some work > with the dependency plugin to take them out again. On the other hand > if you assemble an ear that does not include a bunch of jars in the > lib directory but the modules have maven dependencies that you need, > you can use the car-maven-plugin to build the ear into a geronimo > plugin that references the jars as (geronimo) dependencies. When you > install the plugin, it will pull the jars into geronimo also. > > thanks > david jencks > >> >> >> Thanks, >> Olaf >> >> >> djencks wrote: >>> >>> >>> On Mar 18, 2009, at 2:33 PM, Olaf Bergner wrote: >>> >>>> >>>> I have several ejb-jar packaged inside an ear. Libraries to be >>>> shared between >>>> some or all of these ejb-jars are placed inside the encompassing >>>> ear's "lib" >>>> directory, as decreed by the standard. Some libraries, however, are >>>> local to >>>> the using ejb-jar, i.e. they don't need to be shared. >>>> >>>> I tried to package these libraries inside the using ejb-jar, >>>> creating >>>> appropriate Class-Path entries in that ejb-jar's manifest file. >>>> This, >>>> however, leads to a deployment error as obviously the Class-Path >>>> entries in >>>> the ejb-jar's manifest file are resolved relative to the enclosing >>>> ear and >>>> are therefore not found. >>>> >>>> Suggestion: make Geronimo resolve those dependencies relative to the >>>> ejb-jar >>>> declaring them. Same goes for rars. >>>> >>>> What do you think? >>> >>> >>> rars already have a nested structure, anything inside has to be in a >>> jar. Or are you suggesting we support infinitely nested jars? >>> >>> In geronimo everything in all the ejb jars and rars ends up in the >>> same classloader so you won't get any difference in behavior by doing >>> this. >>> >>> I'm generally against these nested packagings. I think they were >>> dreamed up in the dark ages before people realized that their >>> software >>> was part of the worldwide software ecosystem and that you need to >>> document explicitly how your software relates to other stuff. This >>> is >>> the kind of problem maven tries to solve. People who still use ant >>> IMO still haven't recognized that this is something they can think >>> about. >>> >>> So, in geronimo I recommend packing as little as possible in an ear, >>> instead using dependencies to include the same jars from the geronimo >>> repo into the appropriate classloaders. >>> >>> thanks >>> david jencks >>> >>>> >>>> >>>> Cheers, >>>> Olaf >>>> -- >>>> View this message in context: >>>> http://www.nabble.com/Suggestion-to-improve-packaging-of-ejb-jars-tp22588998s134p22588998.html >>>> Sent from the Apache Geronimo - Users mailing list archive at >>>> Nabble.com. >>>> >>> >>> >>> >> >> -- >> View this message in context: >> http://www.nabble.com/Suggestion-to-improve-packaging-of-ejb-jars-tp22588998s134p22589890.html >> Sent from the Apache Geronimo - Users mailing list archive at >> Nabble.com. >> > > > -- View this message in context: http://www.nabble.com/Suggestion-to-improve-packaging-of-ejb-jars-tp22588998s134p22603235.html Sent from the Apache Geronimo - Users mailing list archive at Nabble.com.
