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/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.
<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.
