initial setup of plugin structure

[atomfrede]

These are the first steps to create a gradle base plugin. Currently id does nothing except applying the java plugin and creating a new task when you are under windows.

Mostly I have two open questions (maybe @oehme or @eriwen can help here).

• What is the best way to apply 3rd party plugins like the spring boot plugin or the sonar plugin?
• How to I configure the PathingJarTask via code and plugin the same as in the current build file? Overwriting the methods (like for the the appendix) seems no not right to me, but couldn't find much about it.

What I need to consider is plugin versions. Currently I think of something like @oehme suggested, that we can easily overwrite the version of certain plugins like this, so a user can easily update versions:

jhipster {
 bootVersion = 1.5.8
 aptVersion =0.11
}

jhipster-docker {
 dockerPluginVersion = 3.1.0
}

What do you think?
Updates jhipster/generator-jhipster#6252
Updates #1

[oehme]

What is the best way to apply 3rd party plugins like the spring boot plugin or the sonar plugin?

You add a dependency on them in your build file and then apply them, just like you apply the Java plugin. Of course you should only do this with plugins that are core to the "JHipster experience".

If there are some "optional integrations", you have two approaches at your disposal:

• Have a dedicated plugin which applies that other one and configures it. That way users only ever apply plugins from your namespace. E.g. there could be a jhipster-sonar plugin.
• Let the user apply the original Sonar plugin and only react to its presence. You can do that by using project.plugins.withId(). You'll still need a dependency on it to make the classes visible to you, but you wouldn't apply it automatically anywhere.

How to I configure the PathingJarTask via code and plugin the same as in the current build file?

You could literally use the same API as in the build file, i.e. just create a Jar task and call dependsOn etc. But I think a PathingJar is special enough to have a dedicated class that

• sets the appendix in the constructor, since that's a default that is good for all instances of this task
• has an @InputFiles property for the runtime classpath
• overrides the copy() method to first do the manifest manipulation and then call super.copy().

You then create an instance of this dedicated type and only set the runtimeClasspath property.

What I need to consider is plugin versions. Currently I think of something like @oehme suggested, that we can easily overwrite the version of certain plugins like this, so a user can easily update versions

I'm not sure where the code snippet above should live, can you elaborate?

[atomfrede]

Thanks for your input, so basically just apply the plugin the buildscript to have it available in the plugin source code and apply it to the project, sounds easy. 👍

Basically I would like to have the plugin and the generated code not tightly coupled. In particular, if someone wants to use a newer boot version the version of the boot plugin should be easily configurable and not fixed by e.g. the plugin version.

So in a generated build file I could do

jhipster {
 apt = 0.12
}

if I want the newest apt plugin applied, although jhipster applies 0.11 by default.

[oehme]

That's not possible. By the time you are applied, the plugin classpath is long resolved. The user can apply the apt plugin herself to override your version. I'm not sure how common that is though and I'd probably not add boilerplate into the build script for that case.

[atomfrede]

✔️ Alright, was not sure about it, but that is what I already thought.

[bmuschko]

Basically I would like to have the plugin and the generated code not tightly coupled.

As mentioned by @oehme that's not possible. Also please be aware that you would be dependent on the API/DSL exposed by the third-party plugin you are configuring in your plugin. This API/DSL of course might change between versions and potentially break your plugin.

+1 for a dedicated plugin as suggested to avoid too tight integration in a single plugin e.g. jhipster-sonar plugin.

[atomfrede]

Thats even more fine granular than I had planned (jhipster-base, jhipster-gatling, jhipster-swagger), but the more I think about the more it sounds like a good idea, as users can easily remove e.g. sonar from the generated code when not needed or overwrite it 👍

[CLAassistant]

All committers have signed the CLA.