Refactoring project names to use micronaut-xxx

[melix]

Currently, the project templates use a layout like this one:

micronaut-foo-parent
     |----- gradle.properties
     |----- foo-bom
     |----- foo-core
     |----- foo-client
     |----- foo-fighters

and the internal build plugins make it so that when the projects are published, the GAV coordinates of the different modules are determined from the projectGroup property found in gradle.properties, and the project name, prepended by micronaut. For example, we would publish io.micronaut.foo:micronaut-foo-bom, io.micronaut.foo:micronaut-foo-core, io.micronaut.foo:micronaut-client and io.micronaut.foo:micronaut-foo-fighters in the example above (granted that each of those projects apply the internal Micronaut publishing plugin).

While this has work for years, it has a major drawback: this breaks Gradle composite builds. Gradle is not capable of realizing that when a project depends on, say io.micronaut:micronaut-core, then it should substitute it with the local version of Micronaut core that we use. Not being able to use composite builds has a number of issues:

• we need to introduce mavenLocal() as a repository on the consumer, which is not always obvious to do (there can be multple places to do this)
• we need to publish the dependent project to our local Maven repository, which is cumbersome
• we cannot use plugins like the Git include plugin to test remote branches

To make this work, we have to rely on arcane invocations like the one described in our wiki. Even so, this doesn't always work.

Therefore, the proposal is to change the project names so that they are directly micronaut-foo-core and micronaut-foo-client, ... instead of "remapping" them.

There are several ways to do this, each of them having the drawback that instead of executing a command line like:

./gradlew :data-core:test

you would have to invoke:

./gradlew :micronaut-data-core:test

which is longer, but can be simplified to ./gradlew :m-d-c:test

We would also likely lose our test distribution history (but it would relearn) in Gradle Enterprise.

More annoyingly, all project dependencies will have to be rewritten. For projects which use stringly-typed project dependencies, you'd change from:

implementation project(":foo-core")

to

implementation project(":micronaut-foo-core")

And for projects which use type-safe project accessors from:

implementation projects.foo.core

to:

implementation projects.micronaut.foo.core

Then we have those options:

1. no magic, rename all directories so that the directory name matches the project artifact id.
   • Pros
     • Gradle idiomatic
     • Can visually make the difference between "published" modules and "test" modules (e.g micronaut-foo-core vs test-suite-core)
   • Cons
     • messes up Git history, makes PRs before the change hard to merge
     • requires change to micronaut-build otherwise projects would be published with artifact id micronaut-micronaut-foo-core
2. Keep directories as is, and conventionally rename the projects
   • Pros
     • Minimal changes to projects, keep history clean
   • Cons
     • Require changes to micronaut-build so that project names are remapped automatically
     • will rename "non published" projects too (e.g test-suite will become micronaut-test-suite)
     • unless we add an opt-out (not sure if it's doable), then any project upgrading to the latest build plugins would immediately break
       because of the project dependencies being different

Note that whatever option is selected, there could be implementation difficulties which would prevent us from doing it altogether, but I need to have the option the @micronaut-projects/core-developers prefer.

[graemerocher]

Option 1 is a non-starter for me, it would mess up our git history and make merging and maintaining older branches a nightmare

[wetted]

It seems to me Option 1 is rather painful for the long term, indefinitely. I agree with @graemerocher that it's a scary thing to confront.

Option 2 is just somewhat painful in the short term, but should have no lingering negative effects. I can help unbreak modules as we update them to new versions of the build plugins. I'm used to it now. ;)

[dstepanov]

Can we use this to fix it using some scripts?

includeBuild('anonymous-library') {
    dependencySubstitution {
        substitute module('org.sample:number-utils') using project(':')
    }
}

[melix]

We can use dependency substitutions, as described in our wiki, but it's not practical to use as each project which wants to include a build has to understand the internal structure and publication model of the underlying included build.

[sdelamo]

I would like to delay anything about this change until 4.0.0-M1 is released. We are still struggling to get every module building.

I would also go for option 2. But:

Could we add logic so that projects starting with test-suite, or located within a folder named docs-examples, or set as not publishable are not renamed?

Moreover, could the build tool make this optin, not automatically enabled, for modules. For example, to get project renaming working you have to do in gradle.properties or in another place

micronaut.builld.projectrename=true

[sdelamo]

@melix I am going to close this discussion. I think we have a good solution in place.