FUSETOOLS-2879 - filter runtime in "New Runtime" wizard

[apupier]

Signed-off-by: Aurélien Pupier apupier@redhat.com

Pull Request Checklist

After this checklist is all checked or PR provides explanations for possible pass-through, please put the label "Ready for review" on the PR.

General

• Did you use the Jira Issue number in the commit comments?
• Did you set meaningful commit comments on each commit?
• Did you sign off all commits for this PR? (git commit -s -m "jira issue number - your commit comment")

Functional

• Did the CI job report a successful build?
• Is the non-happy path working, too?

Maintainability

• Are all Sonar reported issues fixed or can they be ignored?
• Is there no duplicated code?
• Are method-/class-/variable-names meaningful?

Tests

• Are there unit-tests?
• Are there integration tests (or at least a jira to tackle these)?
• Do we need a new UI test?

Legal

• Have you used the correct file header copyright comment?
• Have you used the correct year in the headers of new files?

[apupier]

for Karaf:

for wildly/EAP:

for comparison without filter (as it is currently):

we can notice that several runtimes not Fuse/Karaf/Wildfly/EAP are still appearing but it seems a bug to me. What do you think? @robstryker

[apupier]

@lhein @bfitzpat having the list hardcoded makes it easier to see which versions we are supporting and is a bit faster, on the other hand when a new runtime is added, we will need to update this list. Do you have another argument to choose between one of those 2 solutions? (we can also start like that and modify in a next iteration)

[lhein]

doesn't it work with org.jboss.ide.eclipse.as.runtime.* also? I would prefer if we can make it more dynamic

[apupier]

doesn't it work with org.jboss.ide.eclipse.as.runtime.* also?

no it doesn't work

[lhein]

Then I fear I don't understand what the alternative approach to hard coding would be here?

[apupier]

Then I fear I don't understand what the alternative approach to hard coding would be here?

Retrieve all runtimes from our code and filter the list based on ids and the kind of pattern that you mentioned.

[lhein]

Actually the later approach is easier to maintain and I would opt for the dynamic approach.

[robstryker]

The weird ones still being shown aren't server adapters. They are references to extensions that can be installed. I imagine an API enhancement could be made here to not show those.

[apupier]

The weird ones still being shown aren't server adapters. They are references to extensions that can be installed. I imagine an API enhancement could be made here to not show those.

thanks for the answer. I opened the enhancement request: https://issues.jboss.org/browse/JBIDE-25920

[apupier]

Actually the later approach is easier to maintain and I would opt for the dynamic approach.

updated with dynamic approach.
Maybe some old Wildfly/EAP versions can be filtered out? If yes, we can raise another JIRA enhancement request.