Preparing for Confluence 9.0 - EAP out now

Confluence Development Confluence Data Center Announcements
, , , ,
61

Apologies, it’s quite likely you adopted very early-on. 2021-06-09 but it’s always been best practice, just like with Spring Scanner. You’ll want this so the plugin system knows your plugin uses Spring for DI. https://developer.atlassian.com/server/framework/atlassian-sdk/configuration-of-instructions-in-atlassian-plugins/

This in combination with <Atlassian-Plugin-Key> informs the plugin system that it shouldn’t try and create the Spring+OSGi wiring for you, you have full control by doing everything explicitly yourself. We call this “transformerless” because the process of the plugin system creating the wiring and spring context for you is a ‘transformation’ of the plugin.

Transformerless requires a little bit more learning (sounds like you’re at the very least most of the way though since you’re using OSGi Spring Java config) for newcomers, but we’ve found causes less headaches. It’s also faster to install your plugins.

3 Likes
62

To our Developer Community Members,

I’m the lead Product Manager on Confluence 9.0 here at Atlassian, and I’m writing to express our apologies for the delayed responses in this thread. We value your eagerness to try out the 9.0 EAPs and understand how important timely communication is in acknowledging and actioning the feedback you’ve spent your time providing to us.

I understand how there’d be frustration caused by the delays in our responses and I know we can do better. We’re now working on measures to improve our response time and engagement. Please bear with us while we make these improvements.

In the meantime, feel free to reach out with any questions, concerns, or feedback you may have. Your voice matters to us, and we are here to support you.

Thank you for your understanding and patience.

63

Hi @jens,
We are not bringing in the Cloud editor to DC at this time. We’re upgrading the TinyMCE editor as part of our regular maintenance efforts. We don’t expect end users to notice any difference beyond possibly bug fixes. So far we’ve seen no breaking changes and expect the upgrade to be of similar effort than the Tiny5 to Tiny6 upgrade we did last year, but will keep you posted on both points.

64

Hi Robert,

Apologies for this. The dependency of the osgi-javaconfig tool on the Gemini packages fell between the cracks on our analysis. I’ve reinstated the gemini packages to the public API, which should be fixed in 8.8.1, as well as the next 8.9.0 and 9.0.0 milestones.

In the meantime, setting the confluence.osgi.treatDeprecatedPackagesAsPublic system property to true will override the default dev mode behaviour, and force open the availability of those hidden packages (note that this property will cease to work in 9.0 onwards).

2 Likes
65

Please check this message - Preparing for Confluence 9.0 - EAP coming soon - #64 by kmacleod

1 Like
66

Hi @kmacleod

I don’t know if I understand correctly, but I would like to verify my knowledge, in Confluence 9.0:

  1. you remove many third party libraries and we have to add them to our applications ourselves (aka grey API)
  2. all packages marked as deprecated (planned to be removed in 9.0) are not available for public use, unless that we will add this parameter confluence.osgi.treatDeprecatedPackagesAsPublic to true (this property will cease to work in 9.0 onwards)
  3. all packages marked as deprecated (not planned to be removed in 9.0) are not available for public use, unless that we will add this parameter confluence.osgi.treatDeprecatedPackagesAsPublic to true (will these be available to us?)

Please check this problem Confluence 8.9 release EAP available now - #5 by adam.labus (@NikhilJain is also in this thread) and can you send more information regarding point 3, because I have problems in version 8.9 (started with 8.8) and I don’t know what strategy we should adopt based on your answer, should I remove them for version 9.0 or will they be available until they are removed?

Cheers
Adam

67

Thanks @NamHo, will this update be available in a milestone soon?

Our apps Scroll Versions and Scroll Translations are integrated with the editor and I’d like to check compatibility there rather sooner than later.

68

Hi Kenny,

Thank you very much for your reply! I think that was the miracle I was hoping for! :slight_smile:

Unfortunately I still do only get it to work if I set DEV mode to false.

This is what I have tried in DEV mode:

<systemPropertyVariables>
  <atlassian.dev.mode>true</atlassian.dev.mode>
  <upm.plugin.upload.enabled>true</upm.plugin.upload.enabled>
  <confluence.osgi.treatDeprecatedPackagesAsPublic>true</confluence.osgi.treatDeprecatedPackagesAsPublic>
</systemPropertyVariables>

When I deploy my app to a server started in the configuration above, Confluence 8.8.0, Java 11, AMPS 8.13.5, I get the following:

