Some questions on plugin system

[taher]

Hello Everyone,

I need some opinions for a PoC that I'm working on for the plugin system
(OFBIZ-7972) and appreciate your help:

repository design
----------------------
I am thinking of just having a very simple web server denoted as a
repository where the plugins are just zip or tar archives that expand to
OFBiz components. For example, if the repository URL is www.example.com
then the plugin could be www.example.com/plugins/SpecificPluginHere.tar.gz.
It downloads to the specialpurpose (hopefully renamed to plugins) to expand
and install

dependencies
------------------
This is a complicated subject, and there are a few ideas I have in mind:
- Try to deploy the gradle project dependency model
- Alternatively write custom dependency resolution

However, this might be too complex to kickstart the project, and I think
perhaps we can start without a dependency management system and implement
it in a later stage.

Thank you in advance for your help and feedback.

Taher Alkhateeb

[Jacques Le Roux]

Le 25/08/2016 à 16:39, Taher Alkhateeb a écrit :

> Hello Everyone,
>
> I need some opinions for a PoC that I'm working on for the plugin system
> (OFBIZ-7972) and appreciate your help:
>
> repository design
> ----------------------
> I am thinking of just having a very simple web server denoted as a
> repository where the plugins are just zip or tar archives that expand to
> OFBiz components. For example, if the repository URL is www.example.com
> then the plugin could be www.example.com/plugins/SpecificPluginHere.tar.gz.
> It downloads to the specialpurpose (hopefully renamed to plugins) to expand
> and install

I'm for removing the difference between specialpurpose and hot-deploy. Why? Simplification!

We should remove specialpurpose and rename hot-deploy into plugins.
This also means that we should have a Gradle task to automatically download and install a plugin.
All current specialpurpose would become plugins available in the repo easily installable using something like
     gradlew installPlugins plugins1Name plugins2Name etc.
I don't see the need to have a differentiated task to install only 1 plugin

The repo should be installed on the new OFBIZ-VM2

We know that, like for the misnamed hot-deploy, installing a plugin will need a restart of the OFBiz instance.
So this can't be dynamically done (at least for now), but need to be at least automated.

The only current issue is if we have dependencies among plugins.
For now we can simply documented them for users to set their own component-load.xml

BTW as a reminder, after OFBIZ-6760 we need to update
https://cwiki.apache.org/confluence/display/OFBIZ/Component+and+Component+Set+Dependencies
And possibly complete the possible existing interdependencies between specialpurpose components, though I can't remember any, but I feel I'm wrong here.


> dependencies
> ------------------
> This is a complicated subject, and there are a few ideas I have in mind:
> - Try to deploy the gradle project dependency model

I'd like to know if you crossed issues with that and if yes what they are. If it's the case can't we share the burden?

> - Alternatively write custom dependency resolution

Please no :)

> However, this might be too complex to kickstart the project, and I think
> perhaps we can start without a dependency management system and implement
> it in a later stage.

Yes why not? Baby steps for the win

Jacques

>
> Thank you in advance for your help and feedback.
>
> Taher Alkhateeb
>

[taher]

Hi Everyone,

I am very happy to announce that after a lot of research I finally have a
little working PoC solution for the OFBiz plugin system. I believe this
system is very simple yet very powerful with the following simple API tasks

1- ./gradlew createPlugin: creates a plugin from templates
2- ./gradlew installPlugin: downloads a plugin and all its dependency
plugins from a maven repository(it could be local, remote, jcenter,
whatever), extracts the archives, add the plugin to component-load.xml, and
calls the install task.
3- ./gradlew uninstallPlugin: calls the uninstall task, removes the plugin
from component-load.xml, and deletes the plugin (but ignores dependencies).
4- ./gradlew publishPlugin: create a maven compatible package that can be
published to either a local or a remote repository.

So what is very powerful about this solution? Well, you use the maven
format for your packages, so you can host it on any maven repository
including jcenter. Also, you have a standard way of declaring dependencies
(pom.xml) and you pretty much gain all the benefits that comes with maven
packages (versioning, dependencies, meta data, etc ...)

The solution can be expanded later on, but I think the above provides a
good starting point. Ideas? Feedback? Should I go ahead and fine-tune /
share the PoC on JIRA?

Regards,

Taher Alkhateeb

On Fri, Aug 26, 2016 at 6:17 PM, Jacques Le Roux <
[hidden email]> wrote:

> Le 25/08/2016 à 16:39, Taher Alkhateeb a écrit :
>
>> Hello Everyone,
>>
>> I need some opinions for a PoC that I'm working on for the plugin system
>> (OFBIZ-7972) and appreciate your help:
>>
>> repository design
>> ----------------------
>> I am thinking of just having a very simple web server denoted as a
>> repository where the plugins are just zip or tar archives that expand to
>> OFBiz components. For example, if the repository URL is www.example.com
>> then the plugin could be www.example.com/plugins/Specif
>> icPluginHere.tar.gz.
>> It downloads to the specialpurpose (hopefully renamed to plugins) to
>> expand
>> and install
>>
>
> I'm for removing the difference between specialpurpose and hot-deploy.
> Why? Simplification!
>
> We should remove specialpurpose and rename hot-deploy into plugins.
> This also means that we should have a Gradle task to automatically
> download and install a plugin.
> All current specialpurpose would become plugins available in the repo
> easily installable using something like
>     gradlew installPlugins plugins1Name plugins2Name etc.
> I don't see the need to have a differentiated task to install only 1 plugin
>
> The repo should be installed on the new OFBIZ-VM2
>
> We know that, like for the misnamed hot-deploy, installing a plugin will
> need a restart of the OFBiz instance.
> So this can't be dynamically done (at least for now), but need to be at
> least automated.
>
> The only current issue is if we have dependencies among plugins.
> For now we can simply documented them for users to set their own
> component-load.xml
>
> BTW as a reminder, after OFBIZ-6760 we need to update
> https://cwiki.apache.org/confluence/display/OFBIZ/Component+
> and+Component+Set+Dependencies
> And possibly complete the possible existing interdependencies between
> specialpurpose components, though I can't remember any, but I feel I'm
> wrong here.
>
>
> dependencies
>> ------------------
>> This is a complicated subject, and there are a few ideas I have in mind:
>> - Try to deploy the gradle project dependency model
>>
>
> I'd like to know if you crossed issues with that and if yes what they are.
> If it's the case can't we share the burden?
>
> - Alternatively write custom dependency resolution
>>
>
> Please no :)
>
> However, this might be too complex to kickstart the project, and I think
>> perhaps we can start without a dependency management system and implement
>> it in a later stage.
>>
>
> Yes why not? Baby steps for the win
>
> Jacques
>
>
>
>> Thank you in advance for your help and feedback.
>>
>> Taher Alkhateeb
>>
>>
>

[Pierre Smits]

This solutions must be able to work with:

   - zip files
   - tar files and other zip variants (tar.gz, etc)
   - folder structures.

That will enable the adopter to use local storage, but also releases stored
in GitHub or even svn repos.

At the moment I see the use of maven repos as overkill, adding unnecessary
complexity when developing extensions. OFBiz is not that complex.. Unless
we want to have a full-fledged Eclipse-like plugin management solution from
the start. This is not low-hanging fruit, but rather something to have
later in the life-cycle of the solution maturity wise. Quick-win, at the
moment, would be that something could be retrieved from svn, github or
local folder and deployed in the hot-deploy folder.

I guess I need to see this solution in combination with an example/demo
component that requires all the elements described in the PoC and the
earlier postings in this ml.

Best regards,

Pierre Smits

ORRTIZ.COM <http://www.orrtiz.com>
OFBiz based solutions & services

OFBiz Extensions Marketplace
http://oem.ofbizci.net/oci-2/

On Sun, Aug 28, 2016 at 6:41 PM, Taher Alkhateeb <[hidden email]
> wrote:

