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
interdependencies.
https://cwiki.apache.org/confluence/display/OFBIZ/Component+and+Component+Set+Dependencies
Jacques
Le 01/12/2016 à 10:35, Taher Alkhateeb a écrit :
Hello Everyone,
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
Ideas?
Taher Alkhateeb
On Thu, Nov 24, 2016 at 1:02 AM, Nicolas Malin <nicolas.ma...@nereide.fr>
wrote:
Hello Taher,
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
Nicolas
Le 28/09/2016 à 10:30, Taher Alkhateeb a écrit :
Hello Everyone,
Trying to move forward with our plugin system in OFBiz, I suggest the
following changes:
- 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
releases.
- Create a new SVN repository for plugins with a structure similar to the
following:
- ofbiz-core/trunk (what we have)
- ofbiz-core/branches/RELX.Y.Z
- ofbiz-plugins/trunk/birt
- ofbiz-plugins/trunk/cmssite
- ofbiz-plugins/trunk/ecommerce
- ofbiz-plugins/branches/RELX.Y.Z
- 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
pullPlugin -PdependencyId='org.apache.ofbiz.plugin:myplugin:0.1.5'
- Using OFBiz trunk with a specific version of a plugin: ./gradlew
pullPlugin -PdependencyId='org.apache.ofbiz.plugin:myplugin:0.1.5'
- 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?
Cheers,
Taher Alkhateeb
On Thu, Sep 15, 2016 at 2:22 PM, Taher Alkhateeb <
slidingfilame...@gmail.com
wrote:
Thank you Jacopo, work is committed in r1760917 which mostly involves
changes to the master build.gradle and README.md to describe the plugin
system.
On Thu, Sep 15, 2016 at 9:05 AM, Jacopo Cappellato <jacopo.cappellato@
hotwaxsystems.com> wrote:
Hi Taher,
this is a follow up to the reviews and comments posted by me and others
to
the work you have contributed in OFBIZ-7972.
Considering the feedback so far, and the minimal risk of side effects
that
your contribution may cause, I am asking you to commit your code to
trunk:
in this way it will be easier for all contributors to start playing with
this new plugin api.
Jacopo
On Tue, Sep 13, 2016 at 7:20 PM, Taher Alkhateeb <
slidingfilame...@gmail.com
wrote:
Hello Folks,
After quite a bit of work, I have a first working PoC for the plugin
system
with the following highlights:
- Plugins are OFBiz components that reside in /specialpurpose
(hopefully
renamed to /plugins later)
- Plugins can be published to maven repositories and retrieved from
maven
repositories
- Plugins can have dependencies on other plugins
- I created a minimal set of tasks that do the essentials:
createPlugin,
installPlugin, uninstallPlugin, pullPlugin (install from maven repo)
and
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
is
on your mind.
You will find the patch in https://issues.apache.org/
jira/browse/OFBIZ-7972
Cheers,
Taher Alkhateeb
On Fri, Sep 9, 2016 at 12:55 PM, Jacques Le Roux <
jacques.le.r...@les7arts.com> wrote:
Le 09/09/2016 à 10:32, Jacopo Cappellato a écrit :
On Thu, Sep 8, 2016 at 11:31 PM, Jacques Le Roux <
jacques.le.r...@les7arts.com> wrote:
...
So it would be easier for us (OFBiz team) and contributors to
deliver
(at
least free) plugins [...]
The terms "us", "OFBiz team" and the distinction with "contributors"
don't
make much sense to me and can cause confusion: there is just one
"OFBiz
community" in which everyone can contribute with ideas, work, code...
and
plugins.
Jacopo
Yes you are right, and actually, as Taher outlined, the
components/plugins provided by OFBiz OOTB would not fit in the
possible
use
of JitPack anyway.
Jacques
