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
