# Subvariant selection in multi-project build to use java-classes-directory

**URL:** <https://discuss.gradle.org/t/subvariant-selection-in-multi-project-build-to-use-java-classes-directory/36123>\
**Category:** Help/Discuss\
**Created:** [May 17, 2020, 2:00am UTC](https://discuss.gradle.org/t/subvariant-selection-in-multi-project-build-to-use-java-classes-directory/36123 "2020-05-17T02:00:06Z")\
**Posts on this page:** 1\
**Page:** 1

<div class="post-metadata">

**Author:** ![keturn](https://sea1.discourse-cdn.com/gradle/user_avatar/discuss.gradle.org/keturn/32/8529_2.png) [@keturn](https://discuss.gradle.org/u/keturn)\
**Post date:** [May 17, 2020, 2:00am UTC](https://discuss.gradle.org/t/subvariant-selection-in-multi-project-build-to-use-java-classes-directory/36123/1 "2020-05-17T02:00:06Z")

</div>

The manual for the [Java-Library Plugin](https://docs.gradle.org/6.4.1/userguide/java_library_plugin.html#sec:java_library_classes_usage) says:

> A feature of the `java-library` plugin is that projects which consume the library only require the classes folder for compilation, instead of the full JAR. This enables lighter inter-project dependencies as resources processing ( `processResources` task) and archive construction ( `jar` task) are no longer executed when only Java code compilation is performed during development.

Yes! Sounds great! I want that! Not only to skip the jar creation step, which sounds nice, but because I believe that if the consumer runs using the classes folder, that will make it faster and easier to do live reloading of classes and resources in our application during the development process.

When I look at `outgoingVariants` of the producing project (`:engine`), I see that there are secondary variants with artifactTypes of java-classes-directory and java-resources-directory. Looks good to me.

But when I `run` the application that depends on it, I get this:

> Selected primary task ‘run’ from project :facades  
> Tasks to be executed: [task ‘:engine:compileJava’, task ‘:engine:processResources’, task ‘:engine:classes’, task ‘:engine:compileDevJava’, task ‘:engine:processDevResources’, task ‘:engine:devClasses’, task ‘:engine:cacheReflections’, task ‘:engine:copyResourcesToClasses’, task ‘:engine:createVersionInfoFile’, task ‘:engine:jar’, task ‘:facades:PC:compileJava’, task ‘:facades:PC:processResources’, task ‘:facades:PC:classes’, task ‘:facades:PC:run’]

which is certainly not skipping the `:engine:jar` task, and the application’s classpath has the jar on it instead of a directory.

Build scan for that run task: [Build Scan® | Gradle Cloud Services](https://scans.gradle.com/s/6mrxp74uzzf4y)

Build scan for just the outgoingVariants task: [Build Scan® | Gradle Cloud Services](https://scans.gradle.com/s/2xradzdaiu3ag/console-log)

The manual goes on at great length about customizing variants and attributes and all that, but if I understand correctly, what I’m looking for is expected to be the _default_ behavior between sibling Java projects.

There’s lots of _stuff_ going on in the build configuration, so it seems likely we’ve done _something_ to cause that variant selection to break down, but how do I find out what or why?