[BlueOcean] BlueOcean Extensibility JEP

80 views
Skip to first unread message

Ivan Meredith

unread,
Jun 5, 2018, 11:12:01 PM6/5/18
to Jenkins Developers
Hello everyone,

I have been working on a JEP for Blue Ocean Extensibility. This will come in several parts that cover the technical aspects of how javascript extensions are registered and how packaging is done as well as documentation and an SDK to help develop extensions.

I've opened a PR for https://github.com/imeredith/jep/tree/jep-submission/jep/0000 that explains Blue Oceans extensibility generally, and https://github.com/imeredith/jep/tree/jep-submission-extensibility-api/jep/0000 that defines a Javascript API for plugins to use. 

I'm currently working on a JEP for packaging/bundling the Javascript extensions and assets.

Any feedback/questions on the JEPs or just the general direction is welcome.

Thanks, Ivan








Liam Newman

unread,
Jun 12, 2018, 1:24:56 PM6/12/18
to Jenkins Developers

Oleg Nenashev

unread,
Jun 14, 2018, 7:28:12 PM6/14/18
to Jenkins Developers
Hi,

Great to see that BlueOcean is finally going to get some extensibility.
I was waiting for it since Beta, and it was blocker for BlueOcean adoption in some of my projects.

JEP-204 looks good to me. Few questions there:
  • What is the reason to create a new extension engine/store? I'd guess there are many existing engines for JS/TS
  • There is no logic to unregister extensions. IIUC it means that I may need to reload BlueOcean page if the master restarts and uninstalls some plugins
  • Does BlueOcean project plan switch to TypeScript? Or is it just a quick reference implementation?
Sorry if I ask stupid questions, I am not a JavaScript guy.

JEP-203... Would it be possible to clarify the specification in JEP-203?
From what I see it's a top-level document which defines the extensibility goals and announces breaking changes in existing APIs.
Without links to downstream JEPs describing particular sections, IMHO there is no much value in this JEP. And I doubt it can be accepted in the current state until there are specifications for all sections in the document (in downstream JEPs?).

Best regards,
Oleg

Ivan Meredith

unread,
Jun 26, 2018, 6:30:15 PM6/26/18
to Jenkins Developers
Hi Oleg,

Sorry for taking so long to reply, I have been distracted from this for a bit.


JEP-204 looks good to me. Few questions there:
  • What is the reason to create a new extension engine/store? I'd guess there are many existing engines for JS/TS
Not really anything browser based from what we have seen. Atlassian has some libraries, but its iframe based.

  • There is no logic to unregister extensions. IIUC it means that I may need to reload BlueOcean page if the master restarts and uninstalls some plugins
Currently if the master restarts Blue Ocean will reload automatically because of the plugin issue. Maybe in the future this could be enhanced. Incidentally we currently have no way to detect when plugins are installed without a restart which I will add to the JEP 
  • Does BlueOcean project plan switch to TypeScript? Or is it just a quick reference implementation?
Yes. Typesript is a superset of ES2015 which we were already using. Typescript helps a lot with type safety, and its also provides code completion driven by the types which is supported by basically all editors 

Sorry if I ask stupid questions, I am not a JavaScript guy.

JEP-203... Would it be possible to clarify the specification in JEP-203?
From what I see it's a top-level document which defines the extensibility goals and announces breaking changes in existing APIs.
Without links to downstream JEPs describing particular sections, IMHO there is no much value in this JEP. And I doubt it can be accepted in the current state until there are specifications for all sections in the document (in downstream JEPs?).

I agree.

I have not had the time to work on this JEP recently as something came up basically just after I created this thread. But I will be spending some time on this each week now.

- Ivan
Reply all
Reply to author
Forward
0 new messages