Consider publishing the plugin on the gradle portal

[ftomassetti]

Hi, I think this should be relatively easy and make a little bit easier to use the plugin. It is also straightforward, I have already done for two gradle plugins. You just need to register a profile and submit the plugin for approval (normally very quick)

[arimer]

Hi Federico, I really like the idea. Are these two mentioned gradle plugins of yours on github?
I would be interested in having a look at the code for the publication to the gradle portal.

Is it just a regular gradle publication or is there more behind it?

[ftomassetti]

Yes:

• https://github.com/Strumenta/antlr-kotlin/tree/master/antlr-kotlin-gradle-plugin
• https://github.com/Strumenta/mpsserver-gradle-plugin

It is a publication with a small set of metadata. You also need to register for the gradle portal and write the credentials on a configuration file. It is all quite straightforward.

Here there is a guide: https://guides.gradle.org/publishing-plugins-to-gradle-plugin-portal/

[coolya]

This isn't as easy as it seems. This repo contains only two real plugins in terms of gradle. The vast majority of content are tasks that aren't related to a plugin. That code doesn't even ship with a plugin descriptor because it doesn't contain any plugin and is only used by putting the classes on the classpath and then these classes are used in the end users build scripts.

[ftomassetti]

Could those tasks be made accessible as part of the plugin? Or do you think it would not work?

[sergej-koscejev]

I think having a plugin would make no difference, you would still have to import the tasks in your script to use them and add the itemis repository to the build script to make use of the tasks, I think.

@ftomassetti in your opinion, how would publishing the plugin make it easier to use?

[ftomassetti]

It would not be a huge difference but every gradle users is used to including plugins, let's so to add classes to the classpath of the script. One has to type a few more lines, and typically would need to copy them over from some other projects. While a one-line to include plugins seems more "normal". I suggested because, while the benefit can be minor, I thought also the work required would be minor.

[ftomassetti]

Also, the plugin can do some initialization when applied, like adding the itemis repository to you, so configuration could become a one-liner. For example, I do something similar in the mpsserver gradle plugin: I look at the repositories, configuration, and dependencies and add some default stuff, if it is not present

[coolya]

tl;dr: Yes we should publish it to gradle portal, but there is more to it and we need to do some renaming and add a "dummy" plugin.

The thing here is we are talking about different things, gradle plugin in the gradle sense, yes that's true it can do these things and we do that with generator plugin etc. But these are niche use cases for the plugin at the moment. The vast majority use that tasks defined in the jar directly without applying any gradle plugin.
A large part of this repository is a collection of tasks that used without any gradleplugin. These java classes need to be on the classpath of the buildscript. This repository at the moment results in at least six maven artifacts that all have different purposes.

• mps-gradle-plugin: collection of useful tasks around MPS projects with no gradle plugin.
• gradle plugin: modelcheck: gradle side of the modelcheck subsystem. Its a real gradle plugin used to add the tasks and dependencies required for running the model checker. Note this is only the gradle side of the story, there is a runtime dependency that is added to you project by this plugin.
• gradle plugin: generate-models: gradle side of the generation subsystem. Its a real gradle plugin used to add the tasks and dependencies required for running the generator with no ant build scripts. Note this is only the gradle side of the story, there is a runtime dependency that is added to you project by this plugin.

The two gradle plugins above are mostly metadata that on the maven repo for gradle to fetch the right dependencies and to know which project plugin classes to apply at runtime. The actual classes are contained in the mps-gradle-plugin.

• project-loader: versioned together with MPS and is used by runtime code used by the model check and generate model runtime code.
• modelcheck: runtime code for running MPS in headless mode and check models. This code is versioned together with MPS update and the gradle plugin will create a dependency in your buildscript to this in order to be able download it and run the classes from it in a separate task outside of gradle.
• generate-models: runtime code for running MPS in headless mode and generate modles. This code is versioned together with MPS update and the gradle plugin will create a dependency in your buildscript to this in order to be able download it and run the classes from it in a separate task outside of gradle.

Now if we want to provide real value to the end user to make things easier to use we can't just publish the existing things to the gradle portal / maven central. Leaving out the fact that we would need to rename the modelcheck and generate-models gradle plugins because these are not valid names for the public repositories.

In order to get gradle to put our tasks on the classpath of the build script we would need a real gradle plugin. Now one would ask why not apply either modelcheck or generate-models to get this. While in theory it would work, these plugins search for their configuration and fail if the configuration is missing. We would need to define an empty gradle plugin with a valid name, that does nothing when applied to the build script but carries the dependency to mps-gradle-plugin.
I think this is easily possible.

For renaming the existing plugins, I think the impact to most users is marginal since old versions would still be available on the itemis nexus and without an explicit configuration change you won't run into problems at the user side.

To conclude my thoughts, is it flipping a switch and just pushing the existing jars to maven central/gradle portal? No! Is it still worth doing it? Yes!

If we create an empty gradle plugin called de.itemis.mps and renamed the others to de.itemis.mps.generate and de.itemis.mps.modelcheck I think we are good to go after some testing.

I hope it made clear why we can't do this right away.

[vlsi]

The vast majority use that tasks defined in the jar directly without applying any gradle plugin.

What tasks do you mean?
I guess it is better to have task-oriented "plugins" rather than "an obscure no-op plugin".

For instance
a) There might be: de.itemis.mps.dmg plugin for CreateDmg and BundleMacosJdk tasks.
b) de.itemis.mps.libraries for libraries.xml (it could add a configuration for libraries, and it could add a default task that generates the XML)

I guess that would be slightly better than a dummy plugin since it would make the resulting build scripts easier to read and understand.

[ftomassetti]

I reflect on this and I tried building a simpler plugin to help people getting started on simple projects with KernelF.

This experimental plugin (called MPS Wizard) is configured like this:

plugins {
	id 'com.strumenta.mpswizard' version '1.0.0'
}

// This part is optional. If you leave it out it just pick a default MPS version
mpsWizard {
	mpsVersion = "2020.1.6"
	useIets3 = true
}

It does a few things:

• create a .gitignore file
• download mps
• download the mbeddr platform and iets3
• generate the MPS project
• setup libraries.xml

Now, this plugin will never be as powerful as this one, and I plan to use it in tutorials to help people getting started more easily. In real projects I use this plugin, but I always need to copy the configuration from other projects, because there are too many things to remember for me. It typically requires me 20-30 minutes to setup a new MPS project with a proper build file (I recorded myself to measure it). My goal with this other plugin is to stay below 1 minute. The drawback is that it would be very "opinionated" and not as poweful and flexibile like this one.

I am sharing this because maybe we could steer this plugin to be easier to configure, combining the best of both worlds: having something powerful and easy to use.

[ftomassetti]

Also, a benefit is that by running ./gradlew tasks I can see which tasks are available