[jira] [Commented] (ARIES-1491) Fragment-host bundle is refreshed when a new fragment is installed
[ https://issues.apache.org/jira/browse/ARIES-1491?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15130467#comment-15130467 ] Wouter Bancken commented on ARIES-1491: --- We indeed tried to refresh the fragment-host bundle and this did work. As Tom said, we think solution (3) is the best option since it solves the issues and has the least overall impact on deployment. I can't think of any cases where that behaviour would be undesirable. If we discover a case, we could still consider making the refresh configurable. > Fragment-host bundle is refreshed when a new fragment is installed > -- > > Key: ARIES-1491 > URL: https://issues.apache.org/jira/browse/ARIES-1491 > Project: Aries > Issue Type: Improvement > Components: Subsystem >Affects Versions: subsystem-2.0.8 >Reporter: Wouter Bancken > > The Felix framework will not allow fragments to attach to an already resolved > host. This results in resolution errors when a new fragment bundle appears in > a new subsystem while the fragment-host is in an already started subsystem. > These resolution errors can be resolved by refreshing > (FrameworkWiring.refreshBundles) the resolved fragment-host bundle after > installing the fragment. > Aries could do this automatically when it encounters a fragment-host > requirement when resolving a subsystem. > Related mailinglist discussion: > http://mail-archives.apache.org/mod_mbox/aries-user/201602.mbox/browser -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Comment Edited] (ARIES-1491) Fragment-host bundle is refreshed when a new fragment is installed
[ https://issues.apache.org/jira/browse/ARIES-1491?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15130467#comment-15130467 ] Wouter Bancken edited comment on ARIES-1491 at 2/3/16 2:31 PM: --- We indeed tried to refresh the fragment-host bundle by itself and this did work. As Tom said, we think solution (3) is the best option since it solves the issues and has the least overall impact on deployment. I can't think of any cases where that behaviour would be undesirable. If we discover a case, we could still consider making the refresh configurable. was (Author: wouter bancken): We indeed tried to refresh the fragment-host bundle and this did work. As Tom said, we think solution (3) is the best option since it solves the issues and has the least overall impact on deployment. I can't think of any cases where that behaviour would be undesirable. If we discover a case, we could still consider making the refresh configurable. > Fragment-host bundle is refreshed when a new fragment is installed > -- > > Key: ARIES-1491 > URL: https://issues.apache.org/jira/browse/ARIES-1491 > Project: Aries > Issue Type: Improvement > Components: Subsystem >Affects Versions: subsystem-2.0.8 >Reporter: Wouter Bancken > > The Felix framework will not allow fragments to attach to an already resolved > host. This results in resolution errors when a new fragment bundle appears in > a new subsystem while the fragment-host is in an already started subsystem. > These resolution errors can be resolved by refreshing > (FrameworkWiring.refreshBundles) the resolved fragment-host bundle after > installing the fragment. > Aries could do this automatically when it encounters a fragment-host > requirement when resolving a subsystem. > Related mailinglist discussion: > http://mail-archives.apache.org/mod_mbox/aries-user/201602.mbox/browser -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Created] (ARIES-1493) Investigate making the org.osgi.service.cm dependency optional rather than mandatory.
John Ross created ARIES-1493: Summary: Investigate making the org.osgi.service.cm dependency optional rather than mandatory. Key: ARIES-1493 URL: https://issues.apache.org/jira/browse/ARIES-1493 Project: Aries Issue Type: Improvement Components: Subsystem Affects Versions: subsystem-2.0.8 Reporter: John Ross Priority: Minor The subsystem core bundle currently has a mandatory dependency on package org.osgi.service.cm. I believe this was added as part of ARIES-1252. We should make this optional if possible. David, do you see any issues with making this dependency optional? -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (ARIES-1493) Investigate making the org.osgi.service.cm dependency optional rather than mandatory.
[ https://issues.apache.org/jira/browse/ARIES-1493?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15130566#comment-15130566 ] David Bosschaert commented on ARIES-1493: - No big issue, but the ConfigAdminContentHandler depends on it. This one is created and registered as a service in the main Activator. So we need to probably change the activator a little bit so that it does not register this service and does not cause any exceptions if the ConfigAdmin package is not available. > Investigate making the org.osgi.service.cm dependency optional rather than > mandatory. > - > > Key: ARIES-1493 > URL: https://issues.apache.org/jira/browse/ARIES-1493 > Project: Aries > Issue Type: Improvement > Components: Subsystem >Affects Versions: subsystem-2.0.8 >Reporter: John Ross >Priority: Minor > > The subsystem core bundle currently has a mandatory dependency on package > org.osgi.service.cm. I believe this was added as part of ARIES-1252. We > should make this optional if possible. > David, do you see any issues with making this dependency optional? -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (ARIES-1493) Investigate making the org.osgi.service.cm dependency optional rather than mandatory.
[ https://issues.apache.org/jira/browse/ARIES-1493?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15130586#comment-15130586 ] David Bosschaert commented on ARIES-1493: - Or... as friend suggested: bq. Register as a ServiceFactory with the service name as a String (instead of XYZ.class.name()). Then the service is registered and once the API becomes available and the service is requested the ServiceFactory returns the actual instance. The cm package has to be DynamicImport-Package-ed for this to work. > Investigate making the org.osgi.service.cm dependency optional rather than > mandatory. > - > > Key: ARIES-1493 > URL: https://issues.apache.org/jira/browse/ARIES-1493 > Project: Aries > Issue Type: Improvement > Components: Subsystem >Affects Versions: subsystem-2.0.8 >Reporter: John Ross >Priority: Minor > > The subsystem core bundle currently has a mandatory dependency on package > org.osgi.service.cm. I believe this was added as part of ARIES-1252. We > should make this optional if possible. > David, do you see any issues with making this dependency optional? -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (ARIES-1486) can't create proxy on java 8 vm for interfaces containing lambda
[ https://issues.apache.org/jira/browse/ARIES-1486?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Samuel Bratton updated ARIES-1486: -- Fix Version/s: proxy-impl-1.0.5 > can't create proxy on java 8 vm for interfaces containing lambda > - > > Key: ARIES-1486 > URL: https://issues.apache.org/jira/browse/ARIES-1486 > Project: Aries > Issue Type: Bug > Components: Proxy >Affects Versions: proxy-impl-1.0.5 > Environment: Java 8 vm >Reporter: Samuel Bratton >Assignee: Samuel Bratton > Fix For: proxy-impl-1.0.5 > > Attachments: aries1486.patch > > > Creating proxy of an interface containing a default method implemented with a > lambda will result in a invalid Proxy class file (see attached test case). -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (ARIES-1491) Fragment-host bundle is refreshed when a new fragment is installed
[ https://issues.apache.org/jira/browse/ARIES-1491?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15130355#comment-15130355 ] John Ross commented on ARIES-1491: -- So then the motivating use case here is when it is not possible to ensure that all subsystems are installed first before starting any. You have an environment in which subsystems containing fragments may come and go after the subsystem containing the host bundle has been started. Note that simply stopping then starting the host subsystem will not work since the bundles will remain in the RESOLVED state, and resolving an already RESOLVED bundle is a no-op. You noted that refreshing only the host bundle works. Is this something you've actually tried? It should work in theory since both Felix and Equinox will automatically search for installed fragments as part of a host bundle's resolution, but would be nice to know for sure. Refreshing only the host bundle is a much simpler task for a client then having to compute the host as well as all fragments itself. I can think of the following possible implementations. (1) Always refresh a subsystem's bundles as part of starting. Heavyweight. Affects everyone all the time. (2) Always refresh a subsystem's bundles as part of starting if indicated by a configurable property whose default value would result in the current behavior. Heavyweight if the desired behavior is not often necessary. (3) Detect installing fragments, query the current state of the host, refresh if necessary. Optimal for this particular case but are there other cases when a refresh would be desirable that we want to address? Also, are there cases where this behavior would be undesirable (i.e. should the behavior be configurable)? (4) Add an additional method to the AriesSubsystem interface called "startWithRefresh", or simply "restart" where the refresh is implied, or whatever name is desired, and let clients dictate exactly when a refresh should occur. It's not clear if this adds any value above and beyond simply calling FrameworkWiring.refreshBundles() on the host. > Fragment-host bundle is refreshed when a new fragment is installed > -- > > Key: ARIES-1491 > URL: https://issues.apache.org/jira/browse/ARIES-1491 > Project: Aries > Issue Type: Improvement > Components: Subsystem >Affects Versions: subsystem-2.0.8 >Reporter: Wouter Bancken > > The Felix framework will not allow fragments to attach to an already resolved > host. This results in resolution errors when a new fragment bundle appears in > a new subsystem while the fragment-host is in an already started subsystem. > These resolution errors can be resolved by refreshing > (FrameworkWiring.refreshBundles) the resolved fragment-host bundle after > installing the fragment. > Aries could do this automatically when it encounters a fragment-host > requirement when resolving a subsystem. > Related mailinglist discussion: > http://mail-archives.apache.org/mod_mbox/aries-user/201602.mbox/browser -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (ARIES-1491) Fragment-host bundle is refreshed when a new fragment is installed
[ https://issues.apache.org/jira/browse/ARIES-1491?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15130366#comment-15130366 ] Tom De Wolf commented on ARIES-1491: Looks like option (3) is the best option as in general normal bundles do not need such a refresh cross-subsystem. OSGi fragments-host is part of the OSGi spec so have fragment specific support cross-subsystems seems logical to implement. The current aries subsystem implementation already has specific fragment support for other reasons. > Fragment-host bundle is refreshed when a new fragment is installed > -- > > Key: ARIES-1491 > URL: https://issues.apache.org/jira/browse/ARIES-1491 > Project: Aries > Issue Type: Improvement > Components: Subsystem >Affects Versions: subsystem-2.0.8 >Reporter: Wouter Bancken > > The Felix framework will not allow fragments to attach to an already resolved > host. This results in resolution errors when a new fragment bundle appears in > a new subsystem while the fragment-host is in an already started subsystem. > These resolution errors can be resolved by refreshing > (FrameworkWiring.refreshBundles) the resolved fragment-host bundle after > installing the fragment. > Aries could do this automatically when it encounters a fragment-host > requirement when resolving a subsystem. > Related mailinglist discussion: > http://mail-archives.apache.org/mod_mbox/aries-user/201602.mbox/browser -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Resolved] (ARIES-1486) can't create proxy on java 8 vm for interfaces containing lambda
[ https://issues.apache.org/jira/browse/ARIES-1486?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Samuel Bratton resolved ARIES-1486. --- Resolution: Fixed > can't create proxy on java 8 vm for interfaces containing lambda > - > > Key: ARIES-1486 > URL: https://issues.apache.org/jira/browse/ARIES-1486 > Project: Aries > Issue Type: Bug > Components: Proxy >Affects Versions: proxy-impl-1.0.5 > Environment: Java 8 vm >Reporter: Samuel Bratton >Assignee: Samuel Bratton > Fix For: proxy-impl-1.0.5 > > Attachments: aries1486.patch > > > Creating proxy of an interface containing a default method implemented with a > lambda will result in a invalid Proxy class file (see attached test case). -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Resolved] (ARIES-1492) Exception creating a subclass proxy of class with package-private access modifer.
[ https://issues.apache.org/jira/browse/ARIES-1492?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Samuel Bratton resolved ARIES-1492. --- Resolution: Fixed Fix Version/s: proxy-impl-1.0.5 > Exception creating a subclass proxy of class with package-private access > modifer. > - > > Key: ARIES-1492 > URL: https://issues.apache.org/jira/browse/ARIES-1492 > Project: Aries > Issue Type: Bug > Components: Proxy >Affects Versions: proxy-impl-1.0.3 >Reporter: Samuel Bratton >Assignee: Samuel Bratton > Fix For: proxy-impl-1.0.5 > > > Creating a subclass proxy of class with package-private access modifer throws > an IllegalArgumentException: > java.lang.IllegalArgumentException: null > at org.objectweb.asm.commons.Method.getMethod(Method.java:175) > at org.objectweb.asm.commons.Method.getMethod(Method.java:144) > at > org.apache.aries.proxy.impl.gen.ProxySubclassAdapter.visit(ProxySubclassAdapter.java:154) > at org.objectweb.asm.ClassReader.accept(ClassReader.java:622) > at org.objectweb.asm.ClassReader.accept(ClassReader.java:506) > at > org.apache.aries.proxy.impl.gen.ProxySubclassGenerator.processClass(ProxySubclassGenerator.java:255) > at > org.apache.aries.proxy.impl.gen.ProxySubclassGenerator.generateAndLoadSubclass(ProxySubclassGenerator.java:234) > at > org.apache.aries.proxy.impl.gen.ProxySubclassGenerator.getProxySubclass(ProxySubclassGenerator.java:130) > at > org.apache.aries.proxy.impl.gen.ProxySubclassGenerator.getProxySubclass(ProxySubclassGenerator.java:75) > at > org.apache.aries.blueprint.proxy.ProxySubclassGeneratorTest.testPackageAccessCtor(ProxySubclassGeneratorTest.java:190) -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (ARIES-1452) Subsystem throws exception when bundle imports osgi framework
[ https://issues.apache.org/jira/browse/ARIES-1452?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15130713#comment-15130713 ] John Ross commented on ARIES-1452: -- Is this still an ongoing issue? The output seems strange because the two referenced providers of org.osgi.framework appear to be the same object (i.e. "[org.apache.felix.framework [0](R 0)]"), so how could there be a problem? Something interesting is the first import wants version [1.5, 2.0) while the second wants [1.3, 2.0), but if the provider is really the same, the exported versions should be the same. Different versions (say one exporting at 1.3 and the other at 1.5) would appear to imply that there must be two system bundles involved, which seems unlikely. Maybe subsystems is returning different objects to two separate findProviders requests? One wrapped and one not? > Subsystem throws exception when bundle imports osgi framework > - > > Key: ARIES-1452 > URL: https://issues.apache.org/jira/browse/ARIES-1452 > Project: Aries > Issue Type: Bug > Components: Subsystem >Affects Versions: subsystem-2.0.6, subsystem-2.0.8 > Environment: Mac OS X > Apache Felix (inside Apache Sling 9-SNAPSHOT) >Reporter: Roy Teeuwen > Attachments: testcase.zip > > > When building an OSGi subsystem feature, I created two bundles, an api and a > core. The core has following embedded dependency: > >com.squeakysand.osgi >squeakysand-osgi >0.4.0 > > Using previous dependency in the core, it creates the Import-Package > org.osgi.framework;version="[1.5,2)” when using maven-bundle-plugin version > 3.0.1. > Starting up this subsystem through the webconsole subsystem plugin of Apache > Felix, following error is thrown: > 13.11.2015 22:01:23.849 *ERROR* [Thread-95] > org.apache.sling.extensions.threaddump.internal.Activator Uncaught exception > in Thread Thread[Thread-95,5,main] > org.osgi.service.subsystem.SubsystemException: > org.osgi.service.resolver.ResolutionException: Uses constraint violation. > Unable to resolve resource idoneus.mdm-parser-core > [/var/folders/h1/k9tr352j615f8jrrzh5yr5b8gn/T/inputStreamExtract734624941409606295.zip/mdm-parser-core-1.0.0-SNAPSHOT.jar] > because it is exposed to package 'org.osgi.framework' from resources > org.apache.felix.framework [org.apache.felix.framework [0](R 0)] and > org.apache.felix.framework [org.apache.felix.framework [0](R 0)] via two > dependency chains. > Chain 1: > idoneus.mdm-parser-core > [/var/folders/h1/k9tr352j615f8jrrzh5yr5b8gn/T/inputStreamExtract734624941409606295.zip/mdm-parser-core-1.0.0-SNAPSHOT.jar] > import: > (&(osgi.wiring.package=org.osgi.framework)(&(version>=1.5.0)(!(version>=2.0.0 > | > export: osgi.wiring.package: org.osgi.framework > org.apache.felix.framework [org.apache.felix.framework [0](R 0)] > Chain 2: > idoneus.mdm-parser-core > [/var/folders/h1/k9tr352j615f8jrrzh5yr5b8gn/T/inputStreamExtract734624941409606295.zip/mdm-parser-core-1.0.0-SNAPSHOT.jar] > import: > (&(osgi.wiring.package=org.apache.sling.event.jobs.consumer)(&(version>=1.2.0)(!(version>=2.0.0 > | > export: osgi.wiring.package=org.apache.sling.event.jobs.consumer; > uses:=org.osgi.service.event > org.apache.sling.event [org.apache.sling.event [103](R 103.0)] > import: > (&(osgi.wiring.package=org.osgi.service.event)(version>=1.2.0)(!(version>=2.0.0))) > | > export: osgi.wiring.package=org.osgi.service.event; > uses:=org.osgi.framework > org.apache.felix.eventadmin [org.apache.felix.eventadmin [9](R 9.0)] > import: > (&(osgi.wiring.package=org.osgi.framework)(version>=1.3.0)(!(version>=2.0.0))) > | > export: osgi.wiring.package: org.osgi.framework > org.apache.felix.framework [org.apache.felix.framework [0](R 0)] > at > org.apache.aries.subsystem.core.internal.SubsystemResource.computeDependencies(SubsystemResource.java:395) > This does not happen when I install the api and core as seperate bundles in > the OSGi container -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (ARIES-1452) Subsystem throws exception when bundle imports osgi framework
[ https://issues.apache.org/jira/browse/ARIES-1452?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15130944#comment-15130944 ] John Ross commented on ARIES-1452: -- I'm able to successfully install and start the attached EBA in my environment, which is basically an extension of the existing itest framework. You should be able to take the attached Aries1452Test.java file, drop it in org.apache.aries.subsystem.itests/org.apache.aries.subsystem.itests.defect, modify the DIR variable as needed, and run it as a JUnit tests from within Eclipse. If we can get that to fail, that would help. I noticed that one of your poms has the following entry: org.apache.felix org.osgi.core 1.4.0 provided Is that the system bundle implementation from Felix or is that the core api library (i.e. the equivalent of osgi.core)? If the latter then you may very well have two different bundles in your environment exporting org.osgi.framework at different versions. > Subsystem throws exception when bundle imports osgi framework > - > > Key: ARIES-1452 > URL: https://issues.apache.org/jira/browse/ARIES-1452 > Project: Aries > Issue Type: Bug > Components: Subsystem >Affects Versions: subsystem-2.0.6, subsystem-2.0.8 > Environment: Mac OS X > Apache Felix (inside Apache Sling 9-SNAPSHOT) >Reporter: Roy Teeuwen > Attachments: testcase.zip > > > When building an OSGi subsystem feature, I created two bundles, an api and a > core. The core has following embedded dependency: > >com.squeakysand.osgi >squeakysand-osgi >0.4.0 > > Using previous dependency in the core, it creates the Import-Package > org.osgi.framework;version="[1.5,2)” when using maven-bundle-plugin version > 3.0.1. > Starting up this subsystem through the webconsole subsystem plugin of Apache > Felix, following error is thrown: > 13.11.2015 22:01:23.849 *ERROR* [Thread-95] > org.apache.sling.extensions.threaddump.internal.Activator Uncaught exception > in Thread Thread[Thread-95,5,main] > org.osgi.service.subsystem.SubsystemException: > org.osgi.service.resolver.ResolutionException: Uses constraint violation. > Unable to resolve resource idoneus.mdm-parser-core > [/var/folders/h1/k9tr352j615f8jrrzh5yr5b8gn/T/inputStreamExtract734624941409606295.zip/mdm-parser-core-1.0.0-SNAPSHOT.jar] > because it is exposed to package 'org.osgi.framework' from resources > org.apache.felix.framework [org.apache.felix.framework [0](R 0)] and > org.apache.felix.framework [org.apache.felix.framework [0](R 0)] via two > dependency chains. > Chain 1: > idoneus.mdm-parser-core > [/var/folders/h1/k9tr352j615f8jrrzh5yr5b8gn/T/inputStreamExtract734624941409606295.zip/mdm-parser-core-1.0.0-SNAPSHOT.jar] > import: > (&(osgi.wiring.package=org.osgi.framework)(&(version>=1.5.0)(!(version>=2.0.0 > | > export: osgi.wiring.package: org.osgi.framework > org.apache.felix.framework [org.apache.felix.framework [0](R 0)] > Chain 2: > idoneus.mdm-parser-core > [/var/folders/h1/k9tr352j615f8jrrzh5yr5b8gn/T/inputStreamExtract734624941409606295.zip/mdm-parser-core-1.0.0-SNAPSHOT.jar] > import: > (&(osgi.wiring.package=org.apache.sling.event.jobs.consumer)(&(version>=1.2.0)(!(version>=2.0.0 > | > export: osgi.wiring.package=org.apache.sling.event.jobs.consumer; > uses:=org.osgi.service.event > org.apache.sling.event [org.apache.sling.event [103](R 103.0)] > import: > (&(osgi.wiring.package=org.osgi.service.event)(version>=1.2.0)(!(version>=2.0.0))) > | > export: osgi.wiring.package=org.osgi.service.event; > uses:=org.osgi.framework > org.apache.felix.eventadmin [org.apache.felix.eventadmin [9](R 9.0)] > import: > (&(osgi.wiring.package=org.osgi.framework)(version>=1.3.0)(!(version>=2.0.0))) > | > export: osgi.wiring.package: org.osgi.framework > org.apache.felix.framework [org.apache.felix.framework [0](R 0)] > at > org.apache.aries.subsystem.core.internal.SubsystemResource.computeDependencies(SubsystemResource.java:395) > This does not happen when I install the api and core as seperate bundles in > the OSGi container -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (ARIES-1452) Subsystem throws exception when bundle imports osgi framework
[ https://issues.apache.org/jira/browse/ARIES-1452?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] John Ross updated ARIES-1452: - Attachment: Aries1452Test.java > Subsystem throws exception when bundle imports osgi framework > - > > Key: ARIES-1452 > URL: https://issues.apache.org/jira/browse/ARIES-1452 > Project: Aries > Issue Type: Bug > Components: Subsystem >Affects Versions: subsystem-2.0.6, subsystem-2.0.8 > Environment: Mac OS X > Apache Felix (inside Apache Sling 9-SNAPSHOT) >Reporter: Roy Teeuwen > Attachments: Aries1452Test.java, testcase.zip > > > When building an OSGi subsystem feature, I created two bundles, an api and a > core. The core has following embedded dependency: > >com.squeakysand.osgi >squeakysand-osgi >0.4.0 > > Using previous dependency in the core, it creates the Import-Package > org.osgi.framework;version="[1.5,2)” when using maven-bundle-plugin version > 3.0.1. > Starting up this subsystem through the webconsole subsystem plugin of Apache > Felix, following error is thrown: > 13.11.2015 22:01:23.849 *ERROR* [Thread-95] > org.apache.sling.extensions.threaddump.internal.Activator Uncaught exception > in Thread Thread[Thread-95,5,main] > org.osgi.service.subsystem.SubsystemException: > org.osgi.service.resolver.ResolutionException: Uses constraint violation. > Unable to resolve resource idoneus.mdm-parser-core > [/var/folders/h1/k9tr352j615f8jrrzh5yr5b8gn/T/inputStreamExtract734624941409606295.zip/mdm-parser-core-1.0.0-SNAPSHOT.jar] > because it is exposed to package 'org.osgi.framework' from resources > org.apache.felix.framework [org.apache.felix.framework [0](R 0)] and > org.apache.felix.framework [org.apache.felix.framework [0](R 0)] via two > dependency chains. > Chain 1: > idoneus.mdm-parser-core > [/var/folders/h1/k9tr352j615f8jrrzh5yr5b8gn/T/inputStreamExtract734624941409606295.zip/mdm-parser-core-1.0.0-SNAPSHOT.jar] > import: > (&(osgi.wiring.package=org.osgi.framework)(&(version>=1.5.0)(!(version>=2.0.0 > | > export: osgi.wiring.package: org.osgi.framework > org.apache.felix.framework [org.apache.felix.framework [0](R 0)] > Chain 2: > idoneus.mdm-parser-core > [/var/folders/h1/k9tr352j615f8jrrzh5yr5b8gn/T/inputStreamExtract734624941409606295.zip/mdm-parser-core-1.0.0-SNAPSHOT.jar] > import: > (&(osgi.wiring.package=org.apache.sling.event.jobs.consumer)(&(version>=1.2.0)(!(version>=2.0.0 > | > export: osgi.wiring.package=org.apache.sling.event.jobs.consumer; > uses:=org.osgi.service.event > org.apache.sling.event [org.apache.sling.event [103](R 103.0)] > import: > (&(osgi.wiring.package=org.osgi.service.event)(version>=1.2.0)(!(version>=2.0.0))) > | > export: osgi.wiring.package=org.osgi.service.event; > uses:=org.osgi.framework > org.apache.felix.eventadmin [org.apache.felix.eventadmin [9](R 9.0)] > import: > (&(osgi.wiring.package=org.osgi.framework)(version>=1.3.0)(!(version>=2.0.0))) > | > export: osgi.wiring.package: org.osgi.framework > org.apache.felix.framework [org.apache.felix.framework [0](R 0)] > at > org.apache.aries.subsystem.core.internal.SubsystemResource.computeDependencies(SubsystemResource.java:395) > This does not happen when I install the api and core as seperate bundles in > the OSGi container -- This message was sent by Atlassian JIRA (v6.3.4#6332)