[INFO] [talledLocalContainer] Caused by: org.osgi.framework.BundleException: Unable to resolve de.smartics.atlassian.confluence.smartics-atlassian-confluence-macros
[308](R 308.0): missing requirement [de.smartics.atlassian.confluence.smartics-atlassian-confluence-macros
[308](R 308.0)] osgi.wiring.package; (osgi.wiring.package=org.apache.commons.lang3) Unresolved requirements: [[de.smartics.atlassian.confluence.smartics-atlassian-confluence-macros
[308](R 308.0)] osgi.wiring.package; (osgi.wiring.package=org.apache.commons.lang3)]

I assume that, because of Confluence 8.x, I leave the scope of my dependencies as provided. If I change them to compile, then I get the old requirement issue.

[INFO] [talledLocalContainer] Caused by: org.osgi.framework.BundleException: Unable to resolve de.smartics.atlassian.confluence.smartics-atlassian-confluence-macros
[311](R 311.0): missing requirement [de.smartics.atlassian.confluence.smartics-atlassian-confluence-macros
[311](R 311.0)] osgi.wiring.package; (osgi.wiring.package=org.eclipse.gemini.blueprint.context) Unresolved requirements: [[de.smartics.atlassian.confluence.smartics-atlassian-confluence-macros
[311](R 311.0)] osgi.wiring.package; (osgi.wiring.package=org.eclipse.gemini.blueprint.context)]

As I mentioned above: If I start Confluence in this configuration, but not in DEV mode, everything works smoothly.

Maybe I am overlooking something?

@matthiasbertsch Could you get this working for you?

Cheers,
Robert

69

Docker container for atlassian/confluence:9.0.0-m13-jdk17 fails on database init with PostgreSQL:

COPY postgresql-42.7.1.jar /opt/atlassian/confluence/confluence/WEB-INF/lib

atlassian/confluence:9.0.0-m11-jdk17 docker image seems to work fine

The last lines in the logs are:

confluence-server9-1   | Running Changeset: META-INF/db-changelog/68-add-containerId-transferId-column.xml::68-add-containerId-transferId-column.xml::MPT
confluence-server9-1   | Running Changeset: META-INF/db-changelog/69-add-step-progress-properties-table.xml::69-add-step-progress-properties-table.xml::MPT
confluence-server9-1   | Running Changeset: META-INF/db-changelog/70-remove-planId-column-from-mig_stats.xml::70-remove-planId-column-from-mig_stats::MPT
confluence-server9-1   | 27-Feb-2024 12:41:52.472 SEVERE [http-nio-8090-exec-5] org.apache.catalina.core.StandardHostValve.custom Exception Processing ErrorPage[errorCode=500, location=/500page.jsp]
confluence-server9-1   |        java.lang.IllegalStateException: The CacheManager has been shut down. It can no longer be used.
confluence-server9-1   |                at net.sf.ehcache.CacheManager.checkStatus(CacheManager.java:1559)
confluence-server9-1   |                at net.sf.ehcache.CacheManager.getEhcache(CacheManager.java:1108)
confluence-server9-1   |                at com.atlassian.confluence.cache.ehcache.EhCacheManager.wrapCache(EhCacheManager.java:162)
70

Are Personal Access Tokens disabled by default in Confluence 9.0.0-m11 (milestone 11)?
The link to /plugins/personalaccesstokens/usertokens.action is missing from:
/users/viewmysettings.action

71

I haven’t tried it out yet, as we are testing against the 9.0.0 milestones, and @kmacleod mentioned that we have to wait for the next milestone release to be available because the confluence.osgi.treatDeprecatedPackagesAsPublic won’t work there. I’ll let you know once the new milestone is available and we’ve been able to try it out.

1 Like
72

Hi @MichaelAndreacchio

I’m thrilled that you are here and willing to listen to comments.

This is a departure from many of my other forum suggestions, so I admit it is bordering on being a rant, but…could Atlassian please consider not chucking additional breaking changes into Confluence 8.x under the guise of “helping” developers prepare for 9.0, unless actually required for security purposes?

The community already understands that many things are going to break in 9.0. The scope of this breakage, however, will exceed (by far) anything that is being directly signaled in the 8.x series. We don’t need any more signaling in shipping 8.x products. It doesn’t “help”. It just generates more work. Keeping up with even just the forum threads for 8.x feels almost like a full-time job, without actually spending time to implement those changes…let alone work on 9.x.

