You are viewing a plain text version of this content. The canonical link for it is here.
Posted to notifications@netbeans.apache.org by GitBox <gi...@apache.org> on 2019/07/29 08:37:44 UTC

[GitHub] [netbeans] JaroslavTulach commented on issue #1403: [NETBEANS-1802] Basic infrastructure to load a project with a Project Type

JaroslavTulach commented on issue #1403: [NETBEANS-1802] Basic infrastructure to load a project with a Project Type
URL: https://github.com/apache/netbeans/pull/1403#issuecomment-515900371
 
 
   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".

----------------------------------------------------------------
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.
 
For queries about this service, please contact Infrastructure at:
users@infra.apache.org


With regards,
Apache Git Services

---------------------------------------------------------------------
To unsubscribe, e-mail: notifications-unsubscribe@netbeans.apache.org
For additional commands, e-mail: notifications-help@netbeans.apache.org

For further information about the NetBeans mailing lists, visit:
https://cwiki.apache.org/confluence/display/NETBEANS/Mailing+lists