Let m2e discover the build tree of a project from its projects

[laeubi]

Currently the view of m2e to a multi module project is simply flat... each project is handled as its own. When working with a mult-module build, there is actually some kind of tree structure of related projects that are likely to work together.

Because of this, it would be useful to have a function in m2e that takes a single project as its input and then traverse to the modules declared for them and mark such projects in a special way as a multi-module aggregator.

This can then be used to:

• represent the structure in the project view (not yet checked how hard this would be)
• building more than one project (maybe in parallel) in one execution (that will be important for mojos scanning the set of reactor projects, e.g. Tycho)
• reuse maven facilities to compute what projects needs updates (-am / -amd) instead of m2e trying to figure this out directly

While it sound obvious there are some challenge:

1. A single (physical) maven module could be mentioned in several pom.xml files
2. A pom.xml might include modules outside the workspace
3. A pom.xml with modules might not necessarily be a parent of the module it includes

Because of this, the idea would be to have a special project type a user could import named "Multi Module Maven Project" where I must point m2e to one pom.xml file that contains <module> declarations and m2e then uses this as the root to source the list of projects to import (that of course can contain other modules as well).

The final goal would be, that the only thing required as a user is that I point m2e to my "root pom" and everything else is handled automatically, I get a tree that represents the structure of my modules and I can build/use each sub project as if called from the command line with -am and if I change something in the child each dependent project is also updated similar to -amd).

This relates to the story

• [EPIC] allow m2e to process projects that don't have a nature #682

[mickaelistria]

Does Import > Existing Maven projects already do that?

[laeubi]

Does Import > Existing Maven projects already do that?

What specific part of the described story? :-)

If I use the wizard it shows the module mentioned projects to import, but each one is handled as an individual project, also after the import, I need to enable "hierarchic" project layout but then I get the layout of the file-system not the layout of the modules in the pom.

[palminha]

i have a similar problem... here is my setup:

parent project -> pom.xml in the root directory of the project
modules, each one in each sub-directory
|- module 1 -> pom.xml
|- module 2 -> pom.xml

Here is the pom.xml example in the parent directory

    <modules>
        <module>xxxx-resources</module>
        <module>xxxx-commons</module>
        <module>xxxx-security</module>
        <module>xxxx-api-filters</module>
        <module>xxxx-core</module>
        <module>xxxx-search</module>
        <module>xxxx-docs</module>
    </modules>

for "manually" compiling i'll do this in the root directory
mvn -pl xxxx-core -am

from maven documentation:
-pl => Comma-delimited list of specified reactor projects to build instead of all projects. A project can be specified by [groupId]:artifactId or by its relative path
-am,--also-make => If project list is specified, also build projects required by the list

[laeubi]

@palminha if this is crucial to your business and you likes to speed up the development of m2e in general a sponsoring would allow me to assign more time-slots to bug fixing or you can contact me for an individual contract for example fixing this specific issue.

Beside that contributions are of course always welcome.

[mickaelistria]

I think this issue is not clearly titled: m2e has access to such build tree, or could easily rebuild it from the metadata it has.
What functionality is missing concretely?

[laeubi]

@mickaelistria can you tell what exactly is unclear from the PR description?

The main goal is summarized at the end:

The final goal would be, that the only thing required as a user is that I point m2e to my "root pom" and everything else is handled automatically

So today I have to import all and every project pom (what could change over time), and

I can build/use each sub project as if called from the command line with -am

Currently m2e builds each project individually and one needs workspace resolution to be enabled or install the modules in the local repository if there are dependencies, also one needs several run configs with individual project names (what sdly is not possible to automate at the moment).

[mickaelistria]

The final goal would be, that the only thing required as a user is that I point m2e to my "root pom" and everything else is handled automatically

What is "everything else"?
For the import, the dedicated wizard does the job.
For the hierarchical view, it's now default for the Project Explorer in the IDE if I'm not mistaken.

(what could change over time)

So this is the actual new story: basically reacting to addition of modules in pom.xml ?
Would it work with a file listener reacting to changes on pom.xml by suggesting to reopen the import wizard when a new module is added?

[laeubi]

As mentioned all projects are currently handled / imported individually, this is not how the are handled in a usual maven build (unless you go into a specific folder). Also the builder currently figures out what needs to be rebuild when one project changes (what not necessarily match what maven thinks).

So basically this is closely related to

• Add support for creating workspace private project descriptions eclipse-platform/eclipse.platform#1787

So from a uses point of view you only ever import "the root" project as a classic eclipse project, all modules should be discovered / updated automatically (and we might handle them as transient projects to make eclipse happy), also when building we should not compute the related projects but let maven do it with -am / -amd option.

Another point would be to let the hierarchical view of navigator represent the real structure and not the structure in the file system. So assume I have

• parent/pom.xml (referencing module1 ... N)
• module1/pom.xml
• module2/pom.xml
• module3/pom.xml
• ..
• moduleN/pom.xml

and I import parent/pom.xml the result should be

• parent
  • module1
  • module2
  • module3
  • ..
  • moduleN

[mickaelistria]

So from a uses point of view you only ever import "the root" project as a classic eclipse project, all modules should be discovered automatically

That's what the dedicated wizard already does.

updated automatically

That is indeed a missing feature in m2e.

Another point would be to let the hierarchical view of navigator represent the real structure and not the structure in the file system.

That this is the opposite of why the hierarchical view was desired, implemented and made mainstream. There is a lesson to learn: developers do take care of the way they manage their modules and their filesystem. What developers want to see is what they have chosen. If they have flat filesystem Maven modules, they want to see flat modules; if they want them hierarchical, they make their filesystem hierarchical.
Anything that tries to render the navigator differently from what developers have chosen is negative in term of usability and goes the opposite way of developers expectation.

[laeubi]

That's what the dedicated wizard already does.

It does not do that, it import one project for each child and the parent.

[mickaelistria]

it import one project for each child and the parent.

Yes, and it won't change until JDT is capable of supporting multiple classpaths per project; or until JDT is capable of creating an IJavaProject without an underlying IProject.

Everything else is presentation and UI: if you don't want the children modules/projects to appear in the navigator, just create a navigator filter to hide them. Or maybe let's just change the icon for nested project so it just looks like a folder.

[laeubi]

@mickaelistria I really appreciate your insight here but all this does not help in what the proposal wants to improve.

You wrote here that one goal among others is that m2e should behave more like a CLI invocation and this does currently not match the current concept of singular individually imported project, and it has nothing to do with JDT or IJavaProject.

Also no one will be forced to use that (therefore a new project type), so anyone who is happy with the old concept can use it everyone else can enjoy the more native maven project model integration.