Multiconfiguration Job Support - Extends "features mixins"

[mwitcraft]

Multiconfiguration Jobs included in a Build Monitor View may be configured to show a widget for each build configuration

• Generic support for representing a single Job with multiple JobView instances
• Configurable
• Unit Tested
• Acceptance Tested

[NeverOddOrEven]

Do not merge yet. Troubleshooting NoClassDefFoundError when comparing the job type to MatrixProject.

Caused by: java.lang.NoClassDefFoundError: hudson/matrix/MatrixProject
	at com.smartcodeltd.jenkinsci.plugins.buildmonitor.viewmodel.JobViews.viewsOf(JobViews.java:51)

[mwitcraft]

Added optional plugin dependency to resolve this problem.

[NeverOddOrEven]

Hey @jan-molak, we tried to follow the guidance from #62. Effectively, this PR extends "feature mixins" to allow a single job to present multiple JobView instances.

However, I am skeptical this is the right direction to take things. There are a few different directions we could take things.

• Do you want support for multiple JobView instances for a single Job? We could perhaps clean things up some with a new WidgetView abstraction.
• I believe a more natural approach is to extend ListView, override getItems, and BuildMonitorView could extend this new class.
• Is it possible to override an extension point via a new plugin, such that MatrixConfiguration implements TopLevelItem or that ListView.getItems() is able to include MatrixConfiguration instances? If so, could use some help designing this approach. I'm new to Jenkins plugin development.

What are your immediate thoughts on this PR?

[jan-molak]

Hey @NeverOddOrEven, @mwitcraft !

Multi-configuration projects, as well as support for folders and any other concept of grouping, is something that's been requested for quite some time. Regretfully, I didn't get a chance to commit enough time to solve this problem yet, but I'd be happy to help you out with direction.

To answer your questions:

• I agree that representing a group of Jenkins jobs as a single job doesn't feel right. We could introduce a new abstraction, such as WidgetView (or Widget) and perhaps have different types of widgets? Folder widget, pipeline widget, matrix build widget, etc. come to mind... A "single job widget" could be a good place to start perhaps?
• Yes, that could be an option. How do you propose the new getItems should behave?
• My knowledge in this area is somewhat limited, I'm afraid. Jenkins documentation lists Matrix Project Plugin on the list of extension points, so I'd probably start my investigation there

[NeverOddOrEven]

The problem:

• ListView only renders TopLevelItem instances
• MatrixConfiguration is not a TopLevelItem (all build history and configuration owned by MatrixProject)
• ListView relies on private state (e.g. cannot override getItems() as I suggested above)

The most robust approach:

• Publish a new plugin "Generalized List View" that implements GeneralListView which is basically a ListView with built in support for grouping. New selection predicate is not based on TopLevelItem. The AllListView.getItems() selection criteria may be more appropriate. The default view associated with a GeneralListView would have to take into consideration the availability of properties and methods it can use to display information about included items. This will likely require a refresh of the configuration UX.
• Add optional dependency to the new plugin, which maintains backwards compatibility. BuildViewMonitor is a ListView if it is not installed. BuildViewMonitor is a GeneralListView if the plugin is installed.
• Add support to the view layer to take advantage of the richer grouping metadata if available
• Celebrate separation of concerns and clearly defined abstractions