To answer your last question: for my particular use case it just betrays a lack of elegance. But, you know, being a methematician, I'm afraid I have always been looking for elegance ;-)
And yes, I wish you could get 2.2 out soon, too ... Thx, Olaf djencks wrote: > > > On Mar 19, 2009, at 9:27 AM, Olaf Bergner wrote: > >> >> 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. >> > > Using plugins is much easier in trunk.... there we do (by default) > follow maven transitive dependencies, and track if they've changed > with src/history/dependency.xml files, and we also have the framework > plugin group which makes assembling a server very easy. I wish we > could get 2.2 out really soon. :-((((((( > >> 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. > > I don't think I've fought with this recently :-) I have some > recollection that some of the maven plugins could use some more > configuration about whether they package jars into the ear/war/rar > automatically depending on the dependency scope. For geronimo I think > we'd like a flag that would let the dependencies be "normal scope" so > geronimo would see them but maven would not include them in the ee > artifact. I think I saw that there were some changes recently but I > don't know if this is supported yet. > > Anyway your ear-building seems like it will work. > > How important do you see separate classloaders for each ejb jar and > rar? Do you expect any actual problems from a shared classloader or > does it just seem inelegant? > > thanks > david jencks > >> >> >> 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. >> > > > -- View this message in context: http://www.nabble.com/Suggestion-to-improve-packaging-of-ejb-jars-tp22588998s134p22608416.html Sent from the Apache Geronimo - Users mailing list archive at Nabble.com.
