You are viewing a plain text version of this content. The canonical link for it is here.
Posted to cvs@cocoon.apache.org by gk...@apache.org on 2007/03/12 23:46:18 UTC
svn commit: r517439 -
/cocoon/trunk/core/cocoon-servlet-service/cocoon-servlet-service-impl/pom.xml
Author: gkossakowski
Date: Mon Mar 12 15:46:17 2007
New Revision: 517439
URL: http://svn.apache.org/viewvc?view=rev&rev=517439
Log:
Add missing dependency on spring-core.
Modified:
cocoon/trunk/core/cocoon-servlet-service/cocoon-servlet-service-impl/pom.xml
Modified: cocoon/trunk/core/cocoon-servlet-service/cocoon-servlet-service-impl/pom.xml
URL: http://svn.apache.org/viewvc/cocoon/trunk/core/cocoon-servlet-service/cocoon-servlet-service-impl/pom.xml?view=diff&rev=517439&r1=517438&r2=517439
==============================================================================
--- cocoon/trunk/core/cocoon-servlet-service/cocoon-servlet-service-impl/pom.xml (original)
+++ cocoon/trunk/core/cocoon-servlet-service/cocoon-servlet-service-impl/pom.xml Mon Mar 12 15:46:17 2007
@@ -83,7 +83,12 @@
<artifactId>logkit</artifactId>
</exclusion>
</exclusions>
- </dependency>
+ </dependency>
+ <dependency>
+ <groupId>org.springframework</groupId>
+ <artifactId>spring-core</artifactId>
+ <version>2.0.3</version>
+ </dependency>
<dependency>
<groupId>org.springframework</groupId>
<artifactId>spring-beans</artifactId>
Re: Maven dependency resolution (Re: svn commit: r517439 - /cocoon/trunk/core/cocoon-servlet-service/cocoon-servlet-service-impl/pom.xml)
Posted by Ralph Goers <Ra...@dslextreme.com>.
Grzegorz Kossakowski wrote:
> I would suggest to read my mail once again. The problem is that ClassNotFoundException will not be thrown.
> Let's assume me have A, B, C:
> A depends on B and dependency is declared in A's pom
> B depends on C and dependency is declared in B's pom
> A depends on C but dependency is not declared in A's pom
>
> Now A's dependency on C will be satisfied by transitive dependency. However, transitive dependencies are really
> vulnerable to the ambiguity of dependency mediation. My main point was that we should avoid satisfying dependencies by
> transitive dependencies. Given that, we should find a way to find out that we really rely on transitive dependencies.
>
My point was that transitive dependencies need not be ambiguous any
longer. Project A can now specify in it's dependencyManagement section a
version for C. If C is referenced in a transitive dependency its version
will be ignored and the version specified in the dependencyManagement
will be used instead. I suspect that the reason C isn't in A's pom is
that it isn't an "explicit" dependency, i.e. it is only referenced
indirectly through B. In this case a transitive dependency is appropriate.
As a developer you should go through the dependencies you are using in
your pom and find out what their dependencies are and explicitly define
them in your dependencyManagement (or a parent's). If you don't do this
you will eventually end up with a mess. This is exactly why this patch
was developed.
Yes, the case above can occur, and is probably likely with the released
versions of Maven. However, with explicit dependencyManagement it should
not occur if developers do what they are supposed to. The real culprit
in your scenario above wasn't that there was a transitive dependency. It
was that the way in which you declare the version of the transitive
dependency.
So ultimately, if there is a single "master" pom it would contain all
the versions of everything used anywhere in Cocoon. directly or
indirectly. Since ultimately every other project would extend this you
could be assured that the versions are in synch.
Re: Maven dependency resolution (Re: svn commit: r517439 - /cocoon/trunk/core/cocoon-servlet-service/cocoon-servlet-service-impl/pom.xml)
Posted by Grzegorz Kossakowski <gk...@apache.org>.
Ralph Goers napisał(a):
>
>
> Grzegorz Kossakowski wrote:
>>> Although this feature is helpful while updating dependencies (you
>>> have to do it in one place), I hardly see how this
>>> relates to the situation I've described. In my case, problem was
>>> caused not by dependency to the wrong (old) version but
>>> by the lack of any dependency at all! dependencyManagement section
>>> will not help us in this scenario, doesn't it?
>>>
> Well, yes. If you never declare a dependency when there really is one
> then you will have problems. I would presume they would be very
> noticeable in most cases as they would result in ClassNotFoundExceptions
> to occur in most cases.
I would suggest to read my mail once again. The problem is that ClassNotFoundException will not be thrown.
Let's assume me have A, B, C:
A depends on B and dependency is declared in A's pom
B depends on C and dependency is declared in B's pom
A depends on C but dependency is not declared in A's pom
Now A's dependency on C will be satisfied by transitive dependency. However, transitive dependencies are really
vulnerable to the ambiguity of dependency mediation. My main point was that we should avoid satisfying dependencies by
transitive dependencies. Given that, we should find a way to find out that we really rely on transitive dependencies.
--
Grzegorz Kossakowski
Re: Maven dependency resolution (Re: svn commit: r517439 - /cocoon/trunk/core/cocoon-servlet-service/cocoon-servlet-service-impl/pom.xml)
Posted by Ralph Goers <Ra...@dslextreme.com>.
Grzegorz Kossakowski wrote:
>> Although this feature is helpful while updating dependencies (you have to do it in one place), I hardly see how this
>> relates to the situation I've described. In my case, problem was caused not by dependency to the wrong (old) version but
>> by the lack of any dependency at all! dependencyManagement section will not help us in this scenario, doesn't it?
>>
Well, yes. If you never declare a dependency when there really is one
then you will have problems. I would presume they would be very
noticeable in most cases as they would result in ClassNotFoundExceptions
to occur in most cases.
I was really commenting on the larger section of your email where you
were talking about how maven handles dependency management.
Ralph
Maven dependency resolution (Re: svn commit: r517439 - /cocoon/trunk/core/cocoon-servlet-service/cocoon-servlet-service-impl/pom.xml)
Posted by Grzegorz Kossakowski <gk...@apache.org>.
Ralph Goers napisał(a):
> We should consider leveraging the new feature that I finally got
> committed into Maven - real dependency management. With the change any
> version you specify in a dependencyManagement section will override
> versions specified in transitive dependencies as well as being the
> version used when no version is specified in a pom. What I would
> suggest trying is having a "master" pom that everything extends. The
> master should specify all the versions to be used across all the blocks,
> unless a block has a real need to use a different version. This will be
> available in 2.0.6.
>
Although this feature is helpful while updating dependencies (you have to do it in one place), I hardly see how this
relates to the situation I've described. In my case, problem was caused not by dependency to the wrong (old) version but
by the lack of any dependency at all! dependencyManagement section will not help us in this scenario, doesn't it?
--
Grzegorz Kossakowski
Maven dependency resolution (was: Re: svn commit: r517439 - /cocoon/trunk/core/cocoon-servlet-service/cocoon-servlet-service-impl/pom.xml)
Posted by Reinhard Poetz <re...@apache.org>.
Ralph Goers wrote:
> We should consider leveraging the new feature that I finally got
> committed into Maven - real dependency management. With the change any
> version you specify in a dependencyManagement section will override
> versions specified in transitive dependencies as well as being the
> version used when no version is specified in a pom. What I would
> suggest trying is having a "master" pom that everything extends. The
> master should specify all the versions to be used across all the blocks,
> unless a block has a real need to use a different version. This will be
> available in 2.0.6.
Good to hear. IIUC from a recent thread on dev@maven, 2.0.6 will be out soon.
Then we should define 2.0.6 being a prerequisite for building trunk.
--
Reinhard Pötz Independent Consultant, Trainer & (IT)-Coach
{Software Engineering, Open Source, Web Applications, Apache Cocoon}
web(log): http://www.poetz.cc
--------------------------------------------------------------------
Re: svn commit: r517439 - /cocoon/trunk/core/cocoon-servlet-service/cocoon-servlet-service-impl/pom.xml
Posted by Ralph Goers <Ra...@dslextreme.com>.
We should consider leveraging the new feature that I finally got
committed into Maven - real dependency management. With the change any
version you specify in a dependencyManagement section will override
versions specified in transitive dependencies as well as being the
version used when no version is specified in a pom. What I would
suggest trying is having a "master" pom that everything extends. The
master should specify all the versions to be used across all the blocks,
unless a block has a real need to use a different version. This will be
available in 2.0.6.
Ralph
Grzegorz Kossakowski wrote:
> This dependency is really important. Otherwise Maven 2.0.5 will (but
> it's for sure) include all Spring's artifacts of version 2.0.3 but not
> core of which 2.0.2 version will be used at runtime. This of course
> leads to many really hard-to-track problems.
>
> What's more interesting it's not really next Maven bug. Take a look at
> this quotation[1]:
> "Dependency mediation - this determines what version of a dependency
> will be used when multiple versions of an artifact are encountered.
> Currently, Maven 2.0 only supports using the "nearest definition" which
> means that it will use the version of the closest dependency to your
> project in the tree of dependencies. You can always guarantee a version
> by declaring it explicitly in your project's POM. Note that if two
> dependency versions are at the same depth in the dependency tree it's
> not defined which one will win."
>
> Last sentence is crucial here. We depend on spring-configurator which
> depends on 2.0.2 version of spring. This dependency is overrided by
> dependencies from servlet-service-impl when it comes to all spring
> artifacts because they are one step "closer". However, core is
> referenced indirectly (by dependencies in other spring artifacts) which
> lengthen "dependency distance" by one step. Now we are in _real_ trouble
> - Maven is completely unpredictable on which version of spring's core is
> going to choose.
>
> I personally think that Maven's mechanism is not that bad as far as all
> direct dependencies are correctly specified in all poms. Even more, I
> think that eclipse plug-in generating build path which includes
> transitive dependencies is most problematic part[2].
>
> If you wonder why I've written all of this - just for your information,
> I hope this will save you from some frustration (especially if you are
> not skilled with debugging Maven).
>
>
Re: svn commit: r517439 - /cocoon/trunk/core/cocoon-servlet-service/cocoon-servlet-service-impl/pom.xml
Posted by Grzegorz Kossakowski <gk...@apache.org>.
gkossakowski@apache.org napisał(a):
> Log:
> Add missing dependency on spring-core.
>
> + </dependency>
> + <dependency>
> + <groupId>org.springframework</groupId>
> + <artifactId>spring-core</artifactId>
> + <version>2.0.3</version>
> + </dependency>
This dependency is really important. Otherwise Maven 2.0.5 will (but
it's for sure) include all Spring's artifacts of version 2.0.3 but not
core of which 2.0.2 version will be used at runtime. This of course
leads to many really hard-to-track problems.
What's more interesting it's not really next Maven bug. Take a look at
this quotation[1]:
"Dependency mediation - this determines what version of a dependency
will be used when multiple versions of an artifact are encountered.
Currently, Maven 2.0 only supports using the "nearest definition" which
means that it will use the version of the closest dependency to your
project in the tree of dependencies. You can always guarantee a version
by declaring it explicitly in your project's POM. Note that if two
dependency versions are at the same depth in the dependency tree it's
not defined which one will win."
Last sentence is crucial here. We depend on spring-configurator which
depends on 2.0.2 version of spring. This dependency is overrided by
dependencies from servlet-service-impl when it comes to all spring
artifacts because they are one step "closer". However, core is
referenced indirectly (by dependencies in other spring artifacts) which
lengthen "dependency distance" by one step. Now we are in _real_ trouble
- Maven is completely unpredictable on which version of spring's core is
going to choose.
I personally think that Maven's mechanism is not that bad as far as all
direct dependencies are correctly specified in all poms. Even more, I
think that eclipse plug-in generating build path which includes
transitive dependencies is most problematic part[2].
If you wonder why I've written all of this - just for your information,
I hope this will save you from some frustration (especially if you are
not skilled with debugging Maven).
[1]
http://maven.apache.org/guides/introduction/introduction-to-dependency-mechanism.html
[2] http://article.gmane.org/gmane.comp.jakarta.turbine.maven.user/63793
--
Grzegorz Kossakowski