As it stands, developers are being forced to contend with a myriad of issues in 8.7/8/9 with regards to grey API removals, changes to OSGi exports, and other random product API changes. Reading between the lines of other forum comments, a lot of vendors have barely finished with 8.8, the 8.9 EAP is being tossed out now, and we’re also needing to dedicate resources to 9.0.

I understand that Atlassian might feel obligated to mark a package as “deprecated” in a prior major release before actually removing it. I want to point out that the past practice (ie. loosely for the last decade) has generally been to mark the deprecations at the beginning of a major release line, rather than at the tail end like we are doing now.

Doing it this way defeats the point. Having packages marked as “deprecated” and partially-hidden from OSGi for three months (or however long it’s going to take 9.0 to land) doesn’t truly benefit anyone: it’s not enough time to allow any cross-major compatibility, plus enterprise customers are mostly not using post-8.5 (non-LTS) releases anyway, so these interim releases never even show up on their radar. But it still creates a ton of extra work for Marketplace vendors.

Atlassian can certainly check the box for “yes, it was technically marked as deprecated in the prior major release before we removed it”, but for all intents and purposes, you might as well not have bothered.

Here’s a recent example. Although we caught it in CI before shipping, it’s already broken things in the wild for other people. Could this not have been postponed until 9.0? And can we ask similarly for other API changes that might be planned for 8.9+?

It would also be great if the grey APIs in 8.x (and warnings and OSGi configuration and whatever else) could no longer be a moving target, by simply just shipping whatever you’ve already shipped in 8.8, per my comment above about not needing any more signaling in 8.x.

Scott

PS: On the note of messaging, the Preparing for Confluence 8.9 page says: From Confluence 8.7 to 8.9, these third-party libraries as well as a few Atlassian-specific libraries will no longer be exposed as transitive Maven dependencies of the main confluence artefact.*

This is misleading. Large swaths of Atlassian-specific libraries and principal Atlassian product code have been removed from product exports. The third-party libraries are relatively easy to deal with and they are far less problematic because they can usually be bundled.

11 Likes
73

Thank you for putting it so clearly (and calmly).

I still have 4 more plugins to go for 8.8 compat and THEN I can look at 9. I am not looking at any schedules because I cannot go any faster than I’m going and I’m already late.

74

Hi Guys,

I managed to compile my app on all versions - 8.* and 9.* :slight_smile:

It may be useful to someone, so I’m sharing my pom version below.

Additionally:

  • I’m using only Spring Scanner (I removed all <component-import… and <component… tags)
  • I removed the use of all deprecated packages from Atlassian (only whole packages)
  • I added some libraries to pom that are no longer available

pom.xml

<?xml version="1.0" encoding="UTF-8"?>

