Skip to content

[NETBEANS-1802] Basic infrastructure to load a project with a Project Type #1403

New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Open
wants to merge 3 commits into
base: master
Choose a base branch
from

Conversation

lkishalmi
Copy link
Contributor

Well this would be a possible start of a long journey. To make folders which has multiple build flavors be loaded as a specific project. Please check the code it should be backward compatible.

@lkishalmi lkishalmi added work-in-progress API Change [ci] enable extra API related tests do not merge Don't merge this PR, it is not ready or just demonstration purposes. labels Jul 28, 2019
@JaroslavTulach
Copy link

Yes, with the growing number of cases where people mix various build technologies into the same directories, it is becoming more and more clear that the NetBeans system of one project type per directory doesn't fit many real world projects anymore.

My friend told me two months ago about his struggle with a project combining package.json and build.gradle. I wanted to help him with a "Multi Project" module. The idea was to create a decorator Project implementation that would delegate to all the other Project implementations that can physically recognize and handle the same directory. When user invokes build - it would invoke build via NPM and also via Gradle. The logical view would be merged. Queries like classpath would be delegated to both projects and their result merged as well.

Of course, this is not always what the user wants, so I was thinking of a UI that would allow the user to select the (set of) project(s) to delegate to. E.g. user could choose that only Gradle is preferred and the IDE should only invoke Gradle actions. Later, the user could switch to NPM view and work with the project only from the node.js perspective, completely ignoring Gradle.

Such "Multi Project" would implement "natures" in a reasonably natural way. "natures" - e.g. the current Project implementations would completely care about their physical representation on disk and physical commands to execute. The "Multi Project" would be just the UI to control & delegate to the "natures".

As far as I can tell @lkishalmi attempt is heading in the same direction. Just it starts with API change, I wanted to prototype the solution from outside. Solving the problem may turn into significant effort and having the ability to offer it as an extension module could help us get some user feedback before we change such a core functionality of the IDE. Ideally, once we succeed, all Project instances obtained from ProjectManager would be instances of the "multi project".

Btw. let's CC @jglick - he introduced the ProjectManager and fought hard against "natures".

@jlahoda
Copy link
Contributor

jlahoda commented Jul 29, 2019

I am afraid I am not sure how exactly this patch should help? Projects are often through the FileOwnerQuery, which does not know currently which type of project it is trying to load.

When I was thinking of this, I was imagining two possible approaches:

  1. a Multi Project similar to what @jtulach was proposing. Could work when the two projects merged into the Multi Project are sufficiently different (like possibly Java Gradle and NPM). Unlikely to work for two Java projects, but that is presumably fine. Maybe we would have a Multi Project that would allow only such combinations of projects that are known to work. This could be prototyped as an extension module.
  2. have an action that would tell the project infra to recognize the given directory as a project of a particular type, and ignore all rest. Probably not reasonably doable as an extension module, but possibly also simpler to do.

I think that the code here might be to some degree useful for either of these, but details on what is needed will likely be more clear only when the actual UI so this is implemented.

@lkishalmi
Copy link
Contributor Author

Well, this patch is just a very first step. I'm planning to add some others down on the road, I just would like it to be visible from the start, to be able to talk this through as a process not just one big change.
@JaroslavTulach Unfortunately my direction is not that far reaching. Having general project with natures seems to be a compelling idea, though that would be a big step to jump. I'm not sure if I can make that jump happen. Though if anyone could deliver that, I would happily ditch this set of patches in favor of that. So I'm not trying to reaching that high.
So my plan is to try something built on the current ProjectFactory2 and ProjectManager.Result. My steps would be:

  1. Enhance the PM API to be able to query/load Project "natures" recongnized by the IDE.
  2. Improve the isProject2 usage to actually return project type
  3. Add an Open Project As action if more than one project "nature" is detected on a folder.
  4. Fix: There could be some glitches around re-opening the projects.
  5. Probably add more UI entry for the project "nature" selection

I have something half working on 3., but need to do some real work on 2.

@Chris2011
Copy link
Contributor

Chris2011 commented Oct 28, 2019

What is the progress of this PR here and how can I help here?

@lkishalmi
Copy link
Contributor Author

Well, it is hard to say. It requires some dedication and coordination. Right now we have a ProjectFactory2 interface to implemented by project providers, but most projects do not even implement ProjectFactory correctly. This is easily fixable for Maven and Gradle projects, but the others needs some serious attention.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
API Change [ci] enable extra API related tests do not merge Don't merge this PR, it is not ready or just demonstration purposes. work-in-progress
Projects
None yet
Development

Successfully merging this pull request may close these issues.

4 participants