You are viewing a plain text version of this content. The canonical link for it is here.
Posted to notifications@ant.apache.org by "Nicholas Hinds (Created) (JIRA)" <ji...@apache.org> on 2012/01/23 22:53:40 UTC

[jira] [Created] (IVY-1333) Impossible to get artifacts when data has not been loaded for multiple dynamic revisions

Impossible to get artifacts when data has not been loaded for multiple dynamic revisions
----------------------------------------------------------------------------------------

                 Key: IVY-1333
                 URL: https://issues.apache.org/jira/browse/IVY-1333
             Project: Ivy
          Issue Type: Bug
    Affects Versions: 2.2.0
            Reporter: Nicholas Hinds


When some transitive dependencies depend on the same artifact with the same dynamic revision (say, "1.0.0.+"), and some depend on the actual latest version (say, "1.0.0.m4"), sometimes it results in an IllegalStateException:
{code}
java.lang.IllegalStateException: impossible to get artifacts when data has not been loaded. IvyNode = rev#artifact;1.0.0.m4
	at org.apache.ivy.core.resolve.IvyNode.getArtifacts(IvyNode.java:762)
	at org.apache.ivy.core.resolve.IvyNode.getSelectedArtifacts(IvyNode.java:739)
	at org.apache.ivy.core.report.ResolveReport.setDependencies(ResolveReport.java:235)
	at org.apache.ivy.core.resolve.ResolveEngine.resolve(ResolveEngine.java:238)
	at org.apache.ivy.Ivy.resolve(Ivy.java:512)
{code}
This exception is reproducable for a given combination of artifacts. Changing the dependencies slightly so the module depends directly on a specific version of the artifact seems to fix this problem, as does changing some of the transitive dependencies.

The issue seems to be caused by the {{LatestRevisionStrategy}} comparing two IvyNodes as equal because they have the same resolved id, but their actual IDs differ. The following debug log shows the conflict manager trying to resolve the 1.0.0.+ and 1.0.0.m4 dependencies:
{quote}
found conflicting revisions for rev#artifact;1.0.0.m4 in rev#another-artifact;1.0.0.beta: [rev#artifact;1.0.0.m4, rev#artifact;1.0.0.m4]
{quote}
When the {{LatestRevisionStrategy}} is asked to pick the latest revision out of those two artifacts, it just chooses the last one in the list (since they compare as equal the order is maintained). At different points in the resolve, the list is passed to the {{LatestRevisionStrategy}} in a different order and a different artifact is considered the latest one, so both versions end up being evicted.

{quote}
loadData of rev#artifact;1.0.0.m4 of rootConf=dist
dist is evicted.  Skip loading
{quote}

The fix is to make the order deterministic when the resolved ids are equal but unresolved ids are not. A simple hacky workaround is to try the regular comparison, and if that doesn't work, try comparing the real revisions. This seems hacky because the {{ArtifactInfo}} class doesn't provide any information about the real revisions, only the resolved revisions. I have a local hacked subclass of {{LatestRevisionStrategy}} which fixes this problem, if it helps.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira

        

[jira] [Commented] (IVY-1333) Impossible to get artifacts when data has not been loaded for multiple dynamic revisions

