Preparing for Confluence 9.0 - EAP out now

[WendyR]

Hi Andreas. Yes, sometimes the page caching is a bit slow to display changes. Try doing a hard refresh when that happens, or opening in an incognito window if the hard refresh fails.

[Kusal]

@AndreasEbert

@Kusal, thanks. I guess the next EAP (21) will contain this; the current EAP (20) does not.

That’s correct, the changes are included from 9.0.0-m110.

[RomanStoffel]

Thanks for all the help. The app is up on Confluence 9 \o/.

One last issue I’m not sure where it comes from is that the Macro-Preview window shows a ‘Wrong URL configured’ pop-up:

Update: Happend on m95. On the latestest m109 the issue is fixed.
So, if anyone else sees this, check it on m109. @Kusal

[Kusal]

Is this EAP20? It should be fixed in EAP20

[m.frank]

Hey there,

I’m not able to install my plugin with the following error:

Caused by: org.osgi.framework.BundleException: Unable to resolve com.decadis.confluence.spaceadmin [308](R 308.0): missing requirement [com.decadis.confluence.spaceadmin [308](R 308.0)] osgi.wiring.package; (&(osgi.wiring.package=com.google.common.base)(version>=32.1.3.jre)(version<=32.1.3.jre)) Unresolved requirements: [[com.decadis.confluence.spaceadmin [308](R 308.0)] osgi.wiring.package; (&(osgi.wiring.package=com.google.common.base)(version>=32.1.3.jre)(version<=32.1.3.jre))]
	at org.apache.felix.framework.Felix.resolveBundleRevision(Felix.java:4398)
	at org.apache.felix.framework.Felix.startBundle(Felix.java:2308)
	at org.apache.felix.framework.BundleImpl.start(BundleImpl.java:1006)
	at org.apache.felix.framework.BundleImpl.start(BundleImpl.java:992)
	at com.atlassian.plugin.osgi.factory.OsgiPlugin.enableInternal(OsgiPlugin.java:408)
	... 103 more

I found the same problem already in this post here. However, I do not see any solution there. Do you know if there is any way to fix it?

I checked my plugin and dependencies and I think it comes from the activeobjects-plugin. At least I did not find any other reference (checked all possibilities described in this post already).

So if I got it right, Atlassian removed the guava dependency, but as it looks like in the activeobjects-plugin they are using it. Is this intended to be, or will Atlassian remove it in another EAP-release? I followed the guideline of upgrading the dependency to 6.0.0-m03, to be platform 7 compatible.

Any ideas, what I could do? Or do I have to wait for a fix from Atlassian?

Cheers,
Marcel

SOLUTION:

Preparing for Confluence 9.0 - EAP out now

@RomanStoffel In your pom.xml, under build → plugins → plugin(maven-confluence-plugin) → configuration → instructions, do you have this? <Atlassian-Plugin-Key>${atlassian.plugin.key}</Atlassian-Plugin-Key>

[scott.dudley]

Hi @MarekTokarski @TomRijnbeek @mkemp

I’m tagging a couple of people here (mostly drawn from a list of recent PR approvers for the atlassian-plugins repo, who are also active on CDAC), with the hope of drawing some attention to this issue below. In short, would Atlassian be able to either fix transformer-based plugins on platform 7 so that they actually work, or else remove support for such plugins so that people don’t keep trying to use it and inevitably fail?

@scott.dudley

@kmacleod Multiple plugin vendors have fallen into the trap of trying to use <component-import> with Platform 7 and it seems like this is causing a lot of hang-wringing and wasted time (I believe there are half a dozen examples on just this thread).

Could Atlassian consider either removing support for <component-import> entirely (at least for non-Atlassian plugins), thereby forcing people to upgrade by showing a sensible error message? Alternatively, can you fix <component-import> so that it actually works on platform 7?

The root cause seems to be that the transformation process adds OSGi imports for all classes referenced by all methods of the imported class, plus all classes referenced by all methods of any superclasses. This prevents people from importing many non-trivial beans. If Atlassian is going to maintain <component-import>, I imagine that this auto-import-generation procedure needs to automatically skip any packages listed in the banned dependency list.

[rlander]

+1 for this, they don’t seem to work well with the new platform 7 paradigm, now would be a good time to either deprecate, fix, or remove this option.

