Spring boot: Example with spring-boot-configuration-processor

[vaslabs]

I think it's a good example to have in mill due to the annotation processor

and that should also test the IDE navigation of Mill & BSP

[vaslabs]

This works OOTB but with a warning if we just place the dependencies in

[36] [info] compiling 2 Java sources to /home/vnicolaou/mill/example/javalib/springboot/5-configuration-processor/out/compile.dest/classes ...
[36] [info] Annotation processing is enabled because one or more processors were found
[36] [info]   on the class path. A future release of javac may disable annotation processing
[36] [info]   unless at least one processor is specified by name (-processor), or a search
[36] [info]   path is specified (--processor-path, --processor-module-path), or annotation
[36] [info]   processing is enabled explicitly (-proc:only, -proc:full).
[36] [info]   Use -Xlint:-options to suppress this message.
[36] [info]   Use -proc:none to disable annotation processing.
[36] [info] done compiling
[36/36] ============================== compile ============================== 4s

[vaslabs]

@lihaoyi @lefou would it be a good idea to add an annotations processor task in Java modules to make this easier? This will make the setup for spring boot, micronaut and the likes easier than doing this ceremony, which is a bit error prone if the setup involves a bom.

I think we can have a task like annotationProcessorMvnDeps that does what the examples do + the bom which is available since this and feeds the javacOptions task

If we go with the direction of having a new task, we'd of course need to deal with backwards compatibility, so perhaps some flag or a trait that mixes in these new tasks and javac options

[lefou]

I think we want that. But I wouldn't introduce a new trait. Can you explain, where you see the backward compatibility issues? Adding a new task should not be an issue, as long as we provide a default, which should be the empty seq. This is what we want anyways, to be able to stack traits and call super.

[vaslabs]

I think we want that. But I wouldn't introduce a new trait. Can you explain, where you see the backward compatibility issues? Adding a new task should not be an issue, as long as we provide a default, which should be the empty seq. This is what we want anyways, to be able to stack traits and call super.

Ah you are right, I was thinking if it is set, it will break any examples, but yeah it will be empty. Ok then, I'll create a PR for it