ant-notifications mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Maarten Coene (JIRA)" <j...@apache.org>
Subject [jira] Resolved: (IVY-1124) IbiblioResolver not always correctly configured when using JRE 1.5
Date Tue, 29 Sep 2009 22:14:07 GMT

     [ https://issues.apache.org/jira/browse/IVY-1124?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]

Maarten Coene resolved IVY-1124.
--------------------------------

    Resolution: Fixed

I've applied your patch into SVN trunk.
Thanks a lot for the contribution!

Maarten

> IbiblioResolver not always correctly configured when using JRE 1.5
> ------------------------------------------------------------------
>
>                 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
>            Assignee: Maarten Coene
>             Fix For: trunk
>
>         Attachments: IBiblioRepository.java.diff, IvyTest.zip
>
>
> 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