How can I make component, exposed by plugin of type 1, visible to plugin of version 2

[Vitaly Trifanov]

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 [86]: 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.

[brainicorn]

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.

[Ellen Feaheny [AppFusions]]

Vitaly

If you'd like some development help to just handle this and any others in your system in question without the headache, we can help you get this done fast.

Ellen

info@appfusions.com

[Radu Dumitriu]

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 ...

[Vitaly Trifanov]

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 :)

[Nic Brough -Adaptavist-]

If you definitely can't update the plugins to v2, then I have to say I'd follow up Radu's link - the information there was the route I was going when I realised it was far easier to just convert to v2.

[Vitaly Trifanov]

This plugin v1 is very old and a lot of other v1-plugins depend on it, so it would be very hard and ineffective to convert it to v2.

I definitely need the way to just add dependency from v2 to v1 :(

[Radu Dumitriu]

I think I responded that some time ago.

https://answers.atlassian.com/questions/11656/exchange-data-between-v1-and-v2-plugin

[Nic Brough -Adaptavist-]

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)