search

devonfw / dashboard

devonfw dashboard
Apache License 2.0
5 stars 17 forks source link

Mismatch of projects vs workspaces between devonfw ide and dashboard #94

Open maybeec opened 4 years ago

maybeec commented 4 years ago

Describe the bug In devonfw ide, there is a concept of workspaces, whereas there can be multiple workspaces per installation and multiple projects per workspace. At the moment, creating a new project would create a new workspace in devonfw ide, which finally leads to the fact, that update all workspaces will create eclipse settings files and temporary data into the projects git repository.

To Reproduce Steps to reproduce the behavior:

  1. Go to Projects in Dashboard
  2. Create new Project
  3. Run devon eclipse ws-up
  4. See files in project folder

Expected behavior On creation of Projects you need to decide in which workspace to place it. A workspace is simply a folder. You can even allow the user to create a new workspace with the same name of the project, which will be done by the dashboard automatically.

Furthermore, projects should be discovered within all workspaces folders.

hohwille commented 2 years ago

There is a clear hierarchy that should also be reflected by devonfw-dashboard and brought to the end-user:

  1. devonfw-ide Installation (${DEVON_IDE_HOME}) - this is already addressed somehow in the select box at the top bar of dashboard. BTW: To create a new installation meanwhile devonfw-ide has the command devon ide create and dashboard could offer a button to add a new installation. This is actually what end-users would call a "project" or even "engagement" they "are working in". IMHO the user should have different role per IDE installation. So for one he could be "admin" and for the other one he could be "developer". Depending on this choice, the dashboard should behave differently. E.g. "admin" should get notified when tools could be updated because newer releases are available, etc. what does not make sense for "developer" who has to follow what "admin" has configured. Please note that a project can decide if every team member is "admin" (agile, smaller teams) or if only one or two experts have the "admin" role (large teams, command&control) and actually access to commit changes to the settings git repo.
  2. workspace (${WORKSPACE}) - by default main but user can create as many workspaces as he likes. So a second hierarchy should be visualized by devonfw-dashboard. Features like launching Eclipse/IntelliJ/VSCode depend on the workspace selected. User should have the option to create a new workspace (technically only mkdir workspaces/«workspacename»).
  3. sub-projects/repos within a workspace users can have "folders" that are typically technical git repositories. This is what is currently called "project" but confuses with 1. - also Eclipse and Maven has the term of "project" but what we have here on level 3 may be a maven-multi-module build resulting in multiple projects to make the confusion complete. Also worth to notice that I would call this level 3. asset a repository. FYI: devonfw-dashboard already has something build into the menu called "repositories" what lists devonfw repositories on github. I personally would remove this feature and do not clearly see why this was build into devonfw-dashboard.

IMHO we first need a kind of UX session where we come to a new UI design how to address there three levels in an intuitive way for end-users. This can make use of tabs, drop-downs, menus (flat or hierarchical), etc. But only if we first think how to address the whole picture we should actually build something.