Make a View that Shows Folders, not Projects

[tsmaeder]

The API to handle code in Eclipse is the IWorkspace and it's associated IResource management API. It contains a flat list of projects that Eclipse is aware of. The problem with this approach is that you always have to set up Eclipse metadata (.project) in the folder even if you just want to view a folder.

My idea would be to create a view that you can add root folders to (akin to what IDE's like VS Code do). Any folders containing a .project file would be added to the IWorkspace and would be visible as projects through their icon annotations. For other folders, the user might get a UI that prompts to create Eclipse projects from the folder where appropriate (for example, those containing pom.xml or package.json).

Many project build systems (maven, npm) use folders containment on disk as an organizing principle. The "folders" view would support that kind of organisation better.

[mickaelistria]

FWIW, the idea of multiplying navigators doesn't sound good to me. We've been working on the problem of "there are too many navigators" for several years, and your proposal to add on seems contrary to the goal. Moreover, there are already plugins allowing FileSystem navigation. Multiplying the view does require to multiply maintenance as it multiply similar workflow, similar needs for customization, and so on...
Also, are you using Project Explorer with Hierarchical project view? It does cover a file system view of a project decently, in a non-flat mode.

The API to handle code in Eclipse is the IWorkspace and it's associated IResource management API. It contains a flat list of projects that Eclipse is aware of. The problem with this approach is that you always have to set up Eclipse metadata (.project) in the folder even if you just want to view a folder.

If creating .project is a problem, then we should instead fix the issue of allowing .project to not be stored in the folder but instead in workspace metadata. That would fix a lot of other stories by the way.

My idea would be to create a view that you can add root folders to (akin to what IDE's like VS Code do). Any folders containing a .project file would be added to the IWorkspace and would be visible as projects through their icon annotations.

You don't need an extra view for that; one could for example create an "External folder" project and use linked resources to present a view of some external folders.

For other folders, the user might get a UI that prompts to create Eclipse projects from the folder where appropriate (for example, those containing pom.xml or package.json).

That's already what happens when you do File > Open Projects from File System... However, this would create a .project for the root folder, which brings us back to the idea of not creating .project inside projects.

[laeubi]

If you use the Project Manager View and add a simple .project file to the folder you like as your root you can import that folder and get what you want (beside automatic project import what you can do with 'search for nested projects').

If you really like something like a System Explorer that would not have anything to do with the IWorkspace.

[tsmaeder]

You don't need an extra view for that; one could for example create an "External folder" project and use linked resources to present a view of some external folders.

I think you're underestimating the height of my ambition ;-). Currently, the primary UI concept that we're showing in the navigator is the eclipse workspace. I suggest making the file system the primary thing and the workspace an implementation detail. I would suggest that the concept of a workspace with a flat list of projects (yes, I'm aware of the hierarchical mode, but that's a workaround, really) is one of the weirdest things for people not familiar with Eclipse.

[tsmaeder]

If you use the Project Manager View and add a simple .project file to the folder you like as your root you can import that folder and get what you want (beside automatic project import what you can do with 'search for nested projects').

I'd rather not impose on people in this way to just view a folder.

If you really like something like a System Explorer that would not have anything to do with the IWorkspace.

Absolutely, it would not (directly, anyway)

[laeubi]

I'd rather not impose on people in this way to just view a folder.

you only need one project in the "root" (whatever seems suitable for your... User home?) then you can navigate anything below it.

[laeubi]

Absolutely, it would not (directly, anyway)

Also not indirectly :-)

The workspace is not imported folders, it is about imported project (from anywhere on disk or even virtual on remote file systems) if you "autodetect" projects and show then as such there is no need for a Workspace anymore.

By the way I find this the most powerful feature of eclipse and even if people often complain about the project files it is much more powerful and convenient as idea / vscode handle this where the assume I put all my stuff into one folder and that I'm happy with losing all project settings when switching to a different computer :-)

[mickaelistria]

I suggest making the file system the primary thing and the workspace an implementation detail.

That's IMO a bad idea. The workspace is a projection of the filesystem, an interesting subset. The projection and intentional exclusion of some content does map the idea of a project that allow developers to keep focus.

I would suggest that the concept of a workspace with a flat list of projects (yes, I'm aware of the hierarchical mode, but that's a workaround, really) is one of the weirdest things for people not familiar with Eclipse.

If you want things to be flat and still work, the real issue to work in is in JDT: JDT is the reason why we have nested projects, why things that were hierarchical on filesystem appear as Flat on the workspace, the reason why we have the Hierarchical project view as workaround, the reason why we have duplicated resources in some views an dialogs... because it does require multiple projects in order for it to be capable of dealing with multiple classpath or settings, and isn't able to work well with multiple modules without different projects. Remove this constraint from JDT, and you won't need nested projects and everything can then more easily be flat.
FWIW, JS or Rust projects do not require nested projects and the filesystem view of the folder is really sufficient, because the LS does the stuff to separate context internally without it surfacing on the workspace.
JDT should learn from it, and then no issue with hierarchical/nested projects. Basically, JDT should be able to load an IJavaProject and Java settings without requiring an underlying IProject...

[laeubi]

Basically, JDT should be able to load an IJavaProject and Java settings without requiring an underlying IProject...

But m2e does suffer from the same isn't it? Beside that hierarchical projects work quite well for me with some flaws (more related to markers/search but that's not JDT to blame here I think) so whats the problem with it?

