After looking at the debug output again, the maven-metadata.xml file is being read at the group/artifact level of the Maven compatible NXRM3 repository. The 404 messages are generated when trying to read from each version level. Since there is no XML file (or Ivy resource trying to be read) at the version level, it would be expected that the 404 error would be created.
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? 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? Secondly, is this an Ivy issue or did Sonartype introduce the issue with their version 3.x? 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. >>>> >>>> >>> >
