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




Reply via email to