You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@maven.apache.org by Vincent Siveton <vs...@apache.org> on 2008/04/14 12:52:35 UTC
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: dev-unsubscribe@maven.apache.org
For additional commands, e-mail: dev-help@maven.apache.org
Re: How to use central repo into an Eclipse project?
Posted by Max Bowsher <ma...@ukf.net>.
Vincent Siveton wrote:
> 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.
> 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 :)
Has anyone considered making eclipse:to-maven write version-ranges of
the form [1.0.0-!,2.0.0) ? ("!" being the lowest valued printable
unicode character, and so a pretty good approximation to the "oldest"
possible qualifier according to the current comparison logic of Maven).
If the intent of the eclipse dependency is to match a version of 1.0.0
with any qualifier, this mapping seems to me to be the best way to
translate that intent to Maven notation.
Max.
Re: How to use central repo into an Eclipse project?
Posted by Vincent Siveton <vi...@gmail.com>.
Hi Micah,
2008/4/14, Micah Hainline <mi...@asolutions.com>:
> 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" <vs...@apache.org>
> To: "Maven Developers List" <de...@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: dev-unsubscribe@maven.apache.org
> For additional commands, e-mail: dev-help@maven.apache.org
>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
> For additional commands, e-mail: dev-help@maven.apache.org
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
For additional commands, e-mail: dev-help@maven.apache.org
Re: How to use central repo into an Eclipse project?
Posted by Carlos Sanchez <ca...@apache.org>.
On Tue, Apr 15, 2008 at 4:06 AM, Vincent Siveton
<vi...@gmail.com> wrote:
> Hi Carlos,
>
> 2008/4/14, Carlos Sanchez <ca...@apache.org>:
>
> > btw the problem is not just let's make the repo work for maven as
> > there are other consumers out there, ie. Equinox provisioning, that
> > may like to use the repo as a source and if you change their metadata
> > to adjust it to maven it wont be useful for them anymore
>
> Agree and it is why I did MNG-3518, ie only changing Maven logic.
agree, Maven should keep the old behavior for snapshot timestamps but
should change for the rest
>
> But, WDYT to put Eclipse artifacts without classifier in central? Make
> sense for osgi/eclipse?
i think it'd be confusing because there are many builds and the only
difference would be where the build is bundled.
ie it could happen that eclipse 4.0 bundles foo-1.0.0.20080101 but
then foo could release a new build foo-1.0.0.20080201
at least theoretically it could happen
but as I'm not going to invest much time on this I'm leaving the door
open for other people that are actually willing to do the work to come
up with usable solutions
>
> Cheers,
>
> Vincent
>
>
>
> >
> >
> > On Mon, Apr 14, 2008 at 10:44 AM, Carlos Sanchez <ca...@apache.org> wrote:
> > > 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
> > > <mi...@asolutions.com> 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" <vs...@apache.org>
> > > > To: "Maven Developers List" <de...@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: dev-unsubscribe@maven.apache.org
> > > > For additional commands, e-mail: dev-help@maven.apache.org
> > > >
> > > >
> > > >
> > > > ---------------------------------------------------------------------
> > > > To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
> > > > For additional commands, e-mail: dev-help@maven.apache.org
> > > >
> > > >
> > >
> > >
> > >
> > > --
> > > I could give you my word as a Spaniard.
> > > No good. I've known too many Spaniards.
> > > -- The Princess Bride
> > >
> >
> >
> >
> > --
> > I could give you my word as a Spaniard.
> > No good. I've known too many Spaniards.
> > -- The Princess Bride
> >
> > ---------------------------------------------------------------------
> > To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
> > For additional commands, e-mail: dev-help@maven.apache.org
> >
> >
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
> For additional commands, e-mail: dev-help@maven.apache.org
>
>
--
I could give you my word as a Spaniard.
No good. I've known too many Spaniards.
-- The Princess Bride
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
For additional commands, e-mail: dev-help@maven.apache.org
Re: How to use central repo into an Eclipse project?
Posted by Vincent Siveton <vi...@gmail.com>.
Hi Carlos,
2008/4/14, Carlos Sanchez <ca...@apache.org>:
> btw the problem is not just let's make the repo work for maven as
> there are other consumers out there, ie. Equinox provisioning, that
> may like to use the repo as a source and if you change their metadata
> to adjust it to maven it wont be useful for them anymore
Agree and it is why I did MNG-3518, ie only changing Maven logic.
But, WDYT to put Eclipse artifacts without classifier in central? Make
sense for osgi/eclipse?
Cheers,
Vincent
>
>
> On Mon, Apr 14, 2008 at 10:44 AM, Carlos Sanchez <ca...@apache.org> wrote:
> > 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
> > <mi...@asolutions.com> 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" <vs...@apache.org>
> > > To: "Maven Developers List" <de...@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: dev-unsubscribe@maven.apache.org
> > > For additional commands, e-mail: dev-help@maven.apache.org
> > >
> > >
> > >
> > > ---------------------------------------------------------------------
> > > To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
> > > For additional commands, e-mail: dev-help@maven.apache.org
> > >
> > >
> >
> >
> >
> > --
> > I could give you my word as a Spaniard.
> > No good. I've known too many Spaniards.
> > -- The Princess Bride
> >
>
>
>
> --
> I could give you my word as a Spaniard.
> No good. I've known too many Spaniards.
> -- The Princess Bride
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
> For additional commands, e-mail: dev-help@maven.apache.org
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
For additional commands, e-mail: dev-help@maven.apache.org
Re: How to use central repo into an Eclipse project?
Posted by Carlos Sanchez <ca...@apache.org>.
btw the problem is not just let's make the repo work for maven as
there are other consumers out there, ie. Equinox provisioning, that
may like to use the repo as a source and if you change their metadata
to adjust it to maven it wont be useful for them anymore
On Mon, Apr 14, 2008 at 10:44 AM, Carlos Sanchez <ca...@apache.org> wrote:
> 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
> <mi...@asolutions.com> 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" <vs...@apache.org>
> > To: "Maven Developers List" <de...@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: dev-unsubscribe@maven.apache.org
> > For additional commands, e-mail: dev-help@maven.apache.org
> >
> >
> >
> > ---------------------------------------------------------------------
> > To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
> > For additional commands, e-mail: dev-help@maven.apache.org
> >
> >
>
>
>
> --
> I could give you my word as a Spaniard.
> No good. I've known too many Spaniards.
> -- The Princess Bride
>
--
I could give you my word as a Spaniard.
No good. I've known too many Spaniards.
-- The Princess Bride
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
For additional commands, e-mail: dev-help@maven.apache.org
Re: How to use central repo into an Eclipse project?
Posted by Carlos Sanchez <ca...@apache.org>.
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
<mi...@asolutions.com> 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" <vs...@apache.org>
> To: "Maven Developers List" <de...@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: dev-unsubscribe@maven.apache.org
> For additional commands, e-mail: dev-help@maven.apache.org
>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
> For additional commands, e-mail: dev-help@maven.apache.org
>
>
--
I could give you my word as a Spaniard.
No good. I've known too many Spaniards.
-- The Princess Bride
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
For additional commands, e-mail: dev-help@maven.apache.org
Re: How to use central repo into an Eclipse project?
Posted by Micah Hainline <mi...@asolutions.com>.
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" <vs...@apache.org>
To: "Maven Developers List" <de...@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: dev-unsubscribe@maven.apache.org
For additional commands, e-mail: dev-help@maven.apache.org
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
For additional commands, e-mail: dev-help@maven.apache.org