geronimo-dependency.xml
Folks, In trunk, I've noticed that dependencies specified in geronimo-dependency.xml without an explicit version get resolved to an incorrect version when installed. For example, the root pom defines geronimo-schema-j2ee_1.4 dependency with version 1.2. But in the final javaee assembly only the version 1.1-SNAPSHOT was installed. I see the same issue with other such dependencies. Is anyone else seeing that too? Looks like we will need to specify explicit versions in the geronimo-dependency.xml files. If so, how do we keep the versions in synch with the root pom? Jarek
Re: geronimo-dependency.xml
On 10/12/07, David Jencks <[EMAIL PROTECTED]> wrote: > > On Oct 12, 2007, at 8:28 AM, Prasad Kashyap wrote: > > This is geronimo's "transitive depenendency" feature. When you > include a jar with such a file in a configuration's dependencies, all > the jars listed in the g-d.xml file also get included (recursively). > > I'm not longer sure this g-d.xml file is a wonderful idea. There > aren't that many of them and they seem to mostly cause confusion. Yes, it's definitely confusing me :) Should we try to eliminating the geronimo-dependency.xml files that we have right now? I can take a stab at it if people agree. Jarek
Re: geronimo-dependency.xml
On Oct 12, 2007, at 8:28 AM, Prasad Kashyap wrote: A quick investigation into this gave rise to some insights and more questions - Insights: 1) An explicit-versions.properties gets generated by the PackageMojo while building every config. 2) I doubt if this is getting serialized into the car. So I am unsure if this ever gets used. It is used when "compiling" the car file. It's intended only to restrict the c-m-p view of the local maven repo to make it look more like a geronimo repo. It would definitely not be appropriate to use it at any other time. 3) An explicit-version.properties gets generated by the InstallModulesMojo while building assembles in 2.0 but not in trunk. 4) And obviously, we are not using InstallModulesMojo for assembly in trunk. Actually we are using InstallModuleMojo in trunk, however it now uses the PluginInstallerGBean to do all the work. Since we're using the same plugin installer as we would be in a running geronimo server, there is no way to figure out what an appropriate explicit- version.properties would be or no way to send one from the maven environment into the plugin. Questions: 1) what is the explicit-version.properties used for (in configs and in 2.0 assembly) ? As noted above, to filter the maven repo to the versions specified in the pom 2) what is the geronimo-dependency.xml used for ? (a handful of modules contain it) This is geronimo's "transitive depenendency" feature. When you include a jar with such a file in a configuration's dependencies, all the jars listed in the g-d.xml file also get included (recursively). I'm not longer sure this g-d.xml file is a wonderful idea. There aren't that many of them and they seem to mostly cause confusion. Thanx Prasad On 10/12/07, Jarek Gawor <[EMAIL PROTECTED]> wrote: Folks, In trunk, I've noticed that dependencies specified in geronimo-dependency.xml without an explicit version get resolved to an incorrect version when installed. For example, the root pom defines geronimo-schema-j2ee_1.4 dependency with version 1.2. But in the final javaee assembly only the version 1.1-SNAPSHOT was installed. I see the same issue with other such dependencies. Is anyone else seeing that too? Looks like we will need to specify explicit versions in the geronimo-dependency.xml files. If so, how do we keep the versions in synch with the root pom? I'm starting to wonder if we should abandon the idea of allowing you to leave out versions in dependencies so geronimo will pick up the latest available. The alternative hot-upgrade method would be to explicitly map the old version to the new version in artifact_aliases.properties. If we decided on this approach we could insert all the versions into the g-d.xml during the build. This would be a major philosophical change so I'd definitely like some discussion before we decide. thanks david jencks Jarek
Re: geronimo-dependency.xml
A quick investigation into this gave rise to some insights and more questions - Insights: 1) An explicit-versions.properties gets generated by the PackageMojo while building every config. 2) I doubt if this is getting serialized into the car. So I am unsure if this ever gets used. 3) An explicit-version.properties gets generated by the InstallModulesMojo while building assembles in 2.0 but not in trunk. 4) And obviously, we are not using InstallModulesMojo for assembly in trunk. Questions: 1) what is the explicit-version.properties used for (in configs and in 2.0 assembly) ? 2) what is the geronimo-dependency.xml used for ? (a handful of modules contain it) Thanx Prasad On 10/12/07, Jarek Gawor <[EMAIL PROTECTED]> wrote: > Folks, > > In trunk, I've noticed that dependencies specified in > geronimo-dependency.xml without an explicit version get resolved to an > incorrect version when installed. For example, the root pom defines > geronimo-schema-j2ee_1.4 dependency with version 1.2. But in the final > javaee assembly only the version 1.1-SNAPSHOT was installed. I see the > same issue with other such dependencies. > > Is anyone else seeing that too? Looks like we will need to specify > explicit versions in the geronimo-dependency.xml files. If so, how do > we keep the versions in synch with the root pom? > > Jarek >
Re: geronimo-dependency.xml
+1 -Donald Jarek Gawor wrote: On 10/12/07, David Jencks <[EMAIL PROTECTED]> wrote: On Oct 12, 2007, at 8:28 AM, Prasad Kashyap wrote: This is geronimo's "transitive depenendency" feature. When you include a jar with such a file in a configuration's dependencies, all the jars listed in the g-d.xml file also get included (recursively). I'm not longer sure this g-d.xml file is a wonderful idea. There aren't that many of them and they seem to mostly cause confusion. Yes, it's definitely confusing me :) Should we try to eliminating the geronimo-dependency.xml files that we have right now? I can take a stab at it if people agree. Jarek smime.p7s Description: S/MIME Cryptographic Signature
[jira] Created: (GERONIMO-2937) clean up geronimo-openejb geronimo-dependency.xml
clean up geronimo-openejb geronimo-dependency.xml - Key: GERONIMO-2937 URL: https://issues.apache.org/jira/browse/GERONIMO-2937 Project: Geronimo Issue Type: Bug Security Level: public (Regular issues) Affects Versions: 2.0-M3 Reporter: David Jencks Fix For: 2.0-beta1 At least the geronimo-openejb geronimo-dependency.xml needs to be drastically cleaned up. Guidelines for when to put a dependency in geronimo-dependency.xml rather than a config dependency: - If the jar is something that will ONLY be used by the jar being built or things that MUST use the jar being built and there is NO CHANCE anyone else will want to use the jar put it in geronimo-dependency.xml. Typical examples of this are when you are integrating an external project such as jetty, tomcat, or openejb. Generally it is not appropriate to put a library in geronimo-dependency.xml since someone else might want to use it but not your jar. - In all other cases but the dependency in a config.Put it in the config that you think everyone who wants to use the jar will depend on, not necessarily in the config that depends on the jar you are building. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Closed: (GERONIMO-2937) clean up geronimo-openejb geronimo-dependency.xml
[ https://issues.apache.org/jira/browse/GERONIMO-2937?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] David Jencks closed GERONIMO-2937. -- Resolution: Fixed Assignee: David Jencks At some point I did clean up the geronimo-dependencies.xml, but these principles should really be in a more accessible place than this jira > clean up geronimo-openejb geronimo-dependency.xml > - > > Key: GERONIMO-2937 > URL: https://issues.apache.org/jira/browse/GERONIMO-2937 > Project: Geronimo > Issue Type: Bug > Security Level: public(Regular issues) >Affects Versions: 2.0-M3 >Reporter: David Jencks > Assigned To: David Jencks > Fix For: 2.0-M4 > > > At least the geronimo-openejb geronimo-dependency.xml needs to be drastically > cleaned up. > Guidelines for when to put a dependency in geronimo-dependency.xml rather > than a config dependency: > - If the jar is something that will ONLY be used by the jar being built or > things that MUST use the jar being built and there is NO CHANCE anyone else > will want to use the jar put it in geronimo-dependency.xml. Typical examples > of this are when you are integrating an external project such as jetty, > tomcat, or openejb. Generally it is not appropriate to put a library in > geronimo-dependency.xml since someone else might want to use it but not your > jar. > - In all other cases but the dependency in a config.Put it in the config > that you think everyone who wants to use the jar will depend on, not > necessarily in the config that depends on the jar you are building. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
Re: svn commit: r584194 - in /geronimo/server/trunk: modules/geronimo-openejb/src/main/resources/META-INF/geronimo-dependency.xml pom.xml
Could we investigate this more and remove the dependency? I really doubt we should need to pull this in. thanks david jencks On Oct 12, 2007, at 8:55 AM, [EMAIL PROTECTED] wrote: Author: gawor Date: Fri Oct 12 08:55:29 2007 New Revision: 584194 URL: http://svn.apache.org/viewvc?rev=584194&view=rev Log: openejb now needs commons-dbcp dependency (GERONIMO-3531) Modified: geronimo/server/trunk/modules/geronimo-openejb/src/main/ resources/META-INF/geronimo-dependency.xml geronimo/server/trunk/pom.xml Modified: geronimo/server/trunk/modules/geronimo-openejb/src/main/ resources/META-INF/geronimo-dependency.xml URL: http://svn.apache.org/viewvc/geronimo/server/trunk/modules/ geronimo-openejb/src/main/resources/META-INF/geronimo- dependency.xml?rev=584194&r1=584193&r2=584194&view=diff == --- geronimo/server/trunk/modules/geronimo-openejb/src/main/ resources/META-INF/geronimo-dependency.xml (original) +++ geronimo/server/trunk/modules/geronimo-openejb/src/main/ resources/META-INF/geronimo-dependency.xml Fri Oct 12 08:55:29 2007 @@ -63,4 +63,8 @@ asm asm-commons + + commons-dbcp + commons-dbcp + Modified: geronimo/server/trunk/pom.xml URL: http://svn.apache.org/viewvc/geronimo/server/trunk/pom.xml? rev=584194&r1=584193&r2=584194&view=diff == --- geronimo/server/trunk/pom.xml (original) +++ geronimo/server/trunk/pom.xml Fri Oct 12 08:55:29 2007 @@ -443,6 +443,12 @@ +commons-dbcp +commons-dbcp +1.3-SNAPSHOT + + + org.objectweb.howl howl 1.0.1-1
Re: svn commit: r584194 - in /geronimo/server/trunk: modules/geronimo-openejb/src/main/resources/META-INF/geronimo-dependency.xml pom.xml
David, I did investigate it. But maybe there is a better solution. Here's the change in OpenEJB: http://svn.apache.org/viewvc/openejb/trunk/openejb3/server/openejb-ejbd/src/main/java/org/apache/openejb/server/ejbd/JndiRequestHandler.java?r1=570629&r2=581127 Jarek On 10/12/07, David Jencks <[EMAIL PROTECTED]> wrote: > Could we investigate this more and remove the dependency? I really > doubt we should need to pull this in. > > thanks > david jencks > > On Oct 12, 2007, at 8:55 AM, [EMAIL PROTECTED] wrote: > > > Author: gawor > > Date: Fri Oct 12 08:55:29 2007 > > New Revision: 584194 > > > > URL: http://svn.apache.org/viewvc?rev=584194&view=rev > > Log: > > openejb now needs commons-dbcp dependency (GERONIMO-3531) > > > > Modified: > > geronimo/server/trunk/modules/geronimo-openejb/src/main/ > > resources/META-INF/geronimo-dependency.xml > > geronimo/server/trunk/pom.xml > > > > Modified: geronimo/server/trunk/modules/geronimo-openejb/src/main/ > > resources/META-INF/geronimo-dependency.xml > > URL: http://svn.apache.org/viewvc/geronimo/server/trunk/modules/ > > geronimo-openejb/src/main/resources/META-INF/geronimo- > > dependency.xml?rev=584194&r1=584193&r2=584194&view=diff > > ====== > > > > --- geronimo/server/trunk/modules/geronimo-openejb/src/main/ > > resources/META-INF/geronimo-dependency.xml (original) > > +++ geronimo/server/trunk/modules/geronimo-openejb/src/main/ > > resources/META-INF/geronimo-dependency.xml Fri Oct 12 08:55:29 2007 > > @@ -63,4 +63,8 @@ > >asm > >asm-commons > > > > + > > + commons-dbcp > > + commons-dbcp > > + > > > > > > Modified: geronimo/server/trunk/pom.xml > > URL: http://svn.apache.org/viewvc/geronimo/server/trunk/pom.xml? > > rev=584194&r1=584193&r2=584194&view=diff > > == > > > > --- geronimo/server/trunk/pom.xml (original) > > +++ geronimo/server/trunk/pom.xml Fri Oct 12 08:55:29 2007 > > @@ -443,6 +443,12 @@ > > > > > > > > +commons-dbcp > > +commons-dbcp > > +1.3-SNAPSHOT > > + > > + > > + > > org.objectweb.howl > > howl > > 1.0.1-1 > > > > > >
[jira] Created: (GERONIMO-2823) System class loader should not be searched for resource META-INF/geronimo-dependency.xml by AbstractRepository.getDependencies
System class loader should not be searched for resource META-INF/geronimo-dependency.xml by AbstractRepository.getDependencies -- Key: GERONIMO-2823 URL: https://issues.apache.org/jira/browse/GERONIMO-2823 Project: Geronimo Issue Type: Bug Security Level: public (Regular issues) Components: dependencies Affects Versions: 2.0-M1 Reporter: Gianny Damour Assigned To: Gianny Damour AbstractRepository.getDependencies loads the resource META-INF/geronimo-dependency.xml in order to retrieve the child dependencies of the provided Artifact. The system class loader should be excluded when this resource is loaded as it may result in an infinite loop. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Closed: (GERONIMO-2823) System class loader should not be searched for resource META-INF/geronimo-dependency.xml by AbstractRepository.getDependencies
[ https://issues.apache.org/jira/browse/GERONIMO-2823?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Gianny Damour closed GERONIMO-2823. --- Resolution: Fixed Fix Version/s: 2.0-beta1 This is now fixed. > System class loader should not be searched for resource > META-INF/geronimo-dependency.xml by AbstractRepository.getDependencies > -- > > Key: GERONIMO-2823 > URL: https://issues.apache.org/jira/browse/GERONIMO-2823 > Project: Geronimo > Issue Type: Bug > Security Level: public(Regular issues) > Components: dependencies >Affects Versions: 2.0-M1 >Reporter: Gianny Damour > Assigned To: Gianny Damour > Fix For: 2.0-beta1 > > > AbstractRepository.getDependencies loads the resource > META-INF/geronimo-dependency.xml in order to retrieve the child dependencies > of the provided Artifact. The system class loader should be excluded when > this resource is loaded as it may result in an infinite loop. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Reopened: (GERONIMO-2823) System class loader should not be searched for resource META-INF/geronimo-dependency.xml by AbstractRepository.getDependencies
[ https://issues.apache.org/jira/browse/GERONIMO-2823?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] David Jencks reopened GERONIMO-2823: porting to 1.2 > System class loader should not be searched for resource > META-INF/geronimo-dependency.xml by AbstractRepository.getDependencies > -- > > Key: GERONIMO-2823 > URL: https://issues.apache.org/jira/browse/GERONIMO-2823 > Project: Geronimo > Issue Type: Bug > Security Level: public(Regular issues) > Components: dependencies >Affects Versions: 1.2, 2.0-M1 >Reporter: Gianny Damour > Assigned To: Gianny Damour > Fix For: 1.2, 2.0-M3 > > > AbstractRepository.getDependencies loads the resource > META-INF/geronimo-dependency.xml in order to retrieve the child dependencies > of the provided Artifact. The system class loader should be excluded when > this resource is loaded as it may result in an infinite loop. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Updated: (GERONIMO-2823) System class loader should not be searched for resource META-INF/geronimo-dependency.xml by AbstractRepository.getDependencies
[ https://issues.apache.org/jira/browse/GERONIMO-2823?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] David Jencks updated GERONIMO-2823: --- Affects Version/s: 1.2 Fix Version/s: 1.2 Ported to 1.2 in rev 514937 > System class loader should not be searched for resource > META-INF/geronimo-dependency.xml by AbstractRepository.getDependencies > -- > > Key: GERONIMO-2823 > URL: https://issues.apache.org/jira/browse/GERONIMO-2823 > Project: Geronimo > Issue Type: Bug > Security Level: public(Regular issues) > Components: dependencies >Affects Versions: 1.2, 2.0-M1 >Reporter: Gianny Damour > Assigned To: Gianny Damour > Fix For: 1.2, 2.0-M3 > > > AbstractRepository.getDependencies loads the resource > META-INF/geronimo-dependency.xml in order to retrieve the child dependencies > of the provided Artifact. The system class loader should be excluded when > this resource is loaded as it may result in an infinite loop. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Closed: (GERONIMO-2823) System class loader should not be searched for resource META-INF/geronimo-dependency.xml by AbstractRepository.getDependencies
[ https://issues.apache.org/jira/browse/GERONIMO-2823?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] David Jencks closed GERONIMO-2823. -- Resolution: Fixed port done > System class loader should not be searched for resource > META-INF/geronimo-dependency.xml by AbstractRepository.getDependencies > -- > > Key: GERONIMO-2823 > URL: https://issues.apache.org/jira/browse/GERONIMO-2823 > Project: Geronimo > Issue Type: Bug > Security Level: public(Regular issues) > Components: dependencies >Affects Versions: 1.2, 2.0-M1 >Reporter: Gianny Damour > Assigned To: Gianny Damour > Fix For: 1.2, 2.0-M3 > > > AbstractRepository.getDependencies loads the resource > META-INF/geronimo-dependency.xml in order to retrieve the child dependencies > of the provided Artifact. The system class loader should be excluded when > this resource is loaded as it may result in an infinite loop. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
Re: svn commit: r631012 - in /geronimo/server/trunk/plugins/openejb/geronimo-openejb: pom.xml src/main/resources/META-INF/geronimo-dependency.xml
Thanks for this. Excellent change.
-David
On Feb 25, 2008, at 1:49 PM, [EMAIL PROTECTED] wrote:
Author: gawor
Date: Mon Feb 25 13:49:02 2008
New Revision: 631012
URL: http://svn.apache.org/viewvc?rev=631012&view=rev
Log:
less maintainace headaches
Modified:
geronimo/server/trunk/plugins/openejb/geronimo-openejb/pom.xml
geronimo/server/trunk/plugins/openejb/geronimo-openejb/src/main/
resources/META-INF/geronimo-dependency.xml
Modified: geronimo/server/trunk/plugins/openejb/geronimo-openejb/
pom.xml
URL:
http://svn.apache.org/viewvc/geronimo/server/trunk/plugins/openejb/geronimo-openejb/pom.xml?rev=631012&r1=631011&r2=631012&view=diff
=
=
=
=
=
=
=
=
==
--- geronimo/server/trunk/plugins/openejb/geronimo-openejb/pom.xml
(original)
+++ geronimo/server/trunk/plugins/openejb/geronimo-openejb/pom.xml
Mon Feb 25 13:49:02 2008
@@ -146,4 +146,13 @@
+
+
+
+src/main/resources
+true
+
+
+
+
Modified: geronimo/server/trunk/plugins/openejb/geronimo-openejb/src/
main/resources/META-INF/geronimo-dependency.xml
URL:
http://svn.apache.org/viewvc/geronimo/server/trunk/plugins/openejb/geronimo-openejb/src/main/resources/META-INF/geronimo-dependency.xml?rev=631012&r1=631011&r2=631012&view=diff
=
=
=
=
=
=
=
=
==
--- geronimo/server/trunk/plugins/openejb/geronimo-openejb/src/main/
resources/META-INF/geronimo-dependency.xml (original)
+++ geronimo/server/trunk/plugins/openejb/geronimo-openejb/src/main/
resources/META-INF/geronimo-dependency.xml Mon Feb 25 13:49:02 2008
@@ -20,32 +20,32 @@
org.apache.openejb
openejb-loader
- 3.0.0-SNAPSHOT
+ ${openejbVersion}
org.apache.openejb
openejb-ejbd
- 3.0.0-SNAPSHOT
+ ${openejbVersion}
org.apache.openejb
openejb-server
- 3.0.0-SNAPSHOT
+ ${openejbVersion}
org.apache.openejb
openejb-client
- 3.0.0-SNAPSHOT
+ ${openejbVersion}
org.apache.openejb
openejb-javaagent
- 3.0.0-SNAPSHOT
+ ${openejbVersion}
org.apache.openejb
openejb-jee
- 3.0.0-SNAPSHOT
+ ${openejbVersion}
org.apache.xbean
Re: [jira] Closed: (GERONIMO-2823) System class loader should not be searched for resource META-INF/geronimo-dependency.xml by AbstractRepository.getDependencies
Thanks! I ran into this problem a while back and it was really frustrating! david jencks On Feb 12, 2007, at 3:51 AM, Gianny Damour (JIRA) wrote: [ https://issues.apache.org/jira/browse/GERONIMO-2823? page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Gianny Damour closed GERONIMO-2823. --- Resolution: Fixed Fix Version/s: 2.0-beta1 This is now fixed. System class loader should not be searched for resource META-INF/ geronimo-dependency.xml by AbstractRepository.getDependencies - - Key: GERONIMO-2823 URL: https://issues.apache.org/jira/browse/ GERONIMO-2823 Project: Geronimo Issue Type: Bug Security Level: public(Regular issues) Components: dependencies Affects Versions: 2.0-M1 Reporter: Gianny Damour Assigned To: Gianny Damour Fix For: 2.0-beta1 AbstractRepository.getDependencies loads the resource META-INF/ geronimo-dependency.xml in order to retrieve the child dependencies of the provided Artifact. The system class loader should be excluded when this resource is loaded as it may result in an infinite loop. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
