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.
