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
