Re: XSP block dependencies
On Mon, 2007-11-26 at 08:45 +0100, Reinhard Poetz wrote: The problem is that the groupId of the Avalon framework changed and that's the root of all evil in this case. We ever never need a dependency on Avalon 4.1.3 but how to express this in the managedDependencies section? The only chance for us is configuring exclusions but first you have to figure out that you have to do it at all (here the dependency module comes into play). I have also experienced very strange behaviour of the dependency resultion mechanism e.g. I exclude avalon-framework from being pulled in by commons-logging but then, when I use commons-beanutils, which pulls in commons-logging, the avalon-framework dependency is used again. TBH, I have no idea why the dependency resolution is still buggy after such a long time after the first final Maven 2 release :-/ I now added exclusion rules to all our explicit dependencies which pick up the old avalon-framework through transitive dependencies. Although that brings us out of jar hell for the moment, it is only a stop-gap solution. Any new explicit dependencies could bring back the problem. For once, it is not a fault of m2. It is doing the right thing. The problem is in the avalon-framework poms changing groupId and artefactId between versions. Maven should, however, provide a mechanism to deal with this globally in a parent pom. Here is the pedestrian approach I used to find the places where the exclusions needed to be inserted: 1.) rm -r $M2_REPO/avalon-framework 2.) fgrep avalon-framework-4 `find trunk -name .classpath` 3.) cd to first project directory containing a matching .classpath 4.) mvn -X eclipse:clean eclipse:eclipse 5.) Identify the explicit dependency with triggers the download of avalon-framework-4.1.3.pom. 6.) Add exclusion rule to that explicit dependency, e.g.: dependency groupIdcommons-httpclient/groupId artifactIdcommons-httpclient/artifactId + exclusions +exclusion + groupIdavalon-framework/groupId + artifactIdavalon-framework/artifactId +/exclusion + /exclusions /dependency 7.) mvn eclipse:clean eclipse:eclipse 8.) Rinse and repeat. Cheers, Alfred.
Re: XSP block dependencies
On 07.02.2008 11:11, Alfred Nathaniel wrote: I now added exclusion rules to all our explicit dependencies which pick up the old avalon-framework through transitive dependencies. Thanks very much, Alfred. That's really appreciated! Joerg
Re: XSP block dependencies
Joerg Heinicke pisze: On 25.11.2007 10:45 Uhr, Grzegorz Kossakowski wrote: Just check file target/site/dependencies.html. You will find everything (or even more) you need there. Oh man, I have not even had the idea of looking into an output directory, I just expected it on the console. Anyway, this report does not help at all, it only mentions 4.3.1 of Avalon Framework API and Impl. The generated .classpath has following entries though: classpathentry kind=var path=M2_REPO/org/apache/avalon/framework/avalon-framework-impl/4.3.1/avalon-framework-impl-4.3.1.jar sourcepath=M2_REPO/org/apache/avalon/framework/avalon-framework-impl/4.3.1/avalon-framework-impl-4.3.1-sources.jar/ classpathentry kind=var path=M2_REPO/avalon-framework/avalon-framework/4.1.3/avalon-framework-4.1.3.jar/ classpathentry kind=var path=M2_REPO/org/apache/avalon/framework/avalon-framework-api/4.3.1/avalon-framework-api-4.3.1.jar sourcepath=M2_REPO/org/apache/avalon/framework/avalon-framework-api/4.3.1/avalon-framework-api-4.3.1-sources.jar/ Notably the difference in the module name: org/apache/avalon/framework/avalon-framework-impl resp. -api vs. avalon-framework/avalon-framework But how to trace it back when the dependency report does not even mention it. I wonder if I'm actually the only one with this problem? It's probably not critical since it seems to occur only with the Eclipse plugin and fixing the build path is easy. But it might point to a deeper error who the next one hit at a completely different point. I suspect that Maven's eclipse plug-in has a bug in it's code responsible for dependency resolution. Seizing the opportunity I would like to recommend q4e (http://code.google.com/p/q4e/) Eclipse plug-in. It allows to import Maven project directly to workspace and it manages project classpath dynamically so it will spot any changes to project dependencies immediately. It is quite young project but it is already usable and I can recommend it for Cocoon development (I'm using it for more than two months now). It doesn't suffer from the problem described above, of course. -- Grzegorz Kossakowski Committer and PMC Member of Apache Cocoon http://reflectingonthevicissitudes.wordpress.com/
Re: XSP block dependencies
Can you point me at the poms I should look at to see this? Reinhard Poetz wrote: Ralph Goers wrote: Is the cocoon build really trying to rely on transitive dependency verions? Very bad idea. Versions of every dependency cocoon uses directly or indirectly should be specified in the managedDependencies. The problem is that the groupId of the Avalon framework changed and that's the root of all evil in this case. We ever never need a dependency on Avalon 4.1.3 but how to express this in the managedDependencies section? The only chance for us is configuring exclusions but first you have to figure out that you have to do it at all (here the dependency module comes into play). I have also experienced very strange behaviour of the dependency resultion mechanism e.g. I exclude avalon-framework from being pulled in by commons-logging but then, when I use commons-beanutils, which pulls in commons-logging, the avalon-framework dependency is used again. TBH, I have no idea why the dependency resolution is still buggy after such a long time after the first final Maven 2 release :-/
Re: XSP block dependencies
On 25.11.2007 23:47 Uhr, Joerg Heinicke wrote: PS: There is also an error somewhere with the dependencies I think. XSP block includes Avalon Framework 4.1.3 instead of 4.3.1 which causes bunch of problems in Eclipse. How to trace the dependencies? Grek sent once a mail with mvn project-info-reports:dependencies [1] but this does not work for me: Just check file target/site/dependencies.html. You will find everything (or even more) you need there. Oh man, I have not even had the idea of looking into an output directory, I just expected it on the console. Anyway, this report does not help at all, it only mentions 4.3.1 of Avalon Framework API and Impl. The generated .classpath has following entries though: classpathentry kind=var path=M2_REPO/org/apache/avalon/framework/avalon-framework-impl/4.3.1/avalon-framework-impl-4.3.1.jar sourcepath=M2_REPO/org/apache/avalon/framework/avalon-framework-impl/4.3.1/avalon-framework-impl-4.3.1-sources.jar/ classpathentry kind=var path=M2_REPO/avalon-framework/avalon-framework/4.1.3/avalon-framework-4.1.3.jar/ classpathentry kind=var path=M2_REPO/org/apache/avalon/framework/avalon-framework-api/4.3.1/avalon-framework-api-4.3.1.jar sourcepath=M2_REPO/org/apache/avalon/framework/avalon-framework-api/4.3.1/avalon-framework-api-4.3.1-sources.jar/ Notably the difference in the module name: org/apache/avalon/framework/avalon-framework-impl resp. -api vs. avalon-framework/avalon-framework But how to trace it back when the dependency report does not even mention it. I wonder if I'm actually the only one with this problem? It's probably not critical since it seems to occur only with the Eclipse plugin and fixing the build path is easy. But it might point to a deeper error who the next one hit at a completely different point. Found this thread on the user list which has the same symptoms: http://marc.info/?t=11751141251r=1w=4. Joerg
Re: XSP block dependencies
Is the cocoon build really trying to rely on transitive dependency verions? Very bad idea. Versions of every dependency cocoon uses directly or indirectly should be specified in the managedDependencies. Joerg Heinicke wrote: Found this thread on the user list which has the same symptoms: http://marc.info/?t=11751141251r=1w=4. Joerg
Re: XSP block dependencies
Ralph Goers wrote:
Is the cocoon build really trying to rely on transitive dependency
verions? Very bad idea. Versions of every dependency cocoon uses
directly or indirectly should be specified in the managedDependencies.
The problem is that the groupId of the Avalon framework changed and that's the
root of all evil in this case. We ever never need a dependency on Avalon 4.1.3
but how to express this in the managedDependencies section?
The only chance for us is configuring exclusions but first you have to figure
out that you have to do it at all (here the dependency module comes into play).
I have also experienced very strange behaviour of the dependency resultion
mechanism e.g. I exclude avalon-framework from being pulled in by
commons-logging but then, when I use commons-beanutils, which pulls in
commons-logging, the avalon-framework dependency is used again.
TBH, I have no idea why the dependency resolution is still buggy after such a
long time after the first final Maven 2 release :-/
--
Reinhard PötzManaging Director, {Indoqa} GmbH
http://www.indoqa.com/en/people/reinhard.poetz/
Member of the Apache Software Foundation
Apache Cocoon Committer, PMC member, PMC Chair[EMAIL PROTECTED]
_
