> On Mon, Feb 14, 2011 at 8:49 AM, Justin Edelson > <[email protected]> wrote: >> On Mon, Feb 14, 2011 at 5:06 AM, Vidar Ramdal <[email protected]> wrote: >>>>> On Tue, Feb 8, 2011 at 8:19 AM, Vidar Ramdal <[email protected]> wrote: >>>>> >>>>>> > On Tue, Feb 8, 2011 at 4:00 AM, Vidar Ramdal <[email protected]> wrote: >>>>>> > >>>>>> >> > On Feb 7, 2011, at 9:49 AM, Vidar Ramdal <[email protected]> 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 < >>>>>> [email protected]> >>>>>> >> 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 <[email protected]> >>>>>> 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 <[email protected]> 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 [email protected] [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 <[email protected]> wrote: > Actually, I'll create the issue. It's fixed locally. Great :) -- Vidar S. Ramdal <[email protected]> - http://www.idium.no Sommerrogata 13-15, N-0255 Oslo, Norway + 47 22 00 84 00 Quando omni flunkus moritatus!
