GRADLE-2966 might not seem like a big deal because there are only 7 voters and 5 watchers. But it is actually a big concern. And actually if you googled for “gradle depending on tests” or similar you’d easily see that it effects way more than 7 people. I say that because, unless I miss something (always quite possible), GRADLE-2966 is really the only way that setting up “exported dependencies” on a test/testing jar will ever be practically possible with Gradle.
Yes, yes, I could set up a Configuration, add my “test jar” artifact to that Configuration and other modules could access it that way. Heck, I could even publish it and builds outside my immediate build could access it via a classifier-specific dependency. But I said “practically” above because of course that misses the dependencies that should transitively apply from these test/testing classes. So some other project depending on my test/testing configuration/classifier still needs to duplicate all my dependencies as their dependencies (aka, there would be no transitivity, because a “simple artifact” in a Publication shares the same POM).
And not to mention this bites my build in the ass in a major way and has for the nearly 2 years since I first reported it. I work on an OSS project, so I know how these things go. But it just stinks that there is zero transparency here. 2 years later (publishing has been “incubating” for 2 years!!) and I still have absolutely no clue what the plan is for this issue, or if there even is any plan.
Please… is there some plan for finally implementing this? Or in some other way to be able to REALLY publish test artifacts?
Your correct that we made a bad call by introducing the “new” publishing DSL and leaving it ‘incubating’ and incomplete for so long. The reason for this is that it’s fundamentally tied to the concepts that are being introduced in the new configuration model and the new component model, and those things have taken much longer to develop than we had hoped.
It’s quite possible to use a configuration to export a testing jar and it’s dependencies in Gradle. You would then declare a project dependency on that configuration, which would bring in the transitive dependencies as well as the artifacts. To do this, you should not need to include a second publication to the exporting project.
Unfortunately, if you want to publish this testing jar for consumption outside of the immediate build, you’ll have multiple publications defined, which means that you’ll be hitting GRADLE-2966 when trying to use maven-publish.
A couple of options I see.
Don’t use the maven-publish plugin
Use the maven-publish plugin, but only configure a single publication per project by default.
Only configure the additional publications on hibernate-core when publishing hibernate-core, but not when you are publishing hibernate-c3p0 (which is the trigger for this failure).
Given my limited understanding of your exact problem (GRADLE-2966 doesn’t mention testing jars), that’s the best I can offer.
First, I really have no issue with how long things may or may not take. What is hard to deal with is the lack of transparency in this process wrt Gradle. Partially that is a function of hiding Jira I think, which again is completely up to y’all if that is what you want to do. But try to understand how to me, as a user, it simply looks like these issues “fall through the cracks”. Nothing is ever done to the Jiras (which I can find to watch, but only because I happen to create them in the first place), I cannot watch the Jiras related to “those [other] things” and nothing is ever linked in your Jira, nothing is mentioned on the dev list about them (at least not in terms of how they are effecting things I am interested in, etc.
As to your suggestions, I am sorry but I am not understanding. I’d highly prefer to keep using the maven-publish plugin. I have updated my plugins to work with maven-publish and would rather not go back. The second one I do not understand at all.
So let me explain what I have and maybe you can suggest what to do…
In Hibernate I developed a bunch of extension to JUnit specific to Hibernate testing. At the moment (for various reasons) these classes exist in a module called hibernate-testing . One of the functions of hibernate-testing is to help build a Hibernate SessionFactory as part of a tests lifecycle. As such, it relies on the hibernate-core module; but just the “production” classes (src/main). However, the tests for hibernate-core (as do the tests for most of the Hibernate modules) in turn rely on hibernate-testing. What I would really love to do instead is to move the hibernate-testing stuff into hibernate-core (somehow… as part of sourceSets.test, a different sourceSet, whatever) and to have other modules depend on the “hibernate testing” (no more module) classes from there. As a bonus I would love to be able to have users be able to pull those classes in as well, since we outline this as the appreciated means for submitting bug report test cases.
This is the frustrating lack of transparency I mentioned.
What I am trying to do is not unreasonable. In fact, I’d argue it is pretty common. Yet there does not seem to be a way to do it. And I have been asking y’all for almost 2 years now and never get a straight answer.
This is not directed at you Daz directly. But please understand how frustrating this is.