<project xmlns="http://maven.apache.org/POM/4.0.0" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xsi:schemaLocation="http://maven.apache.org/POM/4.0.0 http://maven.apache.org/maven-v4_0_0.xsd">
    
	... APP INFO ...
	
    <dependencies>
        <!-- CONFLUENCE 8.8 + 8.9 + 9.0 - START -->
        <dependency>
            <groupId>org.json</groupId>
            <artifactId>json</artifactId>
            <version>20240205</version>
            <scope>compile</scope>
        </dependency>
        <dependency>
            <groupId>com.google.guava</groupId>
            <artifactId>guava</artifactId>
            <version>33.0.0-jre</version>
            <scope>compile</scope>
            <exclusions>
                <exclusion>
                    <artifactId>jsr305</artifactId>
                    <groupId>com.google.code.findbugs</groupId>
                </exclusion>
            </exclusions>
        </dependency>
        <dependency>
            <groupId>org.apache.commons</groupId>
            <artifactId>commons-text</artifactId>
            <version>1.11.0</version>
            <scope>compile</scope>
        </dependency>
        <dependency>
            <groupId>commons-codec</groupId>
            <artifactId>commons-codec</artifactId>
            <version>1.16.1</version>
            <scope>compile</scope>
        </dependency>
        <dependency>
            <groupId>commons-fileupload</groupId>
            <artifactId>commons-fileupload</artifactId>
            <version>1.5</version>
            <scope>compile</scope>
        </dependency>
        <dependency>
            <groupId>commons-io</groupId>
            <artifactId>commons-io</artifactId>
            <version>2.15.1</version>
            <scope>compile</scope>
        </dependency>
        <!-- CONFLUENCE 8.8 + 8.9 + 9.0 - END -->

        <!-- Provided - Other -->
        <dependency>
            <groupId>javax.ws.rs</groupId>
            <artifactId>jsr311-api</artifactId>
            <scope>provided</scope>
        </dependency>
        <dependency>
            <groupId>org.slf4j</groupId>
            <artifactId>slf4j-api</artifactId>
            <scope>provided</scope>
        </dependency>
        <dependency>
            <groupId>javax.servlet</groupId>
            <artifactId>javax.servlet-api</artifactId>
            <scope>provided</scope>
        </dependency>
        <dependency>
            <groupId>javax.inject</groupId>
            <artifactId>javax.inject</artifactId>
            <scope>provided</scope>
        </dependency>

        <!-- Provided - Atlassian -->
        <dependency>
            <groupId>com.atlassian.confluence</groupId>
            <artifactId>confluence-rest-api</artifactId>
            <scope>provided</scope>
        </dependency>
        <dependency>
            <groupId>com.atlassian.confluence.plugins</groupId>
            <artifactId>confluence-space-ia</artifactId>
            <scope>provided</scope>
        </dependency>
        <dependency>
            <groupId>com.atlassian.upm</groupId>
            <artifactId>licensing-api</artifactId>
            <scope>provided</scope>
        </dependency>
        <dependency>
            <groupId>com.atlassian.upm</groupId>
            <artifactId>upm-api</artifactId>
            <scope>provided</scope>
        </dependency>
        <dependency>
            <groupId>com.atlassian.templaterenderer</groupId>
            <artifactId>atlassian-template-renderer-api</artifactId>
            <scope>provided</scope>
        </dependency>
        <dependency>
            <groupId>com.atlassian.confluence</groupId>
            <artifactId>confluence</artifactId>
            <scope>provided</scope>
        </dependency>
        <dependency>
            <groupId>com.atlassian.plugin</groupId>
            <artifactId>atlassian-spring-scanner-annotation</artifactId>
            <version>${atlassian.spring.scanner.version}</version>
            <scope>provided</scope>
        </dependency>
        <dependency>
            <groupId>com.atlassian.mail</groupId>
            <artifactId>atlassian-mail</artifactId>
            <scope>provided</scope>
        </dependency>
    </dependencies>

    <dependencyManagement>
        <dependencies>
            <dependency>
                <groupId>com.atlassian.confluence</groupId>
                <artifactId>confluence-plugins-platform-pom</artifactId>
                <version>${confluence.version}</version>
                <type>pom</type>
                <scope>import</scope>
            </dependency>
            <dependency>
                <groupId>com.atlassian.platform.dependencies</groupId>
                <artifactId>platform-public-api</artifactId>
                <version>${platform.version}</version>
                <type>pom</type>
                <scope>import</scope>
            </dependency>
            <dependency>
                <groupId>com.atlassian.platform.dependencies</groupId>
                <artifactId>platform-deprecated-public-api</artifactId>
                <version>${platform.version}</version>
                <type>pom</type>
                <scope>import</scope>
            </dependency>
        </dependencies>
    </dependencyManagement>

    <build>
        <plugins>
            <plugin>
                <groupId>com.atlassian.maven.plugins</groupId>
                <artifactId>confluence-maven-plugin</artifactId>
                <version>${amps.version}</version>
                <extensions>true</extensions>
                <configuration>
                    <banningExcludes>
                        <exclude>org.apache.commons:commons-lang3</exclude>
                        <exclude>commons-fileupload:commons-fileupload</exclude>
                        <exclude>commons-io:commons-io</exclude>
                        <exclude>com.google.guava:guava</exclude>
                    </banningExcludes>
                    <productVersion>${confluence.version}</productVersion>
                    <productDataVersion>${confluence.data.version}</productDataVersion>
                    <compressResources>false</compressResources>
                    <enableQuickReload>true</enableQuickReload>
                    <skipRestDocGeneration>true</skipRestDocGeneration>
                    <allowGoogleTracking>false</allowGoogleTracking>
                    <skipManifestValidation>true</skipManifestValidation>
                    <instructions>
                        <Atlassian-Plugin-Key>${atlassian.plugin.key}</Atlassian-Plugin-Key>
                        <Spring-Context>*</Spring-Context>
                    </instructions>
                    <extractDependencies>false</extractDependencies>
                </configuration>
            </plugin>
            <plugin>
                <groupId>com.atlassian.plugin</groupId>
                <artifactId>atlassian-spring-scanner-maven-plugin</artifactId>
                <version>${atlassian.spring.scanner.version}</version>
                <executions>
                    <execution>
                        <goals>
                            <goal>atlassian-spring-scanner</goal>
                        </goals>
                        <phase>process-classes</phase>
                    </execution>
                </executions>
            </plugin>
        </plugins>
    </build>

    <properties>
        <confluence.version>9.0.0-m13</confluence.version>
        <platform.version>7.0.0-m20</platform.version>

        <confluence.data.version>${confluence.version}</confluence.data.version>
        <amps.version>8.13.5</amps.version>

        <atlassian.spring.scanner.version>2.2.6</atlassian.spring.scanner.version>
        <atlassian.plugin.key>${project.groupId}.${project.artifactId}</atlassian.plugin.key>
        <project.build.sourceEncoding>UTF-8</project.build.sourceEncoding>
        <project.reporting.outputEncoding>UTF-8</project.reporting.outputEncoding>
        <maven.compiler.source>8</maven.compiler.source>
        <maven.compiler.target>8</maven.compiler.target>
    </properties>
