[jira] [Commented] (FELIX-6358) 2 jars with different names but the exact same bundle cause multiple chains

["Tom Watson (Jira)" <ji...@apache.org>]

    [ https://issues.apache.org/jira/browse/FELIX-6358?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17230698#comment-17230698 ] 

Tom Watson commented on FELIX-6358:
-----------------------------------

If the resolve context is duplicating resources for the exact same content then I can imagine it presenting the resolver with a problem that is a bit more difficult to navigate.  More choices requires more data to be stored in the decision tree/stack which takes more memory.  I'm not sure if BND uses a timeout to cancel the operation or not.  If it does then it could be cancelling the resolve at which point the resolver just goes with the "best solution" found so far.  A fix has just gone into BND to address the duplicate resources.  I think that fix would help address your issue.

> 2 jars with different names but the exact same bundle cause multiple chains 
> ----------------------------------------------------------------------------
>
>                 Key: FELIX-6358
>                 URL: https://issues.apache.org/jira/browse/FELIX-6358
>             Project: Felix
>          Issue Type: Bug
>          Components: Resolver
>    Affects Versions: resolver-2.0.0
>            Reporter: Jürgen Albert
>            Priority: Major
>
> # Scenario
> We have a bnd project where the resolver eats all the memory until eclipse dies. 
> After some search and investigation of the log I stumbled upon the following repeating chains it complained about:
>  
> {code:java}
> DEBUG: Candidate permutation failed due to a conflict between imports; will try another if possible. (Uses constraint violation. Unable to resolve resource some.bundle.1 [some.bundle.1 version=1.0.0.SNAPSHOT] because it is exposed to package 'org.eclipse.swt.widgets' from resources org.eclipse.swt [org.eclipse.swt version=3.113.0.v20191204-0601] and org.eclipse.swt [org.eclipse.swt version=3.113.0.v20191204-0601] via two dependency chains.Chain 1:
>   some.bundle.1 [some.bundle.1 version=1.0.0.SNAPSHOT]
>     import: (osgi.wiring.package=org.eclipse.swt.widgets)
>      |
>     export: osgi.wiring.package: org.eclipse.swt.widgets
>   org.eclipse.swt [org.eclipse.swt version=3.113.0.v20191204-0601]Chain 2:
>   some.bundle.2 [some.bundle.2 version=1.0.0.SNAPSHOT]
>     import: (&(osgi.wiring.package=some.package.1)(version>=1.3.0)(!(version>=2.0.0)))
>      |
>     export: osgi.wiring.package=some.package.1; uses:=org.eclipse.swt.widgets
>   some.bundle.3 [some.bundle.3 version=1.3.0.SNAPSHOT]
>     import: (osgi.wiring.package=org.eclipse.swt.widgets)
>      |
>     export: osgi.wiring.package: org.eclipse.swt.widgets
>   org.eclipse.swt [org.eclipse.swt version=3.113.0.v20191204-0601])
> {code}
> (I replaced the bundle and package names. I hope I didn't screw up)
> It turned out (after debugging), that org.eclipse.swt version=3.113.0.v20191204-0601 is available twice. One from a p2 repo and one as a maven artifact, that was uploaded manually. The maven upload was renamed by artifactory and had the name swt-4.14.0.jar. besides the name, the two jars are identical to the best of my knowledge. 
> # the issue
> The two Bundles jars, that represent the exact same bundle where handled by the resolver as two separate bundles. I'm not sure if this is an actual issue or a matter of works as intended.
> If it is the latter the resource location should should be part error message. Without there is no way to distinguish the jars.
> If it is the former it might be a good idea to compare resources via a hash of their content (I saw something in the debugger around the resource location, that looked like a hash and was identical for both jars, but I could be mistaken).  
> This could be a bnd issue as well and might be related to: https://github.com/bndtools/bnd/issues/4172 
>  



--
This message was sent by Atlassian Jira
(v8.3.4#803005)