You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@cocoon.apache.org by Joerg Heinicke <jo...@gmx.de> on 2007/11/26 06:25:55 UTC
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=117511412500001&r=1&w=4.
Joerg
Re: XSP block dependencies
Posted by Joerg Heinicke <jo...@gmx.de>.
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
Posted by Alfred Nathaniel <an...@apache.org>.
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>
<groupId>commons-httpclient</groupId>
<artifactId>commons-httpclient</artifactId>
+ <exclusions>
+ <exclusion>
+ <groupId>avalon-framework</groupId>
+ <artifactId>avalon-framework</artifactId>
+ </exclusion>
+ </exclusions>
</dependency>
7.) mvn eclipse:clean eclipse:eclipse
8.) Rinse and repeat.
Cheers, Alfred.
[SlightlyOT] Maven dependency resolution
Posted by Reinhard Poetz <re...@apache.org>.
Ralph Goers wrote:
> 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 :-/
>
> Can you point me at the poms I should look at to see this?
If you refer to the commons-beanutils/commons-logging problem, here is a
stripped down variant of a custom project of ours that reproduced the problem:
PARENT:
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
<?xml version="1.0" encoding="UTF-8"?>
<project xmlns="http://maven.apache.org/POM/4.0.0"
xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
xsi:schemaLocation="http://maven.apache.org/POM/4.0.0
http://maven.apache.org/maven-v4_0_0.xsd">
<modelVersion>4.0.0</modelVersion>
<packaging>pom</packaging>
<groupId>com.example</groupId>
<artifactId>test-parent</artifactId>
<version>1-SNAPSHOT</version>
<dependencyManagement>
<dependencies>
<dependency>
<groupId>org.apache.cocoon</groupId>
<artifactId>cocoon-core</artifactId>
<version>2.2.0-RC2</version>
</dependency>
<dependency>
<groupId>commons-beanutils</groupId>
<artifactId>commons-beanutils</artifactId>
<version>1.8.0-BETA</version>
</dependency>
<dependency>
<groupId>commons-logging</groupId>
<artifactId>commons-logging</artifactId>
<version>1.1</version>
</dependency>
</dependencies>
</dependencyManagement>
<profiles>
<profile>
<id>use-snapshots</id>
<build>
<plugins>
<plugin>
<artifactId>maven-dependency-plugin</artifactId>
<version>2.0-alpha-5-SNAPSHOT</version>
</plugin>
</plugins>
</build>
<repositories>
<repository>
<id>apache.org</id>
<name>Maven Snapshots</name>
<url>http://people.apache.org/repo/m2-snapshot-repository</url>
<releases>
<enabled>false</enabled>
</releases>
<snapshots>
<enabled>true</enabled>
</snapshots>
</repository>
<repository>
<id>codehaus.org</id>
<name>CodeHaus Snapshots</name>
<url>http://snapshots.repository.codehaus.org</url>
<releases>
<enabled>false</enabled>
</releases>
<snapshots>
<enabled>true</enabled>
</snapshots>
</repository>
</repositories>
<pluginRepositories>
<pluginRepository>
<id>apache.org</id>
<name>Maven Plugin Snapshots</name>
<url>http://people.apache.org/repo/m2-snapshot-repository</url>
<releases>
<enabled>false</enabled>
</releases>
<snapshots>
<enabled>true</enabled>
</snapshots>
</pluginRepository>
<pluginRepository>
<id>codehaus.org</id>
<name>Maven Plugin Snapshots (Codehaus)</name>
<url>http://snapshots.repository.codehaus.org</url>
<releases>
<enabled>false</enabled>
</releases>
<snapshots>
<enabled>true</enabled>
</snapshots>
</pluginRepository>
</pluginRepositories>
</profile>
</profiles>
</project>
CHILD:
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
<?xml version="1.0" encoding="UTF-8"?>
<project xmlns="http://maven.apache.org/POM/4.0.0"
xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
xsi:schemaLocation="http://maven.apache.org/POM/4.0.0
http://maven.apache.org/maven-v4_0_0.xsd">
<modelVersion>4.0.0</modelVersion>
<packaging>pom</packaging>
<parent>
<groupId>com.example</groupId>
<artifactId>test-parent</artifactId>
<version>1-SNAPSHOT</version>
</parent>
<artifactId>test-child</artifactId>
<version>1.0.0-SNAPSHOT</version>
<dependencies>
<dependency>
<groupId>org.apache.cocoon</groupId>
<artifactId>cocoon-core</artifactId>
</dependency>
<dependency>
<groupId>commons-beanutils</groupId>
<artifactId>commons-beanutils</artifactId>
</dependency>
</dependencies>
<profiles>
<profile>
<id>foo</id>
</profile>
</profiles>
</project>
Run "mvn dependency:list -P use-snapshots" and "mvn dependency:list -P
use-snapshots,foo" for the child project and compare the results with regard to
avalon-framework.
--
Reinhard Pötz Managing Director, {Indoqa} GmbH
http://www.indoqa.com/en/people/reinhard.poetz/
Member of the Apache Software Foundation
Apache Cocoon Committer, PMC member, PMC Chair reinhard@apache.org
_________________________________________________________________________
Re: XSP block dependencies
Posted by Ralph Goers <Ra...@dslextreme.com>.
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
Posted by Reinhard Poetz <re...@apache.org>.
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ötz Managing Director, {Indoqa} GmbH
http://www.indoqa.com/en/people/reinhard.poetz/
Member of the Apache Software Foundation
Apache Cocoon Committer, PMC member, PMC Chair reinhard@apache.org
_________________________________________________________________________
Re: XSP block dependencies
Posted by Ralph Goers <Ra...@dslextreme.com>.
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=117511412500001&r=1&w=4.
>
> Joerg