I have plugin of type 1. It exposes some component:
<atlassian-plugin key="com.atlassian.jira.plugin.common-plugin" name="Common"> <plugin-info> <description>Common Jira Extension Plugin</description> <version>1.0</version> </plugin-info> <component key="MyExtendedPropertyStorage" name="Advanced Property Storage" class="com.devexperts.jira.propertystorage.DelegatePropertyStorage" public="true"> <interface>com.devexperts.jira.propertystorage.PropertyStorage</interface> </component> </atlassian-plugin>
Then I want to make this component visible to some other plugin of type 2. I've tried to include "Import-Package" to <bundle-instructions> tag, but it didn't help:
<atlassian-plugin key="com.devexperts.jira.plugin.dxdelivery" name="Some plugin of type 2" plugins-version="2"> <plugin-info> <description>Some plugin of type 2</description> <version>0.1</version> <bundle-instructions> <Import-Package>com.devexperts.jira.propertystorage</Import-Package> </bundle-instructions> .... </plugin-info>
When I try to upload this plugin via Plugin Administration web interface, JIRA fails to enable it and I get the following error in logs:
Caused by: org.osgi.framework.BundleException: Unresolved constraint in bundle com.devexperts.jira.plugin.dxdelivery : Unable to resolve 86.0: missing requirement [86.0] package; (package=com.devexperts.jira.propertystorage) at org.apache.felix.framework.Felix.resolveBundle(Felix.java:3409) at org.apache.felix.framework.Felix.startBundle(Felix.java:1709) at org.apache.felix.framework.BundleImpl.start(BundleImpl.java:905) at org.apache.felix.framework.BundleImpl.start(BundleImpl.java:892) at com.atlassian.plugin.osgi.factory.OsgiPlugin.enableInternal(OsgiPlugin.java:402) ... 87 more
Please, help to cope with this problem.
Thanks in advance! Vitaly.
I hit this a while ago, but quickly got bogged down in trying to work around it. To do so, I think you might actually need to amend some of the core code in Jira and it was starting to look like you'd need two class loaders and a way to make them talk somehow.
I decided it was going to be far more easy to convert the v1 plugin to v2 than persue that any further.
(I was working in 4.2 if that matters)
Yeah, I think that would help - I can pick up corresponding classloader and ask it for certain class.
But it seems to be a kind of hack - instead of using Attlassian's plugins system correctly, we use reflection&Ko to hack it :)
Isn't there some kind of the config/bundling-level solution? I mean, some "official" mechanism to say that "Hey, my plugin v2 would need that specific component from main classloader. Dear OSGI, pick-up it for me, please".
I am almost sure that such solution should exist because java.* and core atlassian classes (and lot more) are available in any v2 plugin. Therefore, OSGI was told about them somehow :)
1. I do not force anybody to use it ;)
2. "I am almost sure that such solution should exist because java.* and core atlassian classes (and lot more) are available in any v2 plugin. Therefore, OSGI was told about them somehow" - that's normal, because it is how Jira bundles Felix. Check it out in their sources ...
Although not impossible, this would be A LOT of work.
Basically your V1 component is added to an internal spring container and gets all of it's dependencies injected, but sinces it's not an OSGi bundle, it is not aware of the OSGi container and visaversa.
In a V2 plugin, the component is also added to a spring container AND since it's an OSGi bundle, spring has the ability to expose the components to other OSGi bundles.
So essentially, the only way you could make OSGi aware of your V1 plugin component would be to write a V2 plugin with the V1 plugin as a dependency (at build time), then write an OSGi Bundle Activator to load your V1 class and expose it as a service. However, if your V1 component has dependencies injected, you're gonna face a how lot of headaches to get all of the dependencies exposed as well.
At that point, it would be easier to just maintain a V1 and V2 version of your plugin rather than writing a complicated wrapper that's really fragile.
As for core JIRA, we have a special HostComponentProvider that takes care of mapping core components to OSGi services, but it's a part of JIRA and so we have access to a lot of low-level spring/OSGi framework code to make it happen.
Hello Atlassian Community! Each month, we run a series of Spotlights to highlight Marketplace vendors and apps that our team thinks this Community would find valuable. In last month's Spotlig...
Connect with like-minded Atlassian users at free events near you!Find a group
Connect with like-minded Atlassian users at free events near you!
Unfortunately there are no AUG chapters near you at the moment.Start an AUG