ant-notifications mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Flavio Coutinho da Costa (JIRA)" <j...@apache.org>
Subject [jira] Created: (IVY-1124) Ivy succeeds to publish in Java6 but fails in Java5
Date Thu, 17 Sep 2009 04:33:57 GMT
Ivy succeeds to publish in Java6 but fails in Java5
---------------------------------------------------

                 Key: IVY-1124
                 URL: https://issues.apache.org/jira/browse/IVY-1124
             Project: Ivy
          Issue Type: Bug
          Components: Core
    Affects Versions: 2.1.0-RC2
         Environment: Linux
            Reporter: Flavio Coutinho da Costa
             Fix For: trunk


IBiblioResolver has a small bug due to a change in the behaviour between Java5 and Java6.
After spending quite a lot of time debugging this I finally found where the problem is.

I've added some debugging messages to the following methods so that I could keep track of
what is happening behind the scenes.
* setM2compatible
* setUsepoms
* setPattern
* setRoot
All the debug does it print the name of the method that's getting called and print the hash
code of the instance (just for the sake of identifying in which repository the call happened)

>From the documentation and from the code we can see that the 'usepoms' property defaults
to 'true'.
Now let's take a look the following snippet of code extracted from IBiblioResolver:
	
	private void updateWholePattern() {
		if (isM2compatible() && isUsepoms()) {
	            	setIvyPatterns(Collections.singletonList(getWholePattern()));
	        }
	        setArtifactPatterns(Collections.singletonList(getWholePattern()));
	}

Assuming that setM2compatible(true) happens before a setUsepoms(false) Ivy would end up calling
setIvyPatterns(...) and therefore setting an invalid Ivy pattern (actually it's not invalid
but a default one like this: http://repo1.maven.org/maven2/). After this happens Ivy won't
have a chance to ever "unset/reset" the Ivy patterns list and because of that any artifact
which type equals to "ivy" will (try) to be uploaded to Maven Central repository as this code
extracted from RepositoryResolver highlights:

	public void publish(Artifact artifact, File src, boolean overwrite) throws IOException {
	        String destPattern;
	        if ("ivy".equals(artifact.getType()) && !getIvyPatterns().isEmpty()) {
	            destPattern = (String) getIvyPatterns().get(0);
	        } else if (!getArtifactPatterns().isEmpty()) {
	            destPattern = (String) getArtifactPatterns().get(0);
	        }
		...
	}

Instead of falling back to getArtifactPatterns (as desired and expected), Ivy sees that the
List returned by getIvyPatterns() is not empty (due to the bug mentioned above) and tries
to upload the ivy.xml file to Maven Central (where, most of the mortals, can't HTTP PUT) resulting
on the following:

	/home/flavio/workspace/IvyTestCase/build.xml:16: impossible to publish artifacts for my.test.case#ivy-test;1.0:
java.io.IOException: PUT operation to URL http://repo1.maven.org/maven2/my/test/case/ivy-test/1.0/ivy-1.0.xml
failed with status code 405

Enough of side effects, let's get back to the actual bug.

Like I said before this bug happens due to a difference in behaviour between Java5 and Java6.
The following ant output shows that:

--- Running Java(TM) SE Runtime Environment - 1.6.0_16-b01
[ivy:configure] :: Ivy 2.2.x-local-20090917003317 - 20090917003317 :: http://ant.apache.org/ivy/
::
[ivy:configure] :: loading settings :: file = /home/flavio/workspace/IvyTestCase/ivysettings.xml
[ivy:configure] setM2compatible called for repo: 9740137
[ivy:configure] setUsepoms called for repo: 13228332
[ivy:configure] setPattern called for repo: 13228332
[ivy:configure] setRoot called for repo: 13228332
[ivy:configure] setM2compatible called for repo: 13228332

setUsepoms(false) is called before setM2compatible(true) so the bug is never triggered because
the condition in IBiblioResolver.updateWholePattern() evaluates to false and setIvyPatterns(...)
is NEVER called thus resulting on getIvyPatterns() returning an empty List later on and because
of that RepositoryResolver falls back to getArtifactPatterns(). Everything works just fine.

--- Running Java(TM) 2 Runtime Environment, Standard Edition - 1.5.0_21-b01
[ivy:configure] :: Ivy 2.2.x-local-20090917003317 - 20090917003317 :: http://ant.apache.org/ivy/
::
[ivy:configure] :: loading settings :: file = /home/flavio/workspace/IvyTestCase/ivysettings.xml
[ivy:configure] setM2compatible called for repo: 18923308
[ivy:configure] setM2compatible called for repo: 13078969
[ivy:configure] setUsepoms called for repo: 13078969
[ivy:configure] setRoot called for repo: 13078969
[ivy:configure] setPattern called for repo: 13078969

setM2compatible(true) is called before setUsepoms(false) and the condition inside IBiblioResolver.updateWholePattern()
evaluates to true causing a cascade effect (setIvyPatterns() is called and can't be reseted/unseted,
RepositoryResolver never falls back to getArtifactPatterns(), etc, etc...). Everything falls
apart!

So the fact of the XML parser interpreting the arguments in a different order totally screw
up the logic.

I found a way around this by change the IBiblioResolver.updateWholePattern() to this:
	private void updateWholePattern() {
        	if (isM2compatible() && isUsepoms()) {
	            setIvyPatterns(Collections.singletonList(getWholePattern()));
	        } else {
	            setIvyPatterns(Collections.EMPTY_LIST);
	        }
	        setArtifactPatterns(Collections.singletonList(getWholePattern()));
	}
Basically resetting the list whenever the condition doesn't evaluates to true, giving Ivy
the chance to "recover" from the wrong state it was set. Not sure if that's the right way
but it did fix the problem since the IvyPatterns List is actually empty when it should, not
counting on a weird behaviour of a specific JVM version.

I'll be attaching the diff of IBiblioRepository.java and also a sample project that can trigger
this bug.

-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.


Mime
View raw message