Maven multi-module support

[fabapp2]

Until now Spring Boot Migrator was only working with single module applications.
Support for Maven multi-module projects was missing.

In this discussion, I'll try to note my thoughts and learning while working on #270.
Feel free to jump in and bring in your ideas and remarks, it's appreciated!

Maven multi-module projects and generic Actions

In a multi-module Maven project, the hardest problem is to decide which modules should be affected by an applied Action.
For specialized Actions there's often only one algorithm to select affected modules (BuildFile and source sets).
But for more generic Actions like AddDependency, RemoveDependencies the affected modules heavily depend on the context of the migration.

Example

E.g. The pom.xml where dependencies should be added differs from recipe to recipe.

When initializing a new Spring Boot project the spring-boot-starter and spring-boot-starter-test dependencies must be added to the same modules as the starter class(es) annotated with @SpringBootStarter.

But when migrating a Maven multi-module project with a JPA-module containing JPA related classes and being referenced by other modules the dependency for spring-boot-starter-data-jpa must be added to this module.

Learning

• Some Actions need to be configurable in how they chose the modules to migrate.
• Every implementation needs access to the Actions configuration, e.g. the dependency to add

Possible Solutions

One Action implementation per use case

A new Action for Every variation: AddDependenciesToApplicationModules, `AddDependencyTo

👍

• Simple design, a new class for every new use case
• Easy to understand with minimal configuration in YAML or recipe config

👎

• Brings a lot of similar classes AddDependencyHere, AddDependencyThere, ...
• Naming of classes is even more important

One Action implementation with replaceable strategies

Actions can be configured by exchanging strategies to handle multi-module projects

👍

• Cohesive Action names AddDependency adds dependencies
• Highly configurable

👎

• Complicated setup in YAML and also recipe configs
• Hard to understand
• Requires extraction of Action configuration data
• MultiModuleHandler not reusable
• Requires a new ActionDeserializer

Every Action has support for an optional, replaceable strategy

This is the same as above but with a default strategy.

Conclusion

We will create "One Action implementation per use case" for Actions that need to deal with multi-module projects.

With the approach of a replaceable strategy the Action hierarchy becomes more complex, the YAML setup becomes much more complex and a recipe configuration in Java also becomes much more complex.

But the benefits are minimal. The Handler or Strategies can hardly be reused but will contain the apply logic of an Action and could thus be the Action itself with easier setup.

ApplicationModule(s)

In a multi-module project each module is represented by an ApplicationModule.
The ProjectContext provides getApplicationModules() to retrieve ApplicaitonModules which encapsulates all ApplicationModules.

Add new Dependency

When adding a new dependency to a pom.xml, the classpath updates only for dependant modules and for child modules.

ApplicationModules.getDependantModules(ApplicationModule)

Returns all modules that declare the given module as dependency.

getDeclaredModules()

Returns all modules declared in <modules>

getModuleResources

Returns all resources contained in any of the ApplicationModules SourceSets.

contains

Checks if a given Path matches the absolute path of any of a resource in any of the SourceSets

[fabapp2]

Closing this as done after successfully parsing and running SBM against a 50+ modules JEE application.