Remove spring.provides files

[snicoll]

There isn't a single reference of spring.provides in the reference doc and users are wondering what they should do with it (looking at the official starters).

There was an answer in #1926 but I think it should be clarified and/or adapted.

[wilkinsona]

I've never understood the point of spring.provides, despite the explanation in #1926.

If the META-INF/spring.provides file can be read then, presumably, the starter that contains it is already on the class path. If it's already on the class path then, presumably, its transitive dependencies are too. At that point, metadata that ambiguously identifies a subset of the starter's transitive dependencies doesn't seem very useful.

If they're somehow intended for use when a starter isn't on the classpath, referring to the starter's pom would seem to be a more accurate way of determining the transitive dependencies that it provides. It also avoids the risk of spring.provides being out of sync with the pom.

I cloned spring-projects/spring-ide and searched for uses of spring.provides. It doesn't appear to be used:

$ find . -type f | xargs grep spring.provides | wc -l
       0

If the assumptions I've made about how spring.provides is intended to be used are correct then I think we should be looking to get rid of it rather than documenting it.

[wilkinsona]

I'm still none the wiser after looking at the commit that introduced the initial batch of spring.provides files.

[dsyer]

It was (or is) used by STS, but I don't think any of the other IDEs ever used the data. The jar doesn't have to be on the classpath for STS to read and cache the data, which I think is the point. But it wasn't a very successful feature IMO, and I never use it much.

[philwebb]

I think STS downloads a big XML file from a remote endpoint to allow JAR completion. The XML file seems to be generated using this project. Take a look at SpringProvidesInfo.java

[wilkinsona]

Thanks, @philwebb. I still don't understand the benefit of a spring.provides file that duplicates a subset of the starter's pom. That project seems to use Aether in places. Any idea why it doesn't go a step further and use some of Maven's tooling for pom parsing?

[philwebb]

I've no idea, I guess we need some input from @kdvolder.

Perhaps we thought that using the entire POm would give too many false positives. FWIW I don't really like the IDE feature anyway. I've always found starting with an import and updating the POM file a little backward.

[kdvolder]

@wilkinsona

It does use pom parsing indirectly, since aether parses the poms. The info may look like its duplicating information but it isn't exactly. The provides is used to resolve ambiguity. Basically if a provides file says that a 'starter S provides X'... then 'S' takes priority over other things that also provide it.

It is surprising how many things end up multiple times in the dependency graph reachable from severral different things. The provides files were added to avoid some surprising/unwanted suggestions. Think of the provides file as a very strong hint to the ide that a boot developer thought 'if I want to add X to my pom, you should use starter S'. The dependencies inferred from pom are often just accidental and not as 'deliberate'. (Heuristics like dependency's depth in the graph were explored but didn't provide good results).

@dsyer helped with populating the provides files. This was a long time ago and i'm not sure if it has been kept up to date, so the quality of the info in the various provides file may not be as good/complete as it once was. It has also been a bit of a controversial feature. I'm sure a few people like it, but there's also a lot of folks who have asked how to turn it of.

[philwebb]

I've re-purposed this issue to remove the spring.provides files in 2.1. I feel like there's too much confusion over them and they cause too much of a maintenance burden to justify keeping them in Spring Boot itself.

This issue caused us to review a few, and we can see they have indeed become out of date. Take spring-boot-starter-data-jpa for example which has a provide for hibernate-entity-manager which is no longer pulled in by the starter.

I think scanning a starter pom for the immediate dependencies that it declares should probably be enough of an indication for the IDE. I'll raise a Spring IDE issue to see how they want to proceed.