| Re: [lsp4e-dev] Project types with LSP4E |
_______________________________________________I am quite happy with the idea that project natures (sorry I used the wrong terminology before) are a thing of the past.
My question arose because I imported a project which had been built using the ScalaIDE which provided a nature into an eclipse installation which did not have support for that nature, and so complained - only a warning, but still mentioned in the error view and I am one of those who like to eliminate all warnings as well as errors.
Firstly there is a mindset that has been embedded in Eclipse users (at least this one) that natures are good, and should be used. In this respect a reassuring note that with LSP they are obsolete (maybe a bit strong) would guide people into the nature free LSP world.
Secondly in the past there were ways of changing the nature of a project, but only in selected and special places. Maybe this only needs to occur in the case of an Import rather than a do-it-anytime option, but an option that says I am importing this project, forget the old nature, would be a good idea.
David
On Tuesday, 24 September 2019 07:58:24 BST Mickael Istria wrote:
Hello,
In general, it's not the role of LSP4E to "type" the projects (ie add nature). LSP4E works perfectly without natures, and adding a requirement on a nature would drastically increase the usage complexity and the maintenance code. It's basically not desirable for LSP4E to rely on project natures when just using file locations (as it does now) brings much more usability (support for files outside of workspace or in any kind of projects) without extra effort.
In case some specific project need some specific nature, it's the duty of the LSP4E "consumer" to ship the necessary code in their plugin to define the nature and use it.
In this case, the Metals plugin is where support for a Metals nature and some Bloop actions should be developed, as they're not at all related with LSP4E, but more to other project management features.
Now, independently of LSP4E, I'd like to raise a question: why even typing projects statically with natures? Which features of it do you want to bring for your use-case? In Wild Web Developer, we've rejected the idea of natures, and by using "dynamic" check (existing marker file, or file extension or whatever...) we can have the right action available at the right place, and the result is much easier to use than forcing users to go through specific wizards to enable some features on the code they import.
lsp4e-dev mailing list
lsp4e-dev@xxxxxxxxxxx
To change your delivery options, retrieve your password, or unsubscribe from this list, visit
https://www.eclipse.org/mailman/listinfo/lsp4e-dev