"target" directory not marked as derived/hidden in Maven project nested in generic project

[JanecekPetr]

This is related to https://bugs.eclipse.org/bugs/show_bug.cgi?id=500624 which is the issue I was trying to reproduce when I found this. The original issue (nested multi-moduled Maven project) is I think resolved now as I e.g. do no longer see classes from within .../nested/target in the Open Resource dialog unless Show Derived Resources is enabled.

This is happening on 2021-03 (4.19) with m2e 1.17.2.

Imagine a generic project containing a nested Maven project. Unfortunately, the Open Resource dialog sees the resources under nested/target:

Workaround: In the generic parent project, navigate to nested/ui/target (Project Presentation: Flat might be needed) and mark that manually as Derived. From my casual testing today, it seems to preserve the flag.

[laeubi]

Also see https://bugs.eclipse.org/bugs/show_bug.cgi?id=384356

[kjsmita6]

We are getting this too in our Eclispe 4.21 (m2e 1.18.1)-based IDE when we have our own custom project type nested inside of a generic Maven project. It doesn't happen with our projects by themselves - only when they are inside of another Maven project.

[kjsmita6]

Update: As I was working on #569 with m2e-core projects, using search provides results that are in the target folder due to nested project structure as mentioned. Search for derived resources was disabled. So it seems that having a Maven project nested inside another (even for basic Maven/Java projects) causes this bug.

[mickaelistria]

Right if you have a root project with a child project.

• In child project, target folder is derived
• In root project, child/target is not derived (and child isn't either)

I think it's a more general issue for Platform. Should the nested projects be usually marked as derived? https://bugs.eclipse.org/bugs/show_bug.cgi?id=568790

[sorin-costea]

@mickaelistria there is already the "experimental" Maven preferences option to hide modules of nested projects, which does absolutely nothing (as seen in a few projects and a few Eclipse versions). You are asking for a reason to hide the target or the nested modules, but I would love to hear one single reason to actually see them. Isn't a target always a target? Isn't a nested module already a standalone project? Does seeing any of these (some twice) provide any value to the user? Maybe I'm missing it...

[kjsmita6]

As @mickaelistria said, this is probably a platform problem. I believe it works like this. Say you have a project structure like this, where Main is a multi-module Maven project and sub1 and sub2 are its modules (also Maven projects):
Main
--- sub1
--- sub2

Eclipse will display them in the package explorer like this:

(note that the project explorer seems to display them correctly)

Since each project has two copies of target/ in the workspace, with only one of them marked derived, the non-derived one will still show results in the search.

Maybe this is "fixed" by removing the aggregator project from the workspace?

[sorin-costea]

@kjsmita6 indeed that makes sense. I also most of the time don't import the parent project in the workplace, or sometimes use the AutoDerive Eclipse plugin and handle stuff by hand in .derived. So I have my acceptable workaround, but just wonder why the platform reasons like this.

[mickaelistria]

Nested projects are the root of many evils in Platform ;) They basically duplicate resources in the model and these resources, although they link to the same file can have different state/metadata. This is particularly useful in some (relatively rare case) where some build execution happen on different levels and having different metadata do allow to have some files ignored for one builder but not for the other.
I don't think there can be a clean solution as long as JDT requires nested projects to function well with multi-modules unfortunately.