Writing a RuleSource plugin that post-processes .class files

[st_oehme (Stefan Oehme)]

@jvff

I failed to mention I’m attempting to apply the plugin on a Play! framework project, so I was changing the source sets of the PlayApplicationSpec. I erroneously assumed that it would be similar to a generic Java project, sorry

Ah, in that case you will indeed have to use rule-based configuration, as the Play plugin is built on that.

@jvff

If I understood correctly, you added a new source set (normal JavaSourceSet) called “entities”, and by doing so configurations for it were automatically created. When you “configure” the main and test source sets, you’re declaring them to be dependent on the result of the entities source set, correct?

Correct.

@jvff

The only documentation I found related to the configure call was NamedDomainObjectContainer.configure(), but I’m not sure if (1) it’s the same method and (2) if the parameters specify which elements of the container should have the closure executed on them.

It’s Project#configure and just a convenience method to apply the same closure to several objects. In this case I wanted to do the same thing to both main and test.

@jvff

Finally, what I think you did was that you redefined the compile and runtime configurations to extend from the respective configurations of the entities source set. I don’t understand why this is necessary though, don’t the default configurations extend from the main configuration, and therefore automatically include the entities source set as well?

I don’t know what you mean by “default” and “main” in that sentence. We need to make sure that everything your entities need transitively is also visible to the code that uses your entities. That’s why compile needs to extend entitiesCompile.

@jvff

If you don’t mind me asking, is there a reason the software model for Java projects won’t be developed further? Is rule-based plugins still the way to go (especially for the long-term)?

There will be an in-depth blog post about this decision soon. The short answer is that many of the benefits can be achieved with the “old” model too. And the migration path for people with large builds is just too hard. That’s why we decided to take a step back and instead evolve the old model. In the long run, this might lead to a solution that incorporates many ideas like the rule engine, but in a more incremental way that makes migration easier.

We will of course keep supporting the Play and Native ecosystems that are already built on top of the software model.

@jvff

Thank you again very much for the reply!

You’re welcome