How to configure compile-only *sources* for Java?

Help/Discuss
1

I know about compile-only depencencies, but I need a compile-only source.
What’s the best way to achieve that?

Background:
The compile-only sources are templates. They are valid Java code alright, but they are not supposed to go into jar files, or the runtime classpath.

Workaround:
I think I can place the Java file in the test SourceSet, but that feels terribly wrong.
Actually I’m using the “test” scope in Maven projects for such files, and it’s been feeling terribly wrong all the time but in Maven I have no other chance; do I have a chance in Gradle?

P.S.: I’m using Gradle 7.4. I can upgrade to any desired version at the drop of a hat, this is a new project so upgrades are easy.

2

Can you elaborate a bit more?
What are those sources?
What are they used for in the end?
Do you just want them to be highlighted as code in the IDE?
Or why do you need them at compile time?
Maybe they should be in a separate project.
Or maybe a separate source set would be appropriate for them.
Hard to advise how to solve it without more semantical information about the situation.
Maybe you can even provide an MCVE demonstrating your use-case.

3

Some more concrete example (no MVCE because it’s all just bits and pieces and experimental):

Here’s an example use case: Generate a JavaBean class from a specification, via an annotation processor.

For reference, here’s the desired outcome, a normal runtime class:

public class Foo {
  private String value;
  public String getValue() { return value; }
  public Bean setValue(String value) { this.value = value; return this; }
}

The source-only code would be something like this:

@BeanSpec(fluent=true)
interface FooSpec {
  String value;
}

Note that the bean class does not inherit from the interface.
That’s one of the more immediate consequences of the project’s desiderata.
(BTW if the bean class could be make to be Foo implements FooSpec, FooSpec would have to be in the runtime classpath and I wouldn’t be asking this question.)

Solved issues:

  • Since the bean class does not exist until the annotation processor has run, you need to tell contributors to run gradle compile before using the source tree in the IDE. (Maybe a future version of Gradle will automatically run the annotation processor on checkout, but that’s out of scope here, and maybe it’s even a Bad Idea.)
  • Generated code should not sit in the normal source directory, so one would tell the annotation processor to generate into another directory and tell javac to include that directory.These are pretty standard settings in Gradle (or Maven), so that’s already covered.
4

Hm, I guess just adding a source set for those templates is what you are after.
The source set gets separate compilation tasks that are not wired into anything automatically.
Then you can wire the task and its output as generated source files into the main source set and you are probably done cleanly without abusing the test source set.

Maybe a future version of Gradle will automatically run the annotation processor on checkout, but that’s out of scope here, and maybe it’s even a Bad Idea.

I think I agree that it would be a bad idea.
Especially as Gradle is not the tool responsible for checkouts, so can hardly do anyhting automatically.
You could maybe have some post-checkout hook to run the correct task in case it is a Git repository, but those hooks are client-side, so you cannot put them in your repository so that it works automatically for people, but it has to be setup once for each user.

Another option if the IDE is for example IntelliJ is, that you can configure specific Gradle tasks to run at certain points, for example after a sync, or before a build, …
Those automatic tasks can even be configured from your build script using the idea-ext Gradle plugin.

5

Just in case you don’t know about it, Lombok can do something similar with chain set to true for accessors?

6

Thanks @Vampire, that answered the question.
Just a heads-up: It seems that source directories don’t form a common classpath unless instructed to.
(I don’t yet know what classpaths and internal dependencies I’ll actually want, so I have postponed diving into that particular rabbit hole until I have a better idea of what I need/want.)