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 :)
Actually, I'll create the issue. It's fixed locally. > > Justin > >> >> >> [1] http://markmail.org/thread/zyz23ootcpsucsrn >> >> >> -- >> 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! >> >
