[extension] let user to select which library/technical extension an integration should pick up

[lburgazzoli]

This is a...

[X] Feature request
[ ] Regression (a behavior that used to work and stopped working in a new release)
[ ] Bug report  
[ ] Documentation issue or request

The problem

It is not possible to choose which library extensions an integration should include i.e. jdbc driver are added using tags which means that an integration using an sql connector does not have only the driver needed for the connection but all the known ones.

Expected behavior

There should be a "customization" section on the integration editor page to let user pick the library/technical extension needed by the integration (excluding connector/steps of course).

[gashcrumb]

Wouldn't this be more of a connection thing vs an integration thing?

[lburgazzoli]

For the jdbc stuff yes but extension may have a broader scope i.e. an error handler, route policies and so on so the impact is also on the integration editor.

[gashcrumb]

Sounds more like an 'integration settings' section of the editor. This issue then starts to feel a bit open ended. I wonder if it'd be worth thinking about breaking this out into distinct use cases for each of those things you've mentioned? Or I guess we can make the settings page a catch-all kinda page, I think it makes it harder to figure out a good design though.

[lburgazzoli]

yeah I do not know what is the best way, I've opened this issue to keep track of a need (i.e. for servicenow connector I'm evaluating, one can supply its own model to bind data from sn)

[gashcrumb]

Hmm. But that still sounds more like a connection level thing, as this leads me to believe this would affect what data shapes the actions would input/output for such a connector.

[lburgazzoli]

yes but again, the impact of an extension could be larger that the connection so we should think about it soon or later :)

[gashcrumb]

Would it make sense to raise features for all these different use cases and link them to this one? Feels like there's some big picture stuff here as well, doesn't it?

[lburgazzoli]

maybe we should convert this one on a epic and do some brainstorming with UX to understand what direction we should follow, make sense ?

[amysueg]

@kcbabo What does PM think about this? Priority?

[kcbabo]

It's important. As customers add more and more extensions to their environment, they will need a way to specify which ones should be used in any given integration.

@lburgazzoli how do we handle associating extensions with integrations today? Do we only add an extension to the classpath when a step in that extension is used? Or do all extensions get mapped into every integration?

[lburgazzoli]

For step/connector extensions, they are included only when a step/action is used For things such as jdbc, we include all the extensions that are tagged with jdbc because we do not have a way to let the user select which jdbc driver and version is needed for an integration

[amysueg]

@dongniwang Since you worked on the extensions UX, it probably makes sense for you to look at this as well. I will set up a meeting for us to discuss with @lburgazzoli and @gashcrumb.

[gashcrumb]

I think it's better to consider that the citizen user shouldn't have to pick a specific extension to associate with an integration. It should be figured out by usage. I think tbh this issue is defined in too broadly a scope while the problem we're trying to solve here is actually pretty specific, i.e. what JDBC driver instance that was uploaded should be included in the integration. So maybe it'd be better to just focus on that. In which case, I kinda still think this is a connection level thing and not an integration level thing, i.e. the user would maybe choose what driver to use when defining the connection.

[lburgazzoli]

@gashcrumb @amysueg I've created the following two epics:

• https://github.com/syndesisio/syndesis/issues/2808
• https://github.com/syndesisio/syndesis/issues/2809