Did Tippy.js add Popper2 to Jenkins core?

[Basil Crow]

https://github.com/jenkinsci/bootstrap5-api-plugin/pull/213 (comment)
concerns me:

> Popper2 is now part of Jenkins core.

As far as I can tell the Popper dependency was added when replacing
YUI tooltips with Tippy in
https://github.com/jenkinsci/jenkins/pull/6408. Has this abstraction
now leaked as an implementation detail that plugins are starting to
depend on?

Any recent JavaScript dependencies of Jenkins core like Tippy and
Popper should be built and packaged in such a way that they are not
exposed to plugins. Plugins that want to use Popper should be using
the Popper plugin. Both should be able to coexist at the same time.
Ignoring this separation of concerns leads to maintenance problems in
the future.

[Ullrich Hafner]

In JS and CSS and Jelly we have no concepts of encapsulation and APIs in the moment. Everything what is available in the browser is public by default. In JS this is even more complex to hide than in Java.

I think that users also will benefit from views that do not load the same library multiple times (loading time of a page). Also it duplicates the development effort if we create a plugin API for each JS library that we are using in core.

> --
> You received this message because you are subscribed to the Google Groups "Jenkins Developers" group.
> To unsubscribe from this group and stop receiving emails from it, send an email to jenkinsci-de...@googlegroups.com.
> To view this discussion on the web visit https://groups.google.com/d/msgid/jenkinsci-dev/CAFwNDjpLEVif3Es6yJafE29zkW6gxSROTLH0dV-cJ5sBrr5Gzw%40mail.gmail.com.

[Basil Crow]

On Tue, May 23, 2023 at 12:28 AM Ullrich Hafner
<ullrich...@gmail.com> wrote:
> In JS and CSS and Jelly we have no concepts of encapsulation and APIs in the
> moment. Everything what is available in the browser is public by default. In
> JS this is even more complex to hide than in Java.

Can Webpack be made to build a library under a hidden (shaded) namespace, with
core consuming the private version?

> I think that users also will benefit from views that do not load the same
> library multiple times (loading time of a page). Also it duplicates the
> development effort if we create a plugin API for each JS library that we are
> using in core.

These are indeed benefits, but I think the maintenance costs of exposing core
libraries to plugins are higher. This is a serious problem in every modular
system that fails to hide its internal implementation details from consumers;
see, for example:

http://dtrace.org/blogs/wesolows/2014/04/10/libsunw_ssl-or-how-smartos-avoids-sadness/

[Gavin Mogan]

> Can Webpack be made to build a library under a hidden (shaded) namespace, with core consuming the private version?

You explicitly have to configure things to make bundled libraries global. by default require("") statements are localized, so `const $ = require('jquery')` would not make it public.

looking at https://github.com/atomiks/tippyjs/blob/ad85f6feb79cf6c5853c43bf1b2a50c4fa98e7a1/src/createTippy.ts#L1 if tippy is being required, it should be properly self contained, but if its being loaded as a generic <script> tag, it probably depends on versions  attached to window.

looking at https://github.com/jenkinsci/jenkins/blob/d5cf94affc4424fc32e2de76a3a1a9dc3b8ef8ff/war/src/main/js/components/tooltips/index.js#L1 it should be required property

that being said, I also see https://github.com/jenkinsci/jenkins/blob/d5cf94affc4424fc32e2de76a3a1a9dc3b8ef8ff/war/pom.xml#L407 which looks to be an import but in the way basil already wanted?

I tried accessing "Popper.createPopper" on ci.jenkins.io and it doesn't seem to be defined, so I don't think its exposed?

--
You received this message because you are subscribed to the Google Groups "Jenkins Developers" group.
To unsubscribe from this group and stop receiving emails from it, send an email to jenkinsci-de...@googlegroups.com.

To view this discussion on the web visit https://groups.google.com/d/msgid/jenkinsci-dev/CAFwNDjoeFbXySnWOXhXhDLbeksKQkxbbB%2B%2Bbpo_bBme1WkK%3D-Q%40mail.gmail.com.

[Ullrich Hafner]

>
>> I think that users also will benefit from views that do not load the same
>> library multiple times (loading time of a page). Also it duplicates the
>> development effort if we create a plugin API for each JS library that we are
>> using in core.
>
> These are indeed benefits, but I think the maintenance costs of exposing core
> libraries to plugins are higher. This is a serious problem in every modular
> system that fails to hide its internal implementation details from consumers;
> see, for example:
>
> http://dtrace.org/blogs/wesolows/2014/04/10/libsunw_ssl-or-how-smartos-avoids-sadness/
>

I’m a little biased as a plugin developer but for me Jenkins core is not a system on its own that needs to be encapsulated. Jenkins core should provide all required components to create rich user interface for plugins. Providing the same JS libraries for my plugins feels a little bit like providing my own core to create value for my users. When we create new form elements in core (and tooltips like tippy) I want to use them in my plugins as well. That means core should be the basis for all other development and not a parallel component side by side with plugins.

[Gavin Mogan]

I totally agree for jenkins components to be exposed, but not artifacts of those ui components because it leads to the 15 years of trying to get rid of prototype because people used it directly.

