Re: No new version with ivy:buildnumber using Nexus 3.X RM
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 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 > 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: > defaultResolver="nexus"/> > m2compatible="true" root=" >> http://localhost:8081/repository/maven-public/; /> >> I then have a build.xml with a target as follows: >> > module="junit" defaultBuildNumber="1" /> 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. >> 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 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. >
Re: No new version with ivy:buildnumber using Nexus 3.X RM
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 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: > > > > > > http://localhost:8081/repository/maven-public/; /> > > > > I then have a build.xml with a target as follows: > > > > organisation="junit" module="junit" > defaultBuildNumber="1" /> > > > > 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. >> >> > 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 >> 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. >>> >
Re: No new version with ivy:buildnumber using Nexus 3.X RM
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: root="http://localhost:8081/repository/maven-public/; /> I then have a build.xml with a target as follows: 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/repository/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. 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 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.
Re: No new version with ivy:buildnumber using Nexus 3.X RM
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. 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 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. >> > >
Re: No new version with ivy:buildnumber using Nexus 3.X RM
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.
No new version with ivy:buildnumber using Nexus 3.X RM
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.
