ant-ivy-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Jaikiran Pai <jai.forums2...@gmail.com>
Subject Re: No new version with ivy:buildnumber using Nexus 3.X RM
Date Sat, 21 Jul 2018 10:41:35 GMT

On 17/07/18 1:06 AM, t4rockets wrote:
> However, after reading the group/artifact XML file, the latest version
> is not calculated properly. Is this the error eluded to in the
> ApacheURLLister class? 
Yes.

> Since the maven-metadata.xml file could be updated and uploaded to
> Nexus, is there a modification (or work-around) that you would
> recommend to see if the ivy:buildnumber is working as expected?
Not right now, for Nexus 3.x. I need to understand and read up their
discussion on how it's implemented in Nexus 3.

> Secondly, is this an Ivy issue or did Sonartype introduce the issue
> with their version 3.x? 
What Ivy does is - it uses the repository's URL (the one configured for
the resolver) to "list" the versions. While doing so, it parses the
rendered HTML page to "understand" (by searching for <a href...> links)
the available versions. As noted in the javadoc of ApacheURLLister[1],
this parsing works against a specific set of servers, which render the
HTML in a format that this parser understands. Right now, what Nexus 3
does is it presents a generic HTML (error kind of) page which asks you
to use a different URL in order to list the content.

[1]
https://github.com/apache/ant-ivy/blob/master/src/java/org/apache/ivy/util/url/ApacheURLLister.java#L37

-Jaikiran
> On Fri, Jul 13, 2018 at 8:13 AM, Jaikiran Pai
> <jai.forums2013@gmail.com> wrote:
>> I haven't done extensive testing yet. However, my quick tests against
>> a local installed Nexus 3 (latest, default configs) doesn't show this
>> issue of 404. Here's a ivysettings.xml very similar to your except
>> that it uses the "maven-public" repo: <ivysettings> <settings
>> defaultResolver="nexus"/> <resolvers> <ibiblio name="nexus"
>> m2compatible="true" root="
>> http://localhost:8081/repository/maven-public/" /> </resolvers>
>> </ivysettings> I then have a build.xml with a target as follows:
>> <target name="ivy-new-version"> <ivy:buildnumber organisation="junit"
>> module="junit" defaultBuildNumber="1" /> <echo message="New version
>> is ${ivy.new.revision}"/> </target> Running this target doesn't show
>> the 404 issue. It successfully finds the maven-metadata.xml (which it
>> uses for build number computation) as shown in the logs:
>> [ivy:buildnumber] default resolver: nexus [ivy:buildnumber] -- 1
>> resolvers: [ivy:buildnumber] nexus [ibiblio] [ivy:buildnumber]
>> listing revisions from maven-metadata:
>> http://localhost:8081/repository/maven-public/junit/junit/
>> maven-metadata.xml [echo] New version is 0 Even a curl against that
>> http://localhost:8081/reposito
>> ry/maven-public/junit/junit/maven-metadata.xml returns a valid
>> response. Having said that, it doesn't generate a right build number
>> and the reason for that is a potential bug in (an internal class of
>> Ivy) ApacheURLLister which has a specific logic while parsing the
>> rendered HTML content, which no longer is satisfied by Nexus 3. I'll
>> be looking into that part separately. However, can you run your Ant
>> build by using the "-d" option to generate debug logs and share the
>> build logs to show where/why it throws the 404? By the way, if curl
>> itself can't get to the maven-metadata.xml file (noted in the logs
>> above), then that's an issue that needs to be sorted at Nexus
>> configuration, IMO. -Jaikiran On 13/07/18 7:02 PM, t4rockets wrote:
>>> The resolver for NXRM is a standard ibiblio resolver configuration
>>> with Maven 2 compatibility enabled and the remaining options are the
>>> default. Changing the resolver options (i.e., has not provided any
>>> different behavior. <ibiblio name="release" m2compatible="true"
>>> root="http://localhost:8081/repository/release> Using curl, it can
>>> be shown that NXRM returns the 404 error for a HEAD or GET request
>>> which is believed to be the same request that Ivy in processing.
>>> When NXRM3 was released, the following ticket was written for an
>>> issue that seems similar to the Ivy 404 error,
>>> https://issues.sonatype.org/browse/NEXUS-12531. However, the
>>> resolution has been implemented in the latest version of NXRM, but
>>> Ivy is still getting the 404 error code. Thanks, On Thu, Jul 12,
>>> 2018 at 11:28 PM, Jaikiran Pai <jai.forums2013@gmail.com> wrote:
>>> Could you share with us the ivysettings.xml which configures this
>>> Nexus(?)
>>>> 3 resolver? -Jaikiran On 12/07/18 11:33 PM, t4rockets wrote: When
>>>> Ivy 2.4.0 is requesting header information during an ivy:buildnumber
>>>>> task, NXRM 3.x is returning for 404 error code indicating the page
>>>>> was not found. Because of the 404 error, the buildnumber task can
>>>>> not determine the current build number so that it can be
>>>>> incremented. The Ivy multi-project example has the test case where
>>>>> this error can be seen. The Ivy example uses the local filesystem
>>>>> resolver and that work as expected, but adding NXRM OSS 3.X as
>>>>> another resolver for publication causes the error to occur after
>>>>> the initial artifact (version/build number 1) is published. The
>>>>> version/build number is always 1 because the ivy:buildnumber task
>>>>> does not find the existing artifact for version/build number 1. 
>



Mime
View raw message