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 :)

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!
>

Reply via email to