Preparing for Confluence 9.0 - EAP out now

Confluence Development Confluence Data Center Announcements
, , , ,
10

Hi @Kusal,

Would you be able to upgrade confluence-compat-lib so that it does not prevent apps from loading on Confluence 9.0? If any app incorporates the latest 1.6.1 of the compat lib, it induces a transitive dependency on the com.atlassian.fugue package, which is no longer OSGi-exported in 9.0, so it causes the plugin to fail to load.

I suspect that Atlassian is not getting a ton of feedback on the 9.0 EAP yet because many vendors probably cannot even load their plugins to test them. The fact that the OSGi load fails on the first missing package (and that it notes only the first problem and none of the subsequent problems) is an aggravating factor, because an app can be missing dozens of packages with the latest changes, and you have to fix them one by one. (I know it’s an OSGi thing and not something you can probably fix yourselves. And I guess trying to load against Conf 8.8 helps because it just spits out warnings rather than failing, but I don’t know if there are guarantees that the lists of missing packages are the same.)

As a workaround, I found that one can ask BND to explicitly remove packages from the auto-generated manifest using the following notation. (This will allow your app to work, at least up until the point where the classloader tries to load the referencing class.)

                        <Import-Package>
                            com.atlassian.plugin.web.conditions,
                            com.atlassian.plugin.web.conditions.*,

                            <!-- ... other packages here ... -->

                            !com.atlassian.fugue.*,
                            *
                        </Import-Package>

It can also be difficult to even locate where the “banned” package references are coming from when they result from transitive dependencies. I hope there is an easier way that someone can share, but I ended up running Maven inside a debugger and setting up a conditional breakpoint inside BND.

To save other people the trouble of figuring this out, here is what I did:

  • temporarily throw the following into any POM to get the classes loaded in your IDE:
        <dependency>
            <groupId>biz.aQute.bnd</groupId>
            <artifactId>biz.aQute.bndlib</artifactId>
            <version>3.5.0</version>
            <scope>test</scope>
        </dependency>
  • Start Maven with: MAVEN_DEBUG_OPTS="-Xdebug -Xrunjdwp:transport=dt_socket,server=y,suspend=y,address=5099 " atlas-mvn package
  • Launch your JVM debugger (attach to port 5099)
  • Set a conditional breakpoint on aQute.bnd.osgi.Analyzer#analyzeJar line 2382. (Use the “download sources” feature in your IDE to make sure you have the source JAR installed.)
						for (PackageRef p : clazz.getReferred()) {
>>>>						referred.put(p);
							refs.add(p);
						}
  • set the breakpoint to fire conditionally when p.toString().contains("fugue") (or whatever banned class name it is you’re looking for)
  • when the breakpoint fires, clazz will contain the name of the referencing class and jar will point to the offending artifact
4 Likes