Thanks. I'll probably apply it in the coming week. Cheers, Scott
On Fri, Oct 2, 2009 at 12:55 AM, Robert Winch <rwi...@gmail.com> wrote: > I created a JIRA issue and attached a patch based upon to > http://www.ja-sig.org/issues/browse/CAS-802 > > > On Thu, Oct 1, 2009 at 10:03 PM, Scott Battaglia < > scott.battag...@gmail.com> wrote: > >> Would you be able to attach a diff to a JIRA issue for me to apply to the >> project? >> >> Thanks! >> Scott >> >> >> On Thu, Oct 1, 2009 at 7:13 PM, Robert Winch <rwi...@gmail.com> wrote: >> >>> I too have seen this problem and am embarrassed to say that I silently >>> fixed it locally and did not contribute back (hopefully I can rectify my >>> wrong). >>> >>> Maven2 "Dependency mediation" specifies that the version that is resolved >>> is the "nearest definition" [1]. With that said, if you explicitly list >>> spring-core-2.5.6.jar that will be the version that is resolved. This is the >>> safest approach when a specific version of a jar is required. >>> >>> The latest version of the m2eclipse plugin uses Maven 3 which is suppose >>> to be compatible (except internal APIs) with Maven 2. I think the >>> discrepancy is in how the shortest path is defined when a parent and child >>> exist. I'm not sure which is the desired behavior, but asked on the maven >>> mailing list [2]. The m2eclipse plugin treats parent dependencies as closer >>> and Maven 2 thinks child dependencies are closer. For example, below is a >>> very simplified list of dependencies that simulates the issue [3]. Both >>> spring-webflow and spring-aop have direct dependencies on spring-core. The >>> m2eclipse plugin thinks that the spring-core-2.0.7.jar found as a direct >>> dependency of spring-webflow (found in the parent) is the "nearest >>> definition". On the other hand maven2 seems to think that >>> spring-core-2.5.6.jar found as a direct dependency of spring-aop (found in >>> the child) is the "nearest definition". If you change the example below to >>> have spring-webflow to be the first dependency directly in the child both >>> m2eclipse and maven2 agree that spring-core-2.0.7 should be resolved. If you >>> move spring-aop to be the second dependency in the parent the version of >>> spring is consistent too. >>> >>> Regards, >>> Rob >>> >>> [1] >>> http://maven.apache.org/guides/introduction/introduction-to-dependency-mechanism.html#Transitive_Dependencies >>> >>> [2] >>> http://www.nabble.com/Transitive-Dependencies%3A-Is-the-parent-or-child-dependency-the--%22nearest-dependency%22--td25708104.html >>> >>> [3] >>> >>> parent >>> >>> <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> >>> <groupId>parent</groupId> >>> <artifactId>parent</artifactId> >>> <packaging>pom</packaging> >>> <version>1.0-SNAPSHOT</version> >>> <dependencies> >>> <dependency> >>> <groupId>org.springframework</groupId> >>> <artifactId>spring-webflow</artifactId> >>> <version>1.0.6</version> >>> </dependency> >>> </dependencies> >>> </project> >>> >>> child >>> >>> <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";> >>> <parent> >>> <artifactId>parent</artifactId> >>> <groupId>parent</groupId> >>> <version>1.0-SNAPSHOT</version> >>> </parent> >>> <modelVersion>4.0.0</modelVersion> >>> <groupId>child</groupId> >>> <artifactId>child</artifactId> >>> <packaging>war</packaging> >>> <version>1.0-SNAPSHOT</version> >>> >>> <dependencies> >>> <dependency> >>> <groupId>org.springframework</groupId> >>> <artifactId>spring-aop</artifactId> >>> <version>2.5.6</version> >>> </dependency> >>> </dependencies> >>> </project> >>> >>> >>> On Thu, Oct 1, 2009 at 1:02 PM, Howard Gilbert >>> <howard.gilb...@yale.edu>wrote: >>> >>>> The problem is triggered because (at least) the >>>> spring-webflow-1.0.6.pom calls up as a dependency (among others) >>>> >>>> >>>> >>>> <dependency> >>>> >>>> >>>> <groupId>org.springframework</groupId> >>>> >>>> >>>> <artifactId>spring-core</artifactId> >>>> >>>> <version>2.0.7</version> >>>> >>>> </dependency> >>>> >>>> >>>> >>>> That is, while all elements of the SpringFramework proper tend to lock >>>> step from release to release, the independent Spring components like >>>> webflow >>>> that have their own release numbers depend on whatever they regard as the >>>> lowest allowable version of the Framework proper. Unfortunately, the >>>> m2eclipse (but apparently not Maven itself) regards this literally and adds >>>> an additional requirement for 2.0.7 as well as the current 2.5.6. >>>> >>>> >>>> >>>> This appears to be a bug in m2eclipse. There is no plausible reason why >>>> any valid Maven technology would use two different versions of the same >>>> artifact name. There seems, however, to be some local (to the subproject) >>>> and global disconnect in the dependency resolution that generates both of >>>> them. >>>> >>>> >>>> >>>> If there is some Maven syntax that will knock m2eclipse hard on the head >>>> and make it realize the problem and fix it automatically, then it would be >>>> great to fix it properly. If not, then the nasty solution I have tested is >>>> to edit : >>>> >>>> >>>> >>>> $HOME/.m2/repository/org/springframework/spring-x/1.0.y/spring-x-1.0.y.pom >>>> >>>> >>>> >>>> >>>> Where x is either “webflow” or “bindings” and y is either “5” or “6”. >>>> >>>> In these POM files delete the <version>2.0.7</version> line in all >>>> spring-xxx artifact dependencies. In think there is one incorrect $Project >>>> version dependency as well and I got rid of it too. >>>> >>>> >>>> >>>> Then you rebuild the m2eclipse Maven dependencies by selecting the >>>> project, Disable Dependency Mangement, Enable Dependency Management, and >>>> Enable Nested Modules. >>>> >>>> >>>> >>>> [Disclaimer: following these instructions may destroy the known >>>> universe. I cannot be responsible for results. Use only on a test >>>> project/reponsitory/machine or if you are prepared to deal with anything >>>> that goes wrong.] >>>> >>>> >>>> >>>> Or we could wait for m2eclipse to fix this, but it is already somewhat >>>> magic that it works as well as it does and I am not sure how easy it will >>>> be >>>> for them to deal with this problem. >>>> >>>> >>>> >>>> >>>> >>>> *From:* Scott Battaglia [mailto:scott.battag...@gmail.com] >>>> *Sent:* Thursday, October 01, 2009 12:26 PM >>>> *To:* cas-dev@lists.jasig.org >>>> *Subject:* Re: [cas-dev] Building cas server with m2eclipse >>>> >>>> >>>> >>>> Howard, if you know what Poms hey came from I can add explicit >>>> exclusions for 3.3.5 I can also see if the dependency tree plugin will >>>> tell >>>> me if you're not sure. >>>> >>>> >>>> -- >>>> You are currently subscribed to cas-dev@lists.jasig.org as: >>>> rwi...@gmail.com >>>> >>>> >>>> To unsubscribe, change settings or access archives, see >>>> http://www.ja-sig.org/wiki/display/JSG/cas-dev >>>> >>>> >>> -- >>> You are currently subscribed to cas-dev@lists.jasig.org as: >>> scott.battag...@gmail.com >>> >>> >>> >>> To unsubscribe, change settings or access archives, see >>> http://www.ja-sig.org/wiki/display/JSG/cas-dev >>> >>> >> -- >> You are currently subscribed to cas-dev@lists.jasig.org as: rwi...@gmail.com >> To unsubscribe, change settings or access archives, see >> http://www.ja-sig.org/wiki/display/JSG/cas-dev >> >> > -- > You are currently subscribed to cas-dev@lists.jasig.org as: > scott.battag...@gmail.com > > To unsubscribe, change settings or access archives, see > http://www.ja-sig.org/wiki/display/JSG/cas-dev > > -- You are currently subscribed to cas-dev@lists.jasig.org as: arch...@mail-archive.com To unsubscribe, change settings or access archives, see http://www.ja-sig.org/wiki/display/JSG/cas-dev
