I want to use Gradle to build two artifacts, one commonly used as implementation("tld.domain:foo")
and one as testImplementation("tld.domain:foo-test")
FWIW foo-test depends on foo. It contain code that helps consumers write tests for their use of the foo library.
I’m seeing two potential directory layouts and I don’t know which of them will carry the more relevant problems, so I’m asking here.
Layout 1: Put the main library right into the root project.
The recommendation is to avoid this though, but I don’t know the reasons or the potential pitfalls.
Layout 2: A dedicated subproject for each artifact.
More regular build, but potential for confusion when talking about “the foo project” because it’s going to be unclear whether it means the root project or the subproject.
I fail to come up with a good name for the project directory; I have been able use purely semantic naming for project roots; if I know say foo-root or foo-project, that mixes a technicality (it’s a root project with subprojects) into the project directory’s name.
All and any insights appreciated!
Thanks in advance!
None of the layouts should really have pros or cons.
If you mean with “The recommendation” the best practice section about build structuring, I personally would say ignore that non-sense. I agree with most of the documented best practices I’ve read so far, but not with that one.
If you want to follow that best practice, you anyway need to restructure all your builds and move the code into a subproject and then you can consistently name all foo-project or whatever.
What you could also do instead is using the test fixtures plugin to add a test fixtures source set to your project that is published along your main jar under the same coordinates.
Gradle consumers will then request it using testImplementation(test fixtures("tld.domain:foo")).
Non Gradle consumers get it like any other classified jar.
This way you only have one project again.
Besides that also with one-project builds that “best practice” says you should have a subproject.
Restructuring the build is going to be necessary anyway.
Reason: Currently everything is in a single project, so I need to split off the code for foo-test into a separate project; the only open question is whether that can be a subproject or not, and if I’m restructuring things anyway, I can just move the main project’s code around as well.
The issue I’m having is that I don’t want to rename the main project to foo-project because that does not fit established naming, where project name is identical to main artifact name; if I have projects foo, bar, and baz, I want them to live in directories foo/, bar/, and baz/, not foo-project/, bar/, and baz/; that’s pretty much nonnegotiable.
Ah. I knew that there’s such a thing as test fixtures, but I was reluctant to dive into that thing as well; Gradle mechanisms tend to be somewhat complicated and not so easy to diagnose if something goes wrong, so I didn’t look up the specifics.
What’s your take:
Given that I can’t keep up with Gradle at my usual “power user” level, as it’s constantly adding advanced new features and forced to follow recipes: Would it be advisable to learn test fixtures and use these, rather than go into subproject yo-yo?
test fixtures is just some semantic sugar to create a feature variant.
Whether you use separate projects or a feature variant is more a question of what output you intend and thus how it is consumed.
Separate artifacts under separate coordinates => better multiple projects
Just a classified artifact as feature variant under the same coordinates => feature variant like with test fuxtures plugin
Yes, I know.
And as I said, you can do it as subproject while the main code lies in the root project if you prefer, I don’t see much problems, I just showed you that you could also do it using the feature variant if you might prefer it like that but just were not aware of how to do it.