</project>

Cheers
Adam

8 Likes
75

Hello,

In Preparing for Confluence 8.x pages you are advancing the introduction of OpenSearch. Will this feature be included in Confluence 9 ? I understand that yes, but as I do not see in Preparing for Conflence 9…

Thanks,
Gorka.

76

Hi @GorkaGalloBustinza. The feature will not be included in Confluence 9.0, but I’ve added a section to Preparing for 9.0 which explains it’s still due in an upcoming feature release after 9.0 is released.

Note also that rather than replacing Lucene right away, our devs are now working on providing OpenSearch as an opt-in feature. Our OpenSearch upgrade guide should be getting some attention early next week the some new information.

2 Likes
77

Looks like Confluence 9.x will support Java 17 only…

However, I got the following error while trying to compile my working plugin against Java 17 using latest AMPS available…and yes, Atlassian REST dependency scope is provided.

Any help? @WendyR

[2024-03-03T17:12:57.791+0100] [INFO] --- confluence-maven-plugin:8.13.5:generate-rest-docs (default-generate-rest-docs) @ my-plugin ---
[2024-03-03T17:12:58.565+0100] [INFO] No previous run data found, generating javadoc.
[2024-03-03T17:12:58.887+0100] [WARNING] Could not generate REST documentation. Please verify that Atlassian REST is a 'provided' scope dependency of the plugin.
org.apache.maven.plugin.MojoExecutionException: An error has occurred in Javadoc report generation: 
Exit code: 1 - error: Class com.atlassian.jersey.wadl.doclet.ResourceDocletJSON is not a valid doclet.
  Note: As of JDK 13, the com.sun.javadoc API is no longer supported.

Command line was: /opt/openjdk/jdk-17.0.8.1+1/bin/javadoc -J-Xmx1024m @options @argfile

