• Build with GitHub actions
• Code quality with codacy
• Security with snyk.io
• CodeQL

Feature request

If the progress dialog ends on an error for any of the commands, it would be good for the UX that the tabs are sorted so the first ones are the failing ones, so the user can quickly check what was wrong.

Feature request

Once #22 is in place, a preference page for system settings should be implemented and should include the Theme section instead of the menu.

Feature request

Expected Behavior - What were you expecting to happen?

Some projects/environments might not require an eclipse configuration (e.g., if a thirdparty plug-in or eventually a core one provides a different way to open the workspace, or a workspace is not required).

Current Behavior - What happens?

If Eclipse plug-in is provided, all environments/projects provide the launcher(s) even if they are not relevant nor configured.

Possible Solution

1. Filter for projects/environements IDs provided on the eclipse config
2. Rely on the oomph setup files (project catalog) and if not present does not show the Eclipse launcher

Context

Configuration for extension plug-in

Feature request

Expected Behavior - What were you expecting to happen?

Create a new menu to clean the obsolete (not configured anymore) environments, removing the worktrees and internal branches.

Current Behavior - What happens?

No way to cleanup environments that are not configured anymore.

Possible Solution

There is already code to handle obsolete environments in the core. The feature should provide an UI to access that functionality and rework whatever is need it.

Feature request

A JIRA extension should be provided to connect to different JIRA instances and return feature-branches based on the tickets.

Bug report

Expected Behavior - What were you expecting to happen?

On refresh, the application should be closed if the state of the same is wrongly configured or not following the HOCON format.

Current Behavior - What happens?

Nothing is communicated to the user nor the application crashes.

Possible Solution

Create a handler for exceptions that should close the application for critical/fatal exceptions.

What are the steps to reproduce this issue? (for bugs)

1. Start GEM with correct configuration
2. Remove and/or rename a repository ID without changing branches for an environment
3. Refresh GEM -> application is still working without updated configuration
4. Close GEM and re-start -> application does not start due to wrong configuration

Context

This is important for the use-case of git-configuration that somehow gets corrupted. Users should be informed so the configuration managers should update as soon as possible.

Any logs, error output, etc?

The logs contain the exception and stacktrace, but nothing is shown to the user.

Your Environment

• Version used: > 0.3.0
• Operating System and version (desktop or mobile): Windows

After the first cleanup of obsolete environments, when the dialog is opened again without closing GEM, the obsolete environments are still shown.

Bug report

Expected Behavior - What were you expecting to happen?

No already successfully removed obsolete environments present on the dialog.

Current Behavior - What happens?

Removed environments are still shown (and kept on the cache of identified obsolete environments).

Possible Solution

Handle properly the cache of obsolete environments, so when removed they are also removed from the cached list.

What are the steps to reproduce this issue? (for bugs)

On a GEM state with obsolete environments:

1. Select the menu ' Clean' -> 'Obsolete Environments'
2. Perform a clean of one or several obsolete environments
3. After the cleanup, close the progress popup
4. Select the menu ' Clean' -> 'Obsolete Environments' again
5. The list of obsolete environments still contains the removed one

Your Environment

• Version used: Any > 0.3.0
• Operating System and version (desktop or mobile): Windows

Feature request

The GitHub extension should provide a way to connect with GitHub issues to provide feature branches based on them.

Feature request

Expected Behavior - What were you expecting to happen?

This feature should be for the core framework for preferences. With this ticket a simple preference to switch/change the log-level for both GEM and third-party ones should be implemented.

Current Behavior - What happens?

Current framework for preferences is not used and not flexible enough, as it is just a draft. The solution to this issue should be also a draft but more refined as it might be changed when UI for preferences is implemented. By now, it should be usable so the file-based configuration can be edited by hand and the preferences being picked up.

Possible Solution

The preference framework should contain:

