If you don't give the test Jar a different name (e.g. by setting `appendix = "test"`), it will overwrite the main Jar on disk. Another thing that's suspicious is that you configure the test Jar to contain `sourceSets.main.output` rather than `sourceSets.test.output`.

Thanks for the quick response Peter

If you don't give the test Jar a different name (e.g. by setting appendix = "test").

Exactly this is what bothers me: if I do give the test Jar a different name the project does not compile anymore. With a different name for some reasons the classes contained in the second test jar are not resolved anymore.

test Jar to contain sourceSets.main.output rather than sourceSets.test.output.

And again exactly because I need some of the test helpers to be available in production code for our internal tools I cannot put them into the test sourceSet (limitation of the IDE that the test classes of one subproject are not visible for production code in another subproject)

If you wish I can provide the minimal project where the problem can be easily reproduced.

> if I do give the test Jar a different name the project does not compile anymore

This just means that fixing one problem (the name collision) exposed another, likely unrelated, problem.

> And again exactly because I need some of the test helpers to be available in production code

The way the two Jar tasks are configured right now, the test Jar is a superset of the main Jar. That doesn't seem right to me.

Thaks for your reply Peter,

I wouldn't claim that I like current layout of the project either. But I have to handle the limitations of the tools I use and limitation in current project structure which requires weeks of refactoring to fix it. Before posting here I tried of course lots of different layouts and the one described in the first post is the only one that worked.

At first to avoid the situation when "test Jar is a superset of the main Jar" I tried to split the code in two separate jars with no overlap. Prod jar has prod classes e.g. everything from com.vozniuk.demo.** and test jar has only test helper classes from com.vozniuk.testing.**

task(testingJar, type: Jar) {
// archiveName = testsArchiveName
from sourceSets.main.output
// exclude(['com/vozniuk/demo/**'])
}

Uncommenting the exclusion line makes the build produce 2 disjoint jars. Unfortunately this setup doesn't work.

Can I then put the question this way:
Without changing the project structure how can one produce two different jars from one subproject such that:
1. The jars have different names
2. One of the jars is used in compile configuration and another is used in testCompile configuration in a different subproject
3. It doesn't matter if the jars overlap or they are disjoint (although I would prefer disjoint)
4. The project actually compiles and all classes are resolved both in compile and testCompile

Thanks for help!

1-3 should be clear by now. (The way you publish and reference the test Jar looks fine.) There is no generic answer to 4. The problem is likely specific to your build, and to help further I'd need a reproducible example.

Sure. Here is a reproducible example: [Download]([1]http://goo.gl/IOzfW6)
Thanks!
----------------------------------------------------------------------------------------
[1] http://goo.gl/IOzfW6

As announced on the Gradle blog we are planning to completely migrate issues from JIRA to GitHub.

We intend to prioritize issues that are actionable and impactful while working more closely with the community. Many of our JIRA issues are inactionable or irrelevant. We would like to request your help to ensure we can appropriately prioritize JIRA issues you’ve contributed to.

Please confirm that you still advocate for your JIRA issue before December 10th, 2016 by:

• Checking that your issues contain requisite context, impact, behaviors, and examples as described in our published guidelines.
• Leave a comment on the JIRA issue or open a new GitHub issue confirming that the above is complete.

We look forward to collaborating with you more closely on GitHub. Thank you for your contribution to Gradle!

Thanks again for reporting this issue. We haven't heard back from you after our inquiry from November 15th. We are closing this issue now. Please create an issue on GitHub if you still feel passionate about getting it resolved.