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.forums2...@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.forums2...@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. >
