Hi,

I was looking through some build scans the other day and noticed some deprecation warnings that seem to be generated by the aggregateJavadoc task: see https://ge.spring.io/s/z27xbdykxsjse/deprecations for an example.

This PR excludes the starters from the Javadoc aggregation which seems to help with the deprecations. As the starters have no source, they don't need to be checked anyways in my opinion. So we gain a little as well in terms of performance.

I couldn't find why the starters are special and throw those warnings while other modules don't. Maybe you have an idea, but I guess it's safe to exclude them in the first place.

Let me know what you think. Cheers, Christoph

Comment From: philwebb

I have a frightening feeling that we need javadoc jars to be generated otherwise the upload to Maven Central will fail.

Comment From: dreis2211

@philwebb My understanding is that the publishing task executes the javadoc tasks still. This PR only excludes it from the javadoc aggregation for the docs, which seems to generate the warnings.

Comment From: wilkinsona

I couldn't find why the starters are special and throw those warnings while other modules don't. Maybe you have an idea

I thought we had warnings for "normal" projects as well as the starters, but looking at a recent build scan it's just the starter projects. I can't explain that for certain, but I wonder if it may be because those other projects have already resolved their compileClasspath configuration by the time the aggregation occurs whereas the starters (due to having no code to compile) have not.

My understanding is that the publishing task executes the javadoc tasks still. This PR only excludes it from the javadoc aggregation for the docs, which seems to generate the warnings.

That's my understanding too. While I'd like to change the way the javadoc aggregation is done so that the spring-boot-docs project isn't reaching into the internals of the aggregated projects, that's a much bigger piece of work. IMO, this is a change that's well worth making in the meantime. Thanks, @dreis2211.