You are viewing a plain text version of this content. The canonical link for it is here.
Posted to users@sling.apache.org by Vidar Ramdal <vi...@idium.no> on 2011/02/07 15:49:13 UTC
Does maven-launchpad-plugin support version ranges?
Hi, I'm trying to set up a build that will always use the latest
snapshot of our in-house bundles.
Thus, I'm specifying <version>LATEST</version> in the bundle list XML file:
<bundle>
<groupId>com.idium.kolibri</groupId>
<artifactId>kolibri-loginmodule</artifactId>
<version>LATEST</version>
</bundle>
The build fails constantly with "Embedded error: Unable to determine
the latest version" (see full stacktrace below).
Is this supposed to work with the Launchpad plugin?
Stacktrace:
[INFO] artifact com.idium.kolibri:kolibri-loginmodule: checking for
updates from apache.incubating
[INFO] artifact com.idium.kolibri:kolibri-loginmodule: checking for
updates from OPS4J
[INFO] artifact com.idium.kolibri:kolibri-loginmodule: checking for
updates from Apache Releases
[INFO] artifact com.idium.kolibri:kolibri-loginmodule: checking for
updates from idium.m2
[INFO] artifact com.idium.kolibri:kolibri-loginmodule: checking for
updates from central
[INFO] ------------------------------------------------------------------------
[ERROR] BUILD ERROR
[INFO] ------------------------------------------------------------------------
[INFO] Unable to find artifact.
Embedded error: Unable to determine the latest version
Try downloading the file manually from the project website.
Then, install it using the command:
mvn install:install-file -DgroupId=com.idium.kolibri
-DartifactId=kolibri-loginmodule -Dversion=LATEST -Dpackaging=jar
-Dfile=/path/to/file
Alternatively, if you host your own repository you can deploy the file there:
mvn deploy:deploy-file -DgroupId=com.idium.kolibri
-DartifactId=kolibri-loginmodule -Dversion=LATEST -Dpackaging=jar
-Dfile=/path/to/file -Durl=[url] -DrepositoryId=[id]
com.idium.kolibri:kolibri-loginmodule:jar:LATEST
[INFO] ------------------------------------------------------------------------
[INFO] Trace
org.apache.maven.lifecycle.LifecycleExecutionException: Unable to find artifact.
at org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoals(DefaultLifecycleExecutor.java:719)
at org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoalWithLifecycle(DefaultLifecycleExecutor.java:556)
at org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoal(DefaultLifecycleExecutor.java:535)
at org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoalAndHandleFailures(DefaultLifecycleExecutor.java:387)
at org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeTaskSegments(DefaultLifecycleExecutor.java:348)
at org.apache.maven.lifecycle.DefaultLifecycleExecutor.execute(DefaultLifecycleExecutor.java:180)
at org.apache.maven.DefaultMaven.doExecute(DefaultMaven.java:328)
at org.apache.maven.DefaultMaven.execute(DefaultMaven.java:138)
at org.apache.maven.cli.MavenCli.main(MavenCli.java:362)
at org.apache.maven.cli.compat.CompatibleMain.main(CompatibleMain.java:60)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39)
at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
at java.lang.reflect.Method.invoke(Method.java:597)
at org.codehaus.classworlds.Launcher.launchEnhanced(Launcher.java:315)
at org.codehaus.classworlds.Launcher.launch(Launcher.java:255)
at org.codehaus.classworlds.Launcher.mainWithExitCode(Launcher.java:430)
at org.codehaus.classworlds.Launcher.main(Launcher.java:375)
Caused by: org.apache.maven.plugin.MojoExecutionException: Unable to
find artifact.
at org.apache.sling.maven.projectsupport.AbstractBundleListMojo.getArtifact(AbstractBundleListMojo.java:200)
at org.apache.sling.maven.projectsupport.AbstractBundleListMojo.getArtifact(AbstractBundleListMojo.java:169)
at org.apache.sling.maven.projectsupport.AbstractLaunchpadFrameworkMojo.copy(AbstractLaunchpadFrameworkMojo.java:59)
at org.apache.sling.maven.projectsupport.AbstractLaunchpadFrameworkMojo.copyBundles(AbstractLaunchpadFrameworkMojo.java:53)
at org.apache.sling.maven.projectsupport.PreparePackageMojo.executeWithArtifacts(PreparePackageMojo.java:94)
at org.apache.sling.maven.projectsupport.AbstractBundleListMojo.execute(AbstractBundleListMojo.java:150)
at org.apache.maven.plugin.DefaultPluginManager.executeMojo(DefaultPluginManager.java:490)
at org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoals(DefaultLifecycleExecutor.java:694)
... 17 more
Caused by: org.apache.maven.artifact.resolver.ArtifactNotFoundException:
Unable to determine the latest version
Try downloading the file manually from the project website.
Then, install it using the command:
mvn install:install-file -DgroupId=com.idium.kolibri
-DartifactId=kolibri-loginmodule -Dversion=LATEST -Dpackaging=jar
-Dfile=/path/to/file
Alternatively, if you host your own repository you can deploy the file there:
mvn deploy:deploy-file -DgroupId=com.idium.kolibri
-DartifactId=kolibri-loginmodule -Dversion=LATEST -Dpackaging=jar
-Dfile=/path/to/file -Durl=[url] -DrepositoryId=[id]
com.idium.kolibri:kolibri-loginmodule:jar:LATEST
at org.apache.maven.artifact.transform.LatestArtifactTransformation.transformForResolve(LatestArtifactTransformation.java:44)
at org.apache.maven.artifact.transform.DefaultArtifactTransformationManager.transformForResolve(DefaultArtifactTransformationManager.java:55)
at org.apache.maven.artifact.resolver.DefaultArtifactResolver.resolve(DefaultArtifactResolver.java:145)
at org.apache.maven.artifact.resolver.DefaultArtifactResolver.resolve(DefaultArtifactResolver.java:90)
at org.apache.sling.maven.projectsupport.AbstractBundleListMojo.getArtifact(AbstractBundleListMojo.java:196)
... 24 more
--
Vidar S. Ramdal <vi...@idium.no> - http://www.idium.no
Sommerrogata 13-15, N-0255 Oslo, Norway
+ 47 22 00 84 00
Quando omni flunkus moritatus!
Re: Does maven-launchpad-plugin support version ranges?
Posted by Vidar Ramdal <vi...@idium.no>.
> On Mon, Feb 14, 2011 at 8:49 AM, Justin Edelson
> <ju...@justinedelson.com> wrote:
>> On Mon, Feb 14, 2011 at 5:06 AM, Vidar Ramdal <vi...@idium.no> wrote:
>>>>> On Tue, Feb 8, 2011 at 8:19 AM, Vidar Ramdal <vi...@idium.no> wrote:
>>>>>
>>>>>> > On Tue, Feb 8, 2011 at 4:00 AM, Vidar Ramdal <vi...@idium.no> wrote:
>>>>>> >
>>>>>> >> > On Feb 7, 2011, at 9:49 AM, Vidar Ramdal <vi...@idium.no> wrote:
>>>>>> >> >> Hi, I'm trying to set up a build that will always use the latest
>>>>>> >> >> snapshot of our in-house bundles.
>>>>>> >> >>
>>>>>> >> >> Thus, I'm specifying <version>LATEST</version> in the bundle list XML
>>>>>> >> file:
>>>>>> >> >> <bundle>
>>>>>> >> >> <groupId>com.idium.kolibri</groupId>
>>>>>> >> >> <artifactId>kolibri-loginmodule</artifactId>
>>>>>> >> >> <version>LATEST</version>
>>>>>> >> >> </bundle>
>>>>>> >> >>
>>>>>> >> >> The build fails constantly with "Embedded error: Unable to determine
>>>>>> >> >> the latest version" (see full stacktrace below).
>>>>>> >> >>
>>>>>> >> >> Is this supposed to work with the Launchpad plugin?
>>>>>> >> >> [...]
>>>>>> >>
>>>>>> >> On Tue, Feb 8, 2011 at 1:38 AM, Justin Edelson <
>>>>>> justin@justinedelson.com>
>>>>>> >> wrote:
>>>>>> >> > The plugin uses the normal Maven artifact resolution subsystem, so it
>>>>>> >> should work. We use RELEASE as the http service version.
>>>>>> >> >
>>>>>> >> > I personally don't use LATEST. I have the impression the Maven devs
>>>>>> >> regret supporting it in the first place, but AFAIK, it's still
>>>>>> supported.
>>>>>> >>
>>>>>> >> Thanks, Justin. The only reason I want to use LATEST in this case, is
>>>>>> >> to have an automated launchpad build with all the latest checkins, for
>>>>>> >> testing purposes. So that I don't have to update the bundle list XML
>>>>>> >> when a bundle is released in a new version.
>>>>>> >> In this case it seems LATEST makes sense - or are there other ways to
>>>>>> >> accomplish what I want?
>>>>>>
>>>>>> On Tue, Feb 8, 2011 at 2:02 PM, Justin Edelson <ju...@justinedelson.com>
>>>>>> wrote:
>>>>>> > I wasn't saying you *shouldn't* use LATEST, just providing some context.
>>>>>> I
>>>>>> > would suggest using RELEASE instead of LATEST in this particular case as
>>>>>> > that seems closer to what you want.
>>>>>>
>>>>>> >> > Can you post the maven-metadata.xml for this artifact from you repo
>>>>>> >> manager to a pastebin?
>>>>>> >>
>>>>>> >> Here: http://pastebin.com/uNpJMXQM
>>>>>> >
>>>>>> > Thanks. There's no <latest> element in this file (or <release> for that
>>>>>> > matter, so forget what I said above about RELEASE until you can figure
>>>>>> that
>>>>>> > out). Compare with
>>>>>> >
>>>>>> http://repo2.maven.org/maven2/org/apache/sling/maven-launchpad-plugin/maven-metadata.xml
>>>>>>
>>>>>> Thanks, that sheds some light on things. So the maven-metadata needs
>>>>>> to explicitly define <latest> and <release>. My impression was that
>>>>>> the artifact resolution process would resolve he latest snapshot (and
>>>>>> release) version by simply examining the <versions> element.
>>>>>>
>>>>>> > Now the question is how does the <latest> and <release> get there. And
>>>>>> that,
>>>>>> > as you say, is a Maven question. What repository manager are you using?
>>>>>> How
>>>>>> > are you doing releases?
>>>>>>
>>>>>> Currently no repository manager at all; the metadata.xml file I posted
>>>>>> was from my local ~/.m2. Again, I thought a simple mvn install/deploy
>>>>>> would update the metadata with what I need.
>>>>>>
>>>>>> So are the <latest> and <release> elements actually proprietary to
>>>>>> some repository managers?
>>>>>>
>>>>>
>>>>> Vidar-
>>>>> I haven't had a chance to look into this further, but I just remembered
>>>>> something. I seem to recall that <latest> and <release> were only set on a
>>>>> remote repository, not in the local repository. You don't need a repository
>>>>> manager, just a place you can copy files to (typically via HTTP, SCP, or
>>>>> file://). Repository managers have other things going for them, but SCP +
>>>>> Apache has served me well in the past as well.
>>>>>
>>>>> Give this a shot.
>>>
>>> On Wed, Feb 9, 2011 at 8:18 PM, Vidar Ramdal <vi...@idium.no> wrote:
>>>> Thanks Justin, it doesn't seem to be set on my remote repository
>>>> either. Someone told me to use -DupdateReleaseInfo=true, but that only
>>>> set <release> to a snapshot version.
>>>>
>>>> I'll look further into it, thanks a lot for your help.
>>>> (One problem of googling for Maven solutions is that you get all these
>>>> hits from pages GENERATED by Maven ... sigh)
>>>
>>> I was explained on users@maven.apache.org [1] that <latest> is only
>>> set for plugins, which explains why it never was updated for my
>>> bundles.
>> Hmmm. This doesn't appear to be the case:
>> http://repo1.maven.org/maven2/org/apache/sling/org.apache.sling.event/maven-metadata.xml
>>
>> But either way, it doesn't work, so it should be fixed.
>>
>>>
>>> As suggested by Benjamin in that thread, I tried specifying a version
>>> range of [0,) instead of LATEST, which then causes an NPE:
>>> ava.lang.NullPointerException: version was null for
>>> com.idium.kolibri:kolibri-cache-util
>>> at
>>> org.apache.maven.artifact.DefaultArtifact.getBaseVersion(DefaultArtifact.java:390)
>>> at
>>> org.apache.maven.artifact.repository.layout.DefaultRepositoryLayout.pathOf(DefaultRepositoryLayout.java:47)
>>> at
>>> org.apache.maven.artifact.repository.DefaultArtifactRepository.pathOf(DefaultArtifactRepository.java:110)
>>> at
>>> org.apache.maven.artifact.resolver.DefaultArtifactResolver.resolve(DefaultArtifactResolver.java:141)
>>> at
>>> org.apache.maven.artifact.resolver.DefaultArtifactResolver.resolve(DefaultArtifactResolver.java:90)
>>> at
>>> org.apache.sling.maven.projectsupport.AbstractBundleListMojo.getArtifact(AbstractBundleListMojo.java:196)
>>>
>>> Should I register this as a bug with maven-launchpad-plugin?
>> Please do. I've almost got this fixed, so if you don't, I'll have to
>> before committing it :)
On Mon, Feb 14, 2011 at 2:52 PM, Justin Edelson
<ju...@justinedelson.com> wrote:
> Actually, I'll create the issue. It's fixed locally.
Great :)
--
Vidar S. Ramdal <vi...@idium.no> - http://www.idium.no
Sommerrogata 13-15, N-0255 Oslo, Norway
+ 47 22 00 84 00
Quando omni flunkus moritatus!
Re: Does maven-launchpad-plugin support version ranges?
Posted by Justin Edelson <ju...@justinedelson.com>.
On Mon, Feb 14, 2011 at 8:49 AM, Justin Edelson
<ju...@justinedelson.com> wrote:
> On Mon, Feb 14, 2011 at 5:06 AM, Vidar Ramdal <vi...@idium.no> wrote:
>>>> On Tue, Feb 8, 2011 at 8:19 AM, Vidar Ramdal <vi...@idium.no> wrote:
>>>>
>>>>> > On Tue, Feb 8, 2011 at 4:00 AM, Vidar Ramdal <vi...@idium.no> wrote:
>>>>> >
>>>>> >> > On Feb 7, 2011, at 9:49 AM, Vidar Ramdal <vi...@idium.no> wrote:
>>>>> >> >> Hi, I'm trying to set up a build that will always use the latest
>>>>> >> >> snapshot of our in-house bundles.
>>>>> >> >>
>>>>> >> >> Thus, I'm specifying <version>LATEST</version> in the bundle list XML
>>>>> >> file:
>>>>> >> >> <bundle>
>>>>> >> >> <groupId>com.idium.kolibri</groupId>
>>>>> >> >> <artifactId>kolibri-loginmodule</artifactId>
>>>>> >> >> <version>LATEST</version>
>>>>> >> >> </bundle>
>>>>> >> >>
>>>>> >> >> The build fails constantly with "Embedded error: Unable to determine
>>>>> >> >> the latest version" (see full stacktrace below).
>>>>> >> >>
>>>>> >> >> Is this supposed to work with the Launchpad plugin?
>>>>> >> >> [...]
>>>>> >>
>>>>> >> On Tue, Feb 8, 2011 at 1:38 AM, Justin Edelson <
>>>>> justin@justinedelson.com>
>>>>> >> wrote:
>>>>> >> > The plugin uses the normal Maven artifact resolution subsystem, so it
>>>>> >> should work. We use RELEASE as the http service version.
>>>>> >> >
>>>>> >> > I personally don't use LATEST. I have the impression the Maven devs
>>>>> >> regret supporting it in the first place, but AFAIK, it's still
>>>>> supported.
>>>>> >>
>>>>> >> Thanks, Justin. The only reason I want to use LATEST in this case, is
>>>>> >> to have an automated launchpad build with all the latest checkins, for
>>>>> >> testing purposes. So that I don't have to update the bundle list XML
>>>>> >> when a bundle is released in a new version.
>>>>> >> In this case it seems LATEST makes sense - or are there other ways to
>>>>> >> accomplish what I want?
>>>>>
>>>>> On Tue, Feb 8, 2011 at 2:02 PM, Justin Edelson <ju...@justinedelson.com>
>>>>> wrote:
>>>>> > I wasn't saying you *shouldn't* use LATEST, just providing some context.
>>>>> I
>>>>> > would suggest using RELEASE instead of LATEST in this particular case as
>>>>> > that seems closer to what you want.
>>>>>
>>>>> >> > Can you post the maven-metadata.xml for this artifact from you repo
>>>>> >> manager to a pastebin?
>>>>> >>
>>>>> >> Here: http://pastebin.com/uNpJMXQM
>>>>> >
>>>>> > Thanks. There's no <latest> element in this file (or <release> for that
>>>>> > matter, so forget what I said above about RELEASE until you can figure
>>>>> that
>>>>> > out). Compare with
>>>>> >
>>>>> http://repo2.maven.org/maven2/org/apache/sling/maven-launchpad-plugin/maven-metadata.xml
>>>>>
>>>>> Thanks, that sheds some light on things. So the maven-metadata needs
>>>>> to explicitly define <latest> and <release>. My impression was that
>>>>> the artifact resolution process would resolve he latest snapshot (and
>>>>> release) version by simply examining the <versions> element.
>>>>>
>>>>> > Now the question is how does the <latest> and <release> get there. And
>>>>> that,
>>>>> > as you say, is a Maven question. What repository manager are you using?
>>>>> How
>>>>> > are you doing releases?
>>>>>
>>>>> Currently no repository manager at all; the metadata.xml file I posted
>>>>> was from my local ~/.m2. Again, I thought a simple mvn install/deploy
>>>>> would update the metadata with what I need.
>>>>>
>>>>> So are the <latest> and <release> elements actually proprietary to
>>>>> some repository managers?
>>>>>
>>>>
>>>> Vidar-
>>>> I haven't had a chance to look into this further, but I just remembered
>>>> something. I seem to recall that <latest> and <release> were only set on a
>>>> remote repository, not in the local repository. You don't need a repository
>>>> manager, just a place you can copy files to (typically via HTTP, SCP, or
>>>> file://). Repository managers have other things going for them, but SCP +
>>>> Apache has served me well in the past as well.
>>>>
>>>> Give this a shot.
>>
>> On Wed, Feb 9, 2011 at 8:18 PM, Vidar Ramdal <vi...@idium.no> wrote:
>>> Thanks Justin, it doesn't seem to be set on my remote repository
>>> either. Someone told me to use -DupdateReleaseInfo=true, but that only
>>> set <release> to a snapshot version.
>>>
>>> I'll look further into it, thanks a lot for your help.
>>> (One problem of googling for Maven solutions is that you get all these
>>> hits from pages GENERATED by Maven ... sigh)
>>
>> I was explained on users@maven.apache.org [1] that <latest> is only
>> set for plugins, which explains why it never was updated for my
>> bundles.
> Hmmm. This doesn't appear to be the case:
> http://repo1.maven.org/maven2/org/apache/sling/org.apache.sling.event/maven-metadata.xml
>
> But either way, it doesn't work, so it should be fixed.
>
>>
>> As suggested by Benjamin in that thread, I tried specifying a version
>> range of [0,) instead of LATEST, which then causes an NPE:
>> ava.lang.NullPointerException: version was null for
>> com.idium.kolibri:kolibri-cache-util
>> at
>> org.apache.maven.artifact.DefaultArtifact.getBaseVersion(DefaultArtifact.java:390)
>> at
>> org.apache.maven.artifact.repository.layout.DefaultRepositoryLayout.pathOf(DefaultRepositoryLayout.java:47)
>> at
>> org.apache.maven.artifact.repository.DefaultArtifactRepository.pathOf(DefaultArtifactRepository.java:110)
>> at
>> org.apache.maven.artifact.resolver.DefaultArtifactResolver.resolve(DefaultArtifactResolver.java:141)
>> at
>> org.apache.maven.artifact.resolver.DefaultArtifactResolver.resolve(DefaultArtifactResolver.java:90)
>> at
>> org.apache.sling.maven.projectsupport.AbstractBundleListMojo.getArtifact(AbstractBundleListMojo.java:196)
>>
>> Should I register this as a bug with maven-launchpad-plugin?
>
> Please do. I've almost got this fixed, so if you don't, I'll have to
> before committing it :)
Actually, I'll create the issue. It's fixed locally.
>
> Justin
>
>>
>>
>> [1] http://markmail.org/thread/zyz23ootcpsucsrn
>>
>>
>> --
>> Vidar S. Ramdal <vi...@idium.no> - http://www.idium.no
>> Sommerrogata 13-15, N-0255 Oslo, Norway
>> + 47 22 00 84 00
>> Quando omni flunkus moritatus!
>>
>
Re: Does maven-launchpad-plugin support version ranges?
Posted by Justin Edelson <ju...@justinedelson.com>.
On Mon, Feb 14, 2011 at 5:06 AM, Vidar Ramdal <vi...@idium.no> wrote:
>>> On Tue, Feb 8, 2011 at 8:19 AM, Vidar Ramdal <vi...@idium.no> wrote:
>>>
>>>> > On Tue, Feb 8, 2011 at 4:00 AM, Vidar Ramdal <vi...@idium.no> wrote:
>>>> >
>>>> >> > On Feb 7, 2011, at 9:49 AM, Vidar Ramdal <vi...@idium.no> wrote:
>>>> >> >> Hi, I'm trying to set up a build that will always use the latest
>>>> >> >> snapshot of our in-house bundles.
>>>> >> >>
>>>> >> >> Thus, I'm specifying <version>LATEST</version> in the bundle list XML
>>>> >> file:
>>>> >> >> <bundle>
>>>> >> >> <groupId>com.idium.kolibri</groupId>
>>>> >> >> <artifactId>kolibri-loginmodule</artifactId>
>>>> >> >> <version>LATEST</version>
>>>> >> >> </bundle>
>>>> >> >>
>>>> >> >> The build fails constantly with "Embedded error: Unable to determine
>>>> >> >> the latest version" (see full stacktrace below).
>>>> >> >>
>>>> >> >> Is this supposed to work with the Launchpad plugin?
>>>> >> >> [...]
>>>> >>
>>>> >> On Tue, Feb 8, 2011 at 1:38 AM, Justin Edelson <
>>>> justin@justinedelson.com>
>>>> >> wrote:
>>>> >> > The plugin uses the normal Maven artifact resolution subsystem, so it
>>>> >> should work. We use RELEASE as the http service version.
>>>> >> >
>>>> >> > I personally don't use LATEST. I have the impression the Maven devs
>>>> >> regret supporting it in the first place, but AFAIK, it's still
>>>> supported.
>>>> >>
>>>> >> Thanks, Justin. The only reason I want to use LATEST in this case, is
>>>> >> to have an automated launchpad build with all the latest checkins, for
>>>> >> testing purposes. So that I don't have to update the bundle list XML
>>>> >> when a bundle is released in a new version.
>>>> >> In this case it seems LATEST makes sense - or are there other ways to
>>>> >> accomplish what I want?
>>>>
>>>> On Tue, Feb 8, 2011 at 2:02 PM, Justin Edelson <ju...@justinedelson.com>
>>>> wrote:
>>>> > I wasn't saying you *shouldn't* use LATEST, just providing some context.
>>>> I
>>>> > would suggest using RELEASE instead of LATEST in this particular case as
>>>> > that seems closer to what you want.
>>>>
>>>> >> > Can you post the maven-metadata.xml for this artifact from you repo
>>>> >> manager to a pastebin?
>>>> >>
>>>> >> Here: http://pastebin.com/uNpJMXQM
>>>> >
>>>> > Thanks. There's no <latest> element in this file (or <release> for that
>>>> > matter, so forget what I said above about RELEASE until you can figure
>>>> that
>>>> > out). Compare with
>>>> >
>>>> http://repo2.maven.org/maven2/org/apache/sling/maven-launchpad-plugin/maven-metadata.xml
>>>>
>>>> Thanks, that sheds some light on things. So the maven-metadata needs
>>>> to explicitly define <latest> and <release>. My impression was that
>>>> the artifact resolution process would resolve he latest snapshot (and
>>>> release) version by simply examining the <versions> element.
>>>>
>>>> > Now the question is how does the <latest> and <release> get there. And
>>>> that,
>>>> > as you say, is a Maven question. What repository manager are you using?
>>>> How
>>>> > are you doing releases?
>>>>
>>>> Currently no repository manager at all; the metadata.xml file I posted
>>>> was from my local ~/.m2. Again, I thought a simple mvn install/deploy
>>>> would update the metadata with what I need.
>>>>
>>>> So are the <latest> and <release> elements actually proprietary to
>>>> some repository managers?
>>>>
>>>
>>> Vidar-
>>> I haven't had a chance to look into this further, but I just remembered
>>> something. I seem to recall that <latest> and <release> were only set on a
>>> remote repository, not in the local repository. You don't need a repository
>>> manager, just a place you can copy files to (typically via HTTP, SCP, or
>>> file://). Repository managers have other things going for them, but SCP +
>>> Apache has served me well in the past as well.
>>>
>>> Give this a shot.
>
> On Wed, Feb 9, 2011 at 8:18 PM, Vidar Ramdal <vi...@idium.no> wrote:
>> Thanks Justin, it doesn't seem to be set on my remote repository
>> either. Someone told me to use -DupdateReleaseInfo=true, but that only
>> set <release> to a snapshot version.
>>
>> I'll look further into it, thanks a lot for your help.
>> (One problem of googling for Maven solutions is that you get all these
>> hits from pages GENERATED by Maven ... sigh)
>
> I was explained on users@maven.apache.org [1] that <latest> is only
> set for plugins, which explains why it never was updated for my
> bundles.
Hmmm. This doesn't appear to be the case:
http://repo1.maven.org/maven2/org/apache/sling/org.apache.sling.event/maven-metadata.xml
But either way, it doesn't work, so it should be fixed.
>
> As suggested by Benjamin in that thread, I tried specifying a version
> range of [0,) instead of LATEST, which then causes an NPE:
> ava.lang.NullPointerException: version was null for
> com.idium.kolibri:kolibri-cache-util
> at
> org.apache.maven.artifact.DefaultArtifact.getBaseVersion(DefaultArtifact.java:390)
> at
> org.apache.maven.artifact.repository.layout.DefaultRepositoryLayout.pathOf(DefaultRepositoryLayout.java:47)
> at
> org.apache.maven.artifact.repository.DefaultArtifactRepository.pathOf(DefaultArtifactRepository.java:110)
> at
> org.apache.maven.artifact.resolver.DefaultArtifactResolver.resolve(DefaultArtifactResolver.java:141)
> at
> org.apache.maven.artifact.resolver.DefaultArtifactResolver.resolve(DefaultArtifactResolver.java:90)
> at
> org.apache.sling.maven.projectsupport.AbstractBundleListMojo.getArtifact(AbstractBundleListMojo.java:196)
>
> Should I register this as a bug with maven-launchpad-plugin?
Please do. I've almost got this fixed, so if you don't, I'll have to
before committing it :)
Justin
>
>
> [1] http://markmail.org/thread/zyz23ootcpsucsrn
>
>
> --
> Vidar S. Ramdal <vi...@idium.no> - http://www.idium.no
> Sommerrogata 13-15, N-0255 Oslo, Norway
> + 47 22 00 84 00
> Quando omni flunkus moritatus!
>
Re: Does maven-launchpad-plugin support version ranges?
Posted by Vidar Ramdal <vi...@idium.no>.
>> On Tue, Feb 8, 2011 at 8:19 AM, Vidar Ramdal <vi...@idium.no> wrote:
>>
>>> > On Tue, Feb 8, 2011 at 4:00 AM, Vidar Ramdal <vi...@idium.no> wrote:
>>> >
>>> >> > On Feb 7, 2011, at 9:49 AM, Vidar Ramdal <vi...@idium.no> wrote:
>>> >> >> Hi, I'm trying to set up a build that will always use the latest
>>> >> >> snapshot of our in-house bundles.
>>> >> >>
>>> >> >> Thus, I'm specifying <version>LATEST</version> in the bundle list XML
>>> >> file:
>>> >> >> <bundle>
>>> >> >> <groupId>com.idium.kolibri</groupId>
>>> >> >> <artifactId>kolibri-loginmodule</artifactId>
>>> >> >> <version>LATEST</version>
>>> >> >> </bundle>
>>> >> >>
>>> >> >> The build fails constantly with "Embedded error: Unable to determine
>>> >> >> the latest version" (see full stacktrace below).
>>> >> >>
>>> >> >> Is this supposed to work with the Launchpad plugin?
>>> >> >> [...]
>>> >>
>>> >> On Tue, Feb 8, 2011 at 1:38 AM, Justin Edelson <
>>> justin@justinedelson.com>
>>> >> wrote:
>>> >> > The plugin uses the normal Maven artifact resolution subsystem, so it
>>> >> should work. We use RELEASE as the http service version.
>>> >> >
>>> >> > I personally don't use LATEST. I have the impression the Maven devs
>>> >> regret supporting it in the first place, but AFAIK, it's still
>>> supported.
>>> >>
>>> >> Thanks, Justin. The only reason I want to use LATEST in this case, is
>>> >> to have an automated launchpad build with all the latest checkins, for
>>> >> testing purposes. So that I don't have to update the bundle list XML
>>> >> when a bundle is released in a new version.
>>> >> In this case it seems LATEST makes sense - or are there other ways to
>>> >> accomplish what I want?
>>>
>>> On Tue, Feb 8, 2011 at 2:02 PM, Justin Edelson <ju...@justinedelson.com>
>>> wrote:
>>> > I wasn't saying you *shouldn't* use LATEST, just providing some context.
>>> I
>>> > would suggest using RELEASE instead of LATEST in this particular case as
>>> > that seems closer to what you want.
>>>
>>> >> > Can you post the maven-metadata.xml for this artifact from you repo
>>> >> manager to a pastebin?
>>> >>
>>> >> Here: http://pastebin.com/uNpJMXQM
>>> >
>>> > Thanks. There's no <latest> element in this file (or <release> for that
>>> > matter, so forget what I said above about RELEASE until you can figure
>>> that
>>> > out). Compare with
>>> >
>>> http://repo2.maven.org/maven2/org/apache/sling/maven-launchpad-plugin/maven-metadata.xml
>>>
>>> Thanks, that sheds some light on things. So the maven-metadata needs
>>> to explicitly define <latest> and <release>. My impression was that
>>> the artifact resolution process would resolve he latest snapshot (and
>>> release) version by simply examining the <versions> element.
>>>
>>> > Now the question is how does the <latest> and <release> get there. And
>>> that,
>>> > as you say, is a Maven question. What repository manager are you using?
>>> How
>>> > are you doing releases?
>>>
>>> Currently no repository manager at all; the metadata.xml file I posted
>>> was from my local ~/.m2. Again, I thought a simple mvn install/deploy
>>> would update the metadata with what I need.
>>>
>>> So are the <latest> and <release> elements actually proprietary to
>>> some repository managers?
>>>
>>
>> Vidar-
>> I haven't had a chance to look into this further, but I just remembered
>> something. I seem to recall that <latest> and <release> were only set on a
>> remote repository, not in the local repository. You don't need a repository
>> manager, just a place you can copy files to (typically via HTTP, SCP, or
>> file://). Repository managers have other things going for them, but SCP +
>> Apache has served me well in the past as well.
>>
>> Give this a shot.
On Wed, Feb 9, 2011 at 8:18 PM, Vidar Ramdal <vi...@idium.no> wrote:
> Thanks Justin, it doesn't seem to be set on my remote repository
> either. Someone told me to use -DupdateReleaseInfo=true, but that only
> set <release> to a snapshot version.
>
> I'll look further into it, thanks a lot for your help.
> (One problem of googling for Maven solutions is that you get all these
> hits from pages GENERATED by Maven ... sigh)
I was explained on users@maven.apache.org [1] that <latest> is only
set for plugins, which explains why it never was updated for my
bundles.
As suggested by Benjamin in that thread, I tried specifying a version
range of [0,) instead of LATEST, which then causes an NPE:
ava.lang.NullPointerException: version was null for
com.idium.kolibri:kolibri-cache-util
at
org.apache.maven.artifact.DefaultArtifact.getBaseVersion(DefaultArtifact.java:390)
at
org.apache.maven.artifact.repository.layout.DefaultRepositoryLayout.pathOf(DefaultRepositoryLayout.java:47)
at
org.apache.maven.artifact.repository.DefaultArtifactRepository.pathOf(DefaultArtifactRepository.java:110)
at
org.apache.maven.artifact.resolver.DefaultArtifactResolver.resolve(DefaultArtifactResolver.java:141)
at
org.apache.maven.artifact.resolver.DefaultArtifactResolver.resolve(DefaultArtifactResolver.java:90)
at
org.apache.sling.maven.projectsupport.AbstractBundleListMojo.getArtifact(AbstractBundleListMojo.java:196)
Should I register this as a bug with maven-launchpad-plugin?
[1] http://markmail.org/thread/zyz23ootcpsucsrn
--
Vidar S. Ramdal <vi...@idium.no> - http://www.idium.no
Sommerrogata 13-15, N-0255 Oslo, Norway
+ 47 22 00 84 00
Quando omni flunkus moritatus!
Re: Does maven-launchpad-plugin support version ranges?
Posted by Vidar Ramdal <vi...@idium.no>.
> On Tue, Feb 8, 2011 at 8:19 AM, Vidar Ramdal <vi...@idium.no> wrote:
>
>> > On Tue, Feb 8, 2011 at 4:00 AM, Vidar Ramdal <vi...@idium.no> wrote:
>> >
>> >> > On Feb 7, 2011, at 9:49 AM, Vidar Ramdal <vi...@idium.no> wrote:
>> >> >> Hi, I'm trying to set up a build that will always use the latest
>> >> >> snapshot of our in-house bundles.
>> >> >>
>> >> >> Thus, I'm specifying <version>LATEST</version> in the bundle list XML
>> >> file:
>> >> >> <bundle>
>> >> >> <groupId>com.idium.kolibri</groupId>
>> >> >> <artifactId>kolibri-loginmodule</artifactId>
>> >> >> <version>LATEST</version>
>> >> >> </bundle>
>> >> >>
>> >> >> The build fails constantly with "Embedded error: Unable to determine
>> >> >> the latest version" (see full stacktrace below).
>> >> >>
>> >> >> Is this supposed to work with the Launchpad plugin?
>> >> >> [...]
>> >>
>> >> On Tue, Feb 8, 2011 at 1:38 AM, Justin Edelson <
>> justin@justinedelson.com>
>> >> wrote:
>> >> > The plugin uses the normal Maven artifact resolution subsystem, so it
>> >> should work. We use RELEASE as the http service version.
>> >> >
>> >> > I personally don't use LATEST. I have the impression the Maven devs
>> >> regret supporting it in the first place, but AFAIK, it's still
>> supported.
>> >>
>> >> Thanks, Justin. The only reason I want to use LATEST in this case, is
>> >> to have an automated launchpad build with all the latest checkins, for
>> >> testing purposes. So that I don't have to update the bundle list XML
>> >> when a bundle is released in a new version.
>> >> In this case it seems LATEST makes sense - or are there other ways to
>> >> accomplish what I want?
>>
>> On Tue, Feb 8, 2011 at 2:02 PM, Justin Edelson <ju...@justinedelson.com>
>> wrote:
>> > I wasn't saying you *shouldn't* use LATEST, just providing some context.
>> I
>> > would suggest using RELEASE instead of LATEST in this particular case as
>> > that seems closer to what you want.
>>
>> >> > Can you post the maven-metadata.xml for this artifact from you repo
>> >> manager to a pastebin?
>> >>
>> >> Here: http://pastebin.com/uNpJMXQM
>> >
>> > Thanks. There's no <latest> element in this file (or <release> for that
>> > matter, so forget what I said above about RELEASE until you can figure
>> that
>> > out). Compare with
>> >
>> http://repo2.maven.org/maven2/org/apache/sling/maven-launchpad-plugin/maven-metadata.xml
>>
>> Thanks, that sheds some light on things. So the maven-metadata needs
>> to explicitly define <latest> and <release>. My impression was that
>> the artifact resolution process would resolve he latest snapshot (and
>> release) version by simply examining the <versions> element.
>>
>> > Now the question is how does the <latest> and <release> get there. And
>> that,
>> > as you say, is a Maven question. What repository manager are you using?
>> How
>> > are you doing releases?
>>
>> Currently no repository manager at all; the metadata.xml file I posted
>> was from my local ~/.m2. Again, I thought a simple mvn install/deploy
>> would update the metadata with what I need.
>>
>> So are the <latest> and <release> elements actually proprietary to
>> some repository managers?
>>
>
> Vidar-
> I haven't had a chance to look into this further, but I just remembered
> something. I seem to recall that <latest> and <release> were only set on a
> remote repository, not in the local repository. You don't need a repository
> manager, just a place you can copy files to (typically via HTTP, SCP, or
> file://). Repository managers have other things going for them, but SCP +
> Apache has served me well in the past as well.
>
> Give this a shot.
Thanks Justin, it doesn't seem to be set on my remote repository
either. Someone told me to use -DupdateReleaseInfo=true, but that only
set <release> to a snapshot version.
I'll look further into it, thanks a lot for your help.
(One problem of googling for Maven solutions is that you get all these
hits from pages GENERATED by Maven ... sigh)
--
Vidar S. Ramdal <vi...@idium.no> - http://www.idium.no
Sommerrogata 13-15, N-0255 Oslo, Norway
+ 47 22 00 84 00
Quando omni flunkus moritatus!
Re: Does maven-launchpad-plugin support version ranges?
Posted by Justin Edelson <ju...@justinedelson.com>.
On Tue, Feb 8, 2011 at 8:19 AM, Vidar Ramdal <vi...@idium.no> wrote:
> > On Tue, Feb 8, 2011 at 4:00 AM, Vidar Ramdal <vi...@idium.no> wrote:
> >
> >> > On Feb 7, 2011, at 9:49 AM, Vidar Ramdal <vi...@idium.no> wrote:
> >> >> Hi, I'm trying to set up a build that will always use the latest
> >> >> snapshot of our in-house bundles.
> >> >>
> >> >> Thus, I'm specifying <version>LATEST</version> in the bundle list XML
> >> file:
> >> >> <bundle>
> >> >> <groupId>com.idium.kolibri</groupId>
> >> >> <artifactId>kolibri-loginmodule</artifactId>
> >> >> <version>LATEST</version>
> >> >> </bundle>
> >> >>
> >> >> The build fails constantly with "Embedded error: Unable to determine
> >> >> the latest version" (see full stacktrace below).
> >> >>
> >> >> Is this supposed to work with the Launchpad plugin?
> >> >> [...]
> >>
> >> On Tue, Feb 8, 2011 at 1:38 AM, Justin Edelson <
> justin@justinedelson.com>
> >> wrote:
> >> > The plugin uses the normal Maven artifact resolution subsystem, so it
> >> should work. We use RELEASE as the http service version.
> >> >
> >> > I personally don't use LATEST. I have the impression the Maven devs
> >> regret supporting it in the first place, but AFAIK, it's still
> supported.
> >>
> >> Thanks, Justin. The only reason I want to use LATEST in this case, is
> >> to have an automated launchpad build with all the latest checkins, for
> >> testing purposes. So that I don't have to update the bundle list XML
> >> when a bundle is released in a new version.
> >> In this case it seems LATEST makes sense - or are there other ways to
> >> accomplish what I want?
>
> On Tue, Feb 8, 2011 at 2:02 PM, Justin Edelson <ju...@justinedelson.com>
> wrote:
> > I wasn't saying you *shouldn't* use LATEST, just providing some context.
> I
> > would suggest using RELEASE instead of LATEST in this particular case as
> > that seems closer to what you want.
>
> >> > Can you post the maven-metadata.xml for this artifact from you repo
> >> manager to a pastebin?
> >>
> >> Here: http://pastebin.com/uNpJMXQM
> >
> > Thanks. There's no <latest> element in this file (or <release> for that
> > matter, so forget what I said above about RELEASE until you can figure
> that
> > out). Compare with
> >
> http://repo2.maven.org/maven2/org/apache/sling/maven-launchpad-plugin/maven-metadata.xml
>
> Thanks, that sheds some light on things. So the maven-metadata needs
> to explicitly define <latest> and <release>. My impression was that
> the artifact resolution process would resolve he latest snapshot (and
> release) version by simply examining the <versions> element.
>
> > Now the question is how does the <latest> and <release> get there. And
> that,
> > as you say, is a Maven question. What repository manager are you using?
> How
> > are you doing releases?
>
> Currently no repository manager at all; the metadata.xml file I posted
> was from my local ~/.m2. Again, I thought a simple mvn install/deploy
> would update the metadata with what I need.
>
> So are the <latest> and <release> elements actually proprietary to
> some repository managers?
>
Vidar-
I haven't had a chance to look into this further, but I just remembered
something. I seem to recall that <latest> and <release> were only set on a
remote repository, not in the local repository. You don't need a repository
manager, just a place you can copy files to (typically via HTTP, SCP, or
file://). Repository managers have other things going for them, but SCP +
Apache has served me well in the past as well.
Give this a shot.
Justin
>
> I don't want to spam you or this list with Maven-specific questions,
> but if you could give me any pointers to anywhere this is explained,
> I'd be grateful.
>
> --
> Vidar S. Ramdal <vi...@idium.no> - http://www.idium.no
> Sommerrogata 13-15, N-0255 Oslo, Norway
> + 47 22 00 84 00
> Quando omni flunkus moritatus!
>
Re: Does maven-launchpad-plugin support version ranges?
Posted by Vidar Ramdal <vi...@idium.no>.
> On Tue, Feb 8, 2011 at 4:00 AM, Vidar Ramdal <vi...@idium.no> wrote:
>
>> > On Feb 7, 2011, at 9:49 AM, Vidar Ramdal <vi...@idium.no> wrote:
>> >> Hi, I'm trying to set up a build that will always use the latest
>> >> snapshot of our in-house bundles.
>> >>
>> >> Thus, I'm specifying <version>LATEST</version> in the bundle list XML
>> file:
>> >> <bundle>
>> >> <groupId>com.idium.kolibri</groupId>
>> >> <artifactId>kolibri-loginmodule</artifactId>
>> >> <version>LATEST</version>
>> >> </bundle>
>> >>
>> >> The build fails constantly with "Embedded error: Unable to determine
>> >> the latest version" (see full stacktrace below).
>> >>
>> >> Is this supposed to work with the Launchpad plugin?
>> >> [...]
>>
>> On Tue, Feb 8, 2011 at 1:38 AM, Justin Edelson <ju...@justinedelson.com>
>> wrote:
>> > The plugin uses the normal Maven artifact resolution subsystem, so it
>> should work. We use RELEASE as the http service version.
>> >
>> > I personally don't use LATEST. I have the impression the Maven devs
>> regret supporting it in the first place, but AFAIK, it's still supported.
>>
>> Thanks, Justin. The only reason I want to use LATEST in this case, is
>> to have an automated launchpad build with all the latest checkins, for
>> testing purposes. So that I don't have to update the bundle list XML
>> when a bundle is released in a new version.
>> In this case it seems LATEST makes sense - or are there other ways to
>> accomplish what I want?
On Tue, Feb 8, 2011 at 2:02 PM, Justin Edelson <ju...@justinedelson.com> wrote:
> I wasn't saying you *shouldn't* use LATEST, just providing some context. I
> would suggest using RELEASE instead of LATEST in this particular case as
> that seems closer to what you want.
>> > Can you post the maven-metadata.xml for this artifact from you repo
>> manager to a pastebin?
>>
>> Here: http://pastebin.com/uNpJMXQM
>
> Thanks. There's no <latest> element in this file (or <release> for that
> matter, so forget what I said above about RELEASE until you can figure that
> out). Compare with
> http://repo2.maven.org/maven2/org/apache/sling/maven-launchpad-plugin/maven-metadata.xml
Thanks, that sheds some light on things. So the maven-metadata needs
to explicitly define <latest> and <release>. My impression was that
the artifact resolution process would resolve he latest snapshot (and
release) version by simply examining the <versions> element.
> Now the question is how does the <latest> and <release> get there. And that,
> as you say, is a Maven question. What repository manager are you using? How
> are you doing releases?
Currently no repository manager at all; the metadata.xml file I posted
was from my local ~/.m2. Again, I thought a simple mvn install/deploy
would update the metadata with what I need.
So are the <latest> and <release> elements actually proprietary to
some repository managers?
I don't want to spam you or this list with Maven-specific questions,
but if you could give me any pointers to anywhere this is explained,
I'd be grateful.
--
Vidar S. Ramdal <vi...@idium.no> - http://www.idium.no
Sommerrogata 13-15, N-0255 Oslo, Norway
+ 47 22 00 84 00
Quando omni flunkus moritatus!
Re: Does maven-launchpad-plugin support version ranges?
Posted by Justin Edelson <ju...@justinedelson.com>.
On Tue, Feb 8, 2011 at 4:00 AM, Vidar Ramdal <vi...@idium.no> wrote:
> > On Feb 7, 2011, at 9:49 AM, Vidar Ramdal <vi...@idium.no> wrote:
> >> Hi, I'm trying to set up a build that will always use the latest
> >> snapshot of our in-house bundles.
> >>
> >> Thus, I'm specifying <version>LATEST</version> in the bundle list XML
> file:
> >> <bundle>
> >> <groupId>com.idium.kolibri</groupId>
> >> <artifactId>kolibri-loginmodule</artifactId>
> >> <version>LATEST</version>
> >> </bundle>
> >>
> >> The build fails constantly with "Embedded error: Unable to determine
> >> the latest version" (see full stacktrace below).
> >>
> >> Is this supposed to work with the Launchpad plugin?
> >> [...]
>
> On Tue, Feb 8, 2011 at 1:38 AM, Justin Edelson <ju...@justinedelson.com>
> wrote:
> > The plugin uses the normal Maven artifact resolution subsystem, so it
> should work. We use RELEASE as the http service version.
> >
> > I personally don't use LATEST. I have the impression the Maven devs
> regret supporting it in the first place, but AFAIK, it's still supported.
>
> Thanks, Justin. The only reason I want to use LATEST in this case, is
> to have an automated launchpad build with all the latest checkins, for
> testing purposes. So that I don't have to update the bundle list XML
> when a bundle is released in a new version.
> In this case it seems LATEST makes sense - or are there other ways to
> accomplish what I want?
>
I wasn't saying you *shouldn't* use LATEST, just providing some context. I
would suggest using RELEASE instead of LATEST in this particular case as
that seems closer to what you want.
>
> > Can you post the maven-metadata.xml for this artifact from you repo
> manager to a pastebin?
>
> Here: http://pastebin.com/uNpJMXQM
Thanks. There's no <latest> element in this file (or <release> for that
matter, so forget what I said above about RELEASE until you can figure that
out). Compare with
http://repo2.maven.org/maven2/org/apache/sling/maven-launchpad-plugin/maven-metadata.xml
Now the question is how does the <latest> and <release> get there. And that,
as you say, is a Maven question. What repository manager are you using? How
are you doing releases?
Justin
>
>
> I am using Maven 2.2.1 on my Mac OS 10.6 system, if that makes a
> difference.
>
> Any help appreciated, although I suspect it is more a Maven question
> than a Sling Launchpad question.
>
>
> --
> Vidar S. Ramdal <vi...@idium.no> - http://www.idium.no
> Sommerrogata 13-15, N-0255 Oslo, Norway
> + 47 22 00 84 00
> Quando omni flunkus moritatus!
>
Re: Does maven-launchpad-plugin support version ranges?
Posted by Vidar Ramdal <vi...@idium.no>.
> On Feb 7, 2011, at 9:49 AM, Vidar Ramdal <vi...@idium.no> wrote:
>> Hi, I'm trying to set up a build that will always use the latest
>> snapshot of our in-house bundles.
>>
>> Thus, I'm specifying <version>LATEST</version> in the bundle list XML file:
>> <bundle>
>> <groupId>com.idium.kolibri</groupId>
>> <artifactId>kolibri-loginmodule</artifactId>
>> <version>LATEST</version>
>> </bundle>
>>
>> The build fails constantly with "Embedded error: Unable to determine
>> the latest version" (see full stacktrace below).
>>
>> Is this supposed to work with the Launchpad plugin?
>> [...]
On Tue, Feb 8, 2011 at 1:38 AM, Justin Edelson <ju...@justinedelson.com> wrote:
> The plugin uses the normal Maven artifact resolution subsystem, so it should work. We use RELEASE as the http service version.
>
> I personally don't use LATEST. I have the impression the Maven devs regret supporting it in the first place, but AFAIK, it's still supported.
Thanks, Justin. The only reason I want to use LATEST in this case, is
to have an automated launchpad build with all the latest checkins, for
testing purposes. So that I don't have to update the bundle list XML
when a bundle is released in a new version.
In this case it seems LATEST makes sense - or are there other ways to
accomplish what I want?
> Can you post the maven-metadata.xml for this artifact from you repo manager to a pastebin?
Here: http://pastebin.com/uNpJMXQM
I am using Maven 2.2.1 on my Mac OS 10.6 system, if that makes a difference.
Any help appreciated, although I suspect it is more a Maven question
than a Sling Launchpad question.
--
Vidar S. Ramdal <vi...@idium.no> - http://www.idium.no
Sommerrogata 13-15, N-0255 Oslo, Norway
+ 47 22 00 84 00
Quando omni flunkus moritatus!
Re: Does maven-launchpad-plugin support version ranges?
Posted by Justin Edelson <ju...@justinedelson.com>.
The plugin uses the normal Maven artifact resolution subsystem, so it should work. We use RELEASE as the http service version.
I personally don't use LATEST. I have the impression the Maven devs regret supporting it in the first place, but AFAIK, it's still supported. Can you post the maven-metadata.xml for this artifact from you repo manager to a pastebin?
Justin
On Feb 7, 2011, at 9:49 AM, Vidar Ramdal <vi...@idium.no> wrote:
> Hi, I'm trying to set up a build that will always use the latest
> snapshot of our in-house bundles.
>
> Thus, I'm specifying <version>LATEST</version> in the bundle list XML file:
> <bundle>
> <groupId>com.idium.kolibri</groupId>
> <artifactId>kolibri-loginmodule</artifactId>
> <version>LATEST</version>
> </bundle>
>
> The build fails constantly with "Embedded error: Unable to determine
> the latest version" (see full stacktrace below).
>
> Is this supposed to work with the Launchpad plugin?
>
> Stacktrace:
>
> [INFO] artifact com.idium.kolibri:kolibri-loginmodule: checking for
> updates from apache.incubating
> [INFO] artifact com.idium.kolibri:kolibri-loginmodule: checking for
> updates from OPS4J
> [INFO] artifact com.idium.kolibri:kolibri-loginmodule: checking for
> updates from Apache Releases
> [INFO] artifact com.idium.kolibri:kolibri-loginmodule: checking for
> updates from idium.m2
> [INFO] artifact com.idium.kolibri:kolibri-loginmodule: checking for
> updates from central
> [INFO] ------------------------------------------------------------------------
> [ERROR] BUILD ERROR
> [INFO] ------------------------------------------------------------------------
> [INFO] Unable to find artifact.
>
> Embedded error: Unable to determine the latest version
>
> Try downloading the file manually from the project website.
>
> Then, install it using the command:
> mvn install:install-file -DgroupId=com.idium.kolibri
> -DartifactId=kolibri-loginmodule -Dversion=LATEST -Dpackaging=jar
> -Dfile=/path/to/file
>
> Alternatively, if you host your own repository you can deploy the file there:
> mvn deploy:deploy-file -DgroupId=com.idium.kolibri
> -DartifactId=kolibri-loginmodule -Dversion=LATEST -Dpackaging=jar
> -Dfile=/path/to/file -Durl=[url] -DrepositoryId=[id]
>
>
> com.idium.kolibri:kolibri-loginmodule:jar:LATEST
>
>
>
> [INFO] ------------------------------------------------------------------------
> [INFO] Trace
> org.apache.maven.lifecycle.LifecycleExecutionException: Unable to find artifact.
> at org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoals(DefaultLifecycleExecutor.java:719)
> at org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoalWithLifecycle(DefaultLifecycleExecutor.java:556)
> at org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoal(DefaultLifecycleExecutor.java:535)
> at org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoalAndHandleFailures(DefaultLifecycleExecutor.java:387)
> at org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeTaskSegments(DefaultLifecycleExecutor.java:348)
> at org.apache.maven.lifecycle.DefaultLifecycleExecutor.execute(DefaultLifecycleExecutor.java:180)
> at org.apache.maven.DefaultMaven.doExecute(DefaultMaven.java:328)
> at org.apache.maven.DefaultMaven.execute(DefaultMaven.java:138)
> at org.apache.maven.cli.MavenCli.main(MavenCli.java:362)
> at org.apache.maven.cli.compat.CompatibleMain.main(CompatibleMain.java:60)
> at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
> at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39)
> at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
> at java.lang.reflect.Method.invoke(Method.java:597)
> at org.codehaus.classworlds.Launcher.launchEnhanced(Launcher.java:315)
> at org.codehaus.classworlds.Launcher.launch(Launcher.java:255)
> at org.codehaus.classworlds.Launcher.mainWithExitCode(Launcher.java:430)
> at org.codehaus.classworlds.Launcher.main(Launcher.java:375)
> Caused by: org.apache.maven.plugin.MojoExecutionException: Unable to
> find artifact.
> at org.apache.sling.maven.projectsupport.AbstractBundleListMojo.getArtifact(AbstractBundleListMojo.java:200)
> at org.apache.sling.maven.projectsupport.AbstractBundleListMojo.getArtifact(AbstractBundleListMojo.java:169)
> at org.apache.sling.maven.projectsupport.AbstractLaunchpadFrameworkMojo.copy(AbstractLaunchpadFrameworkMojo.java:59)
> at org.apache.sling.maven.projectsupport.AbstractLaunchpadFrameworkMojo.copyBundles(AbstractLaunchpadFrameworkMojo.java:53)
> at org.apache.sling.maven.projectsupport.PreparePackageMojo.executeWithArtifacts(PreparePackageMojo.java:94)
> at org.apache.sling.maven.projectsupport.AbstractBundleListMojo.execute(AbstractBundleListMojo.java:150)
> at org.apache.maven.plugin.DefaultPluginManager.executeMojo(DefaultPluginManager.java:490)
> at org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoals(DefaultLifecycleExecutor.java:694)
> ... 17 more
> Caused by: org.apache.maven.artifact.resolver.ArtifactNotFoundException:
> Unable to determine the latest version
>
> Try downloading the file manually from the project website.
>
> Then, install it using the command:
> mvn install:install-file -DgroupId=com.idium.kolibri
> -DartifactId=kolibri-loginmodule -Dversion=LATEST -Dpackaging=jar
> -Dfile=/path/to/file
>
> Alternatively, if you host your own repository you can deploy the file there:
> mvn deploy:deploy-file -DgroupId=com.idium.kolibri
> -DartifactId=kolibri-loginmodule -Dversion=LATEST -Dpackaging=jar
> -Dfile=/path/to/file -Durl=[url] -DrepositoryId=[id]
>
>
> com.idium.kolibri:kolibri-loginmodule:jar:LATEST
>
>
>
> at org.apache.maven.artifact.transform.LatestArtifactTransformation.transformForResolve(LatestArtifactTransformation.java:44)
> at org.apache.maven.artifact.transform.DefaultArtifactTransformationManager.transformForResolve(DefaultArtifactTransformationManager.java:55)
> at org.apache.maven.artifact.resolver.DefaultArtifactResolver.resolve(DefaultArtifactResolver.java:145)
> at org.apache.maven.artifact.resolver.DefaultArtifactResolver.resolve(DefaultArtifactResolver.java:90)
> at org.apache.sling.maven.projectsupport.AbstractBundleListMojo.getArtifact(AbstractBundleListMojo.java:196)
> ... 24 more
>
> --
> Vidar S. Ramdal <vi...@idium.no> - http://www.idium.no
> Sommerrogata 13-15, N-0255 Oslo, Norway
> + 47 22 00 84 00
> Quando omni flunkus moritatus!