i gave a talk at eclipsecon covering the subject. You'll need to use maven 2.0.9+ and force the versions in dependencyManagement You can find the slides at http://www.jroller.com/carlossg/entry/slides_from_eclipsecon
On Mon, Apr 14, 2008 at 7:05 AM, Micah Hainline <[EMAIL PROTECTED]> wrote: > Hey Vincent, the qualifiers in the release versions of the Eclipse plugins > are better off stripped out of the repositories in my opinion. Every release > version of the Eclipse platform should have the incremental version number > incremented, so if the community was going to make another release of the 3.2 > branch it would be 3.2.3--they wouldn't rely on the qualifier for that. I > guess what I'm saying is the qualifier doesn't have much useful information > for the release versions, so it makes sense to me to strip the qualifier when > you're adding the Eclipse artifacts to your repository. > eclipse:make-artifacts[1] does this by default. If you were to need to build > against the nightly Eclipse build or something of that nature you would have > to do something different, but my sense is that you are not. > > These are just my opinions on the subject, and I'd be interested to hear any > others. This was just what I found easiest to deal with. > > [1] > http://maven.apache.org/plugins/maven-eclipse-plugin/make-artifacts-mojo.html > > > > ----- Original Message ----- > From: "Vincent Siveton" <[EMAIL PROTECTED]> > To: "Maven Developers List" <dev@maven.apache.org> > Sent: Monday, April 14, 2008 5:52:35 AM (GMT-0600) America/Chicago > Subject: How to use central repo into an Eclipse project? > > Hi, > > Background: > Trying to mavenize an Eclipse Plugin project, I got error messages > like the following: > Couldn't find a version in [1.0.0-v20070606] to match range [1.0.0,2.0.0) > I put in jira a test project to reproduce this error [1]. > > Discussions: > After some investigations: > * the error comes from transitive dependencies (BTW I updated > DefaultArtifactCollector (r647445) to have the dependency trail). > * a version without qualifier is newer than a version with qualifier, > i.e in our case 1.0.0 is newer than 1.0.0-v20070606 (see also [2] > [3]). This logic is valid for alpha, beta (i.e. 1.0-alpha-1 < 1.0) but > not for Eclipse artifacts. > * Carlos in [4] suggested to use exclusions or dependencyManagement. > With this approach, POM will quickly become ugly (see for instance ASF > Directory Studio POM [6]). Moreover, the actual repo is just unusable > because transitive dependencies are not resolved at all due to the > current logic. > * Using eclipse:to-maven doesn't help [5] > > So, how to make the Eclipse repo workable for an Eclipse project? A > solution could be done in [1], but this might be Eclipse specific. At > least, the repo will work :) > > Thoughts? > > Vincent > > [1] http://jira.codehaus.org/browse/MNG-3518 > [2] > http://docs.codehaus.org/display/MAVEN/Dependency+Mediation+and+Conflict+Resolution#DependencyMediationandConflictResolution-DependencyVersionRanges > [3] http://docs.codehaus.org/display/MAVEN/Versioning > [4] > http://www.nabble.com/Re%3A-in-repo1-it-is-available-td13950144s177.html#a14708458 > [5] > http://www.nabble.com/Couldn%27t-find-a-version-when-building-pde-maven-plugin-td16116114s177.html > [6] http://svn.apache.org/repos/asf/directory/studio/trunk/pom.xml > > --------------------------------------------------------------------- > To unsubscribe, e-mail: [EMAIL PROTECTED] > For additional commands, e-mail: [EMAIL PROTECTED] > > > > --------------------------------------------------------------------- > To unsubscribe, e-mail: [EMAIL PROTECTED] > For additional commands, e-mail: [EMAIL PROTECTED] > > -- I could give you my word as a Spaniard. No good. I've known too many Spaniards. -- The Princess Bride --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
