BTW I feel like repeating myself over and over :D, did not remember just
stumbled upon it http://markmail.org/message/vax77ozzenxtw2ns
Le 01/12/2016 à 10:56, Jacques Le Roux a écrit :
That would be perfect.
The link below could help (thanks to Ron) if we could verify/complete the specialpurpose interdependencies. I think there are none but not totally
sure about that, we know about OFBIZ-6110 "Move as much as possible demo data from ecommerce to product or order components" but it's not
Le 01/12/2016 à 10:35, Taher Alkhateeb a écrit :
After doing some refactoring on the core framework, I came to realize that
we can make /specialpurpose behave like hot-deploy by simply deleting the
component-load.xml. Instead, activating and deactivating the components can
happen by going to an ofbiz-component.xml file and setting
<ofbiz--component enabled="false" ...> (thank you Jacopo for the tip).
The only benefit of component-load.xml is to specify the order of loading,
BUT, i discovered something not yet implemented in ofbiz-component.xml
called <depend-on component-name="whatever"/> to specify dependencies
between components. If we implement this feature then we don't need the
component-load.xml anywhere (this requires cleanup first because we have
some circular dependencies).
So my suggestion to move forward in the plugin system is to:
- Rename /specialpurpose to /plugins
- remove /plugins/component-load.xml
- Refactor gradle to 1) not load a component if enabled="false" and 2) if a
component directory does not have a component-load.xml then load everything
On Thu, Nov 24, 2016 at 1:02 AM, Nicolas Malin <nicolas.ma...@nereide.fr>
Your svn reorganization look fine, I just a doubt if in the future we
arrive to separate the framework and application. And an other on all git
connected on the current svn structure.
After I'm in favor to continue the way, first on deploy plugin only by
source and when we define the rules around plugin release and best pratice
for official, we can thinking about an official repo or use an existing
Le 28/09/2016 à 10:30, Taher Alkhateeb a écrit :
Trying to move forward with our plugin system in OFBiz, I suggest the
- Create a task called "pullPluginSource" which pulls an official Apache
OFBiz plugin from a source repository (version control). This task serves
specifically for developing plugins on Trunk or upgrading them on
- Create a new SVN repository for plugins with a structure similar to the
- ofbiz-core/trunk (what we have)
- and so on
- Rename /specialpurpose to /plugins
- Move all components in specialpurpose to the new SVN tree as per the
above mentioned directory structure
Under these changes, the workflow for plugins would be as follows:
- Using OFBiz release with a specific version of a plugin: ./gradlew
- Using OFBiz trunk with a specific version of a plugin: ./gradlew
- Using OFBiz trunk with latest source code of a plugin: ./gradlew
pullPluginSource -PpluginId=myplugin for the latest code
I think this completes the development cycle for plugins and allows for
official OFBiz plugins to reside in a separate code base and to have both
release, and source versions residing in trunk.
What do you think? Ideas, Suggestions?
On Thu, Sep 15, 2016 at 2:22 PM, Taher Alkhateeb <
Thank you Jacopo, work is committed in r1760917 which mostly involves
changes to the master build.gradle and README.md to describe the plugin
On Thu, Sep 15, 2016 at 9:05 AM, Jacopo Cappellato <jacopo.cappellato@
this is a follow up to the reviews and comments posted by me and others
the work you have contributed in OFBIZ-7972.
Considering the feedback so far, and the minimal risk of side effects
your contribution may cause, I am asking you to commit your code to
in this way it will be easier for all contributors to start playing with
this new plugin api.
On Tue, Sep 13, 2016 at 7:20 PM, Taher Alkhateeb <
After quite a bit of work, I have a first working PoC for the plugin
with the following highlights:
- Plugins are OFBiz components that reside in /specialpurpose
renamed to /plugins later)
- Plugins can be published to maven repositories and retrieved from
- Plugins can have dependencies on other plugins
- I created a minimal set of tasks that do the essentials:
installPlugin, uninstallPlugin, pullPlugin (install from maven repo)
publishPlugin (publish it to maven repo on localhost)
- I provided documentation in README.md
I appreciate your help in feedback, ideas, testing and sharing whatever
on your mind.
You will find the patch in https://issues.apache.org/
On Fri, Sep 9, 2016 at 12:55 PM, Jacques Le Roux <
Le 09/09/2016 à 10:32, Jacopo Cappellato a écrit :
On Thu, Sep 8, 2016 at 11:31 PM, Jacques Le Roux <
So it would be easier for us (OFBiz team) and contributors to
least free) plugins [...]
The terms "us", "OFBiz team" and the distinction with "contributors"
make much sense to me and can cause confusion: there is just one
community" in which everyone can contribute with ideas, work, code...
Yes you are right, and actually, as Taher outlined, the
components/plugins provided by OFBiz OOTB would not fit in the
of JitPack anyway.