Changed behavior or how to implement a specific use case/question about semantics

[tg-freigmbh]

Hello

We have very mixed environment where half of the jars are either jpms modules already or are getting transformed into one, and the other half uses the classpath is not compatible with jpms.

I used to deal with that using a configuration like this

val moduleC by configurations.registering {
    shouldResolveConsistentlyWith(configurations.runtimeClasspath.get())
    isCanBeConsumed = false
    attributes{
        attribute(OperatingSystemFamily.OPERATING_SYSTEM_ATTRIBUTE, objects.named(OperatingSystemFamily.WINDOWS))

        attribute(LibraryElements.LIBRARY_ELEMENTS_ATTRIBUTE, project.objects.named(LibraryElements::class, "jar"))
        attribute(Attribute.of("javaModule", Boolean::class.javaObjectType),true )
        attribute(Usage.USAGE_ATTRIBUTE, objects.named(Usage.JAVA_RUNTIME))
    }

}

And that way i could let gradle know that everything related configuration needed to be jpms compatible, aka know as if it already had a module-info take the file as it is, otherwise perform necessary transformation.
However the behavior of this plugin changed from 1.10.1 to 1.11 has changed.
05ea60c#diff-76ff4b4e6220621d24b63f06bfd513455e106bbdfa3cbba95f2a78950e9cb2a5

       // outgoing variants may express that they already provide a modular Jar and can hence skip the transform altogether

Which will lead to
- Incompatible because this component declares a component, as well as attribute 'javaModule' with value 'false' and the consumer needed a component, as well as attribute 'javaModule' with value 'true'

So my feedback would be that its a bit problematic to simply set skipLocalJars to false by default and add publish this information.
Once you read through the source code ok you realize that ist required to set skipLocalJars to true in every project that already have a module-info but its a bit unintuitive..
Like usually you would use this plugin because your sourcecode has a module-info and thats the reason you are dealing with jpms in the first place, so I would guess in most cases skipLocalJars needs to be true and its really an odd corner case when you are applying this plugin to your project, but your project doesnt have a module-info itself...

[tg-freigmbh]

Its also a bit scuffed since the name "locaJars" kind of implies that this would effect all jars, but it will not affect testFixtures for example

[jjohannes]

Thank you for the feedback. I was actually surprised that the skipLocalJars feature did not break anything yet. The attribute matching is so fragile... but I also wanted to make some progress in this area (#165 and the issues it resolves).

I am not sure I quite understand what broke for you. Can you provide a reproducer? I may have a hint below.

Here is a few more information on the feature and its implementation:

skipLocalJars is false by default as I did want to break existing default behavior. As I remember, you also rely on transforming local Jars. Although I agree it is not the primary idea of the plugin. But there may also be other corner cases. The idea is that skipLocalJars=false (the default) is as close as possible to how the plugin behaved before the flag was introduced. The information is not published. (If by published you mean written to the metadata and used for variant matching).

But looking at the code, you can easily think that that is happening. There are two way of setting attributes for variants vs artifacts (it is totally unintuitive 😞):

There is:

configurations.apiElements {
  // this is what gets published and is used for matching the variant
  attributes { }
}

And then there is:

configurations.apiElements {
  // This is (as far as I understand) only for artifacts and transforming them, it is not published.
  // This is used by the new feature.
  outgoing { attributes { } }
}

I am not sure what broke in your setup, but maybe you also need to switch something from one method to the other?

[tg-freigmbh]

I made this reproducer:
https://github.com/tg-freigmbh/extra-module
calling assemble will fail
downgrading gradlex in lib to
id("org.gradlex.extra-java-module-info") version "1.10"
and gradle assemble will run

Ah yes I think that our setup often relies on the transformation of local jars (but not the main src jars), but I could also add an Automatic-Module-Name to the jars in question (which probably would be smarter)

[tg-freigmbh]

hmm thinking about it, I am not sure if what I am doing makes much sense since I am not applying the extra-mdoule-info in the app project...

[jjohannes]

Thank you for the example project. I see how that fails with the change in the plugin, because now the plugin always sets the attribute to a value on the producer side (lib in the example). Before, it did not set a value for local artifacts, causing the artifact selection to ignore it.

What I still don't understand is for which use case this change in behavior is problematic.

In your example, the app project (consumer) does not apply extra-java-module-info and thus does not register a transform. The way I look at that is, that the attribute javaModule has no meaning in that context.

Why do you want the attribute(Attribute.of("javaModule", Boolean::class.javaObjectType), true) there? (It works when you remove it.)

[tg-freigmbh]

yes I would agree with you that what I did here didnt make much sense and it was probably a copy and paste error where I copied the configuration from a different project but did not apply the extra-module-info plugin...
My memory is pretty bad, but it must be that I ran into this issue->
#134 (comment)
and this whole setup consequently didnt make much sense in the end, and it just barely worked somehow.

I guess we could close this issue.