Hi Daniel, I understand your points, and I agree that the level of care to the framework and plugins repositories are quite not the same as of today.
I dug in mailing list history to get the origin of plugins [1] Before plugins exists, every components we can find in plugin repo where present in /specialpurpose directory, in the main svn repository, and integrators used to develop their own application within an /hot-deploy. Plugin initiative was lead by Taher [2], in the thread we can find lot of references to past discussions that express some concern about CI (those introducing gradle task "pullAllPluginsSource"), "plugins following the framework trend" and so on. The idea was to be able to install/delete plugin using gradle easily from distant repository, to easily customisation of an OFBiz instance. Plugin effort lead to separate repository in february 2017 [3] >From my experience I see plugins code as specific extensions to the OFBiz framework that where contributed in the past, that are possible basis for custom component for integrators. Those are valuable resources, but i feel unsure about their maintenance quality (thinking of codenarc for example) I sadly do not use the plugin ecosystem, only for the createPlugin tasks to initiate a new component, and about the fact that the releases we make are shipped with all plugins (some enabled and others not), i consider that even if I liked the idea of a plugin system, i feel like that the need was not here for me... So i lean towards the idea to merge back into OFBiz framework repository plugins that we would consider relevant about their quality and importance for the project, with the condition to respect CI tests, and to let aside other plugins... Writing it, i'm not sure i like the idea of letting aside those contributions (make me think of incubating or attic plugins). I wonder about the future releases, should we ship all the plugins, or only the enabled ones, and offer the users to pull the one they needs (from the community repository or from custom ones) using plugins system. Thanks. [1] https://issues.apache.org/jira/browse/OFBIZ-7972 [2] https://lists.apache.org/thread/94q920hsfr9z08vw3sz92r084j0c5kkn [3] https://blogsarchive.apache.org/ofbiz/entry/apache-ofbiz-news-february-2017 On 13/03/24 09:40, Daniel Watford wrote: > > Hi Michael, > > By symlink, are you referring to a filesystem symlink? If so, this > unfortunately won't solve the problem of identifying which branch/tag of > the ofbiz-plugins repository should be checked out for a continuous > integration build - a problem we are seeing for tagged releases. > > Also, I think (but may be wrong) that checkstyle runs against plugin code > as part of the CI process. This means we have to set checkstyle error count > thresholds in ofbiz-framework in such a way that takes ofbiz-plugins into > account. This complicates the decision around what is an acceptable > threshold at any given time. Happily the threshold in trunk is currently 0 > (see tasks.checkstyleMain.maxErrors in build.gradle), but when we introduce > a new checkstyle rule we will need to track checkstyle errors in both > ofbiz-framework and ofbiz-pluginsand we work towards being the error count > back to zero. > > If the plugins are not really the focus of the ofbiz-framework developers, > should we even include them in the ofbiz-framework CI process at all? > Perhaps we should instead document and provide examples on how an > integrator would retrieve and build a plugin, but remove platform-specific > code - such as pull*PluginSources* - from ofbiz-framework completely. > > Interested parties could then augment ofbiz-plugins with a solution to > insert plugin sources into the ofbiz-framework source and trigger a build > accordingly. > > If a particular plugin is deemed important enough to the ofbiz-framework > developers - such as the rest-api plugin - then we could port that plugin > to become a component of ofbiz-framework. We would therefore think of > ofbiz-plugins as a contributed code area when components are incubated > before being integrated. > > I suppose the broader problem I'm trying to address is that I'm uneasy with > the idea that we ofbiz-framework developers need to ensure the content of a > seperate ofbiz-plugins repository remains compatible with our build checks, > particularly since contributors may not event be aware ofbiz-plugins > exists. (This position of course does not affect the need to maintain our > API for use by plugins/integrations). Bringing a subset of plugins that > need to be supported into the ofbiz-framework repository should address > this problem. > > Thanks, > > Dan. > > On Tue, 5 Mar 2024 at 10:32, Michael Brohl <michael.br...@ecomify.de> wrote: > > > Hi Dan, > > > > just a short reply for now: you can easily integrate the plugins using a > > symlink to the plugins repository to check if changes in the framework > > are compatible with the plugins. > > > > The plugins do not get as much support as the core framework and > > applications, I even would call some of them experimental. Some were > > also be switched off because of problems/security issues. They are > > optional enhancements and I think it is the right way to leave them in > > their own repository with one exception. > > > > IMO, the rest-api Plugin should be merged into the framework as a core > > functionality after we have provided the enhancements we have developed > > over the last 2 years (still waiting for me to find time to provide a PR). > > > > For the historical view, I would need more time to dig into the past > > discussions... > > > > Best regards, > > > > Michael Brohl > > > > ecomify GmbH - www.ecomify.de > > > > Am 05.03.24 um 09:42 schrieb Daniel Watford: > > > Hello OFBiz developers, > > > > > > I imagine this topic might be revisiting discussions that pre-date my > > > involvement with OFBiz so I would appreciate it if anyone can offer any > > > historical perspective on the separation of the ofbiz-framework and > > > ofbiz-plugins repository. > > > > > > This is a proposal to merge the HEAD of the trunk branch of the > > > ofbiz-plugins repository into a directory within the ofbiz-framework > > > repository. We would then use build-time configuration to include or > > > exclude plugins from the build. > > > > > > Currently the ofbiz-plugins repository is maintained by the main OFBiz > > > framework project's developers. As we make changes to a branch in > > > ofbiz-framework, we need to check that plugins continue to build in the > > > corresponding branch of the ofbiz-plugins repository. Having plugins in a > > > separate repository complicates this process and I'm sure it is often > > > overlooked by contributors to the project. > > > > > > Further, our continuous integration processes need to checkout the > > relevant > > > branch from ofbiz-plugins when building ofbiz-framework. We have some > > > platform-specific scripts that carry out this process for us, but they > > are > > > not able to handle CI builds triggered by applying tags to > > ofbiz-framework. > > > > > > Lastly, should an integrator wish to use one or more plugins from the > > > ofbiz-plugins repository in addition to their own plugins, there is some > > > confusion about how they arrange their own code alongside the > > ofbiz-plugins > > > repository. > > > > > > Proposed changes: > > > - Copy repository content from the HEAD of the trunk branch from > > > ofbiz-plugins to a suitable directory in ofbiz-framework. Perhaps this > > > directory should be named ofbiz-plugins to help identify the contents as > > > being maintained by the project. > > > - Modify the build process to exclude the ofbiz-plugins directory from > > the > > > build by default. The ofbiz-plugins directory can be added to the build > > > through a gradle command line argument or setting. > > > - Set code checking thresholds (e.g. checkstyle) to levels that allow > > > inclusion of the new code. > > > > > > Expected benefits: > > > - Contributors can more easily check their changes do not impact on the > > > building of ofbiz-plugins. > > > - The continuous integration builds do not need to run platform-specific > > > scripts to fetch plugin sources since the sources are already part of the > > > default checkout. > > > - Determining which branch/tag from the ofbiz-plugins repository > > > corresponds to the ofbiz-framework branch/tag being built by CI is no > > > longer an issue. > > > - We have one less repository to manage access/issues/PRs for. > > > - The set of ofbiz-plugins will have more visibility among OFBiz > > developers > > > - perhaps helping us decide which plugins the project no longer wishes to > > > be responsible for and should be removed from ofbiz-framework. These > > > plugins can be spun off into their own repository by any interested > > > maintainers. > > > > > > Possible negatives: > > > - The ofbiz-framework repository size will increase due to additional > > code. > > > I'm not sure this is a major issue, particularly since the number of > > > contributions to ofbiz-plugins is low these days. > > > - The build process is more complicated for users wishing to include > > > plugins. We can mitigate this by documenting the (hopefully) single > > > modification needed to include ofbiz-plugins into the build. > > > - We undo whatever benefit was achieved by having a separate > > ofbiz-plugins > > > repository in the first place. > > > > > > I'm sure there will be other benefits and negatives to consider. Please > > let > > > me know what you think. > > > > > > Thanks, > > > > > > Dan. > > > > > > > > -- > Daniel Watford
