Bridge for C7 Plugins

Development
1

I was thinking today about C7 plugins. We have migrated the Keycloak plugin already for Operaton, but there are quite many plugins existing. Migrating every single one might not be in our sense.

Just an idea that I would like to discuss: Do you think it would be feasible to provide a bridging layer? Roughly I’m thinking in the direction how slf4j does this with bridging the different logging APIs. I.e. provide the implementation classes with Camunda namespace, but internally delegate to Operaton API?

Do you think it would be possible to provide such a layer and would be beneficial?

2

I wondered that, too, and thought this was really hard to achieve. Camunda plugins don’t use a provided API, they have access to the full functionality of the engine, every public class. If they have a UI component, it’s probably HTML with the Angular SDK or JavaScript inlined.

All I can think of to solve this issue are some classloader-shenanigans and even then many of the plugins will rely on the presence of javax.* classes which we won’t ship anymore. I think if we built such a bridge and communicated it, it needs to be really realiable, and I don’t see a way to achieve this – apart from the fact that the old tasklist and cockpit will hopefully be replaced by the new one in the near future, and the plugins with UI-components won’t support this anyways

3

I think you are right here. It could be at least very tricky. It was just a thought now. Maybe we can discuss that later again.

4

You have also to consider that once C7 is EOL, there is no “dual use” use case anymore.

5

Let’s discuss further once we want / need to support the next plugin. A clean plugin API will get important I guess. And the less effort existing plugins need to be used on Operaton the better.