[merks]

You can get a folder view of anything just by linking the folder into any project:

You can also create virtual resources of any type using EFS:

https://wiki.eclipse.org/EFS

With go into you can see just the folder:

I'm doubtful a new view would be all that useful, thought EGit has such a think already too:

[tsmaeder]

If you want things to be flat and still work, the real issue to work in is in JDT: JDT is the reason why we have nested projects, why things that were hierarchical on filesystem appear as Flat on the workspace, the reason why we have the Hierarchical project view as workaround, the reason why we have duplicated resources in some views an dialogs...

Only it's not just JDT, but also npm, for example. I would argue that most build systems that have a notion of "submodule" rely on folder containment (even if implemented with symlinks). Why fight it?

I agree that maybe maybe the java project model does not need to be isomorphic to the workspace model. But that's a different discussion.

[laeubi]

Fight what? No one is fighting anything here?

[mickaelistria]

npm, for example

That's a good example: for npm, Wild Web Developer doesn't require 1 folder per module, doesn't set a nature, yet people can configure things (via standard npm files) and launch things (via standard npm commands).

What you suggest as a new view is more a workaround for the real problem that is that workspace does allow nested projects; and that nested projects have bad implications on usability (and even performance). Remove the need for nested projects (eg fix JDT design), and you hav fixed the usability issues.

But m2e does suffer from the same isn't it?

m2e kinds of maps to what JDT does, and also needs to fight with resource duplication. But that's nothing we can't fix.

In any case, I think adding a new view would be harmful to the Eclipse Platform as it doesn't fix any issue, adds more maintenance and complexity in term of UX (more views => more pain), and distract from fixing the root causes of issues.
An option to import wizards allowing to choose whether to import a folder as a new project or as a linked resource in some other project (eg "External Folders" as suggested by me and @merks ) would be a good addition though.

[laeubi]

An option to import wizards allowing to choose whether to import a folder as a new project

File > New > Project

the Uncheck the default location and select the folder... For sure something that could also be added as an "Import" action like Import > Folder as project with simply projectname -> foldername

[vogella]

A easier way to work on a folder structure directly in Eclipse would be nice. I agree that creating a new view would not be helpful.

For sure something that could also be added as an "Import" action like Import > Folder as project with simply projectname -> foldername

That would be a really nice improvement.

[vogella]

@tsmaeder I'm closing this one, if you plan to enhance the Project Explorer please open new issue or provide PR