It’s causing a bunch of headaches in this thread, and the same will likely be true on Bitbucket/Jira as vendors start testing.

[aorlov]

Hi !

Page with EAP releases doesn’t work. I can see only spinner. I tried in the incognito mode - the same result.

[aorlov]

@AndreasEbert Did you solve the problem with GeneralUtil? Milestone 105 .

I use it like that

<web-item key="item" name="my-name" section="system.space.tools/addons" weight="100">
        <link>/my-link?key=$generalUtil.urlEncode($helper.spaceKey)</link>
     ........ // code
    </web-item>

And it doesn’t transform in browser url.

I tried to add org.apache.velocity:velocity:1.6.4 manually, but it doesn’t help.

[ashraf.teleb85]

Hi,

I wanted to confirm if there are any REST APIs deprecations with Confluence 9
I see in Preparing for Confluence 9.0 | Confluence Data Center 8.9 | Atlassian Documentation
“We’ve now migrated all existing and new API content to Swagger, with some presentation fixes in progress. For example, the migration has caused APIs that use @AnonymousAllowed to be incorrectly marked as deprecated. We’re working on these migration issues, but we’re also keen to give you early access.”

And wanted to confirm the deprecations in https://developer.atlassian.com/server/confluence/rest/v900/intro are not correct

[mkemp]

@scott.dudley

In short, would Atlassian be able to either fix transformer-based plugins on platform 7 so that they actually work, or else remove support for such plugins so that people don’t keep trying to use it and inevitably fail?

Thanks for raising it again, I’ll raise again internally.

Could you give an example OSGi service? Reproduction repository is amazing if you just happen to have one.

Do I understand the suspected issue right? The package import restrictions are causing the beans to not resolve, but the plugin transformation system is introducing them?

[AndreasEbert]

@mkemp

The package import restrictions are causing the beans to not resolve, but the plugin transformation system is introducing them?

Yes, correct. See my comment (#43) where I described the problem with an example.

[AndreasEbert]

@aorlov, in my case the cause was a bug in an earlier EAP which was fixed by Atlassian.

In your case it’s because GeneralUtil has no urlEncode(...) anymore. Use com.atlassian.confluence.util.HtmlUtil instead, as in: $htmlUtil.urlEncode(...). Fyi, a bunch of methods in GeneralUtil were removed with Confluence 9. Don’t know if there is an official communication by Atlassian about this. @Kusal, you know more about that?

[AndreasEbert]

Fyi @Kusal.
I also have this problem since a couple of months. Using Chrome instead of Firefox used to help, but not anymore

[FbioCunha]

Hi @m.frank, are you sure you’re not using the deprecated <component> (Component) and <component-import> (Component import)? Switching to Spring Java Configuration (https://developer.atlassian.com/server/framework/atlassian-sdk/spring-java-config/) solved all of our issues. We also tested with Spring Scanner and it works fine too.

[aorlov]

Thanks! It works as expected.

[aorlov]

Maybe some new items for allow list:

Invocation blocked as method is not allowlisted: java.util.Collections$EmptyList#size()

[m.frank]

Hey @FbioCunha,

thanks for the idea. Normally, I expect that it should work with the Spring Scanner annotations…

But I will give it a try and change to Spring Java Configurations.

Will keep you updated about the result.

Cheers,
Marcel

[scott.dudley]

Hi @mkemp

Could you give an example OSGi service? Reproduction repository is amazing if you just happen to have one.

Thanks for following up. Here is a repo that reproduces the problem.

Note that you don’t even need to do a <component-import>. The simple fact that the plugin is not marked as transformerless, plus the reference in bytecode to an allowed class (in this case, UserAccessor) that happens to depend on a banned class, is sufficient to break everything.

https://bitbucket.org/scottdudley/platform7-transformed-plugin-test/src/master/

[MichaelAndreacchio]

Hi @ashraf.teleb85 yes we can confirm that the APIs using deprecated annotations such as @AnonymousAllowed were not being correctly reflected as deprecated in the REST Docs. We apologise for the confusion this has caused and have managed to get this cleaned up resulting in the removal of the false positives. This is now live, please take a look at the updates here: https://developer.atlassian.com/server/confluence/rest/v900/intro/