Java-library consumer howto

Help/Discuss
1

I’m very much interested in using new java-library plugin capabilites within my multiproject build.
I’ve read all available docs, but how to proceed regarding dependency declarations remains obscure to me,

I’ve got a webapp, divided into several subprojects.
All of them would be java libraries, except one (the webapp proper, using the war plugin).
But then, in the war module, should I declare each dependency on other module twice, like this?

dependencies {
  compile project(path: ':module1', configuration: 'apiElements')
  runtime project(path: ':module1', configuration: 'runtimeElements')
}

Or would a single declaration, not specifying configuration, magically do the same?

dependencies {
  compile project(':module1')
}

Also, it’s not clear to me whether I should continue using compile/runtime in the non-java-library module, as I’ve done above, or I should be doing something else.
I think documentation should provide typical consumer examples to clarify this.
In the meantime, can anybody shed some light on me, please?

2

The examples shown in the HTML documentation are actually excerpts from simple, but fully functional sample builds. The samples in their entirety are not provided in HTML form, but in the complete distribution where you can browse, run, and modify them in source form without having to copy and paste multiple files. The one you’d be interested in is samples/java-library/multiproject.

In your example, the webapp project that creates the WAR would declare the dependency as:

dependencies {
    implementation project(':module1')
}

However, even if you did declare it as a normal compile dependency, only the classes declared as API in the java-library project would be included in the compileClasspath. The output of gradle :app:dependencies will show you this:

compile - Dependencies for source set 'main' (deprecated, use 'implementation ' instead).
\--- project :utils
     +--- project :core
     |    \--- joda-time:joda-time:2.9.7
     \--- org.apache.commons:commons-lang3:3.4

compileClasspath - Compile classpath for source set 'main'.
\--- project :utils
     \--- project :core

The reason this works is because the new configurations were wired up in the java plugin to work for consumers as well. The java-library plugin just sets up the last bit for the library.

Unless you’re familiar with the internal changes though, the release notes for version 3.4 that introduced the java-library plugin seem to be the only place that mention that:

Some of the new configurations of this plugin are available to the java plugin too, and others are just deprecated.

3

Ok, thx.

But there’s something I’d like to understand better.
I had always thought that a project(:module1) dependency implied default configuration, which implied runtime configuration, unless you explicitily ask for a different one.

Now, your response seems to suggest that now, project(:module1) would be using the apiElements for compiling and the runtimeElements for generating the artifact.

Is that correct? Could you expand on that, please?