1. Preferences for the core and also plug-in specific preferences, stored as a HOCON config on the GEM application folder to be consistent with our file-based config structure.
2. A way to communicate plug-in preferences to the UI the different kind of preferences to display properly (the UI part should be a different feature request). A new provider should be available to configure preferences.
3. Resolution of preferences should use also the configuration, so plug-ins can request preferences instead of configuration for their plug-ins. This will also make more flexible the framework so for example for the new JIRA plug-in (see #3) some JQL parts can be part of the preferences (e.g., user-name on JIRA).
4. A way to set by default some preferences values with the configuration and/or programatically.
5. New configuration entry for framework that allows to include on the configuration resolvable preferences not determined by source code (e.g., the user-name for JIRA).

Context

The context is to enable user-preferences at the core level (not UI) to allow user-input on the behavior of GEM core and plug-ins.

Notes and further information

Follow up this ticket the UI counterpart should be created (see next ticket).

Feature request

Expected Behavior - What were you expecting to happen?

A new IGemService for creating several services of one kind with the configuration (e.g., on #3 we can have several Feature Branch Providers (FBPs) for different JIRA instances).

Current Behavior - What happens?

Defined IGemServices are exclusively providing a single instance, which does not allow to configure something like the same FBP with different configurations at the same time.

Possible Solution

Implement a new service (IGemServiceCreator) where services of the same time are created.
The IServiceContainer should handle them and provide services as if they were independent.

Context

See #3 for an example use-case.
It can also be useful for github.com and enterprise instances running on internal networks.

Feature request

Expected Behavior - What were you expecting to happen?

The extension to sort environments/projects should also allow to sort Feature Branch Providers (FBP) as there is no control on how are they are shown to the user for third-party tools.

Current Behavior - What happens?

The implementation of the sorter made on #18 is not complete in terms of what can be sorted by a third-party plug-in.

Possible Solution

Add a new method to the sorter and a default implementation (sort order by ID and/or name, but first the configured default provider).

Feature request

Expected Behavior - What were you expecting to happen?

Currently, if on the Project dropdown the environment have a counterpart on the Environment dropdown, the second should be preserved on project selection. For example, imagine 2 projects called GEM and the other Custom GEM, both with environments v1 and v2. If GEM / v2 is selected, and then the project is switch to Custom GEM, the Environment should be kept to v2.

Current Behavior - What happens?

Currently, in the previously described example, on project selection for Custom GEM the Custom GEM / v1 environment is selected. Although for some use cases it makes sense that this happen, it might be that the version number for 2 different projects have nothing to do with each other so jumping to the first project is the correct solution. This should also be taken into account for the possible solution.

Possible Solution

The solution is simple as keeping the environment if it exists by comparing the environment ID might be easy. This will enforce configurations to keep the same ID for the environments if they want to enable this behavior for some of them and/or prefix the ID if they want to keep it independent.

Context

User experience. E.g., in the case of related projects with similar versioning this makes sense for the user that otherwise is jumping always to the upper version of an environment.

Notes and further information

Low priority as it doesn't affect important behavior but user-experience on a use-case of configuration of projects/environments.

Feature request

The Combo for feature branches is really small, difficult to scroll. The combo popup should be enlarged that users see more than only 3 entries (e.g. up to 10 entries without scrolling).

Expected Behavior - What were you expecting to happen?

Combo popup should be enlarged to e.g. 10 entries without scrolling

Current Behavior - What happens?

Only 3 entries are shown. The other entries requires the usage of scrollbars.

Context

Feature branch combo contains 4 entries. The combo popup is only 3 entries high.

A github workflow to create the release and attach the binaries on merge for that branch would be useful to make the release process easier for developers.

In addition, we can create a main version that gets updated with each PR so the latest non-stable version is created to be tested by users and/or be used as a source for building other products (e.g., create on release also a zipped p2 repository).

Feature request

Expected Behavior - What were you expecting to happen?

A plug-in should be able to provide a extension to sort the returned lists of IEnvironment and IProject from the ICongiguration getters.

Current Behavior - What happens?

Currently the list of environments is sorted with Comparator.reverseOrder(), which is taking the comparison of the environment ID to sort them. For the projects, when loaded with a Stream, the sorted() method it is used (also using the project ID).

Possible Solution

Introduce a IGemService to perform the sorting of those objects (and maybe other in the future if required for the display of them), that should be provided only once to the gem product (e.g., on its own plug-in). By default, if not provided a default sorter should be there with the current behavior.

Bug report

The CommandProgressDialog does not scale with lots of commands, cause the cli-like view is too small and the list goes out of the dialog range so the information is not visible to the user.

Expected Behavior - What were you expecting to happen?

The progress dialog should be usable for cases with any number of commands to run.

Current Behavior - What happens?

As the number of commands increase, little space is left for the actual information of the run command.

Possible Solution

There are several solutions for this:

1. Scrollable composite for the part that shows all the commands cli-like view.
2. A different type of dialog (e.g., show the cli-like view on a different dialog if the user wants to see it), either for all cases or for the ones with more than X number of commands to run.

What are the steps to reproduce this issue? (for bugs)

On a GEM state with a lot of obsolete environments:

1. Select the menu ' Clean' -> 'Obsolete Environments'
2. Perform a clean of all the obsolete environments
3. The progress dialog is not showing anything on the cli-like views and some of the removed environments is not even shown.

Context

This will happen with lots of obsolete environments as in the steps for reproduction, but also in the case of a configured environment with lots of repositories.

Your Environment

• Version used: > 0.3.0
• Operating System and version (desktop or mobile): Windows

Bug report

Expected Behavior - What were you expecting to happen?

On menu refresh, new configuration should be picked up and updated.

Current Behavior - What happens?

On menu refresh, the configuration is not updated. It requires a second refresh to do the job.

Possible Solution

Workflow on session refresh should be properly done (broken with #29)

What are the steps to reproduce this issue? (for bugs)

1. Start GEM
2. Change configuration manually (e.g., remove an environment)
3. Refresh GEM -> removed environment is still shown.

Your Environment

• Version used: > 0.3.0 (with #29)
• Operating System and version (desktop or mobile): Windows

Notes and further information

Also related with #37 (blocked cause the first refresh is not happening anyway)

Provide information to the user when any of the chosen obsolete worktree failed to launch the removal.

Bug report

User not informed if removal of any of the worktree failed to launch

Expected Behavior - What were you expecting to happen?

Should inform user about any failed worktree removal

Current Behavior - What happens?

No information provided to user

Possible Solution

Provide the information to the user via dialog

What are the steps to reproduce this issue? (for bugs)

Context

Any logs, error output, etc?

Your Environment

• Version used:
• Environment name and version (e.g. Chrome 39, node.js 5.4):
• Operating System and version (desktop or mobile):

Notes and further information

Feature request

Expected Behavior - What were you expecting to happen?

Remove Branch button should be enabled for existing branches (not default ones), without checkout to another branch beforehand.

Current Behavior - What happens?

The deletion of branches in the UI currently requires:

1. Have a clean worktree (to allow checkout)
2. Checkout a different branch
3. Select (without checkout) branch to delete
4. Use the Remove Branch button (inactive until now)

Possible Solution

Remove Branch button should checkout the default branch if it is the current branch. This requires a decision of what to do with "dirty" worktrees, so a popup to the user should be shown ask if everything should be deleted or if they want to abort the deletion.

Context

User experience.

Notes and further information

None

Bug report

Expected Behavior - What were you expecting to happen?

No error when switching to an environment where not all repositories are cloned.

Current Behavior - What happens?

Workflow exception appears on popup (only on development version).

Possible Solution

Fix GemDefaultWorkflow on the related launcher.

What are the steps to reproduce this issue? (for bugs)

1. Switch to an environment where one of the clones is not available
2. Exception appears related to workflow exception (not cloned repository)

Context

This error does not happen in the release version but in the current mainone.

Any logs, error output, etc?

Your Environment

• Version used: alpha version
• Environment name and version (e.g. Chrome 39, node.js 5.4): latest version from GEM
• Operating System and version (desktop or mobile): Windows

Notes and further information

None

Feature request

Expected Behavior - What were you expecting to happen?

When the oomph project catalog is not containing an identifiable one to be assigned to a GEM project or environment, then the launcher should be disabled as it is a configuration problem, or a misconfigured-launcher should be present to show the error and communicate to the config managers to be fixed.

Current Behavior - What happens?

Currently (v 0.3.0), if the project ID is not present on the oomph project catalog the launcher fails with an exception. This is rather a configuration problem than a launch error, and should be handle properly.

Possible Solution

1. Check the project catalog on canLaunch to disable it in case that the configuration is not present
2. Does not provide any Eclipse launcher for an environment if it is not found on the project catalog
3. Provide a misconfigured launcher to show to the user that Eclipse is not configured for that project

I personally prefer 2 as it is possible that an environment is not present cause that environment does not support the Eclipse launch; also the first one is possible in case that a filter for those use cases is provided (see #42).

Bug report

Expected Behavior - What were you expecting to happen?

The context menu and the tab-navigation on the tab-folder for progress dialog should be shown in black for the dark theme.

Current Behavior - What happens?

Currently they are white-themed and that also means that the icons are not themed either in the cases where that is relevant.

Possible Solution

Fix the dark theme and implement icon-relevant switch for those use cases.

What are the steps to reproduce this issue? (for bugs)

1. Use dark theme on GEM
2. Open context menu and/or tab-navigation on progress dialog with many tasks
3. The dark theme is not applied to that part of the view

Context

Only affects dark theme.

Your Environment

• Version used: latest
• Operating System and version (desktop or mobile): Windows

Feature request

Currently the EclipseLauncher works as following:

1. XML files are manually created and saved forr oomph, so the workspace startup works as expected.
2. The Eclipse installation is fixed and not configured via Oomph.

We should evaluate if it is possible to use the oomph libraries directly. For 2, each setup should provide its own Eclipse installation and workspace and use a bundle-pool to populate the required plug-ins.

If this is possible, the plug-ín should be completely refactored providing an unique Eclipse launcher (which creates the Eclipse installation and starts the workspace).

Feature request

Expected Behavior - What were you expecting to happen?

On the Obsolete Environment dialog an option to select all of them for removal should be present for the UX perspective.

Current Behavior - What happens?

No way to select all the obsolete environments, so the user should select all manually one by one or project by project.

Possible Solution

Add a button/checkbox to select all the environments.

Context

When a lot of obsolete environments are present, the table is too huge that selecting all of them could be problematic.

Feature request

Expected Behavior - What were you expecting to happen?

Once #21 is implemented, an UI to simplify the user experience should be implemented to select the preferences out of the direct and error-prone HOCON file edition.

Current Behavior - What happens?

After #21, the preference framework would only be reachable by a file-based configuration editable by the user out of GEM.

Possible Solution

New menu entry to start a window with preferences organised by system and plug-ins.

Context

See #21.

Notes and further information

None.