Confluence 8.8 release EAP available now

[scott.dudley]

Hi @mkemp,

@mkemp

I understand that you’re specifically referring to the signature of types. Yes, plugins will fail to load if their OSGi package-import requires the type instead of optionally importing during the resolution stage.

I’m actually not referring to the OSGi-related issues since I know that those can be easily managed with optional imports. Let me rephrase my earlier question in an even more precise manner, using two specific examples:

Starting in Confluence 8.8, the com.atlassian.webresource.api.data.WebResourceDataProvider class is marked as @Deprecated. Will this class be removed in Confluence 9.0? (If you are “moving” it to a different package, that still counts as removal because the fully-qualified class above is gone.)

And the same question for com.atlassian.plugin.webresource.condition.UrlReadingCondition.

I am referring to the “loading” scenario because the first example is the required interface for <data> elements inside <web-resource>s, and the referenced class is unconditionally loaded during plugin startup before we could have a chance to do anything about it.

@mkemp

Let me repeat what I said before, there are other changes that guarantee a plugin cannot be engineered cross-major-compatible which makes this discussion moot.

That seems like a pretty big deal that has not (until now) been announced anywhere. Is it possible to let us vendors know what those changes are? I poked around in the WRM projects but nothing jumped out at me as being impossible.

If you are indeed correct (I am not willing to give up quite yet though ), you implied that OBRs could help solve the distribution issue. Is there any documentation or even a sample for how to create a multi-version-targeting OBR? The existing documentation on OBRs seems scant and potentially obsolete (it still refers to the “Plugin Exchange” and P1 plugins), and it does not describe this use case.

I want, for example, to be able to create an OBR that will deploy variant1.jar on Confluence [8.0,8.5.4) and variant2.jar to Confluence [8.5.4,]. Is this possible?