> Hi Everyone,
>
> I am very happy to announce that after a lot of research I finally have a
> little working PoC solution for the OFBiz plugin system. I believe this
> system is very simple yet very powerful with the following simple API tasks
>
> 1- ./gradlew createPlugin: creates a plugin from templates
> 2- ./gradlew installPlugin: downloads a plugin and all its dependency
> plugins from a maven repository(it could be local, remote, jcenter,
> whatever), extracts the archives, add the plugin to component-load.xml, and
> calls the install task.
> 3- ./gradlew uninstallPlugin: calls the uninstall task, removes the plugin
> from component-load.xml, and deletes the plugin (but ignores dependencies).
> 4- ./gradlew publishPlugin: create a maven compatible package that can be
> published to either a local or a remote repository.
>
> So what is very powerful about this solution? Well, you use the maven
> format for your packages, so you can host it on any maven repository
> including jcenter. Also, you have a standard way of declaring dependencies
> (pom.xml) and you pretty much gain all the benefits that comes with maven
> packages (versioning, dependencies, meta data, etc ...)
>
> The solution can be expanded later on, but I think the above provides a
> good starting point. Ideas? Feedback? Should I go ahead and fine-tune /
> share the PoC on JIRA?
>
> Regards,
>
> Taher Alkhateeb
>
> On Fri, Aug 26, 2016 at 6:17 PM, Jacques Le Roux <
> [hidden email]> wrote:
>
> > Le 25/08/2016 à 16:39, Taher Alkhateeb a écrit :
> >
> >> Hello Everyone,
> >>
> >> I need some opinions for a PoC that I'm working on for the plugin system
> >> (OFBIZ-7972) and appreciate your help:
> >>
> >> repository design
> >> ----------------------
> >> I am thinking of just having a very simple web server denoted as a
> >> repository where the plugins are just zip or tar archives that expand to
> >> OFBiz components. For example, if the repository URL is www.example.com
> >> then the plugin could be www.example.com/plugins/Specif
> >> icPluginHere.tar.gz.
> >> It downloads to the specialpurpose (hopefully renamed to plugins) to
> >> expand
> >> and install
> >>
> >
> > I'm for removing the difference between specialpurpose and hot-deploy.
> > Why? Simplification!
> >
> > We should remove specialpurpose and rename hot-deploy into plugins.
> > This also means that we should have a Gradle task to automatically
> > download and install a plugin.
> > All current specialpurpose would become plugins available in the repo
> > easily installable using something like
> >     gradlew installPlugins plugins1Name plugins2Name etc.
> > I don't see the need to have a differentiated task to install only 1
> plugin
> >
> > The repo should be installed on the new OFBIZ-VM2
> >
> > We know that, like for the misnamed hot-deploy, installing a plugin will
> > need a restart of the OFBiz instance.
> > So this can't be dynamically done (at least for now), but need to be at
> > least automated.
> >
> > The only current issue is if we have dependencies among plugins.
> > For now we can simply documented them for users to set their own
> > component-load.xml
> >
> > BTW as a reminder, after OFBIZ-6760 we need to update
> > https://cwiki.apache.org/confluence/display/OFBIZ/Component+
> > and+Component+Set+Dependencies
> > And possibly complete the possible existing interdependencies between
> > specialpurpose components, though I can't remember any, but I feel I'm
> > wrong here.
> >
> >
> > dependencies
> >> ------------------
> >> This is a complicated subject, and there are a few ideas I have in mind:
> >> - Try to deploy the gradle project dependency model
> >>
> >
> > I'd like to know if you crossed issues with that and if yes what they
> are.
> > If it's the case can't we share the burden?
> >
> > - Alternatively write custom dependency resolution
> >>
> >
> > Please no :)
> >
> > However, this might be too complex to kickstart the project, and I think
> >> perhaps we can start without a dependency management system and
> implement
> >> it in a later stage.
> >>
> >
> > Yes why not? Baby steps for the win
> >
> > Jacques
> >
> >
> >
> >> Thank you in advance for your help and feedback.
> >>
> >> Taher Alkhateeb
> >>
> >>
> >
>

[taher]

Hi Pierre,

- The system can and does work with zip and tar.gz and normal folders.
- The maven repo provides everything we need especially dependency
management. I think upgrading from from your solution to the one I
suggested below might be difficult once an ecosystem builds around the
plug-in system.
- I prefer specialpurpose over hot-deploy becauae of the added value of
activating deactivating components (also easily automated)
- The publishPlugin task takes care of all the details in making your
plugin published as a maven artifact, so you don't do anything by hand.

So I have a solution that works and tested in code. The implementation is
not big because of utilizing established standards like maven and gradle
embedded plugins.

Taher Alkhateeb

On Aug 29, 2016 9:37 AM, "Pierre Smits" <[hidden email]> wrote:

> This solutions must be able to work with:
>
>    - zip files
>    - tar files and other zip variants (tar.gz, etc)
>    - folder structures.
>
> That will enable the adopter to use local storage, but also releases stored
> in GitHub or even svn repos.
>
> At the moment I see the use of maven repos as overkill, adding unnecessary
> complexity when developing extensions. OFBiz is not that complex.. Unless
> we want to have a full-fledged Eclipse-like plugin management solution from
> the start. This is not low-hanging fruit, but rather something to have
> later in the life-cycle of the solution maturity wise. Quick-win, at the
> moment, would be that something could be retrieved from svn, github or
> local folder and deployed in the hot-deploy folder.
>
> I guess I need to see this solution in combination with an example/demo
> component that requires all the elements described in the PoC and the
> earlier postings in this ml.
>
> Best regards,
>
> Pierre Smits
>
> ORRTIZ.COM <http://www.orrtiz.com>
> OFBiz based solutions & services
>
> OFBiz Extensions Marketplace
> http://oem.ofbizci.net/oci-2/
>
> On Sun, Aug 28, 2016 at 6:41 PM, Taher Alkhateeb <
> [hidden email]
> > wrote:
>
> > Hi Everyone,
> >
> > I am very happy to announce that after a lot of research I finally have a
> > little working PoC solution for the OFBiz plugin system. I believe this
> > system is very simple yet very powerful with the following simple API
> tasks
> >
> > 1- ./gradlew createPlugin: creates a plugin from templates
> > 2- ./gradlew installPlugin: downloads a plugin and all its dependency
> > plugins from a maven repository(it could be local, remote, jcenter,
> > whatever), extracts the archives, add the plugin to component-load.xml,
> and
> > calls the install task.
> > 3- ./gradlew uninstallPlugin: calls the uninstall task, removes the
> plugin
> > from component-load.xml, and deletes the plugin (but ignores
> dependencies).
> > 4- ./gradlew publishPlugin: create a maven compatible package that can be
> > published to either a local or a remote repository.
> >
> > So what is very powerful about this solution? Well, you use the maven
> > format for your packages, so you can host it on any maven repository
> > including jcenter. Also, you have a standard way of declaring
> dependencies
> > (pom.xml) and you pretty much gain all the benefits that comes with maven
> > packages (versioning, dependencies, meta data, etc ...)
> >
> > The solution can be expanded later on, but I think the above provides a
> > good starting point. Ideas? Feedback? Should I go ahead and fine-tune /
> > share the PoC on JIRA?
> >
> > Regards,
> >
> > Taher Alkhateeb
> >
> > On Fri, Aug 26, 2016 at 6:17 PM, Jacques Le Roux <
> > [hidden email]> wrote:
> >
> > > Le 25/08/2016 à 16:39, Taher Alkhateeb a écrit :
> > >
> > >> Hello Everyone,
> > >>
> > >> I need some opinions for a PoC that I'm working on for the plugin
> system
> > >> (OFBIZ-7972) and appreciate your help:
> > >>
> > >> repository design
> > >> ----------------------
> > >> I am thinking of just having a very simple web server denoted as a
> > >> repository where the plugins are just zip or tar archives that expand
> to
> > >> OFBiz components. For example, if the repository URL is
> www.example.com
> > >> then the plugin could be www.example.com/plugins/Specif
> > >> icPluginHere.tar.gz.
> > >> It downloads to the specialpurpose (hopefully renamed to plugins) to
> > >> expand
> > >> and install
> > >>
> > >
> > > I'm for removing the difference between specialpurpose and hot-deploy.
> > > Why? Simplification!
> > >
> > > We should remove specialpurpose and rename hot-deploy into plugins.
> > > This also means that we should have a Gradle task to automatically
> > > download and install a plugin.
> > > All current specialpurpose would become plugins available in the repo
> > > easily installable using something like
> > >     gradlew installPlugins plugins1Name plugins2Name etc.
> > > I don't see the need to have a differentiated task to install only 1
> > plugin
> > >
> > > The repo should be installed on the new OFBIZ-VM2
> > >
> > > We know that, like for the misnamed hot-deploy, installing a plugin
> will
> > > need a restart of the OFBiz instance.
> > > So this can't be dynamically done (at least for now), but need to be at
> > > least automated.
> > >
> > > The only current issue is if we have dependencies among plugins.
> > > For now we can simply documented them for users to set their own
> > > component-load.xml
> > >
> > > BTW as a reminder, after OFBIZ-6760 we need to update
> > > https://cwiki.apache.org/confluence/display/OFBIZ/Component+
> > > and+Component+Set+Dependencies
> > > And possibly complete the possible existing interdependencies between
> > > specialpurpose components, though I can't remember any, but I feel I'm
> > > wrong here.
> > >
> > >
> > > dependencies
> > >> ------------------
> > >> This is a complicated subject, and there are a few ideas I have in
> mind:
> > >> - Try to deploy the gradle project dependency model
> > >>
> > >
> > > I'd like to know if you crossed issues with that and if yes what they
> > are.
> > > If it's the case can't we share the burden?
> > >
> > > - Alternatively write custom dependency resolution
> > >>
> > >
> > > Please no :)
> > >
> > > However, this might be too complex to kickstart the project, and I
> think
> > >> perhaps we can start without a dependency management system and
> > implement
> > >> it in a later stage.
> > >>
> > >
> > > Yes why not? Baby steps for the win
> > >
> > > Jacques
> > >
> > >
> > >
> > >> Thank you in advance for your help and feedback.
> > >>
> > >> Taher Alkhateeb
> > >>
> > >>
> > >
> >
>

[Pierre Smits]

Hi Taher,

Like I said earlier: I need to be able to see it working. Could you upload
your solution as a patch to the issue you created earlier?

Best regards,

Pierre Smits

ORRTIZ.COM <http://www.orrtiz.com>
OFBiz based solutions & services

OFBiz Extensions Marketplace
http://oem.ofbizci.net/oci-2/

On Mon, Aug 29, 2016 at 8:51 AM, Taher Alkhateeb <[hidden email]
> wrote:

> Hi Pierre,
>
> - The system can and does work with zip and tar.gz and normal folders.
> - The maven repo provides everything we need especially dependency
> management. I think upgrading from from your solution to the one I
> suggested below might be difficult once an ecosystem builds around the
> plug-in system.
> - I prefer specialpurpose over hot-deploy becauae of the added value of
> activating deactivating components (also easily automated)
> - The publishPlugin task takes care of all the details in making your
> plugin published as a maven artifact, so you don't do anything by hand.
>
> So I have a solution that works and tested in code. The implementation is
> not big because of utilizing established standards like maven and gradle
> embedded plugins.
>
> Taher Alkhateeb
>
> On Aug 29, 2016 9:37 AM, "Pierre Smits" <[hidden email]> wrote:
>
> > This solutions must be able to work with:
> >
> >    - zip files
> >    - tar files and other zip variants (tar.gz, etc)
> >    - folder structures.
> >
> > That will enable the adopter to use local storage, but also releases
> stored
> > in GitHub or even svn repos.
> >
> > At the moment I see the use of maven repos as overkill, adding
> unnecessary
> > complexity when developing extensions. OFBiz is not that complex.. Unless
> > we want to have a full-fledged Eclipse-like plugin management solution
> from
> > the start. This is not low-hanging fruit, but rather something to have
> > later in the life-cycle of the solution maturity wise. Quick-win, at the
> > moment, would be that something could be retrieved from svn, github or
> > local folder and deployed in the hot-deploy folder.
> >
> > I guess I need to see this solution in combination with an example/demo
> > component that requires all the elements described in the PoC and the
> > earlier postings in this ml.
> >
> > Best regards,
> >
> > Pierre Smits
> >
> > ORRTIZ.COM <http://www.orrtiz.com>
> > OFBiz based solutions & services
> >
> > OFBiz Extensions Marketplace
> > http://oem.ofbizci.net/oci-2/
> >
> > On Sun, Aug 28, 2016 at 6:41 PM, Taher Alkhateeb <
> > [hidden email]
> > > wrote:
> >
> > > Hi Everyone,
> > >
> > > I am very happy to announce that after a lot of research I finally
> have a
> > > little working PoC solution for the OFBiz plugin system. I believe this
> > > system is very simple yet very powerful with the following simple API
> > tasks
> > >
> > > 1- ./gradlew createPlugin: creates a plugin from templates
> > > 2- ./gradlew installPlugin: downloads a plugin and all its dependency
> > > plugins from a maven repository(it could be local, remote, jcenter,
> > > whatever), extracts the archives, add the plugin to component-load.xml,
> > and
> > > calls the install task.
> > > 3- ./gradlew uninstallPlugin: calls the uninstall task, removes the
> > plugin
> > > from component-load.xml, and deletes the plugin (but ignores
> > dependencies).
> > > 4- ./gradlew publishPlugin: create a maven compatible package that can
> be
> > > published to either a local or a remote repository.
> > >
> > > So what is very powerful about this solution? Well, you use the maven
> > > format for your packages, so you can host it on any maven repository
> > > including jcenter. Also, you have a standard way of declaring
> > dependencies
> > > (pom.xml) and you pretty much gain all the benefits that comes with
> maven
> > > packages (versioning, dependencies, meta data, etc ...)
> > >
> > > The solution can be expanded later on, but I think the above provides a
> > > good starting point. Ideas? Feedback? Should I go ahead and fine-tune /
> > > share the PoC on JIRA?
> > >
> > > Regards,
> > >
> > > Taher Alkhateeb
> > >
> > > On Fri, Aug 26, 2016 at 6:17 PM, Jacques Le Roux <
> > > [hidden email]> wrote:
> > >
> > > > Le 25/08/2016 à 16:39, Taher Alkhateeb a écrit :
> > > >
> > > >> Hello Everyone,
> > > >>
> > > >> I need some opinions for a PoC that I'm working on for the plugin
> > system
> > > >> (OFBIZ-7972) and appreciate your help:
> > > >>
> > > >> repository design
> > > >> ----------------------
> > > >> I am thinking of just having a very simple web server denoted as a
> > > >> repository where the plugins are just zip or tar archives that
> expand
> > to
> > > >> OFBiz components. For example, if the repository URL is
> > www.example.com
> > > >> then the plugin could be www.example.com/plugins/Specif
> > > >> icPluginHere.tar.gz.
> > > >> It downloads to the specialpurpose (hopefully renamed to plugins) to
> > > >> expand
> > > >> and install
> > > >>
> > > >
> > > > I'm for removing the difference between specialpurpose and
> hot-deploy.
> > > > Why? Simplification!
> > > >
> > > > We should remove specialpurpose and rename hot-deploy into plugins.
> > > > This also means that we should have a Gradle task to automatically
> > > > download and install a plugin.
> > > > All current specialpurpose would become plugins available in the repo
> > > > easily installable using something like
> > > >     gradlew installPlugins plugins1Name plugins2Name etc.
> > > > I don't see the need to have a differentiated task to install only 1
> > > plugin
> > > >
> > > > The repo should be installed on the new OFBIZ-VM2
> > > >
> > > > We know that, like for the misnamed hot-deploy, installing a plugin
> > will
> > > > need a restart of the OFBiz instance.
> > > > So this can't be dynamically done (at least for now), but need to be
> at
> > > > least automated.
> > > >
> > > > The only current issue is if we have dependencies among plugins.
> > > > For now we can simply documented them for users to set their own
> > > > component-load.xml
> > > >
> > > > BTW as a reminder, after OFBIZ-6760 we need to update
> > > > https://cwiki.apache.org/confluence/display/OFBIZ/Component+
> > > > and+Component+Set+Dependencies
> > > > And possibly complete the possible existing interdependencies between
> > > > specialpurpose components, though I can't remember any, but I feel
> I'm
> > > > wrong here.
> > > >
> > > >
> > > > dependencies
> > > >> ------------------
> > > >> This is a complicated subject, and there are a few ideas I have in
> > mind:
> > > >> - Try to deploy the gradle project dependency model
> > > >>
> > > >
> > > > I'd like to know if you crossed issues with that and if yes what they
> > > are.
> > > > If it's the case can't we share the burden?
> > > >
> > > > - Alternatively write custom dependency resolution
> > > >>
> > > >
> > > > Please no :)
> > > >
> > > > However, this might be too complex to kickstart the project, and I
> > think
> > > >> perhaps we can start without a dependency management system and
> > > implement
> > > >> it in a later stage.
> > > >>
> > > >
> > > > Yes why not? Baby steps for the win
> > > >
> > > > Jacques
> > > >
> > > >
> > > >
> > > >> Thank you in advance for your help and feedback.
> > > >>
> > > >> Taher Alkhateeb
> > > >>
> > > >>
> > > >
> > >
> >
>

[taher]

Yup sure, I'll fine tune some issues and upload a patch just as was done in
Gradle. Wanted initial feedback first on the idea.

On Aug 29, 2016 10:10 AM, "Pierre Smits" <[hidden email]> wrote:

