Re: Suggestion to improve packaging of ejb-jars
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 sha
Re: Suggestion to improve packaging of ejb-jars
On Mar 19, 2009, at 5:39 AM, Juergen Weber wrote: djencks wrote: 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. I think this is true for Open Source software. But companies (and especially banks) like ear files which developers can give to IT operations (who don't want to download libraries from the web while putting banking software into production). Sure, but the bank is almost certainly using some software from the outside world such as the app server, db driver, etc. So it needs a way to provide the required software to the developers (and qa, production, etc) and audit what is made available. And it still needs to document the relationship of artifacts to each other. IIUC the maven solution to this is to use a corporate repository manager such as nexus that lets you specify exactly what is available inside the company. The geronimo solution built on this is to assemble a custom server from bits in the repo manager and give that to IT operations all they have to do is unpack and start it. thanks david jencks Greetings, Juergen -- View this message in context: http://www.nabble.com/Suggestion-to-improve-packaging-of-ejb-jars-tp22588998s134p22599300.html Sent from the Apache Geronimo - Users mailing list archive at Nabble.com.
Re: Suggestion to improve packaging of ejb-jars
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 behavio
Re: Suggestion to improve packaging of ejb-jars
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-impr
Re: Suggestion to improve packaging of ejb-jars
djencks wrote: > > > 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. > > I think this is true for Open Source software. But companies (and especially banks) like ear files which developers can give to IT operations (who don't want to download libraries from the web while putting banking software into production). Greetings, Juergen -- View this message in context: http://www.nabble.com/Suggestion-to-improve-packaging-of-ejb-jars-tp22588998s134p22599300.html Sent from the Apache Geronimo - Users mailing list archive at Nabble.com.
Re: Suggestion to improve packaging of ejb-jars
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.
Re: Suggestion to improve packaging of ejb-jars
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. 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? 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.
Re: Suggestion to improve packaging of ejb-jars
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.
