Composite builds with flatDir repos and module classifiers

Help/Discuss
1

Hi @st_oehme,
A couple of weeks ago I asked a question in the IntelliJ webinar about flatDir repositories and composite builds.
I tried some stuff around this and actually can get the most basic case to work.

The provlem I have is that we are using flatDir repos with classifiers that would map to project configurations and I can’t find a way to get this to work with the current dependecySubstitutions.

I created an example repo which show the problem. This is a bit simplified from our current plugin based configurations but it show this exact problem.
See the Readme.

Is there any way to get this to work with compositeBuilds (or normal dependency substitution)?
If not, do you have a recommendation how to change the layout to make it work?

Currently we cannot move to maven repositories although I’m pushing for that,

2

I really don’t see the point in using a flatDir repository… EVER! FlatDir repositories don’t support meta-data (eg transitive dependencies) and dependencies coming from a flatDir repository don’t properly participate in dependency resolution

Instead, you can store artifacts in a local directory using the maven directory layout and configure gradle as

repositories {
   maven {
      url uri('path/to/repo') 
   } 
}

You now have the choice to add meta data (eg transitive dependencies, group, version, classifier etc) via a pom and you can also add javadocs and sources which will be picked up by your IDE. If you don’t add a pom that’s fine too. But at least you have the option

3

Hey @staffanf,

mapping to a specific Configuration is not yet supported by dependency substitution (and thus composite builds), but is definitely on our radar as an important use case. This is already tracked as a limitation in the user guide, but please feel free to open a GitHub issue that you can track as we improve things.

Cheers,
Stefan

4

@Lance We also have old jar jars with no versions in their name which do not map to maven layouts and also we would have to make up maven groups/layouts for old projects.
When we do that for all jars, we might all well go all in with a proper repository.
Anyhow, doesn’t solve the problem with mapping classifiers to a specific configuration.

5

Hi @st_oehme,
Ok, I actually found an issue about targeting project configurations that I already had subscribed. When that is implemented in dependency management, would it automatically work for composite builds?

Also, the part of mapping to a project configuration is only half the issue I think. The dependencySubstitution block’s substitute module("group:artifact:version") does not support classifiers from what I can see (javadoc). Is this something that’s intended to be addressed? Can’t find a specific issue for this.

6

It might be addressed in a different way than adding ‘classifier’ to it, but the use case needs to be solved, yes. Please feel free to open an issue so this doesn’t get forgotten.

It should, but we should just explicitly add test coverage for the composite case regardless. Could be part of solving that ticket.