Hey, I can’t help with all the Confluence specific questions sorry, I’ll message them internally there’s more questions.
I’m sorry I can’t help more generally (I understand this is just indicative of your larger point), but I can help with this specific issue. Atlassian Profiling marked all of those as @Internal before the Gray API project and we never came up with a better annotation to explain the nuance. Profiling should be used in two different ways;
- Adding additional context to existing metrics the product ships with, everything you need for that is in
<artifactId>atlassian-profiling-api</artifactId>. Here’s the developer documentation with more info. One important call-out is to have this as <scope>provided</scope> as the products are providing the API. Another is that this is still relatively “new” in our products so you may need to make these optional OSGi package and OSGi service imports if you’re also supporting older product versions.
- Emitting your own metrics (developer docs). Profiling started off in life being exposed by the products, even before Gray API we came to the conclusion that instead marketplace apps (including our own) should be able to compile scope and manage the version of this. This allows greater flexibility in being able to control exactly how the metrics look, being able to communicate changes on major versions of marketplace apps, etc. So until the next major version of all products it’s still possible to either OSGi import or compile your own versions in products where that has always been the case. With the Gray API project it was decided to move all in on marketplace apps compiling their own versions, and Confluence’s POMs reflect that.
FWIW Atlassian Profiling remains open source, you can continue to use as much or as little of it as you’d like. The metrics space is moving fast and yet nothing really provides a complete API for everything, so it’s totally possible that you decide using Dropwizard, or Micrometer, or OpenTelemetry directly instead makes more sense for you.
If you have more suggestions on how to improve Atlassian Profiling or metrics in general feel free to create a new thread and tag me. I’ll try route internally to the right team, because I no longer own Atlassian Profiling.
That’s my personal recommendation until there is broader sweeping communication from someone like @MalathiVangalapati.
I see the chance of a compatibility runtime layer being developed as low because more broadly the compilation against Java 17 combined with some changes that cannot be done before the next major (because they would break compat early), particularly stemming from Atlassian Plugins as ruling out this working for most plugins. I’ll raise this request internally. Coming back to specifically web-resource manager, it’s of course a fair bit of work, but open source so in the meantime you could develop your own layer if you really wanted to.
There’s many degrees to which you can apply the techniques of splitting apps into smaller plugins AND using OBRs to bundle multiple plugins as one app on marketplace. It’s really hard to know you’re giving the best advice for each app without knowing things like; is the app architected in such a way that you can limit the API changes to a couple of small delegate plugins or is it best to fork the plugin? Is the app already composed of? Then on the business side; does the App only do new features in the next major? Are there breaking functionality changes in the App that should coincide with the product majors?
Specifically, what I think may work for some apps is having two versions building them as separate plugins, one which is for the old product versions, and the other for the next major and beyond. Then taking those plugins and bundling them into a single OBR. If you’d like me or someone else to build an example or documentation, let me know we can probably extract this into a new dev community thread too.
There’s lots of other techniques (off the top of my head) you can apply too that may help you avoid this that could be lower cost, but introduce their own trade-offs; optional package imports, optional service imports, reflective detection of features, reflective invocation, compile scoping our code (be careful, don’t export these packages), JS feature detection, overloading web-resource dependencies, using template functions provided from the products. There’s definitely some apps out there that are quite UI focused that are more likely to be able to apply these. If you want specific help with these, it might be best to create new threads individually and we can try and help you out.
