> >> 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. -- 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-dev+unsubscr...@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.