> Hi Taher,
>
> Like I said earlier: I need to be able to see it working. Could you upload
> your solution as a patch to the issue you created earlier?
>
> Best regards,
>
> Pierre Smits
>
> ORRTIZ.COM <http://www.orrtiz.com>
> OFBiz based solutions & services
>
> OFBiz Extensions Marketplace
> http://oem.ofbizci.net/oci-2/
>
> On Mon, Aug 29, 2016 at 8:51 AM, Taher Alkhateeb <
> [hidden email]
> > wrote:
>
> > Hi Pierre,
> >
> > - The system can and does work with zip and tar.gz and normal folders.
> > - The maven repo provides everything we need especially dependency
> > management. I think upgrading from from your solution to the one I
> > suggested below might be difficult once an ecosystem builds around the
> > plug-in system.
> > - I prefer specialpurpose over hot-deploy becauae of the added value of
> > activating deactivating components (also easily automated)
> > - The publishPlugin task takes care of all the details in making your
> > plugin published as a maven artifact, so you don't do anything by hand.
> >
> > So I have a solution that works and tested in code. The implementation is
> > not big because of utilizing established standards like maven and gradle
> > embedded plugins.
> >
> > Taher Alkhateeb
> >
> > On Aug 29, 2016 9:37 AM, "Pierre Smits" <[hidden email]> wrote:
> >
> > > This solutions must be able to work with:
> > >
> > >    - zip files
> > >    - tar files and other zip variants (tar.gz, etc)
> > >    - folder structures.
> > >
> > > That will enable the adopter to use local storage, but also releases
> > stored
> > > in GitHub or even svn repos.
> > >
> > > At the moment I see the use of maven repos as overkill, adding
> > unnecessary
> > > complexity when developing extensions. OFBiz is not that complex..
> Unless
> > > we want to have a full-fledged Eclipse-like plugin management solution
> > from
> > > the start. This is not low-hanging fruit, but rather something to have
> > > later in the life-cycle of the solution maturity wise. Quick-win, at
> the
> > > moment, would be that something could be retrieved from svn, github or
> > > local folder and deployed in the hot-deploy folder.
> > >
> > > I guess I need to see this solution in combination with an example/demo
> > > component that requires all the elements described in the PoC and the
> > > earlier postings in this ml.
> > >
> > > Best regards,
> > >
> > > Pierre Smits
> > >
> > > ORRTIZ.COM <http://www.orrtiz.com>
> > > OFBiz based solutions & services
> > >
> > > OFBiz Extensions Marketplace
> > > http://oem.ofbizci.net/oci-2/
> > >
> > > On Sun, Aug 28, 2016 at 6:41 PM, Taher Alkhateeb <
> > > [hidden email]
> > > > wrote:
> > >
> > > > Hi Everyone,
> > > >
> > > > I am very happy to announce that after a lot of research I finally
> > have a
> > > > little working PoC solution for the OFBiz plugin system. I believe
> this
> > > > system is very simple yet very powerful with the following simple API
> > > tasks
> > > >
> > > > 1- ./gradlew createPlugin: creates a plugin from templates
> > > > 2- ./gradlew installPlugin: downloads a plugin and all its dependency
> > > > plugins from a maven repository(it could be local, remote, jcenter,
> > > > whatever), extracts the archives, add the plugin to
> component-load.xml,
> > > and
> > > > calls the install task.
> > > > 3- ./gradlew uninstallPlugin: calls the uninstall task, removes the
> > > plugin
> > > > from component-load.xml, and deletes the plugin (but ignores
> > > dependencies).
> > > > 4- ./gradlew publishPlugin: create a maven compatible package that
> can
> > be
> > > > published to either a local or a remote repository.
> > > >
> > > > So what is very powerful about this solution? Well, you use the maven
> > > > format for your packages, so you can host it on any maven repository
> > > > including jcenter. Also, you have a standard way of declaring
> > > dependencies
> > > > (pom.xml) and you pretty much gain all the benefits that comes with
> > maven
> > > > packages (versioning, dependencies, meta data, etc ...)
> > > >
> > > > The solution can be expanded later on, but I think the above
> provides a
> > > > good starting point. Ideas? Feedback? Should I go ahead and
> fine-tune /
> > > > share the PoC on JIRA?
> > > >
> > > > Regards,
> > > >
> > > > Taher Alkhateeb
> > > >
> > > > On Fri, Aug 26, 2016 at 6:17 PM, Jacques Le Roux <
> > > > [hidden email]> wrote:
> > > >
> > > > > Le 25/08/2016 à 16:39, Taher Alkhateeb a écrit :
> > > > >
> > > > >> Hello Everyone,
> > > > >>
> > > > >> I need some opinions for a PoC that I'm working on for the plugin
> > > system
> > > > >> (OFBIZ-7972) and appreciate your help:
> > > > >>
> > > > >> repository design
> > > > >> ----------------------
> > > > >> I am thinking of just having a very simple web server denoted as a
> > > > >> repository where the plugins are just zip or tar archives that
> > expand
> > > to
> > > > >> OFBiz components. For example, if the repository URL is
> > > www.example.com
> > > > >> then the plugin could be www.example.com/plugins/Specif
> > > > >> icPluginHere.tar.gz.
> > > > >> It downloads to the specialpurpose (hopefully renamed to plugins)
> to
> > > > >> expand
> > > > >> and install
> > > > >>
> > > > >
> > > > > I'm for removing the difference between specialpurpose and
> > hot-deploy.
> > > > > Why? Simplification!
> > > > >
> > > > > We should remove specialpurpose and rename hot-deploy into plugins.
> > > > > This also means that we should have a Gradle task to automatically
> > > > > download and install a plugin.
> > > > > All current specialpurpose would become plugins available in the
> repo
> > > > > easily installable using something like
> > > > >     gradlew installPlugins plugins1Name plugins2Name etc.
> > > > > I don't see the need to have a differentiated task to install only
> 1
> > > > plugin
> > > > >
> > > > > The repo should be installed on the new OFBIZ-VM2
> > > > >
> > > > > We know that, like for the misnamed hot-deploy, installing a plugin
> > > will
> > > > > need a restart of the OFBiz instance.
> > > > > So this can't be dynamically done (at least for now), but need to
> be
> > at
> > > > > least automated.
> > > > >
> > > > > The only current issue is if we have dependencies among plugins.
> > > > > For now we can simply documented them for users to set their own
> > > > > component-load.xml
> > > > >
> > > > > BTW as a reminder, after OFBIZ-6760 we need to update
> > > > > https://cwiki.apache.org/confluence/display/OFBIZ/Component+
> > > > > and+Component+Set+Dependencies
> > > > > And possibly complete the possible existing interdependencies
> between
> > > > > specialpurpose components, though I can't remember any, but I feel
> > I'm
> > > > > wrong here.
> > > > >
> > > > >
> > > > > dependencies
> > > > >> ------------------
> > > > >> This is a complicated subject, and there are a few ideas I have in
> > > mind:
> > > > >> - Try to deploy the gradle project dependency model
> > > > >>
> > > > >
> > > > > I'd like to know if you crossed issues with that and if yes what
> they
> > > > are.
> > > > > If it's the case can't we share the burden?
> > > > >
> > > > > - Alternatively write custom dependency resolution
> > > > >>
> > > > >
> > > > > Please no :)
> > > > >
> > > > > However, this might be too complex to kickstart the project, and I
> > > think
> > > > >> perhaps we can start without a dependency management system and
> > > > implement
> > > > >> it in a later stage.
> > > > >>
> > > > >
> > > > > Yes why not? Baby steps for the win
> > > > >
> > > > > Jacques
> > > > >
> > > > >
> > > > >
> > > > >> Thank you in advance for your help and feedback.
> > > > >>
> > > > >> Taher Alkhateeb
> > > > >>
> > > > >>
> > > > >
> > > >
> > >
> >
>

[Nicolas Malin-2]

Hi Taher

Le 28/08/2016 à 18:41, Taher Alkhateeb a écrit :
> Hi Everyone,
>
> I am very happy to announce that after a lot of research I finally have a
> little working PoC solution for the OFBiz plugin system. I believe this
> system is very simple yet very powerful with the following simple API tasks
Nice

> 1- ./gradlew createPlugin: creates a plugin from templates
> 2- ./gradlew installPlugin: downloads a plugin and all its dependency
> plugins from a maven repository(it could be local, remote, jcenter,
> whatever), extracts the archives, add the plugin to component-load.xml, and
> calls the install task.
> 3- ./gradlew uninstallPlugin: calls the uninstall task, removes the plugin
> from component-load.xml, and deletes the plugin (but ignores dependencies).
> 4- ./gradlew publishPlugin: create a maven compatible package that can be
> published to either a local or a remote repository.
>
> So what is very powerful about this solution? Well, you use the maven
> format for your packages, so you can host it on any maven repository
> including jcenter. Also, you have a standard way of declaring dependencies
> (pom.xml) and you pretty much gain all the benefits that comes with maven
> packages (versioning, dependencies, meta data, etc ...)
>
> The solution can be expanded later on, but I think the above provides a
> good starting point. Ideas? Feedback? Should I go ahead and fine-tune /
> share the PoC on JIRA?

Use maven pkg is a good start, and I down know other system for package
format (escape deb package but oriented for operating system)
To continue your Poc I propose to sharing ;) and we can try to convert
some specialpurpose component as test.

Now I detect three potential problem :
  * install/uninstall plugin would be execute some control to
add/update/remove data (maybe by standard service). This would be manage
by a next step
  * When a plugin modify the data-model (adding a new  attribute by
extend-entity or new entity), artifact would be identify the origin
  * When a plugin add a service it would be identify
The two last point is important look my eyes because when you analyses
OFBiz to deploy business solution, it's important to detect where come
from each element who works on the solution and detect the potential
depends. With addon manager I had the case where I break my code because
an addon add an irrelevant attribute on standard entity who we beleive
that already in ofbiz. It's really a painfullest that we can escape :)

But finally, Great way Taher :D

>
> Regards,
>
> Taher Alkhateeb
>
> On Fri, Aug 26, 2016 at 6:17 PM, Jacques Le Roux <
> [hidden email]> wrote:
>
>> Le 25/08/2016 à 16:39, Taher Alkhateeb a écrit :
>>
>>> Hello Everyone,
>>>
>>> I need some opinions for a PoC that I'm working on for the plugin system
>>> (OFBIZ-7972) and appreciate your help:
>>>
>>> repository design
>>> ----------------------
>>> I am thinking of just having a very simple web server denoted as a
>>> repository where the plugins are just zip or tar archives that expand to
>>> OFBiz components. For example, if the repository URL is www.example.com
>>> then the plugin could be www.example.com/plugins/Specif
>>> icPluginHere.tar.gz.
>>> It downloads to the specialpurpose (hopefully renamed to plugins) to
>>> expand
>>> and install
>>>
>> I'm for removing the difference between specialpurpose and hot-deploy.
>> Why? Simplification!
>>
>> We should remove specialpurpose and rename hot-deploy into plugins.
>> This also means that we should have a Gradle task to automatically
>> download and install a plugin.
>> All current specialpurpose would become plugins available in the repo
>> easily installable using something like
>>      gradlew installPlugins plugins1Name plugins2Name etc.
>> I don't see the need to have a differentiated task to install only 1 plugin
>>
>> The repo should be installed on the new OFBIZ-VM2
>>
>> We know that, like for the misnamed hot-deploy, installing a plugin will
>> need a restart of the OFBiz instance.
>> So this can't be dynamically done (at least for now), but need to be at
>> least automated.
>>
>> The only current issue is if we have dependencies among plugins.
>> For now we can simply documented them for users to set their own
>> component-load.xml
>>
>> BTW as a reminder, after OFBIZ-6760 we need to update
>> https://cwiki.apache.org/confluence/display/OFBIZ/Component+
>> and+Component+Set+Dependencies
>> And possibly complete the possible existing interdependencies between
>> specialpurpose components, though I can't remember any, but I feel I'm
>> wrong here.
>>
>>
>> dependencies
>>> ------------------
>>> This is a complicated subject, and there are a few ideas I have in mind:
>>> - Try to deploy the gradle project dependency model
>>>
>> I'd like to know if you crossed issues with that and if yes what they are.
>> If it's the case can't we share the burden?
>>
>> - Alternatively write custom dependency resolution
>> Please no :)
>>
>> However, this might be too complex to kickstart the project, and I think
>>> perhaps we can start without a dependency management system and implement
>>> it in a later stage.
>>>
>> Yes why not? Baby steps for the win
>>
>> Jacques
>>
>>
>>
>>> Thank you in advance for your help and feedback.
>>>
>>> Taher Alkhateeb
>>>
>>>

