This message was deleted.

Would be great to have this as a settings plugin, so that one does not need to apply it to every subprojects manually. Then again, settings plugins are not integrating with any of the Gradle features (e.g. code generation for extensions, version catalogs). 😞

Good news for you (about the first part). It is available as settings plugin now! 😄 (docs can probably be improved to make it clearer). You can apply it as project or settings plugin. Whatever works better for you. https://github.com/gradlex-org/java-ecosystem-capabilities#apply-the-plugin

That’s how it should be, awesome! 👍

It can be a "problem" though if you have a conflict. The resolution strategies are defined "per configuration". So you have to do that on the project level. And you probably want the same resolution for all projects (in most cases). So these need to be defined in each project (or a convention plugin). On the other hand, strictly speaking, you only need those in the places where you actually have a conflict and want Gradle to resolve it. (Maybe you just want to detect conflicts and solve them by changing dependencies... then you are fine)

Great work on this awesome initiative! Presumably this supersedes

de.jjohannes.missing-metadata-guava

plugin?

Yes. I merged that in there because it was already overlapping.

awesome.

If you used that, and update, let me know if you run into any issues.

will do. About to drop this in, wondering how Nebula resolution-rules will play with it as there are areas of overlap (iirc nebula’s replace/substitute rules also apply capabilities).

Some metadata (like with Guava) is clear cut so that it can be applied to all projects without thinking about it. I also see overlap between this and nebula. 😉

I haven't looked at Nebula recently. I know that the (very) old versions of that predated capabilities but that it evolved.

Yea - as of latest v9 they leverage Gradle APIs for alignment, capabilities, etc. Will advise how this plays out.

Some metadata (like with Guava) is clear cut so that it can be applied to all projects without thinking about it.

Idea of my/our plugin is that all rules are like this. But it's easier said than done. So if use it and have issues with a certain rule, please report that.

Will do. So far I never had any issues with nebula rr and it’s sad that it’s not a settings plugin.

I put some effort (and lost some hair) into refining the Javax/Jakarta stuff that is already in the plugin to not make it opinionated (it was in the initial version). But who knows. This part in particular is a mess out there. 😬

🤯

perhaps have this plugin respond to the old plugin being applied and emit a deprecation warning as appropriate.

It does 😄

lol. great! still waking up…

And there is a ⚠️ in the readme of the old Guava plugin 🙂

[WARN] Remove 'de.jjohannes.missing-metadata-guava' plugin from the build. The functionality of is included in 'org.gradlex.java-ecosystem-capabilities'.

Awesome.

And of course there is one word too much

... of is ..

🤔 thanks for posting it here, so that I saw it. 🙂

so far so good - no observed interactions with Nebula. Looking at the Nebula code it doesn’t appear they use capabilities, rather dependency substitution, alignment rules, etc. Found at least one custom Nebula rule that could be added here, will drop in a GH issue.

"substitute": [
    {
      "module": "org.apache.geronimo.specs:geronimo-javamail_1.4_spec",
      "with": "javax.mail:javax.mail-api:1.4.+",
      "reason": "use formal mail api",
      "author": "<mailto:chris@cloudshiftconsulting.com|chris@cloudshiftconsulting.com>",
      "date": "2022-04-01"
    },
    {
      "module": "javax.mail:mail",
      "with": "javax.mail:javax.mail-api:1.4.+",
      "reason": "use formal mail api",
      "author": "<mailto:chris@cloudshiftconsulting.com|chris@cloudshiftconsulting.com>",
      "date": "2022-04-01"
    }
  ]

Yes that is correct. Substitution in that sense can't be done with capabilities alone.

I updated my blog posts about the Javax→Jakarta mess with links to the plugin. Many many thanks for that hard work! https://blog.ltgt.net/javax-jakarta-mess-and-gradle-solution/ https://blog.ltgt.net/javax-jakarta-mess-even-worse/

Nebula resolution rules use the original resolution strategies, indeed no capabilities there (I wrote the plugin), and shouldn't conflict for the most part. We have dozens of internal rules too, they've made a huge difference to the kinds of dependency management issues we see, so more of this is great! (substitutions for bad versions, security vulnerabilities are by far the most common rule internally) I'm working on complete coverage for javax -> jakarta internally preparing for our Spring Boot 3 upgrade. Our approach is similar, but with additional guard rails to prevent internal libraries and applications from accidentally being upgraded, artifact transforms for legacy artifacts we need to roman ride (we contributed to the Tomcat migration tool to make it usable from transforms), and handling for embedded container artifacts, and the ability to specify an EE specification version. Once I'm done I'll look at whether we put that into an EE specific plugin, or contribute upstream to this plugin - because gathering the artifact coordinates, versions, class differences, etc is no joke.

Thanks for sharing @Danny Thomas. If you could provide what you are doing to the community that would be huge! Our plugin only covers a fraction of this right now. Sorry for the short rand: [I already pulled my hair out (and almost abandoned the whole thing). I almost can't comprehend how many bad decisions where made in this context. I assume the costs of this will go into the billions $ if you think about how much this stuff is used. That this was once called "Java Enterprise" only sounds like some kind of joke now.] Doing a separate plugin dedicated only to this topic could be reasonable. You could include some of the "weirder" things there. In our plugin, I think I would like to keep it to the Capability topic (for all the other non-Jakarta things). And not be too opinionated. A dedicated Jakarta plugin could probably be more opinionated or have more configuration options. (There is some discussion here https://github.com/gradlex-org/java-ecosystem-capabilities/issues/6) If you should do such a plugin, I am also happy to recommend that one and remove everything related to Jakarta from our plugin. 🙂 I don't think we'll do much more right now (unless someone else contributes). I currently also don't have a project for which I need more. And I am convinced that you need to test these things on real projects to get it somehow right - so you are in a much better environment for that (although I don't envy you that you have to deal with all of this right now). In any case, let me know if I can help somehow.

From what I can gather, this whole mess is Oracle lawyers being Oracle lawyers. Was leaning towards a dedicated plugin because it'll need to be more opinionated than you might like, let you know when I have something ready

@Danny Thomas Instead of excluding artifacts (using heuristics based on file name), wouldn't it work to declare the dependencies (through a component metadata handler?) with the jakartaee attribute set to true?

@Thomas Broyer that was my intention, but seems a component metadata rule can't add the attribute only to the artifact, and makes the dependency unresolvable

a component metadata rule can't add the attribute only to the artifact

Yes this is an unfortunate limitation right now.