Refer to the generated Javadoc files in '~/my-plugin/target/site/apidocs' dir.

    at org.apache.maven.plugins.javadoc.AbstractJavadocMojo.failOnError (AbstractJavadocMojo.java:7038)
    at org.apache.maven.plugins.javadoc.JavadocReport.doExecute (JavadocReport.java:328)
    at org.apache.maven.plugins.javadoc.AbstractJavadocMojo.execute (AbstractJavadocMojo.java:2010)
    at org.apache.maven.plugin.DefaultBuildPluginManager.executeMojo (DefaultBuildPluginManager.java:137)
    at org.twdata.maven.mojoexecutor.MojoExecutor.executeMojo (MojoExecutor.java:120)
    at com.atlassian.maven.plugins.amps.util.MojoExecutorWrapperImpl.execute (MojoExecutorWrapperImpl.java:28)
    at com.atlassian.maven.plugins.amps.util.MojoExecutorWrapperImpl.executeWithMergedConfig (MojoExecutorWrapperImpl.java:39)
    at com.atlassian.maven.plugins.amps.wadl.RestDocsGenerator.invokeJavadocPluginWithCustomDoclet (RestDocsGenerator.java:105)
    at com.atlassian.maven.plugins.amps.wadl.RestDocsGenerator.lambda$generateRestDocs$0 (RestDocsGenerator.java:97)
    at com.atlassian.maven.plugins.amps.wadl.RestDocsGenerator.withoutGlobalJavadocPlugin (RestDocsGenerator.java:257)
    at com.atlassian.maven.plugins.amps.wadl.RestDocsGenerator.generateRestDocs (RestDocsGenerator.java:97)
    at com.atlassian.maven.plugins.amps.GenerateRestDocsMojo.execute (GenerateRestDocsMojo.java:36)
    at org.apache.maven.plugin.DefaultBuildPluginManager.executeMojo (DefaultBuildPluginManager.java:137)
    at org.apache.maven.lifecycle.internal.MojoExecutor.execute (MojoExecutor.java:208)
    at org.apache.maven.lifecycle.internal.MojoExecutor.execute (MojoExecutor.java:154)
    at org.apache.maven.lifecycle.internal.MojoExecutor.execute (MojoExecutor.java:146)
    at org.apache.maven.lifecycle.internal.LifecycleModuleBuilder.buildProject (LifecycleModuleBuilder.java:117)
    at org.apache.maven.lifecycle.internal.LifecycleModuleBuilder.buildProject (LifecycleModuleBuilder.java:81)
    at org.apache.maven.lifecycle.internal.builder.singlethreaded.SingleThreadedBuilder.build (SingleThreadedBuilder.java:56)
    at org.apache.maven.lifecycle.internal.LifecycleStarter.execute (LifecycleStarter.java:128)
    at org.apache.maven.DefaultMaven.doExecute (DefaultMaven.java:305)
    at org.apache.maven.DefaultMaven.doExecute (DefaultMaven.java:192)
    at org.apache.maven.DefaultMaven.execute (DefaultMaven.java:105)
    at org.apache.maven.cli.MavenCli.execute (MavenCli.java:954)
    at org.apache.maven.cli.MavenCli.doMain (MavenCli.java:288)
    at org.apache.maven.cli.MavenCli.main (MavenCli.java:192)
    at jdk.internal.reflect.NativeMethodAccessorImpl.invoke0 (Native Method)
    at jdk.internal.reflect.NativeMethodAccessorImpl.invoke (NativeMethodAccessorImpl.java:77)
    at jdk.internal.reflect.DelegatingMethodAccessorImpl.invoke (DelegatingMethodAccessorImpl.java:43)
    at java.lang.reflect.Method.invoke (Method.java:568)
    at org.codehaus.plexus.classworlds.launcher.Launcher.launchEnhanced (Launcher.java:289)
    at org.codehaus.plexus.classworlds.launcher.Launcher.launch (Launcher.java:229)
    at org.codehaus.plexus.classworlds.launcher.Launcher.mainWithExitCode (Launcher.java:415)
    at org.codehaus.plexus.classworlds.launcher.Launcher.main (Launcher.java:356)
Caused by: org.apache.maven.reporting.MavenReportException: 
Exit code: 1 - error: Class com.atlassian.jersey.wadl.doclet.ResourceDocletJSON is not a valid doclet.
  Note: As of JDK 13, the com.sun.javadoc API is no longer supported.
78

Hi Scott,

Thanks for your well thought out words and patience with us. We apologise that recent changes have been causing yourself and the developer community additional short-term and reactive work . Our aim was to prepare and aid developers for the changes coming in 9.0, and we understand that the approach has been causing more disruptions than intended.

You raise a valid point about the timing of deprecations. Our current policy is to mark packages as “deprecated” at least 6 months before the end of a major release line. Due to recent security related issues and project dependency/scheduling challenges we have fallen short of this target. Unfortunately marking packages as deprecated right at the beginning of a major release line would be highly challenging given major releases may be over 2 years apart. We need to be able to move quicker than that, but I agree, we shouldn’t be moving as fast as we have been recently. Given recent security related issues we’re doing what we can to tighten up our posture, we acknowledge and are sorry that it also hurts the developer community and will strive to provide a better heads up in future.

Regarding those other points you raised those two seem to be under the same circumstance, I’ll find some help to update you as to what might have happened there. Cheers.

79

Hi Jack,

The current AMPS version is not supported with Java17, hence the DOC generation is broken. You can set <rest.doc.generation.skip>true</rest.doc.generation.skip> in maven properties, or add this to their AMPS plugin configuration: true and switch over to generating docs with some other tooling, like the swagger-maven-plugin

Regards
Nikhil Jain

2 Likes
80

Noted, thx.