Consider deprecating and removing GenerateLibrariesXml task

[sergej-koscejev]

The task is used to generate a libraries.xml file with libraries pointing to custom locations, with the possibility to override some of those locations locally.

I think that instead people should simply check libraries.xml into version control. Library paths can contain project-relative paths so library mylib can be added with path $PROJECT_DIR$/build/dependencies/mylib for example, and Gradle can be configured to put the library there.

For the override functionality, one can instead open a different version of mylib in MPS before opening the main project. The override functionality allows one to change the project library path locally to point to ../mylib-development but the added value over just opening it in MPS first seems to be very small.

[vlsi]

@sergej-koscejev , how about the following:

1. User adds a Gradle configuration for the libraries
2. User adds dependencies to the configuration

val mpsPlugins by configurations.creating { ... }

dependencies {
    mpsPlugins("de.itemis.mps:extensions:$mpsExtensionsVersion")
    mpsPlugins("com.mbeddr:platform:$mbeddrBuildNumber")
}

3. Then GenerateLibrariesXml resolves the configuration, copies the libraries to build/.. and generates (or even updates) libraries.xml with the proper location of the libraries.

I guess it would help to keep the library declarations in a single place.

On top of that, mps-gradle-plugin could declare a default configuration for MPS libraries. For instance mpsLibraries.
Then user could just add the dependencies, and generateXmlLibraries would update .mps/libraries.xml

WDYT?

[sergej-koscejev]

@vlsi I think that generating this file doesn't save that much work, in my experience the set of used libraries doesn't change as much. If it does change often for you then you can add a parent directory such as build/dependencies as a project library and have multiple libraries inside that directory, MPS will find them. Adding each library separately is not really necessary.

[vlsi]

I think that generating this file doesn't save that much work

Well, the dependencies still have to be received and unpacked to a folder, don't they?
So it looks natural that the plugin should both download the dependencies, and generate the relevant libraries.xml

[sergej-koscejev]

I think that generating this file doesn't save that much work

Well, the dependencies still have to be received and unpacked to a folder, don't they?
So it looks natural that the plugin should both download the dependencies, and generate the relevant libraries.xml

Sure but that's not what this task does. This task was for being able to locally override some entries in libraries.xml to point to a different directory.

[vlsi]

Well, as long as libraries.xml generation is there, it looks fine to me :)
However, the issue descriptions look to me like you want to move XML generation to the developers.

[sergej-koscejev]

However, the issue descriptions look to me like you want to move XML generation to the developers.

Yes, that's what I want. Generating this file doesn't save that much work. The task doesn't unpack dependencies, it only writes a few lines of XML.

[vlsi]

Generating this file doesn't save that much work

That is not, however, it is duplication: once I declare dependencies in Gradle, then I need to generate libraries.

[vlsi]

Just in case: previously I knew nothing of Gradle, and I was more-or-less managing the dependencies manually, however, later I realized a Gradle plugin can manage it.

Now you say you are going to remove that from mps-gradle-plugin which is sad.

[sergej-koscejev]

Just in case: previously I knew nothing of Gradle, and I was more-or-less managing the dependencies manually, however, later I realized a Gradle plugin can manage it.

Now you say you are going to remove that from mps-gradle-plugin which is sad.

No, I'm proposing to remove just the task to generate the libraries.xml file. Does the approach of adding a single directory as a "project library" and putting all your dependencies underneath it not work for you? This way you don't have to regenerate or change thelibraries.xml file when adding/removing dependencies.