[
https://issues.apache.org/jira/browse/IVY-1124?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Maarten Coene updated IVY-1124:
-------------------------------
Fix Version/s: (was: trunk)
2.2.0-RC1
> 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: 2.2.0-RC1
>
> 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.
