minimize setup by reducing DEVON_IDE_TOOLS

[hohwille]

The setup of devonfw-ide should be fast for better UX.
Therefore we should remove tools that need longer downloads and installation for the default tools:

ide/scripts/src/main/resources/scripts/devon.properties

Line 7 in f03a588

DEVON_IDE_TOOLS=(java mvn eclipse vscode node npm ng)

All tools are always available via lazy initialization if not explicitly configured in DEVON_IDE_TOOLS.
The only benefit of having a tool in DEVON_IDE_TOOLS is that the tool is immediately there and you could even get offline.

However, the drawback is that it takes very long to setup a vanilla devonfw-ide and new users might think "WTF is going on?"
As people tend to become more and more impatient we should consider reducing this to the minimum.
I would at least kick out:

• Eclipse
• VSCode
• maybe even ng

We could even be radical and make the list empty by default.

Please note that any project is still free to customize this DEVON_IDE_TOOLS to their own needs. However, with the default settings, we do not know what is the use-case of the user. Will he need java or node.js tooling at all?
Preinstalling this therefore seems annoying and waste.

[hohwille]

One thing to consider is that the launch scripts like eclipse-main.bat are currently only created if the according IDE (in this example eclipse) is listed as tool. I never use them as users can simply run devon eclipse to lauch eclipse but newbe users might not be familiar with command shells and will be lost. We should consider still having such launch scripts generated on setup but downloading and installing the IDE on the first launch.

[maybeec]

Actually, I would like to get a clean vanilla devonfw ide not installing anything besides extracting the scripts by default.

To anyhow provide valuable tools to handle bulk installing without the need to actually do installation step by step again based on any project tutorial, I would like to propose a slide adaption to the current possibilities of handling software configuration.

I loved the idea of oomph having a basic eclipse only, possibly even vanilla and let the project decide what is needed for development.
E.g., imagine we introduce something like software dependencies for project. Meaning that in the project configuration, you could think of another property software: (eclipse, maven, java)

Then devon project setup projectname (not 100% sure about the command) would also lead to automatic installation of the software needed for development.

Thus (as we are just talking about the devonfw space having this problems), you could start with vanilla and simply saying which project you want to work on, you would get the necessary tools installed without the need to think about it.

[hohwille]

@maybeec thanks for your feedback. If I got it correct we both want the same goal to minimize the default setup.
A few things to be aware of if we do this radically:

# setup.bat (or ./setup)
# mvn
command not found

WTF? Shitty devonfw-ide
Where is my eclipse-main.bat? Shitty devonfw-ide...

So what is easy for us might be quite confusing for others, newbees or existing users that got used to specific things.
As we still use maven and npm in many if not most of our projects, I am still concerned if we should kick them out as well.
Why dont we go this step by step? So first kick out the big things that really slow down the setup (eclipse, vscode) and then collect further feedback before we kick out all tools by default?
And IMHO we can still generate the eclipse-main[.bat] and vscode-main[.bat] by default that will however not install these IDEs but just delegate to the devon command to launch the IDE that already performs the download and installation if not already present.

For your suggestion I am not convinced about the idea:
The philosophy is that devonfw-ide is a generic tool to automate the IDE installations. It does not know about any project and what users of such project need. Instead anybody or any project can create their own git settings repo where they have the freedom to decide whicht tools they need, in which version and with which configuration.
So instead of building any such knowledge into devonfw-ide we can rather fork ide-settings repo to have some variants like java/devon4j project, ts/devon4ng project, test/MrChecker, etc.
I would have already done this but I was scared about maintenance efforts...