Hi Micah, 2008/4/14, Micah Hainline <[EMAIL PROTECTED]>: > 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.
eclipse:make-artifacts seems to be the unofficial repo layout. eclipse:to-maven should be used instead of. Arnaud, could you confirm? Cheers, Vincent > > 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] > > --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
