Confluence 8.7 beta is available now

[turehoefner_appfire]

Hello @GorkaGalloBustinza

I also ran into problems building against Confluence 8.7 because of the missing atlassian-mail.

I was able to build against 8.7.1 when I added this dependency:

        <dependency>
            <groupId>com.atlassian.mail</groupId>
            <artifactId>atlassian-mail</artifactId>
            <!-- version provided by confluence-plugins-platform-pom -->
            <scope>provided</scope>
        </dependency>

I added that along with the confluence-plugins-platform-pom dependency mentioned in https://developer.atlassian.com/server/confluence/get-your-apps-ready-for-gray-api-removal/

    <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>
        </dependencies>
    </dependencyManagement>

That solved my build problem … cannot access com.atlassian.mail.queue.MailQueueItem
[ERROR] class file for com.atlassian.mail.queue.MailQueueItem not found

[turehoefner_appfire]

I haven’t seen anyone post about problems with com.fasterxml.jackson.core dependencies for a 8.7+ build so I’ll post this (though I think I have worked through it):

My plugin has dependencies on com.fasterxml.jackson.core:jackson-core, jackson-databind, and jackson-annotations.

Those dependencies are listed in the gray API dependency list: https://developer.atlassian.com/server/confluence/get-your-apps-ready-for-gray-api-removal/

So… they were originally in my pom.xml as default scope but I changed them to add <scope>provided</scope> and got rid of my version so it could use the version from confluence-plugins-platform-pom like the rest of the gray API dependencies.

That worked OK for my build but in runtime I ran into java.lang.ClassNotFoundException: com.fasterxml.jackson.core.ObjectCodec

I changed back to default scope instead of provided scope and I specified my version (2.15.3) and now the runtime is fine.

Not sure if this is the way to go but it works for me. I thought it should be available to the runtime with scope=provided… but that didn’t work for me.

Thanks.

[turehoefner_appfire]

Hello @scott.dudley

I ran into the same problems with runtime usage of DisabledUserManager (which I was using to replace the deprecated UserAccessor#isDeactivated with DisabledUserManager#isDisabled).

[INFO] [talledLocalContainer] org.eclipse.gemini.blueprint.service.ServiceUnavailableException: service matching filter=[(objectClass=com.atlassian.confluence.user.DisabledUserManager)] unavailable

In my case, when the service was not found the server hung. Kind of scary because I could only see my problem during runtime. A DB connection leak was reported in the log by my build’s H2 DB while Spring was trying to do some reflection and my browser page was spinning after I did something to get my runtime to enter a line of code that tried to use the DisabledUserManager service.

Anyways, putting the failure aside, I worked around it by going one step deeper than the underlying CrowdDisabledUserManager class. You might be able to follow the same path you were and go just one more layer deeper, to the CrowdService, to get your code working.

I used my Spring Java Configuration to wire up the CrowdService that is used in the CrowdDisabledUserManager constructor. Then I wired up the DisabledUserManager service in Spring by instantiating a new CrowdDisabledUserManager(crowdService())

Maybe a horrible hack, I don’t know… I’m not someone that anyone would go to for OSGi/maven/Spring advice… but it works for my runtime of Confluence 8.7.1:

  @Bean
  public CrowdService crowdService() { return importOsgiService(CrowdService.class); }

  @Bean
//     NOPE: this does not work:
//  public DisabledUserManager disabledUserManager() { return importOsgiService(DisabledUserManager.class);}
  public DisabledUserManager disabledUserManager() {
    return new CrowdDisabledUserManager(crowdService());
  }

For now, I’m going to comment it all out and stick with UserAccessor#isDeactivated 'til the end… and then I could have this in my back pocket for whichever environment does not have the method UserAccessor#isDeactivated (8.8? 9?)

Or… maybe all of this is a mistake and Atlassian can expose the DisabledUserManager for plugins?

[AndreasEbert]

@turehoefner_appfire

Or… maybe all of this is a mistake and Atlassian can expose the DisabledUserManager for plugins?

If DisabledUserManager is to be the replacement for a deprecated public API, then surely it must be available publicly too. I strongly suspect an oversight on Atlassian’s part, fyi @mkemp

[mkemp]

@AndreasEbert

If DisabledUserManager is to be the replacement for a deprecated public API, then surely it must be available publicly too. I strongly suspect an oversight on Atlassian’s part, fyi @mkemp

We’ll forward this to @kmacleod who is actually a member of the Confluence team

[kmacleod]

Hi folks,

Yes, the deprecation of UserAccessor#isDeactivated was probably a mistake in hindsight. The deprecation was targeted at internal Confluence code, not plugins. DisabledUserManager is very much not intended for plugin use, so that will remain internal.

The good news is that we’ve no intention of deleting those methods on UserAccessor, so this is unrelated to the Gray API deprecation & removal work.

[scott.dudley]

Hi @kmacleod,

Thanks for the updates here. Does this mean that the @Deprecated annotation will be removed from UserAccessor#isDisabled?

We rely on these deprecation warnings as one of the signals telling us that code needs to be upgraded, especially given that the docs for the gray API removal say that various APIs will be marked as deprecated and then removed in short order.

If we want to be able to trust the code as the current source of truth, the current state is confusing and it adds noise to these reports (and it presumably also creates confusion for those who do not stumble upon this thread).

[turehoefner_appfire]

@scott.dudley

We rely on these deprecation warnings as one of the signals telling us that code needs to be upgraded, especially given that the docs for the gray API removal say that various APIs will be marked as deprecated and then removed in short order.

Yes. I am currently going through all of my plugins and doing what it takes to remove/replace deprecated Confluence code.

I’ll take care of this situation with a code comment in my plugin that reminds future devs not to touch UserAccessor#isDeactivated calls but I don’t know if all the other plugin devs around me are going to catch this.

Can Atlassian open a bug to fix the @Deprecation (remove it) or adjust the deprecation message to explain this story about 3rd party plugins continuing to use it and DO NOT " Use DisabledUserManager.isDisabled(User) " ?

https://docs.atlassian.com/ConfluenceServer/javadoc/8.5.0-m04/com/atlassian/confluence/user/UserAccessor.html#isDeactivated(com.atlassian.user.User)

Thanks!