IDEasy requires settings with configuration templates for the arbitrary tools.
To get an initial set of these settings we provide the default ide-settings as an initial package. These are also released so you can download the latest stable or any history version at maven central.
To test IDEasy or for very small projects you can also use the latest default settings:
ide create «project-name» -However, for collaborative projects it is important that you create settings specific for your team via a dedidcated git repository.
This gives you the freedom to control and manage the tools with their versions and configurations during the project lifecycle. To setup and customize these settings simply follow the admin usage guide. Then tell your team to create the project using your project sepcific settings git URL:
ide create «project-name» --code «settings-url»It is even possible to include your settings into your code repository by having the settings folder directly on top-level of your code git repository.
This allows you to keep settings changes in sync with code changes and manage them in the same pull/merge requests.
To use this approach simply copy the content of ide-settings to a top-level settings folder in your code repository root and tell your developers to create the project usining the --code option:
ide create «project-name» --code «code-repo-url»IDEasy will clone your repository and create a symlink to the settings folder. Changes to settings can then be committed alongside code changes.
However, please note that the "settings in code repository" approach is not recommended (happy path) and has the following disadvantages:
-
Code repositories have their own CI and review process and it is typically more hard and slow to incorporate changes.
-
Code repositories are typically big and need more time to clone. IDE admins that frequently want to test changes to the settings on feature branches via
ide create …will have to wait longer and might be annoyed. -
In real life you typically work with multiple code repositories (frontend/backend, microservices, libraries, …) but you want to have consistent IDEasy settings for that or at least an N:M mapping between code-repos and settings. With the regular approach you simply have more flexibility and are better prepared for future changes.
-
With the regular approach (standalone settings repo) you can upstream merge changes from our central ide-settings to keep up-to-date and reduce maintenance overhead. With settings in code repository approach this is not working well.
But we do not want to forget the following advantage:
-
With settings in code repository you can easily create consistent feature branches where you change code and IDEasy settings together (e.g. java major upgrade in
pom.xml,ide.properties, etc.). Anyhow you can still create feature branches in standalone settings repositories to manage such scenarios and follow KISS and trunk-based development so you more or less avoid such problems. However, if you are in a monolithic project with complex release branches you may consider using the "settings in code repository" approach.
The settings folder has to follow this file structure:
/settings ├──/ templates │ ├──/ conf │ │ ├──/ mvn │ │ │ ├── settings.xml │ │ │ └── settings-security.xml │ │ ├──/ npm │ │ │ └── .npmrc │ │ └── ide.properties ├──/ eclipse │ ├──/ workspace │ │ ├──/ setup │ │ └──/ update │ ├── lifecycle-mapping-metadata.xml │ └── project.dictionary ├──/ intellij │ └──/ workspace │ ├──/ setup │ └──/ update ├──/ vscode │ └──/ workspace │ ├──/ setup │ └──/ update ├──/ repositories │ ├──/ ... │ └──/ README.adoc ├──/ ... ├── ide.properties └── welcome.txt
As you can see, the settings folder contains various configurations to customize IDEasy to your project needs.
The key configuration is the top-level ide.properties file.
The template folder contains templates that will be applied to $IDE_HOME and therefore allow to define the initial content of the conf folder with the defaults for the developer specific configuration (e.g. settings.xml and ide.properties).
Further, for the IDEs such as Eclipse, VSCode, or IntelliJ the according folders contain the templates to manage the workspace via our configurator.
Different tools and configuration files require a different handling:
-
Where suitable, we directly use these configurations from your
settings(e.g. foreclipse/lifecycle-mapping-metadata.xml, oreclipse/project.dictionary). -
The
templatefolder insettingscontains templates for configuration files. They are copied to theIDEasyinstallation during setup (if no such file already exists). In this way thesettingsrepository can provide reasonable defaults but allows the user to take over control and customize to his personal needs (e.g..m2/settings.xml). -
For tools with complex configuration structures like Eclipse, IntelliJ, or VScode we provide a smart mechanism via our configurator.
You can easily customize these settings for the requirements of your project. We suggest that one team member is responsible to ensure that everything stays consistent and works. However, every team member can contribute changes as pull-/merge-requests.
You may also create new sub-folders in settings and put individual items according to your needs.
E.g. you could add scripts for greasemonkey or tampermonkey, as well as scripts for your database or whatever may be useful and worth to share in your team.
However, to share and maintain knowledge we recommend to use a wiki.
Simply add a file welcome.txt (or any other textual extension like adoc or md) to the root of your settings repository.
The content of this file will be displayed as plain text to the end-user after creating a project from your settings with IDEasy (ide create «project-name» «settings-url») in order to welcome the user.
This is very helpful both for a warm welcome of your developers as well as for further project specific details such as internal wiki links or specific scripts or commands.