--
You received this message because you are subscribed to the Google Groups "Jenkins Developers" group.
To unsubscribe from this group and stop receiving emails from it, send an email to jenkinsci-de...@googlegroups.com.

To view this discussion on the web visit https://groups.google.com/d/msgid/jenkinsci-dev/1A740EFF-B3BA-4891-AEF0-9F3804B63A8B%40gmail.com.

[Basil Crow]

On Tue, May 23, 2023 at 10:18 AM 'Gavin Mogan' via Jenkins Developers
<jenkin...@googlegroups.com> wrote:
> I tried accessing "Popper.createPopper" on ci.jenkins.io and it doesn't seem to be defined, so I don't think its exposed?

Then why was https://github.com/jenkinsci/bootstrap5-api-plugin/pull/213 needed?

[Gavin Mogan]

I don't know.

I now checked https://weekly.ci.jenkins.io/ as well.

curl -s -L https://weekly.ci.jenkins.io/ | grep popper -c
0

--
You received this message because you are subscribed to the Google Groups "Jenkins Developers" group.
To unsubscribe from this group and stop receiving emails from it, send an email to jenkinsci-de...@googlegroups.com.

To view this discussion on the web visit https://groups.google.com/d/msgid/jenkinsci-dev/CAFwNDjqd2pooJbPtZkfeVKN%2Byu4xE%2Bf7ZD2w8aMVpyfS5hxEuw%40mail.gmail.com.

[Ullrich Hafner]

I would not consider Popper as a standalone library an artifact. Now we need to configure and load it twice.

I understand that this is the best thing from an architectural view. But sometimes you need to make tradeoffs otherwise development costs will increase too much…

To view this discussion on the web visit https://groups.google.com/d/msgid/jenkinsci-dev/CAG%3D_Duvx%2BdamT5QFvKoyOO4Og7FFkD1rELW%2BUF%2BfFNyNHh7zCw%40mail.gmail.com.

[Ullrich Hafner]

The dependency to popper2 has been removed from bootstrap a couple of months ago, but not the include. Therefore I removed the include as well.

