m2e doesn't import Maven submodule correctly if its artifact ID is same name as project directory name

[garretwilson]

Steps to reproduce on Windows 10 with OpenJDK 17:

1. Install Eclipse EE 2023-06.
2. Update to m2e 2.4.100.20230802-0719. (I don't know if this is required to reproduce the problem.)
3. Clone https://github.com/globalmentor/guise-mummy.git into a guise-mummy folder inside your Eclipse workspace, as is the Git default. It is important to use the default guise-mummy folder, and to place that folder inside the Eclipse workspace.
4. Import the guise-mummy project as a Maven project, which is an aggregate project consisting of submodule.

Here is what I see in the Project Explorer

Note that the mummy submodule is showing up as a normal folder. Note also that the top-level project is named guise-mummy after the project subdirectory, not guise-mummy-bom after the artifact ID.

Here is what I expect to see:

Note that the mummy folder is showing up correctly as a normal submodule. I should explain also that this project was imported elsewhere beside inside the workspace folder. Hence Eclipse named the top-level folder guise-mummy-bom, according to top-level artifact ID. (I don't know why, but that's what it does.)

If I change the artifact ID of mummy/pom.xml to e.g. guise-mummy-foo, then I can import the project correctly. Apparently m2e doesn't know what to do when the submodule artifact ID guise-mummy matches the name of the top-level project, which in this case Eclipse named after the subdirectory guise-mummy (because it was located in the workspace folder) rather than the artifact ID guise-mummy-bom.

So really there are two issues, one of which is strange, and the second of which is a bug:

• Eclipse m2e uses two different top-level project naming strategies based upon whether the project it is importing is inside the Eclipse workspace or not. (strange)
• If a subproject name (named after the artifact ID) matches the top-level project name (named after the directory name), m2e doesn't know what to do, and doesn't correctly import the submodule as a submodule.

[HannesWell]

Good findings, I remember to noticed some issues with the project-naming during imports in the past as well.

Are you interested in contributing a fix for this?

[garretwilson]

Are you interested in contributing a fix for this?

Sincerely I would love to, but I am so behind already in this project, having lost days just tracking down and filing several bugs. Financially I can't spare the time because I'm not making enough progress on my main project.

[laeubi]

Clone https://github.com/globalmentor/guise-mummy.git into a guise-mummy folder inside your Eclipse workspace, as is the Git default.

Cloning inside the workspace is not an eclipse default and actually not very useful because that is where Eclipse store its project files.

It is important to use the default guise-mummy folder, and to place that folder inside the Eclipse workspace.

Why not simply clone it to the real default (that is a folder outside the workspace)?

Note also that the top-level project is named guise-mummy after the project subdirectory, not guise-mummy-bom after the artifact ID

That is most likely due to the overlap of project folder and workspace folder because eclipse uses the project name as folder here.

[garretwilson]

Cloning inside the workspace is not an eclipse default and actually not very useful because that is where Eclipse store its project files.

I don't understand this comment. Are you referring to the .project files? The eclipse .project files are stored inside the directory of the project it is importing.

Why not simply clone it to the real default (that is a folder outside the workspace)?

I'm really not following you here. If I create a project foo in the workspace, e.g. C:\workspace\foo, and then five years later convert it to a Maven project, that would be normal, right? How is that different from starting a project in C:\workspace\foo already as a Maven project and then importing into Eclipse?

Maybe I'm not understanding what you're saying.

But in any case, the point of this ticket is to report erroneous behavior:

1. m2e should not fully import a project if the directory is located in /location/a, yet only partially import the project if the directory is located in /location/b, wherever those locations are.
2. If m2e should never partially import a project with no errors. If it cannot fully import a project correctly, for whatever reason, it should produce an error instead of leaving the project in some sort of halfway imported state.

[laeubi]

Well I clone the repository to a new location (outside the workspace because that's the usual case and I can't see any 'default' that performs this inside the workspace directory) I then choose Import Existing Maven Projects and get this list:

this maps 1:1 to the declare modules of the project here:
https://github.com/globalmentor/guise-mummy/blob/ecb75ff96b99c1be275a10fe30842bbe6710f249/pom.xml#L56-L59

then after finish I end up with the expected results like this:

So from m2e POV everything works as designed and I can't reproduce what you described, so there must be some state in your workspace or a flaw in your description that allows to reproduce this in a clean environment.

So all that can be recommended is that:

1. git clones should best be performed outside the workspace directory because that's what works best as there is no way of influence
2. you should verify that you can reproduce the problem with a fresh clone and workspace.
3. Probably you should not only show the result of the import.

Just for completeness if there already is a .project file this one is used in almost all cases and m2e won't modify the name that is declared there, also if there is already a project called guise-mummy m2e can't import another one (as show in your screenshot) with the same name but you should see this in the import dialog already!

[garretwilson]

… I can't see any 'default' that performs this inside the workspace directory …

I think I see part of the confusion. I said, "Clone https://github.com/globalmentor/guise-mummy.git into a guise-mummy folder inside your Eclipse workspace, as is the Git default." The "Git default" I was referring to was that by default it will clone into the guise-mummy folder, i.e. don't change the name of the folder (even though Git allows you to do this)—use the Git default. In hindsight the sentence would have been clearer if I would have said, "Inside your Eclipse workspace, clone https://github.com/globalmentor/guise-mummy.git into a guise-mummy folder (which is the Git default)."

[laeubi]

Folder in a workspace (that is by default ~/workspace) have special meanings and implications, therefore you should always clone to another location (what defaults to ~/git/<reponame> for EGit) and import from there (was /tmp/guise-mummy in my example).

[garretwilson]

Well I clone the repository to a new location (outside the workspace because that's the usual case and I can't see any 'default' that performs this inside the workspace directory) …

The whole point of of this ticket is importing a Maven project in a directory inside the workspace. If you perform some steps other than those prescribed, then no, you will not reproduce the bug.

First let me be clear about what I mean when I say "Eclipse workspace". When you first start up a new Eclipse installation (I use a fresh extraction from a .zip file), it asks for your workspace. Let us suppose you enter C:\workspace as your workspace. Then to clone into that workspace as prescribed in this this description, you would go to the command line and enter:

C:
cd \workspace
git clone https://github.com/globalmentor/guise-mummy.git

This will give you a C:\workspace\guise-mummy folder, which you can import into Eclipse using m2e to reproduce this bug.

[laeubi]

As explained this can't work due to how eclipse workspace works, if the folder is inside your workspace it will create a project named guise-mummy, and then won't be able to import your submodule also named guise-mummy ...

To prevent this confusion eclipse standard behavior (EGit, m2e-git-integration, ...) clone into a separate folder. Of course you can enforce this but you should not expect that everything the works smooth or any one is much interested to investigate/fix such "bugs", you can try this out with a bare Eclipse project:

1. Goto New > Project > General > Project
2. Enter a name test
3. remove "use default location"
4. Choose the workspace as a location and use a different project name than the folder name
5. You will get an error from eclipse that such a project can not be created:
   

[garretwilson]

As explained this can't work due to how eclipse workspace works, if the folder is inside your workspace it will create a project named guise-mummy, and then won't be able to import your submodule also named guise-mummy ...

… in which case m2e should provide an error instead of leaving the project in some sort of half-way imported limbo.

It is a bug to halfway import a project and provide no errors. I feel that documenting this buggy behavior is a positive thing, whether anyone is interested in fixing it or not.

In any case, there are much, much bigger problems—blocker issues—introduced in m2e 2.4.x, such as #1501, and I think that should be given priority.

[laeubi]

Please report a bug to eclipse platform then as m2e can't do anything here.

If you absolutely want to use such scheme you need to use a different naming scheme

what already works perfectly fine even if you checkout in the workspace:

[garretwilson]

If you absolutely want to use such scheme you need to use a different naming scheme

Thank you for that tip, @laeubi . I had forgotten that option exists. This bug isn't affecting me at the moment, but this tip could come in handy in the future.