Split the plugin to JCasC API and JCasC plugin

[oleg-nenashev]

Currently JCasC exists as a single plugin. In longer term it may cause issues with adoption of the plugin:

• The plugin depends on the Jenkins core, and there are some fixes needed there to make the plugin more reliable (e.g. we need new milestone to prevent race conditions with Job loading)
• If we update the entire plugin to the new core, plugin developers would have to bump the core requirement as well if they want to support JCasC. In some cases it may be impossible (support policies, user requirements)

I would propose to split the plugin to two ones:

• "Jenkins Configuration-as-Code API" plugin. Targets Jenkins 2.60.x
  • Extension points for Plugin developers
• "Jenkins Configuration-as-Code" plugin. Generally targets recent LTS versions of Jenkins
  • Boot logic: Initializer, plugin management, etc.
  • Configurator implementations for Jenkins Core
  • Complex extension implementations, e.g. DataBoundConfigurator. It may stay in the API plugin, but eventually it may need to pick new core features like @DataBound proposed by @ndeloof

Such plugin split would support evolving the JCasC plugin along with the core, but at the same time it will allow more conservative plugin developers to integrate with the plugin.

[jetersen]

I like this idea of separating them out for the concern for developers

[ndeloof]

We indeed need some separation between the API and the implementation details and dedicated configurators. So far they all live in the same package, an api package would make sense (other could be Restricted, not sur @Restricted annotation can be used package wide with a package-info class ?

About splitting into a distinct plugin, I wonder the benefits for end-user : if this impl-plugin do rely on latest LTS, many won't be able to use a recent version. So if we don't have code which actually require a recent core version, I don't think this is something we want. @DataBound could be such a scenario, but as discussed in ML on this topic this one could be packaged as a separate annotation library to avoid requirement for a recent core.

Generally speaking, we should not target a recent LTS (only), but try to support as much users as possible targeting a pretty old (not too old!) LTS.

[oleg-nenashev]

@ndeloof Another use-case for the Core bump would be adoption of new Load milestones introduced in the core. E.g. #280

[ndeloof]

I agree there's many reason we could benefit a core bump, but on the other side we need to keep compatibility with version used by end-users. I wish we had some multi-release JAR support based on jenkins version for plugin development :)

Generally speaking I don't think we should not require a recent core until we hit a blocker that require such an upgrade. And this only can happen once this core version is there for enough time, or we will just get users frustration not being able to use our plugin. Another option is to maintain parallel versions of the plugin for some older core version... but I'm not sure Jenkins infra can handle this gracefully.

[oleg-nenashev]

Another option is to maintain parallel versions of the plugin for some older core version... but I'm not sure Jenkins infra can handle this gracefully.

It's not. According to the current approach used by @daniel-beck, we host UCs only for 4 latest LTS baselines (Daniel, please correct me if I am wrong). So 2.60.x UC may be removed soon, and the plugin will start offering latest versions after that.

[ndeloof]

right. Anyway how does core-update impact the need to separate plugin API, which would target an older core ? We still would need to release an old-core implementation plugin for adoption (and maintain it as minimal effort) in addition to a recent-core one for bleeding-edge fixes we want to rely on. I'm not -1 on this idea, just would like to understand the actual benefits, which aren't obvious to me

[oleg-nenashev]

Reopening the issue for discussion

[oleg-nenashev]

CC @timja

[ndeloof]

My personnal preference would be to define a metadata API for data-bindable components, that would be both supported by JCasC and Stapler (and maybe Structs-plugin) as an alternative to reflection-discovery.

[timja]

Not sure if it's an approach we would like to take, but here's a minimal spit based on how it's current setup: https://github.com/timja/configuration-as-code-api-plugin https://github.com/timja/configuration-as-code-plugin/tree/feature/create-api-plugin

[jetersen]

@ndeloof agreed though the basis for splitting is to allow the configurator API to stay on 2.60.3 while JCasC plugin can benefit from newer core releases.

One of the things we discussed in this weekly meeting was introducing annotation for blacklisting method in export which would require a newer Core.

Or as @oleg-nenashev suggests was to inherit from the JEP 200 which was introduced in core v2.102 also require a core bump. 99% is on 2.107.3 or newer :sweat:

[timja]

We can't just take that into account though, any plugin that needs to add a dependency to us for testing needs to have at least the same minimal core version as us AFAIK.

[jetersen]

@timja hopefully, if we split the right way that can minimal core stay on 2.60.3? We also discussed moving our test methods to the jenkins test harness.