Popper is now part of the Bootstrap plugin. (So somehow in my own Jenkins UI "core“ to create rich user interfaces without hassle.)

> --
> You received this message because you are subscribed to the Google Groups "Jenkins Developers" group.
> To unsubscribe from this group and stop receiving emails from it, send an email to jenkinsci-de...@googlegroups.com.

> To view this discussion on the web visit https://groups.google.com/d/msgid/jenkinsci-dev/CAFwNDjqd2pooJbPtZkfeVKN%2Byu4xE%2Bf7ZD2w8aMVpyfS5hxEuw%40mail.gmail.com.

[Basil Crow]

On Wed, May 24, 2023 at 2:50 PM Ullrich Hafner <ullrich...@gmail.com> wrote:
> Popper is now part of the Bootstrap plugin.

Yes, jenkinsci/bootstrap5-api-plugin@76fd031d8291a9a836264c34b630c8c273102c86
resolves the issue from my perspective.

On Wed, May 24, 2023 at 2:46 PM Ullrich Hafner <ullrich...@gmail.com> wrote:
> I understand that this is the best thing from an architectural view. But sometimes you need to make tradeoffs otherwise development costs will increase too much…

The development costs of committing to support a third-party API in
perpetuity are prohibitively expensive. But I understand the
frustration — maintaining library plugins is not a lot of fun.

You could gain back development velocity (at the cost of efficiency)
by using the static linking approach (typically with Webpack)
practiced by e.g. azure-ad, pipeline-graph-view, workflow-cps, etc.
That seems to be the way the Golang and Rust communities have evolved,
despite the inefficiency.

Unfortunately maintaining a correct and efficient dynamically-linked
system is just a huge amount of work, as demonstrated by the constant
effort that is needed to build and package software for operating
system distributions. The only thing I can think of that would make
this easier for you would be better documentation to hopefully inspire
others to assist with the burden of maintaining JavaScript Jenkins
library plugins.

[Basil Crow]

It occurs to me that the new Webpack 5 module federation feature could
be used to implement dynamic linking with Webpack builds:

https://webpack.js.org/concepts/module-federation/

Implementing the tooling for this in the Jenkins ecosystem would
likely be an ambitious project of similar scope to the one started
(but never completed) by Tom Fennelly several years back.

[Gavin Mogan]

Unless i'm mistaken, that would keep the same problem, but move it elsewhere. <script> tag would load a module to the global namespace (window), require with module federation would move it to a require, but require('bootstrap') would still load the same global version.

which means if someone upgrades "bootstrap" from 4 to 5, everything would break. The same issue with prototype again (except prototype was so much worse, polluting so much of the global namespace).

Even with the bootstrap4-api thing, you'll have bootstrap4-api and bootstrap5-api, which would lead to two copies being loaded, and could really have weird behavior.

I strongly feel the solution is to have more jelly or web components, that do the standard ui behavior with encapsulation and contracts, and those that want to be able to do custom logic, should include their own dependencies via a bundler.

--
You received this message because you are subscribed to the Google Groups "Jenkins Developers" group.
To unsubscribe from this group and stop receiving emails from it, send an email to jenkinsci-de...@googlegroups.com.

To view this discussion on the web visit https://groups.google.com/d/msgid/jenkinsci-dev/CAFwNDjqpAasSLZymsn3uKAjaekUWvJzx_O5GsLLy1y123o--Mg%40mail.gmail.com.

[Basil Crow]

I meant that Hafner-style JavaScript library Jenkins plugins could be
made to export a federated module instead of (or in addition to) a
Stapler adjunct. That would allow those libraries to be consumed from
other Jenkins plugins with a Webpack build (e.g., pipeline-graph-view)
but without the overhead of static linking. In other words, there
could be a third option that blends the two existing options
(consuming Hafner-style libraries via Stapler adjuncts, and static
linking with Webpack). Core would still have to hide its dependencies
from plugins.

On Wed, May 24, 2023 at 10:24 PM 'Gavin Mogan' via Jenkins Developers
<jenkin...@googlegroups.com> wrote:
> those that want to be able to do custom logic, should include their own dependencies via a bundler.

Sure, that is the static linking approach already in use by many
plugins. But this suffers from the inefficiency problem described
above (as well as making it more difficult to roll out security
fixes).

[Ullrich Hafner]

> I strongly feel the solution is to have more jelly or web components, that do the standard ui behavior with encapsulation and contracts, and those that want to be able to do custom logic, should include their own dependencies via a bundler.

Rather than reinventing the wheel we should use more of those rock-solid component that are already on the market. We have so limited development resources in Jenkins in the moment that it does not make sense to create our own version of ECharts, or Bootstrap, etc.

[Basil Crow]

On Thu, May 25, 2023 at 5:24 AM Ullrich Hafner <ullrich...@gmail.com> wrote:
> Rather than reinventing the wheel we should use more of those rock-solid component [sic] that are already on the market.

Indeed, and I suspect this was the fatal flaw behind Tom Fennelly's
effort several years back: his homegrown dynamic linker never reached
critical adoption. In contrast, Webpack module federation is a general
component that is already on the market and widely deployed.

> it does not make sense to create our own version of ECharts, or Bootstrap, etc

It _does_ make sense to package third-party libraries (either Java or
JavaScript) as Jenkins library plugins in order to facilitate dynamic
linking. This is a consequence of the fact that we maintain a
homegrown plugin distribution, installation, and loading system (and
it is far too late to distribute, install, and load Jenkins plugins
through some generalized method).

[Basil Crow]

On Wed, May 24, 2023 at 2:50 PM Ullrich Hafner <ullrich...@gmail.com> wrote:
>

> Popper is now part of the Bootstrap plugin. (So somehow in my own Jenkins UI "core“ to create rich user interfaces without hassle.)

Then https://github.com/jenkinsci/jenkins/blob/c886642632d81091c17d93f16b50c97ffb04d146/war/pom.xml#L406-L412
needs to be adjusted.

[Basil Crow]

On Mon, Jun 12, 2023 at 10:39 AM Basil Crow <m...@basilcrow.com> wrote:
>
> Then https://github.com/jenkinsci/jenkins/blob/c886642632d81091c17d93f16b50c97ffb04d146/war/pom.xml#L406-L412
> needs to be adjusted.

JENKINS-71666 FTR

[Ullrich Hafner]

Is there a reason that we are still bundling the JUnit plugin in our war? It has been removed from core quite some years ago...

--
You received this message because you are subscribed to the Google Groups "Jenkins Developers" group.
To unsubscribe from this group and stop receiving emails from it, send an email to jenkinsci-de...@googlegroups.com.

To view this discussion on the web visit https://groups.google.com/d/msgid/jenkinsci-dev/CAFwNDjrev6_AbRXZpgf_%3Dx6iRU%2Bwo2eAicsWY-iiUTihBBGoww%40mail.gmail.com.

[Basil Crow]

On Mon, Jul 17, 2023 at 1:05 PM Ullrich Hafner <ullrich...@gmail.com> wrote:
>
> Is there a reason that we are still bundling the JUnit plugin in our war? It has been removed from core quite some years ago...

AFAICT it is so that plugins whose required core is 1.577 or earlier
will continue to work if installed on a clean installation. There are
343 such plugins. Once releases are created whose required core is
1.578 or later (or the plugin(s) formally deprecated in the Update
Center) then we can stop bundling the JUnit plugin in the WAR.

[Basil Crow]

On Mon, Jul 17, 2023 at 3:58 PM Basil Crow <m...@basilcrow.com> wrote:
>
> AFAICT it is so that plugins whose required core is 1.577 or earlier
> will continue to work if installed on a clean installation. There are
> 343 such plugins. Once releases are created whose required core is
> 1.578 or later (or the plugin(s) formally deprecated in the Update
> Center) then we can stop bundling the JUnit plugin in the WAR.

I forgot to mention that not all of those 343 plugins are necessarily
actually consuming the JUnit plugin, just the older version of Jenkins
core. If it can be determined, e.g. through the usage-in-plugins tool,
that one of those old plugins is not consuming the JUnit plugin, then
that plugin can be crossed off the list.