[Jacques Le Roux]

Hi Taher,

While working on notsoserial, I got an idea about using JitPack in conjunction with GitHub for OFBiz-Gradle plugins.
JitPack has a MIT license and allows to freely use standard GitHub repositories (like https://github.com/apache/ofbiz)*.
*

When you use JitPackyou don't download jars but build jars in your Gradle cache from the sources on GitHub.

For instance it was very easy for me to directly compile notsoserial (https://github.com/kantega/notsoserial they have a pom.xml there) and have the
jar put in my Gradle cache.

JitPack allows also to use private (but not free) repositories https://jitpack.io/private. This could maybe make sense to provide paid plugins. But
because only a credential is needed to gain access, it's maybe not enough, you would have to create a paid repo by client.

The FAQ is here https://github.com/jitpack/jitpack.io/blob/master/FAQ.md

So it would be easier for us (OFBiz team) and contributors to deliver (at least free) plugins w/o having to publish then in a Maven or "Gradle"
(jcenter) repository.
A simple project in GitHub, done! When you know how GitHub changed the open source world it's IMO interesting, simple and efficient.

Jacques

Le 28/08/2016 à 18:41, Taher Alkhateeb a écrit :

> Hi Everyone,
>
> I am very happy to announce that after a lot of research I finally have a
> little working PoC solution for the OFBiz plugin system. I believe this
> system is very simple yet very powerful with the following simple API tasks
>
> 1- ./gradlew createPlugin: creates a plugin from templates
> 2- ./gradlew installPlugin: downloads a plugin and all its dependency
> plugins from a maven repository(it could be local, remote, jcenter,
> whatever), extracts the archives, add the plugin to component-load.xml, and
> calls the install task.
> 3- ./gradlew uninstallPlugin: calls the uninstall task, removes the plugin
> from component-load.xml, and deletes the plugin (but ignores dependencies).
> 4- ./gradlew publishPlugin: create a maven compatible package that can be
> published to either a local or a remote repository.
>
> So what is very powerful about this solution? Well, you use the maven
> format for your packages, so you can host it on any maven repository
> including jcenter. Also, you have a standard way of declaring dependencies
> (pom.xml) and you pretty much gain all the benefits that comes with maven
> packages (versioning, dependencies, meta data, etc ...)
>
> The solution can be expanded later on, but I think the above provides a
> good starting point. Ideas? Feedback? Should I go ahead and fine-tune /
> share the PoC on JIRA?
>
> Regards,
>
> Taher Alkhateeb
>
> On Fri, Aug 26, 2016 at 6:17 PM, Jacques Le Roux <
> [hidden email]> wrote:
>
>> Le 25/08/2016 à 16:39, Taher Alkhateeb a écrit :
>>
>>> Hello Everyone,
>>>
>>> I need some opinions for a PoC that I'm working on for the plugin system
>>> (OFBIZ-7972) and appreciate your help:
>>>
>>> repository design
>>> ----------------------
>>> I am thinking of just having a very simple web server denoted as a
>>> repository where the plugins are just zip or tar archives that expand to
>>> OFBiz components. For example, if the repository URL is www.example.com
>>> then the plugin could be www.example.com/plugins/Specif
>>> icPluginHere.tar.gz.
>>> It downloads to the specialpurpose (hopefully renamed to plugins) to
>>> expand
>>> and install
>>>
>> I'm for removing the difference between specialpurpose and hot-deploy.
>> Why? Simplification!
>>
>> We should remove specialpurpose and rename hot-deploy into plugins.
>> This also means that we should have a Gradle task to automatically
>> download and install a plugin.
>> All current specialpurpose would become plugins available in the repo
>> easily installable using something like
>>      gradlew installPlugins plugins1Name plugins2Name etc.
>> I don't see the need to have a differentiated task to install only 1 plugin
>>
>> The repo should be installed on the new OFBIZ-VM2
>>
>> We know that, like for the misnamed hot-deploy, installing a plugin will
>> need a restart of the OFBiz instance.
>> So this can't be dynamically done (at least for now), but need to be at
>> least automated.
>>
>> The only current issue is if we have dependencies among plugins.
>> For now we can simply documented them for users to set their own
>> component-load.xml
>>
>> BTW as a reminder, after OFBIZ-6760 we need to update
>> https://cwiki.apache.org/confluence/display/OFBIZ/Component+
>> and+Component+Set+Dependencies
>> And possibly complete the possible existing interdependencies between
>> specialpurpose components, though I can't remember any, but I feel I'm
>> wrong here.
>>
>>
>> dependencies
>>> ------------------
>>> This is a complicated subject, and there are a few ideas I have in mind:
>>> - Try to deploy the gradle project dependency model
>>>
>> I'd like to know if you crossed issues with that and if yes what they are.
>> If it's the case can't we share the burden?
>>
>> - Alternatively write custom dependency resolution
>> Please no :)
>>
>> However, this might be too complex to kickstart the project, and I think
>>> perhaps we can start without a dependency management system and implement
>>> it in a later stage.
>>>
>> Yes why not? Baby steps for the win
>>
>> Jacques
>>
>>
>>
>>> Thank you in advance for your help and feedback.
>>>
>>> Taher Alkhateeb
>>>
>>>

[taher]

Hi Jacques,

JitPack is indeed a nice service and plugin. However I think it might not
be a good fit for the plugin system because:

- You're mixing up jar dependencies with components. OFBiz components are
not jars and do not require pre-compilation. The primary purpose of JitPack
is to build jars on demand if they are not available on public repos.
- it requires rewriting all components to allow publishing.
- it depends on a single vendor (vendor lock in)
- it requires service registration to use.
- it does not provide dependency management
- it is less flexible. Maven packages can contain anything and can be
hosted everywhere (localhost, jcenter, maven central, private maven, etc).

So not only is it not compatible with OFBiz components but also more
complex to use as described above.

Taher Alkhateeb

On Sep 9, 2016 12:31 AM, "Jacques Le Roux" <[hidden email]>
wrote:

> Hi Taher,
>
> While working on notsoserial, I got an idea about using JitPack in
> conjunction with GitHub for OFBiz-Gradle plugins.
> JitPack has a MIT license and allows to freely use standard GitHub
> repositories (like https://github.com/apache/ofbiz)*.
> *
>
> When you use JitPackyou don't download jars but build jars in your Gradle
> cache from the sources on GitHub.
>
> For instance it was very easy for me to directly compile notsoserial (
> https://github.com/kantega/notsoserial they have a pom.xml there) and
> have the jar put in my Gradle cache.
>
> JitPack allows also to use private (but not free) repositories
> https://jitpack.io/private. This could maybe make sense to provide paid
> plugins. But because only a credential is needed to gain access, it's maybe
> not enough, you would have to create a paid repo by client.
>
> The FAQ is here https://github.com/jitpack/jitpack.io/blob/master/FAQ.md
>
> So it would be easier for us (OFBiz team) and contributors to deliver (at
> least free) plugins w/o having to publish then in a Maven or "Gradle"
> (jcenter) repository.
> A simple project in GitHub, done! When you know how GitHub changed the
> open source world it's IMO interesting, simple and efficient.
>
> Jacques
>
> Le 28/08/2016 à 18:41, Taher Alkhateeb a écrit :
>
>> Hi Everyone,
>>
>> I am very happy to announce that after a lot of research I finally have a
>> little working PoC solution for the OFBiz plugin system. I believe this
>> system is very simple yet very powerful with the following simple API
>> tasks
>>
>> 1- ./gradlew createPlugin: creates a plugin from templates
>> 2- ./gradlew installPlugin: downloads a plugin and all its dependency
>> plugins from a maven repository(it could be local, remote, jcenter,
>> whatever), extracts the archives, add the plugin to component-load.xml,
>> and
>> calls the install task.
>> 3- ./gradlew uninstallPlugin: calls the uninstall task, removes the plugin
>> from component-load.xml, and deletes the plugin (but ignores
>> dependencies).
>> 4- ./gradlew publishPlugin: create a maven compatible package that can be
>> published to either a local or a remote repository.
>>
>> So what is very powerful about this solution? Well, you use the maven
>> format for your packages, so you can host it on any maven repository
>> including jcenter. Also, you have a standard way of declaring dependencies
>> (pom.xml) and you pretty much gain all the benefits that comes with maven
>> packages (versioning, dependencies, meta data, etc ...)
>>
>> The solution can be expanded later on, but I think the above provides a
>> good starting point. Ideas? Feedback? Should I go ahead and fine-tune /
>> share the PoC on JIRA?
>>
>> Regards,
>>
>> Taher Alkhateeb
>>
>> On Fri, Aug 26, 2016 at 6:17 PM, Jacques Le Roux <
>> [hidden email]> wrote:
>>
>> Le 25/08/2016 à 16:39, Taher Alkhateeb a écrit :
>>>
>>> Hello Everyone,
>>>>
>>>> I need some opinions for a PoC that I'm working on for the plugin system
>>>> (OFBIZ-7972) and appreciate your help:
>>>>
>>>> repository design
>>>> ----------------------
>>>> I am thinking of just having a very simple web server denoted as a
>>>> repository where the plugins are just zip or tar archives that expand to
>>>> OFBiz components. For example, if the repository URL is www.example.com
>>>> then the plugin could be www.example.com/plugins/Specif
>>>> icPluginHere.tar.gz.
>>>> It downloads to the specialpurpose (hopefully renamed to plugins) to
>>>> expand
>>>> and install
>>>>
>>>> I'm for removing the difference between specialpurpose and hot-deploy.
>>> Why? Simplification!
>>>
>>> We should remove specialpurpose and rename hot-deploy into plugins.
>>> This also means that we should have a Gradle task to automatically
>>> download and install a plugin.
>>> All current specialpurpose would become plugins available in the repo
>>> easily installable using something like
>>>      gradlew installPlugins plugins1Name plugins2Name etc.
>>> I don't see the need to have a differentiated task to install only 1
>>> plugin
>>>
>>> The repo should be installed on the new OFBIZ-VM2
>>>
>>> We know that, like for the misnamed hot-deploy, installing a plugin will
>>> need a restart of the OFBiz instance.
>>> So this can't be dynamically done (at least for now), but need to be at
>>> least automated.
>>>
>>> The only current issue is if we have dependencies among plugins.
>>> For now we can simply documented them for users to set their own
>>> component-load.xml
>>>
>>> BTW as a reminder, after OFBIZ-6760 we need to update
>>> https://cwiki.apache.org/confluence/display/OFBIZ/Component+
>>> and+Component+Set+Dependencies
>>> And possibly complete the possible existing interdependencies between
>>> specialpurpose components, though I can't remember any, but I feel I'm
>>> wrong here.
>>>
>>>
>>> dependencies
>>>
>>>> ------------------
>>>> This is a complicated subject, and there are a few ideas I have in mind:
>>>> - Try to deploy the gradle project dependency model
>>>>
>>>> I'd like to know if you crossed issues with that and if yes what they
>>> are.
>>> If it's the case can't we share the burden?
>>>
>>> - Alternatively write custom dependency resolution
>>> Please no :)
>>>
>>> However, this might be too complex to kickstart the project, and I think
>>>
>>>> perhaps we can start without a dependency management system and
>>>> implement
>>>> it in a later stage.
>>>>
>>>> Yes why not? Baby steps for the win
>>>
>>> Jacques
>>>
>>>
>>>
>>> Thank you in advance for your help and feedback.
>>>>
>>>> Taher Alkhateeb
>>>>
>>>>
>>>>
>

[Jacques Le Roux]

Taher, inline...

Le 09/09/2016 à 05:40, Taher Alkhateeb a écrit :
> Hi Jacques,
>
> JitPack is indeed a nice service and plugin. However I think it might not
> be a good fit for the plugin system because:
>
> - You're mixing up jar dependencies with components. OFBiz components are
> not jars and do not require pre-compilation. The primary purpose of JitPack
> is to build jars on demand if they are not available on public repos.

Yes that's my point, we would have something dynamic, could be a good complement when working together on a plugin, together could be only the plugin
provider and the plugin user
It's easier for the plugin provider to fix an issue and faster for the plugin user to get the stuff up to date. Because you don't have to upload to a
Maven repo. We could even use the -SNAPSHOT feature. Of course this is only intended for the development phase, but why not?

> - it requires rewriting all components to allow publishing.

We could use it only as a complement

> - it depends on a single vendor (vendor lock in)

It's not a vendor, it's freely available, so are a lot of things we use. If it disappears, then the feature will disappear with it, not preventing us
to continue to use the main way.

> - it requires service registration to use.

Not at all, I did not register, simply used the patch I send in a message in the other thread

> - it does not provide dependency management

Right, it should be used with care, like you use a replacement wheel

> - it is less flexible. Maven packages can contain anything and can be
> hosted everywhere (localhost, jcenter, maven central, private maven, etc).

It's only a complement not a replacement

> So not only is it not compatible with OFBiz components but also more
> complex to use as described above.

It's very easy to use, here is the patch again, nothing else needed and does not prevent anything

Index: build.gradle
===================================================================
--- build.gradle    (revision 1759557)
+++ build.gradle    (working copy)
@@ -30,12 +30,6 @@
  // operating system property
  ext.os = System.getProperty('os.name').toLowerCase()

-// java settings
-def jvmArguments = ['-Xms128M', '-Xmx1024M',
- "-javaagent:${rootDir}/tools/security/notsoserial/notsoserial-1.0-SNAPSHOT.jar",
- "-Dnotsoserial.whitelist=${rootDir}/tools/security/notsoserial/empty.txt",
- "-Dnotsoserial.dryrun=${rootDir}/tools/security/notsoserial/is-deserialized.txt",
- "-Dnotsoserial.trace=${rootDir}/tools/security/notsoserial/deserialize-trace.txt"]
  ext.ofbizMainClass = 'org.apache.ofbiz.base.start.Start'
  javadoc.failOnError = false
  sourceCompatibility = '1.8'
@@ -52,6 +46,7 @@
  allprojects {
      repositories{
          jcenter()
+        maven { url "https://jitpack.io" }
      }
  }

@@ -119,6 +114,7 @@
      compile 'org.zapodot:jackson-databind-java-optional:2.4.2'
      compile 'oro:oro:2.0.8'
      compile 'wsdl4j:wsdl4j:1.6.2'
+    compile 'com.github.kantega:notsoserial:f2baaaa'

      // general framework runtime libs
      runtime 'de.odysseus.juel:juel-spi:2.2.7'
@@ -176,6 +172,16 @@
      runtime files("${rootDir}/build/libs/ofbiz-base-test.jar")
  }

+// Java settings, must be after the dependencies block to avoid a: org.gradle.api.InvalidUserDataException:
+// Cannot change dependencies of configuration ':compile' after it has been resolved.
+def notsoerialFileNameWithPath = project.configurations.compile.find { it.name.startsWith("notsoserial-") }
+def jvmArguments = ['-Xms128M', '-Xmx1024M',
+    "-javaagent:" + notsoerialFileNameWithPath,
+ "-Dnotsoserial.whitelist=${rootDir}/tools/security/notsoserial/empty.txt",
+ "-Dnotsoserial.dryrun=${rootDir}/tools/security/notsoserial/is-deserialized.txt",
+ "-Dnotsoserial.trace=${rootDir}/tools/security/notsoserial/deserialize-trace.txt"]
+
+
  def excludedJavaSources = []
  excludedJavaSources.add 'org/apache/ofbiz/accounting/thirdparty/cybersource/IcsPaymentServices.java'
  excludedJavaSources.add 'org/apache/ofbiz/accounting/thirdparty/ideal/IdealEvents.java'

Jacques

>
> Taher Alkhateeb
>
> On Sep 9, 2016 12:31 AM, "Jacques Le Roux" <[hidden email]>
> wrote:
>
>> Hi Taher,
>>
>> While working on notsoserial, I got an idea about using JitPack in
>> conjunction with GitHub for OFBiz-Gradle plugins.
>> JitPack has a MIT license and allows to freely use standard GitHub
>> repositories (like https://github.com/apache/ofbiz)*.
>> *
>>
>> When you use JitPackyou don't download jars but build jars in your Gradle
>> cache from the sources on GitHub.
>>
>> For instance it was very easy for me to directly compile notsoserial (
>> https://github.com/kantega/notsoserial they have a pom.xml there) and
>> have the jar put in my Gradle cache.
>>
>> JitPack allows also to use private (but not free) repositories
>> https://jitpack.io/private. This could maybe make sense to provide paid
>> plugins. But because only a credential is needed to gain access, it's maybe
>> not enough, you would have to create a paid repo by client.
>>
>> The FAQ is here https://github.com/jitpack/jitpack.io/blob/master/FAQ.md
>>
>> So it would be easier for us (OFBiz team) and contributors to deliver (at
>> least free) plugins w/o having to publish then in a Maven or "Gradle"
>> (jcenter) repository.
>> A simple project in GitHub, done! When you know how GitHub changed the
>> open source world it's IMO interesting, simple and efficient.
>>
>> Jacques
>>
>> Le 28/08/2016 à 18:41, Taher Alkhateeb a écrit :
>>
>>> Hi Everyone,
>>>
>>> I am very happy to announce that after a lot of research I finally have a
>>> little working PoC solution for the OFBiz plugin system. I believe this
>>> system is very simple yet very powerful with the following simple API
>>> tasks
>>>
>>> 1- ./gradlew createPlugin: creates a plugin from templates
>>> 2- ./gradlew installPlugin: downloads a plugin and all its dependency
>>> plugins from a maven repository(it could be local, remote, jcenter,
>>> whatever), extracts the archives, add the plugin to component-load.xml,
>>> and
>>> calls the install task.
>>> 3- ./gradlew uninstallPlugin: calls the uninstall task, removes the plugin
>>> from component-load.xml, and deletes the plugin (but ignores
>>> dependencies).
>>> 4- ./gradlew publishPlugin: create a maven compatible package that can be
>>> published to either a local or a remote repository.
>>>
>>> So what is very powerful about this solution? Well, you use the maven
>>> format for your packages, so you can host it on any maven repository
>>> including jcenter. Also, you have a standard way of declaring dependencies
>>> (pom.xml) and you pretty much gain all the benefits that comes with maven
>>> packages (versioning, dependencies, meta data, etc ...)
>>>
>>> The solution can be expanded later on, but I think the above provides a
>>> good starting point. Ideas? Feedback? Should I go ahead and fine-tune /
>>> share the PoC on JIRA?
>>>
>>> Regards,
>>>
>>> Taher Alkhateeb
>>>
>>> On Fri, Aug 26, 2016 at 6:17 PM, Jacques Le Roux <
>>> [hidden email]> wrote:
>>>
>>> Le 25/08/2016 à 16:39, Taher Alkhateeb a écrit :
>>>> Hello Everyone,
>>>>> I need some opinions for a PoC that I'm working on for the plugin system
>>>>> (OFBIZ-7972) and appreciate your help:
>>>>>
>>>>> repository design
>>>>> ----------------------
>>>>> I am thinking of just having a very simple web server denoted as a
>>>>> repository where the plugins are just zip or tar archives that expand to
>>>>> OFBiz components. For example, if the repository URL is www.example.com
>>>>> then the plugin could be www.example.com/plugins/Specif
>>>>> icPluginHere.tar.gz.
>>>>> It downloads to the specialpurpose (hopefully renamed to plugins) to
>>>>> expand
>>>>> and install
>>>>>
>>>>> I'm for removing the difference between specialpurpose and hot-deploy.
>>>> Why? Simplification!
>>>>
>>>> We should remove specialpurpose and rename hot-deploy into plugins.
>>>> This also means that we should have a Gradle task to automatically
>>>> download and install a plugin.
>>>> All current specialpurpose would become plugins available in the repo
>>>> easily installable using something like
>>>>       gradlew installPlugins plugins1Name plugins2Name etc.
>>>> I don't see the need to have a differentiated task to install only 1
>>>> plugin
>>>>
>>>> The repo should be installed on the new OFBIZ-VM2
>>>>
>>>> We know that, like for the misnamed hot-deploy, installing a plugin will
>>>> need a restart of the OFBiz instance.
>>>> So this can't be dynamically done (at least for now), but need to be at
>>>> least automated.
>>>>
>>>> The only current issue is if we have dependencies among plugins.
>>>> For now we can simply documented them for users to set their own
>>>> component-load.xml
>>>>
>>>> BTW as a reminder, after OFBIZ-6760 we need to update
>>>> https://cwiki.apache.org/confluence/display/OFBIZ/Component+
>>>> and+Component+Set+Dependencies
>>>> And possibly complete the possible existing interdependencies between
>>>> specialpurpose components, though I can't remember any, but I feel I'm
>>>> wrong here.
>>>>
>>>>
>>>> dependencies
>>>>
>>>>> ------------------
>>>>> This is a complicated subject, and there are a few ideas I have in mind:
>>>>> - Try to deploy the gradle project dependency model
>>>>>
>>>>> I'd like to know if you crossed issues with that and if yes what they
>>>> are.
>>>> If it's the case can't we share the burden?
>>>>
>>>> - Alternatively write custom dependency resolution
>>>> Please no :)
>>>>
>>>> However, this might be too complex to kickstart the project, and I think
>>>>
>>>>> perhaps we can start without a dependency management system and
>>>>> implement
>>>>> it in a later stage.
>>>>>
>>>>> Yes why not? Baby steps for the win
>>>> Jacques
>>>>
>>>>
>>>>
>>>> Thank you in advance for your help and feedback.
>>>>> Taher Alkhateeb
>>>>>
>>>>>
>>>>>

[Jacopo Cappellato-5]

On Thu, Sep 8, 2016 at 11:31 PM, Jacques Le Roux <
[hidden email]> 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

[taher]

Hi Jacques,

Perhaps I did not emphasize this point so I'll try to make it clear:

JitPack does not work! It creates jars from github projects which are not
published. Therefore it does not fit as a complement to plugins which are
just OFBiz components.

If you want to use the latest version of a plugin or you don't want to
publish it to a maven repo, then just clone the repository into
/specialpurpose and run the install task and you're done.

So we will only need this plugin if we have libraries (jars not plugins)
that we need in OFBiz that exist in github and are not published in any
maven repo (like jcenter or mavencentral, etc...)

Taher Alkhateeb

On Sep 9, 2016 8:36 AM, "Jacques Le Roux" <[hidden email]>
wrote:

> Taher, inline...
>
> Le 09/09/2016 à 05:40, Taher Alkhateeb a écrit :
>
>> Hi Jacques,
>>
>> JitPack is indeed a nice service and plugin. However I think it might not
>> be a good fit for the plugin system because:
>>
>> - You're mixing up jar dependencies with components. OFBiz components are
>> not jars and do not require pre-compilation. The primary purpose of
>> JitPack
>> is to build jars on demand if they are not available on public repos.
>>
>
> Yes that's my point, we would have something dynamic, could be a good
> complement when working together on a plugin, together could be only the
> plugin provider and the plugin user
> It's easier for the plugin provider to fix an issue and faster for the
> plugin user to get the stuff up to date. Because you don't have to upload
> to a Maven repo. We could even use the -SNAPSHOT feature. Of course this is
> only intended for the development phase, but why not?
>
> - it requires rewriting all components to allow publishing.
>>
>
> We could use it only as a complement
>
> - it depends on a single vendor (vendor lock in)
>>
>
> It's not a vendor, it's freely available, so are a lot of things we use.
> If it disappears, then the feature will disappear with it, not preventing
> us to continue to use the main way.
>
> - it requires service registration to use.
>>
>
> Not at all, I did not register, simply used the patch I send in a message
> in the other thread
>
> - it does not provide dependency management
>>
>
> Right, it should be used with care, like you use a replacement wheel
>
> - it is less flexible. Maven packages can contain anything and can be
>> hosted everywhere (localhost, jcenter, maven central, private maven, etc).
>>
>
> It's only a complement not a replacement
>
> So not only is it not compatible with OFBiz components but also more
>> complex to use as described above.
>>
>
> It's very easy to use, here is the patch again, nothing else needed and
> does not prevent anything
>
> Index: build.gradle
> ===================================================================
> --- build.gradle    (revision 1759557)
> +++ build.gradle    (working copy)
> @@ -30,12 +30,6 @@
>  // operating system property
>  ext.os = System.getProperty('os.name').toLowerCase()
>
> -// java settings
> -def jvmArguments = ['-Xms128M', '-Xmx1024M',
> - "-javaagent:${rootDir}/tools/security/notsoserial/notsoseria
> l-1.0-SNAPSHOT.jar",
> - "-Dnotsoserial.whitelist=${rootDir}/tools/security/notsoseri
> al/empty.txt",
> - "-Dnotsoserial.dryrun=${rootDir}/tools/security/notsoserial/
> is-deserialized.txt",
> - "-Dnotsoserial.trace=${rootDir}/tools/security/notsoserial/
> deserialize-trace.txt"]
>  ext.ofbizMainClass = 'org.apache.ofbiz.base.start.Start'
>  javadoc.failOnError = false
>  sourceCompatibility = '1.8'
> @@ -52,6 +46,7 @@
>  allprojects {
>      repositories{
>          jcenter()
> +        maven { url "https://jitpack.io" }
>      }
>  }
>
> @@ -119,6 +114,7 @@
>      compile 'org.zapodot:jackson-databind-java-optional:2.4.2'
>      compile 'oro:oro:2.0.8'
>      compile 'wsdl4j:wsdl4j:1.6.2'
> +    compile 'com.github.kantega:notsoserial:f2baaaa'
>
>      // general framework runtime libs
>      runtime 'de.odysseus.juel:juel-spi:2.2.7'
> @@ -176,6 +172,16 @@
>      runtime files("${rootDir}/build/libs/ofbiz-base-test.jar")
>  }
>
> +// Java settings, must be after the dependencies block to avoid a:
> org.gradle.api.InvalidUserDataException:
> +// Cannot change dependencies of configuration ':compile' after it has
> been resolved.
> +def notsoerialFileNameWithPath = project.configurations.compile.find {
> it.name.startsWith("notsoserial-") }
> +def jvmArguments = ['-Xms128M', '-Xmx1024M',
> +    "-javaagent:" + notsoerialFileNameWithPath,
> + "-Dnotsoserial.whitelist=${rootDir}/tools/security/notsoseri
> al/empty.txt",
> + "-Dnotsoserial.dryrun=${rootDir}/tools/security/notsoserial/
> is-deserialized.txt",
> + "-Dnotsoserial.trace=${rootDir}/tools/security/notsoserial/
> deserialize-trace.txt"]
> +
> +
>  def excludedJavaSources = []
>  excludedJavaSources.add 'org/apache/ofbiz/accounting/t
> hirdparty/cybersource/IcsPaymentServices.java'
>  excludedJavaSources.add 'org/apache/ofbiz/accounting/t
> hirdparty/ideal/IdealEvents.java'
>
> Jacques
>
>
>
>> Taher Alkhateeb
>>
>> On Sep 9, 2016 12:31 AM, "Jacques Le Roux" <[hidden email]>
>> wrote:
>>
>> Hi Taher,
>>>
>>> While working on notsoserial, I got an idea about using JitPack in
>>> conjunction with GitHub for OFBiz-Gradle plugins.
>>> JitPack has a MIT license and allows to freely use standard GitHub
>>> repositories (like https://github.com/apache/ofbiz)*.
>>> *
>>>
>>> When you use JitPackyou don't download jars but build jars in your Gradle
>>> cache from the sources on GitHub.
>>>
>>> For instance it was very easy for me to directly compile notsoserial (
>>> https://github.com/kantega/notsoserial they have a pom.xml there) and
>>> have the jar put in my Gradle cache.
>>>
>>> JitPack allows also to use private (but not free) repositories
>>> https://jitpack.io/private. This could maybe make sense to provide paid
>>> plugins. But because only a credential is needed to gain access, it's
>>> maybe
>>> not enough, you would have to create a paid repo by client.
>>>
>>> The FAQ is here https://github.com/jitpack/jitpack.io/blob/master/FAQ.md
>>>
>>> So it would be easier for us (OFBiz team) and contributors to deliver (at
>>> least free) plugins w/o having to publish then in a Maven or "Gradle"
>>> (jcenter) repository.
>>> A simple project in GitHub, done! When you know how GitHub changed the
>>> open source world it's IMO interesting, simple and efficient.
>>>
>>> Jacques
>>>
>>> Le 28/08/2016 à 18:41, Taher Alkhateeb a écrit :
>>>
>>> Hi Everyone,
>>>>
>>>> I am very happy to announce that after a lot of research I finally have
>>>> a
>>>> little working PoC solution for the OFBiz plugin system. I believe this
>>>> system is very simple yet very powerful with the following simple API
>>>> tasks
>>>>
>>>> 1- ./gradlew createPlugin: creates a plugin from templates
>>>> 2- ./gradlew installPlugin: downloads a plugin and all its dependency
>>>> plugins from a maven repository(it could be local, remote, jcenter,
>>>> whatever), extracts the archives, add the plugin to component-load.xml,
>>>> and
>>>> calls the install task.
>>>> 3- ./gradlew uninstallPlugin: calls the uninstall task, removes the
>>>> plugin
>>>> from component-load.xml, and deletes the plugin (but ignores
>>>> dependencies).
>>>> 4- ./gradlew publishPlugin: create a maven compatible package that can
>>>> be
>>>> published to either a local or a remote repository.
>>>>
>>>> So what is very powerful about this solution? Well, you use the maven
>>>> format for your packages, so you can host it on any maven repository
>>>> including jcenter. Also, you have a standard way of declaring
>>>> dependencies
>>>> (pom.xml) and you pretty much gain all the benefits that comes with
>>>> maven
>>>> packages (versioning, dependencies, meta data, etc ...)
>>>>
>>>> The solution can be expanded later on, but I think the above provides a
>>>> good starting point. Ideas? Feedback? Should I go ahead and fine-tune /
>>>> share the PoC on JIRA?
>>>>
>>>> Regards,
>>>>
>>>> Taher Alkhateeb
>>>>
>>>> On Fri, Aug 26, 2016 at 6:17 PM, Jacques Le Roux <
>>>> [hidden email]> wrote:
>>>>
>>>> Le 25/08/2016 à 16:39, Taher Alkhateeb a écrit :
>>>>
>>>>> Hello Everyone,
>>>>>
>>>>>> I need some opinions for a PoC that I'm working on for the plugin
>>>>>> system
>>>>>> (OFBIZ-7972) and appreciate your help:
>>>>>>
>>>>>> repository design
>>>>>> ----------------------
>>>>>> I am thinking of just having a very simple web server denoted as a
>>>>>> repository where the plugins are just zip or tar archives that expand
>>>>>> to
>>>>>> OFBiz components. For example, if the repository URL is
>>>>>> www.example.com
>>>>>> then the plugin could be www.example.com/plugins/Specif
>>>>>> icPluginHere.tar.gz.
>>>>>> It downloads to the specialpurpose (hopefully renamed to plugins) to
>>>>>> expand
>>>>>> and install
>>>>>>
>>>>>> I'm for removing the difference between specialpurpose and hot-deploy.
>>>>>>
>>>>> Why? Simplification!
>>>>>
>>>>> We should remove specialpurpose and rename hot-deploy into plugins.
>>>>> This also means that we should have a Gradle task to automatically
>>>>> download and install a plugin.
>>>>> All current specialpurpose would become plugins available in the repo
>>>>> easily installable using something like
>>>>>       gradlew installPlugins plugins1Name plugins2Name etc.
>>>>> I don't see the need to have a differentiated task to install only 1
>>>>> plugin
>>>>>
>>>>> The repo should be installed on the new OFBIZ-VM2
>>>>>
>>>>> We know that, like for the misnamed hot-deploy, installing a plugin
>>>>> will
>>>>> need a restart of the OFBiz instance.
>>>>> So this can't be dynamically done (at least for now), but need to be at
>>>>> least automated.
>>>>>
>>>>> The only current issue is if we have dependencies among plugins.
>>>>> For now we can simply documented them for users to set their own
>>>>> component-load.xml
>>>>>
>>>>> BTW as a reminder, after OFBIZ-6760 we need to update
>>>>> https://cwiki.apache.org/confluence/display/OFBIZ/Component+
>>>>> and+Component+Set+Dependencies
>>>>> And possibly complete the possible existing interdependencies between
>>>>> specialpurpose components, though I can't remember any, but I feel I'm
>>>>> wrong here.
>>>>>
>>>>>
>>>>> dependencies
>>>>>
>>>>> ------------------
>>>>>> This is a complicated subject, and there are a few ideas I have in
>>>>>> mind:
>>>>>> - Try to deploy the gradle project dependency model
>>>>>>
>>>>>> I'd like to know if you crossed issues with that and if yes what they
>>>>>>
>>>>> are.
>>>>> If it's the case can't we share the burden?
>>>>>
>>>>> - Alternatively write custom dependency resolution
>>>>> Please no :)
>>>>>
>>>>> However, this might be too complex to kickstart the project, and I
>>>>> think
>>>>>
>>>>> perhaps we can start without a dependency management system and
>>>>>> implement
>>>>>> it in a later stage.
>>>>>>
>>>>>> Yes why not? Baby steps for the win
>>>>>>
>>>>> Jacques
>>>>>
>>>>>
>>>>>
>>>>> Thank you in advance for your help and feedback.
>>>>>
>>>>>> Taher Alkhateeb
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>

[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 <
> [hidden email]> 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

[taher]

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 <
[hidden email]> wrote:

> Le 09/09/2016 à 10:32, Jacopo Cappellato a écrit :
>
>> On Thu, Sep 8, 2016 at 11:31 PM, Jacques Le Roux <
>> [hidden email]> 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
>
>

[Jacopo Cappellato-5]

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 <[hidden email]
> 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 <
> [hidden email]> wrote:
>
> > Le 09/09/2016 à 10:32, Jacopo Cappellato a écrit :
> >
> >> On Thu, Sep 8, 2016 at 11:31 PM, Jacques Le Roux <
> >> [hidden email]> 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
> >
> >
>

[taher]

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 <
[hidden email]> 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 <
> [hidden email]
> > 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 <
> > [hidden email]> wrote:
> >
> > > Le 09/09/2016 à 10:32, Jacopo Cappellato a écrit :
> > >
> > >> On Thu, Sep 8, 2016 at 11:31 PM, Jacques Le Roux <
> > >> [hidden email]> 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
> > >
> > >
> >
>

[taher]

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 <[hidden email]
> 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 <
>> [hidden email]
>> > 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 <
>> > [hidden email]> wrote:
>> >
>> > > Le 09/09/2016 à 10:32, Jacopo Cappellato a écrit :
>> > >
>> > >> On Thu, Sep 8, 2016 at 11:31 PM, Jacques Le Roux <
>> > >> [hidden email]> 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
>> > >
>> > >
>> >
>>
>
>

[Nicolas Malin-2]

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 <[hidden email]
>> 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 <
>>> [hidden email]
>>>> 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 <
>>>> [hidden email]> wrote:
>>>>
>>>>> Le 09/09/2016 à 10:32, Jacopo Cappellato a écrit :
>>>>>
>>>>>> On Thu, Sep 8, 2016 at 11:31 PM, Jacques Le Roux <
>>>>>> [hidden email]> 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
>>>>>
>>>>>
>>

[taher]

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 <[hidden email]>
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 <
>> [hidden email]
>>
>>> 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 <
>>>> [hidden email]
>>>>
>>>>> 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 <
>>>>> [hidden email]> wrote:
>>>>>
>>>>> Le 09/09/2016 à 10:32, Jacopo Cappellato a écrit :
>>>>>>
>>>>>> On Thu, Sep 8, 2016 at 11:31 PM, Jacques Le Roux <
>>>>>>> [hidden email]> 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
>>>>>>
>>>>>>
>>>>>>
>>>
>