Posted by "Maarten Coene (Commented) (JIRA)" <ji...@apache.org>.
    [ https://issues.apache.org/jira/browse/IVY-1333?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13232399#comment-13232399 ] 

Maarten Coene commented on IVY-1333:
------------------------------------

Could you also attach your ivy.xml (and preferably a build.xml) to this issue so we could reproduce the problem more easily?
                
> Impossible to get artifacts when data has not been loaded for multiple dynamic revisions
> ----------------------------------------------------------------------------------------
>
>                 Key: IVY-1333
>                 URL: https://issues.apache.org/jira/browse/IVY-1333
>             Project: Ivy
>          Issue Type: Bug
>    Affects Versions: 2.2.0
>            Reporter: Nicholas Hinds
>         Attachments: ErrorTest.zip, MaybeFixedLatestRevisionStrategy.java
>
>
> When some transitive dependencies depend on the same artifact with the same dynamic revision (say, "1.0.0.+"), and some depend on the actual latest version (say, "1.0.0.m4"), sometimes it results in an IllegalStateException:
> {code}
> java.lang.IllegalStateException: impossible to get artifacts when data has not been loaded. IvyNode = rev#artifact;1.0.0.m4
> 	at org.apache.ivy.core.resolve.IvyNode.getArtifacts(IvyNode.java:762)
> 	at org.apache.ivy.core.resolve.IvyNode.getSelectedArtifacts(IvyNode.java:739)
> 	at org.apache.ivy.core.report.ResolveReport.setDependencies(ResolveReport.java:235)
> 	at org.apache.ivy.core.resolve.ResolveEngine.resolve(ResolveEngine.java:238)
> 	at org.apache.ivy.Ivy.resolve(Ivy.java:512)
> {code}
> This exception is reproducable for a given combination of artifacts. Changing the dependencies slightly so the module depends directly on a specific version of the artifact seems to fix this problem, as does changing some of the transitive dependencies.
> The issue seems to be caused by the {{LatestRevisionStrategy}} comparing two IvyNodes as equal because they have the same resolved id, but their actual IDs differ. The following debug log shows the conflict manager trying to resolve the 1.0.0.+ and 1.0.0.m4 dependencies:
> {quote}
> found conflicting revisions for rev#artifact;1.0.0.m4 in rev#another-artifact;1.0.0.beta: [rev#artifact;1.0.0.m4, rev#artifact;1.0.0.m4]
> {quote}
> When the {{LatestRevisionStrategy}} is asked to pick the latest revision out of those two artifacts, it just chooses the last one in the list (since they compare as equal the order is maintained). At different points in the resolve, the list is passed to the {{LatestRevisionStrategy}} in a different order and a different artifact is considered the latest one, so both versions end up being evicted.
> {quote}
> loadData of rev#artifact;1.0.0.m4 of rootConf=dist
> dist is evicted.  Skip loading
> {quote}
> The fix is to make the order deterministic when the resolved ids are equal but unresolved ids are not. A simple hacky workaround is to try the regular comparison, and if that doesn't work, try comparing the real revisions. This seems hacky because the {{ArtifactInfo}} class doesn't provide any information about the real revisions, only the resolved revisions. I have a local hacked subclass of {{LatestRevisionStrategy}} which fixes this problem, if it helps.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira

        

[jira] [Commented] (IVY-1333) Impossible to get artifacts when data has not been loaded for multiple dynamic revisions

Posted by "Carl Quinn (Commented) (JIRA)" <ji...@apache.org>.
    [ https://issues.apache.org/jira/browse/IVY-1333?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13230696#comment-13230696 ] 

Carl Quinn commented on IVY-1333:
---------------------------------

We are seeing this exception as well, and it seems similar to IVY-1326 .

Nicholas: I'd be interested in trying out your hacked LatestRevisionStrategy if you still have it handy. Maybe you could attach it to this jira.

                
> Impossible to get artifacts when data has not been loaded for multiple dynamic revisions
> ----------------------------------------------------------------------------------------
>
>                 Key: IVY-1333
>                 URL: https://issues.apache.org/jira/browse/IVY-1333
>             Project: Ivy
>          Issue Type: Bug
>    Affects Versions: 2.2.0
>            Reporter: Nicholas Hinds
>
> When some transitive dependencies depend on the same artifact with the same dynamic revision (say, "1.0.0.+"), and some depend on the actual latest version (say, "1.0.0.m4"), sometimes it results in an IllegalStateException:
> {code}
> java.lang.IllegalStateException: impossible to get artifacts when data has not been loaded. IvyNode = rev#artifact;1.0.0.m4
> 	at org.apache.ivy.core.resolve.IvyNode.getArtifacts(IvyNode.java:762)
> 	at org.apache.ivy.core.resolve.IvyNode.getSelectedArtifacts(IvyNode.java:739)
> 	at org.apache.ivy.core.report.ResolveReport.setDependencies(ResolveReport.java:235)
> 	at org.apache.ivy.core.resolve.ResolveEngine.resolve(ResolveEngine.java:238)
> 	at org.apache.ivy.Ivy.resolve(Ivy.java:512)
> {code}
> This exception is reproducable for a given combination of artifacts. Changing the dependencies slightly so the module depends directly on a specific version of the artifact seems to fix this problem, as does changing some of the transitive dependencies.
> The issue seems to be caused by the {{LatestRevisionStrategy}} comparing two IvyNodes as equal because they have the same resolved id, but their actual IDs differ. The following debug log shows the conflict manager trying to resolve the 1.0.0.+ and 1.0.0.m4 dependencies:
> {quote}
> found conflicting revisions for rev#artifact;1.0.0.m4 in rev#another-artifact;1.0.0.beta: [rev#artifact;1.0.0.m4, rev#artifact;1.0.0.m4]
> {quote}
> When the {{LatestRevisionStrategy}} is asked to pick the latest revision out of those two artifacts, it just chooses the last one in the list (since they compare as equal the order is maintained). At different points in the resolve, the list is passed to the {{LatestRevisionStrategy}} in a different order and a different artifact is considered the latest one, so both versions end up being evicted.
> {quote}
> loadData of rev#artifact;1.0.0.m4 of rootConf=dist
> dist is evicted.  Skip loading
> {quote}
> The fix is to make the order deterministic when the resolved ids are equal but unresolved ids are not. A simple hacky workaround is to try the regular comparison, and if that doesn't work, try comparing the real revisions. This seems hacky because the {{ArtifactInfo}} class doesn't provide any information about the real revisions, only the resolved revisions. I have a local hacked subclass of {{LatestRevisionStrategy}} which fixes this problem, if it helps.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira

        

[jira] [Commented] (IVY-1333) Impossible to get artifacts when data has not been loaded for multiple dynamic revisions

Posted by "Carl Quinn (Commented) (JIRA)" <ji...@apache.org>.
    [ https://issues.apache.org/jira/browse/IVY-1333?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13231720#comment-13231720 ] 

Carl Quinn commented on IVY-1333:
---------------------------------

This particular fix didn't seem to help my case. Same symptom, different root cause I think.

It seems that in my case we've got some modules that added <exclude>s of themselves to hack around some cycle problems while testing, and this then causes downstream builds to break when they depend on those modules. Seems that exclude masks the loading of the module and then the same check fails in IvyInfo later. 

Is this bug possibly related to: IVY-1326?
                
> Impossible to get artifacts when data has not been loaded for multiple dynamic revisions
> ----------------------------------------------------------------------------------------
>
>                 Key: IVY-1333
>                 URL: https://issues.apache.org/jira/browse/IVY-1333
>             Project: Ivy
>          Issue Type: Bug
>    Affects Versions: 2.2.0
>            Reporter: Nicholas Hinds
>         Attachments: MaybeFixedLatestRevisionStrategy.java
>
>
> When some transitive dependencies depend on the same artifact with the same dynamic revision (say, "1.0.0.+"), and some depend on the actual latest version (say, "1.0.0.m4"), sometimes it results in an IllegalStateException:
> {code}
> java.lang.IllegalStateException: impossible to get artifacts when data has not been loaded. IvyNode = rev#artifact;1.0.0.m4
> 	at org.apache.ivy.core.resolve.IvyNode.getArtifacts(IvyNode.java:762)
> 	at org.apache.ivy.core.resolve.IvyNode.getSelectedArtifacts(IvyNode.java:739)
> 	at org.apache.ivy.core.report.ResolveReport.setDependencies(ResolveReport.java:235)
> 	at org.apache.ivy.core.resolve.ResolveEngine.resolve(ResolveEngine.java:238)
> 	at org.apache.ivy.Ivy.resolve(Ivy.java:512)
> {code}
> This exception is reproducable for a given combination of artifacts. Changing the dependencies slightly so the module depends directly on a specific version of the artifact seems to fix this problem, as does changing some of the transitive dependencies.
> The issue seems to be caused by the {{LatestRevisionStrategy}} comparing two IvyNodes as equal because they have the same resolved id, but their actual IDs differ. The following debug log shows the conflict manager trying to resolve the 1.0.0.+ and 1.0.0.m4 dependencies:
> {quote}
> found conflicting revisions for rev#artifact;1.0.0.m4 in rev#another-artifact;1.0.0.beta: [rev#artifact;1.0.0.m4, rev#artifact;1.0.0.m4]
> {quote}
> When the {{LatestRevisionStrategy}} is asked to pick the latest revision out of those two artifacts, it just chooses the last one in the list (since they compare as equal the order is maintained). At different points in the resolve, the list is passed to the {{LatestRevisionStrategy}} in a different order and a different artifact is considered the latest one, so both versions end up being evicted.
> {quote}
> loadData of rev#artifact;1.0.0.m4 of rootConf=dist
> dist is evicted.  Skip loading
> {quote}
> The fix is to make the order deterministic when the resolved ids are equal but unresolved ids are not. A simple hacky workaround is to try the regular comparison, and if that doesn't work, try comparing the real revisions. This seems hacky because the {{ArtifactInfo}} class doesn't provide any information about the real revisions, only the resolved revisions. I have a local hacked subclass of {{LatestRevisionStrategy}} which fixes this problem, if it helps.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira

        

[jira] [Resolved] (IVY-1333) Impossible to get artifacts when data has not been loaded for multiple dynamic revisions

Posted by "Maarten Coene (Resolved) (JIRA)" <ji...@apache.org>.
     [ https://issues.apache.org/jira/browse/IVY-1333?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Maarten Coene resolved IVY-1333.
--------------------------------

       Resolution: Fixed
    Fix Version/s: trunk
         Assignee: Maarten Coene

I've committed a fix for this issue in svn trunk.
Could you give it a try and post your feedback here?

thanks!
Maarten
                
> Impossible to get artifacts when data has not been loaded for multiple dynamic revisions
> ----------------------------------------------------------------------------------------
>
>                 Key: IVY-1333
>                 URL: https://issues.apache.org/jira/browse/IVY-1333
>             Project: Ivy
>          Issue Type: Bug
>    Affects Versions: 2.2.0
>            Reporter: Nicholas Hinds
>            Assignee: Maarten Coene
>             Fix For: trunk
>
>         Attachments: ErrorTest.zip, MaybeFixedLatestRevisionStrategy.java, anterror.zip
>
>
> When some transitive dependencies depend on the same artifact with the same dynamic revision (say, "1.0.0.+"), and some depend on the actual latest version (say, "1.0.0.m4"), sometimes it results in an IllegalStateException:
> {code}
> java.lang.IllegalStateException: impossible to get artifacts when data has not been loaded. IvyNode = rev#artifact;1.0.0.m4
> 	at org.apache.ivy.core.resolve.IvyNode.getArtifacts(IvyNode.java:762)
> 	at org.apache.ivy.core.resolve.IvyNode.getSelectedArtifacts(IvyNode.java:739)
> 	at org.apache.ivy.core.report.ResolveReport.setDependencies(ResolveReport.java:235)
> 	at org.apache.ivy.core.resolve.ResolveEngine.resolve(ResolveEngine.java:238)
> 	at org.apache.ivy.Ivy.resolve(Ivy.java:512)
> {code}
> This exception is reproducable for a given combination of artifacts. Changing the dependencies slightly so the module depends directly on a specific version of the artifact seems to fix this problem, as does changing some of the transitive dependencies.
> The issue seems to be caused by the {{LatestRevisionStrategy}} comparing two IvyNodes as equal because they have the same resolved id, but their actual IDs differ. The following debug log shows the conflict manager trying to resolve the 1.0.0.+ and 1.0.0.m4 dependencies:
> {quote}
> found conflicting revisions for rev#artifact;1.0.0.m4 in rev#another-artifact;1.0.0.beta: [rev#artifact;1.0.0.m4, rev#artifact;1.0.0.m4]
> {quote}
> When the {{LatestRevisionStrategy}} is asked to pick the latest revision out of those two artifacts, it just chooses the last one in the list (since they compare as equal the order is maintained). At different points in the resolve, the list is passed to the {{LatestRevisionStrategy}} in a different order and a different artifact is considered the latest one, so both versions end up being evicted.
> {quote}
> loadData of rev#artifact;1.0.0.m4 of rootConf=dist
> dist is evicted.  Skip loading
> {quote}
> The fix is to make the order deterministic when the resolved ids are equal but unresolved ids are not. A simple hacky workaround is to try the regular comparison, and if that doesn't work, try comparing the real revisions. This seems hacky because the {{ArtifactInfo}} class doesn't provide any information about the real revisions, only the resolved revisions. I have a local hacked subclass of {{LatestRevisionStrategy}} which fixes this problem, if it helps.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira

        

[jira] [Updated] (IVY-1333) Impossible to get artifacts when data has not been loaded for multiple dynamic revisions

Posted by "Nicholas Hinds (Updated) (JIRA)" <ji...@apache.org>.
     [ https://issues.apache.org/jira/browse/IVY-1333?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Nicholas Hinds updated IVY-1333:
--------------------------------

    Attachment: ErrorTest.zip

I don't think it's the same cause as IVY-1326 - when I run the test case attached to that ticket, I don't see anything like
{code}
found conflicting revisions for rev#artifact;1.0.0.m4 in rev#another-artifact;1.0.0.beta: [rev#artifact;1.0.0.m4, rev#artifact;1.0.0.m4]
{code}

I've attached an eclipse project which shows this error. Interestingly, while trying to cut down the ivy files to the minimum configuration which triggers this exception, I found that if I removed a custom attribute from the artifact, the problem went away. In the attached zip file, if you remove the {{o:a}} and {{xmlns:o}} attributes from {{badArtifact}}'s {{ivy.xml}}, no exception is thrown. I would not expect unknown attributes to cause dependency resolution errors.

Also in the test project is the hacked latest strategy which fixes this case.
                
> Impossible to get artifacts when data has not been loaded for multiple dynamic revisions
> ----------------------------------------------------------------------------------------
>
>                 Key: IVY-1333
>                 URL: https://issues.apache.org/jira/browse/IVY-1333
>             Project: Ivy
>          Issue Type: Bug
>    Affects Versions: 2.2.0
>            Reporter: Nicholas Hinds
>         Attachments: ErrorTest.zip, MaybeFixedLatestRevisionStrategy.java
>
>
> When some transitive dependencies depend on the same artifact with the same dynamic revision (say, "1.0.0.+"), and some depend on the actual latest version (say, "1.0.0.m4"), sometimes it results in an IllegalStateException:
> {code}
> java.lang.IllegalStateException: impossible to get artifacts when data has not been loaded. IvyNode = rev#artifact;1.0.0.m4
> 	at org.apache.ivy.core.resolve.IvyNode.getArtifacts(IvyNode.java:762)
> 	at org.apache.ivy.core.resolve.IvyNode.getSelectedArtifacts(IvyNode.java:739)
> 	at org.apache.ivy.core.report.ResolveReport.setDependencies(ResolveReport.java:235)
> 	at org.apache.ivy.core.resolve.ResolveEngine.resolve(ResolveEngine.java:238)
> 	at org.apache.ivy.Ivy.resolve(Ivy.java:512)
> {code}
> This exception is reproducable for a given combination of artifacts. Changing the dependencies slightly so the module depends directly on a specific version of the artifact seems to fix this problem, as does changing some of the transitive dependencies.
> The issue seems to be caused by the {{LatestRevisionStrategy}} comparing two IvyNodes as equal because they have the same resolved id, but their actual IDs differ. The following debug log shows the conflict manager trying to resolve the 1.0.0.+ and 1.0.0.m4 dependencies:
> {quote}
> found conflicting revisions for rev#artifact;1.0.0.m4 in rev#another-artifact;1.0.0.beta: [rev#artifact;1.0.0.m4, rev#artifact;1.0.0.m4]
> {quote}
> When the {{LatestRevisionStrategy}} is asked to pick the latest revision out of those two artifacts, it just chooses the last one in the list (since they compare as equal the order is maintained). At different points in the resolve, the list is passed to the {{LatestRevisionStrategy}} in a different order and a different artifact is considered the latest one, so both versions end up being evicted.
> {quote}
> loadData of rev#artifact;1.0.0.m4 of rootConf=dist
> dist is evicted.  Skip loading
> {quote}
> The fix is to make the order deterministic when the resolved ids are equal but unresolved ids are not. A simple hacky workaround is to try the regular comparison, and if that doesn't work, try comparing the real revisions. This seems hacky because the {{ArtifactInfo}} class doesn't provide any information about the real revisions, only the resolved revisions. I have a local hacked subclass of {{LatestRevisionStrategy}} which fixes this problem, if it helps.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira

        

[jira] [Commented] (IVY-1333) Impossible to get artifacts when data has not been loaded for multiple dynamic revisions

Posted by "Nicholas Hinds (Commented) (JIRA)" <ji...@apache.org>.
    [ https://issues.apache.org/jira/browse/IVY-1333?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13250186#comment-13250186 ] 

Nicholas Hinds commented on IVY-1333:
-------------------------------------

The latest snapshot build has fixed the original problem. Thanks :)
                
> Impossible to get artifacts when data has not been loaded for multiple dynamic revisions
> ----------------------------------------------------------------------------------------
>
>                 Key: IVY-1333
>                 URL: https://issues.apache.org/jira/browse/IVY-1333
>             Project: Ivy
>          Issue Type: Bug
>    Affects Versions: 2.2.0
>            Reporter: Nicholas Hinds
>            Assignee: Maarten Coene
>             Fix For: 2.3.0-RC1
>
>         Attachments: ErrorTest.zip, MaybeFixedLatestRevisionStrategy.java, anterror.zip
>
>
> When some transitive dependencies depend on the same artifact with the same dynamic revision (say, "1.0.0.+"), and some depend on the actual latest version (say, "1.0.0.m4"), sometimes it results in an IllegalStateException:
> {code}
> java.lang.IllegalStateException: impossible to get artifacts when data has not been loaded. IvyNode = rev#artifact;1.0.0.m4
> 	at org.apache.ivy.core.resolve.IvyNode.getArtifacts(IvyNode.java:762)
> 	at org.apache.ivy.core.resolve.IvyNode.getSelectedArtifacts(IvyNode.java:739)
> 	at org.apache.ivy.core.report.ResolveReport.setDependencies(ResolveReport.java:235)
> 	at org.apache.ivy.core.resolve.ResolveEngine.resolve(ResolveEngine.java:238)
> 	at org.apache.ivy.Ivy.resolve(Ivy.java:512)
> {code}
> This exception is reproducable for a given combination of artifacts. Changing the dependencies slightly so the module depends directly on a specific version of the artifact seems to fix this problem, as does changing some of the transitive dependencies.
> The issue seems to be caused by the {{LatestRevisionStrategy}} comparing two IvyNodes as equal because they have the same resolved id, but their actual IDs differ. The following debug log shows the conflict manager trying to resolve the 1.0.0.+ and 1.0.0.m4 dependencies:
> {quote}
> found conflicting revisions for rev#artifact;1.0.0.m4 in rev#another-artifact;1.0.0.beta: [rev#artifact;1.0.0.m4, rev#artifact;1.0.0.m4]
> {quote}
> When the {{LatestRevisionStrategy}} is asked to pick the latest revision out of those two artifacts, it just chooses the last one in the list (since they compare as equal the order is maintained). At different points in the resolve, the list is passed to the {{LatestRevisionStrategy}} in a different order and a different artifact is considered the latest one, so both versions end up being evicted.
> {quote}
> loadData of rev#artifact;1.0.0.m4 of rootConf=dist
> dist is evicted.  Skip loading
> {quote}
> The fix is to make the order deterministic when the resolved ids are equal but unresolved ids are not. A simple hacky workaround is to try the regular comparison, and if that doesn't work, try comparing the real revisions. This seems hacky because the {{ArtifactInfo}} class doesn't provide any information about the real revisions, only the resolved revisions. I have a local hacked subclass of {{LatestRevisionStrategy}} which fixes this problem, if it helps.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira

        

[jira] [Updated] (IVY-1333) Impossible to get artifacts when data has not been loaded for multiple dynamic revisions

Posted by "Nicholas Hinds (Updated) (JIRA)" <ji...@apache.org>.
     [ https://issues.apache.org/jira/browse/IVY-1333?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Nicholas Hinds updated IVY-1333:
--------------------------------

    Attachment: MaybeFixedLatestRevisionStrategy.java

I don't have access to the original fix (or the case which caused this error) at the moment, but the attached {{MaybeFixedLatestRevisionStrategy.java}} should be roughly equivalent. I have not tested this file.
                
> Impossible to get artifacts when data has not been loaded for multiple dynamic revisions
> ----------------------------------------------------------------------------------------
>
>                 Key: IVY-1333
>                 URL: https://issues.apache.org/jira/browse/IVY-1333
>             Project: Ivy
>          Issue Type: Bug
>    Affects Versions: 2.2.0
>            Reporter: Nicholas Hinds
>         Attachments: MaybeFixedLatestRevisionStrategy.java
>
>
> When some transitive dependencies depend on the same artifact with the same dynamic revision (say, "1.0.0.+"), and some depend on the actual latest version (say, "1.0.0.m4"), sometimes it results in an IllegalStateException:
> {code}
> java.lang.IllegalStateException: impossible to get artifacts when data has not been loaded. IvyNode = rev#artifact;1.0.0.m4
> 	at org.apache.ivy.core.resolve.IvyNode.getArtifacts(IvyNode.java:762)
> 	at org.apache.ivy.core.resolve.IvyNode.getSelectedArtifacts(IvyNode.java:739)
> 	at org.apache.ivy.core.report.ResolveReport.setDependencies(ResolveReport.java:235)
> 	at org.apache.ivy.core.resolve.ResolveEngine.resolve(ResolveEngine.java:238)
> 	at org.apache.ivy.Ivy.resolve(Ivy.java:512)
> {code}
> This exception is reproducable for a given combination of artifacts. Changing the dependencies slightly so the module depends directly on a specific version of the artifact seems to fix this problem, as does changing some of the transitive dependencies.
> The issue seems to be caused by the {{LatestRevisionStrategy}} comparing two IvyNodes as equal because they have the same resolved id, but their actual IDs differ. The following debug log shows the conflict manager trying to resolve the 1.0.0.+ and 1.0.0.m4 dependencies:
> {quote}
> found conflicting revisions for rev#artifact;1.0.0.m4 in rev#another-artifact;1.0.0.beta: [rev#artifact;1.0.0.m4, rev#artifact;1.0.0.m4]
> {quote}
> When the {{LatestRevisionStrategy}} is asked to pick the latest revision out of those two artifacts, it just chooses the last one in the list (since they compare as equal the order is maintained). At different points in the resolve, the list is passed to the {{LatestRevisionStrategy}} in a different order and a different artifact is considered the latest one, so both versions end up being evicted.
> {quote}
> loadData of rev#artifact;1.0.0.m4 of rootConf=dist
> dist is evicted.  Skip loading
> {quote}
> The fix is to make the order deterministic when the resolved ids are equal but unresolved ids are not. A simple hacky workaround is to try the regular comparison, and if that doesn't work, try comparing the real revisions. This seems hacky because the {{ArtifactInfo}} class doesn't provide any information about the real revisions, only the resolved revisions. I have a local hacked subclass of {{LatestRevisionStrategy}} which fixes this problem, if it helps.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira

        

[jira] [Updated] (IVY-1333) Impossible to get artifacts when data has not been loaded for multiple dynamic revisions

Posted by "Nicholas Hinds (Updated) (JIRA)" <ji...@apache.org>.
     [ https://issues.apache.org/jira/browse/IVY-1333?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Nicholas Hinds updated IVY-1333:
--------------------------------

    Attachment: anterror.zip

Sure thing, I've converted the eclipse project which reproduced it into an ant project in the attached anterror.zip.

Running {{ant}} or {{ant ivyerror}} will reproduce the problem. Running {{ant ivyfixed}} will do the same resolve but with the modified latest revision strategy, which should succeed (if you've got the attached class on your classpath)
                
> Impossible to get artifacts when data has not been loaded for multiple dynamic revisions
> ----------------------------------------------------------------------------------------
>
>                 Key: IVY-1333
>                 URL: https://issues.apache.org/jira/browse/IVY-1333
>             Project: Ivy
>          Issue Type: Bug
>    Affects Versions: 2.2.0
>            Reporter: Nicholas Hinds
>         Attachments: ErrorTest.zip, MaybeFixedLatestRevisionStrategy.java, anterror.zip
>
>
> When some transitive dependencies depend on the same artifact with the same dynamic revision (say, "1.0.0.+"), and some depend on the actual latest version (say, "1.0.0.m4"), sometimes it results in an IllegalStateException:
> {code}
> java.lang.IllegalStateException: impossible to get artifacts when data has not been loaded. IvyNode = rev#artifact;1.0.0.m4
> 	at org.apache.ivy.core.resolve.IvyNode.getArtifacts(IvyNode.java:762)
> 	at org.apache.ivy.core.resolve.IvyNode.getSelectedArtifacts(IvyNode.java:739)
> 	at org.apache.ivy.core.report.ResolveReport.setDependencies(ResolveReport.java:235)
> 	at org.apache.ivy.core.resolve.ResolveEngine.resolve(ResolveEngine.java:238)
> 	at org.apache.ivy.Ivy.resolve(Ivy.java:512)
> {code}
> This exception is reproducable for a given combination of artifacts. Changing the dependencies slightly so the module depends directly on a specific version of the artifact seems to fix this problem, as does changing some of the transitive dependencies.
> The issue seems to be caused by the {{LatestRevisionStrategy}} comparing two IvyNodes as equal because they have the same resolved id, but their actual IDs differ. The following debug log shows the conflict manager trying to resolve the 1.0.0.+ and 1.0.0.m4 dependencies:
> {quote}
> found conflicting revisions for rev#artifact;1.0.0.m4 in rev#another-artifact;1.0.0.beta: [rev#artifact;1.0.0.m4, rev#artifact;1.0.0.m4]
> {quote}
> When the {{LatestRevisionStrategy}} is asked to pick the latest revision out of those two artifacts, it just chooses the last one in the list (since they compare as equal the order is maintained). At different points in the resolve, the list is passed to the {{LatestRevisionStrategy}} in a different order and a different artifact is considered the latest one, so both versions end up being evicted.
> {quote}
> loadData of rev#artifact;1.0.0.m4 of rootConf=dist
> dist is evicted.  Skip loading
> {quote}
> The fix is to make the order deterministic when the resolved ids are equal but unresolved ids are not. A simple hacky workaround is to try the regular comparison, and if that doesn't work, try comparing the real revisions. This seems hacky because the {{ArtifactInfo}} class doesn't provide any information about the real revisions, only the resolved revisions. I have a local hacked subclass of {{LatestRevisionStrategy}} which fixes this problem, if it helps.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira