Yes, this is exactly what I was afraid of. If this now starts happening with more and more dependencies we are going to get into a very uncomfortable situation. 
Would love to be added to the DEVHELP ticket as this indeed seems to be related.
The findings in the Jira case do make it sound like it’s an issue with the transformer code, particularly in the case where they’re seeing an import for Guava classes that shouldn’t be imported at all.
In terms of workarounds, while not an easy task, the new info also feeds my suspicion that shipping a transformerless plugin by converting over to Spring Scanner or the Java config method will fix it.
For example, if using Spring Scanner, your imports are all generated at build time by you, and not at runtime by the product. In this scenario, I don’t see how installing the app on host product vX.Y.Z could generate an import that shouldn’t exist, because the host isn’t adding imports at all.
1 Like
Right, I can recommend the Java config method. It is compatible with all products which are not EOL. We’ve been using Spring Scanner for most of our apps and run into many different problems with it. For example: We had a class that used @Component. This used to work. At some point we ended up with an Import-Package definition on org.springframework.stereotype.Component resulting into OSGi problems.
Since moving code over to Java config we could remove most of our Import-Package definitions and replace them with *. We’re no longer relying on @Component and can define the beans more sanely. Never had any problems with this way.
Same here with Spring Scanner. Many different issues over the years. We will definitely investigate migrating all our apps from XML wiring to Java config soon.
Threads like this make me happy I’ve only worked with SpringScanner. 
Interesting discussion. Honestly, all our apps have started their lives before Spring Scanner was a recommended approach, and I never felt the urge to migrate. But this annoying bug could be the reason…
So, this problem was solved in Jira 8.6.1: Jira 8.6 is out! - #16 by Ignat
Would be awesome if we could get a statement on when/whether Confluence will apply the same fix @nmansilla 
So, today Confluence 7.2.1 has been released, but from the release notes it doesn’t look like this issue was addressed in the update. Seems like we should just create DEVHELP for this as well I guess.
1 Like
Just chat with the Confluence Server team, and a fix is IN PROGRESS. As soon as there’s a fix / release version date/details, we’ll post here.
1 Like
In my DEVHELP ticket it was said that this was fixed with Confluence 7.2.2. Did not have the time to verify this myself yet.
Also this still means customers will still experience this issue on 7.1.1 and 7.1.2 as no bugfix version for 7.1 has been released.
We’re seeing this issue appear again for customers that are on Confluence 7.3.
This does not seem to be fixed yet. Also commented this on the original DEVHELP-4065 ticket.
1 Like
We now had more customers report this on 7.3.1, 7.3.2, and 7.3.3. Also commented in DEVHELP-4065 again.
Since 4 months have now gone by since we originally reported this and there’s no more responses from Atlassian I have kind of given up my hope that this will still be fixed… 
EDIT: There was an answer in the DEVHELP ticket - it looks like the fix is going to make it into 7.3.4! 
2 Likes