Re: [DISCUSSION] Proposed Task List for Moving Forward with Gradle and the Trunk

[gil portenseigne]

Hi all,

First, I like the idea of gradle being the plugin solution endebbed 
within OFBiz.

This could allow OFBiz integrators to share their specific improvments 
with a easy to use, OOTB tool (thinking about OfbizExtra addons or 
Pierre's OEM initiatives to name a few).

Then, from what i understand about what Nicolas said, is that it'd be 
good to keep hot-deploy and create-component tasks for customer projects.

Why not using plugin into customer project ? It is because that is a 
private, specific and complete new application using core and plugin 
functionnalities. It has to be separated since it is not a plugin (not 
intended to be shared). The plugin dependency could be solved with a 
build.gradle within the hot-deploy component, checking the installation 
state of the dependent plugin (and installing if needed).

And last, for your information, Nereide do not use addons anymore, this 
system created more problems than it helped, the original idea was good, 
but some design flaws did showed up...

Gil



Le 23/07/2016 à 12:35, Jacques Le Roux a écrit :


Le 22/07/2016 à 15:31, Nicolas Malin a écrit :
Hi,

Taher I like you proposal, and I wish to add some complement :)

hot-deploy is to manage specific customer site component with the 
business logic specific to each, Apache OFBiz can help to prepare 
this but do not more (I will like to have this as best practice)

I think plugins could do that also


I agree to add a new directory plugins and structure it for the 
future vision :
* add capacity to download a plugin from the asf repo
* support extension to download from a third plateform (like the 
/etc/apt/source.list on debian)
* manage namespace and as you said dependencies. Need give some 
coding contions

This should be in the specifications indeed, Taher already answered


We can create the plugins directory, and keep specialpurpose on a 
first step and move step by step each component present.

This is a very important point and we have to be very careful about 
the transition!

Jacques


I imagine a process like this :
* ./gradlew installPlugin org.apache.ofbiz.framework.birt :
 -> check if birt is present on the plugins directory, if not 
download from 
svn.apache.org/repos/asf/ofbiz-pulgins/branches/relatedRelease/org/apache/ofbiz/framework/birt
 -> enable it on component-load
 -> compile, load init date and run init service

When you run ./gradlew installAllPlugin :
* Realize installPlugin on all know plugins, with the official apache 
ofbiz release, only plugins present on 
svn.apache.org/repos/asf/ofbiz-pulgins/branches/relatedRelease/org/apache/ofbiz/

Nicolas

Le 20/07/2016 à 07:29, Taher Alkhateeb a écrit :
Hi Pierre, all,

I think perhaps my proposal was short and therefore your 
understanding of
it is a bit different than what I had in mind. So I list below more
specifically what I mean about each point from the ones you 
mentioned above
to further fine-tune the discussion.

- The difference between createComponent and createPlugin is that the
plugin resides in /plugins instead of hot-deploy and added to
component-load.xml and also contains a build.gradle file designed
specifically for plugins. This script contains standard tasks like 
install,
uninstall, perhaps even upgrade. The magic work for plugins will be in
their build scripts to integrate tightly with OFBiz.

- The activate/deactivate tasks are just a little convenience tasks 
that
add/remove components to the component-load.xml instead of editing 
it by
hand so it is just using what exists. Gradle completely ignores a 
component
if it does not exist in component-load.xml and would not even 
compile it.
So you can think of this as just providing more ease to the end-user,
similar to your suggestion with the createComponent.

- The install/uninstall tasks are not just a copy-paste of folders. It
actually executes business logic (optionally) for any plugin author who
wishes to execute it (by calling specific tasks in build.gradle for 
that
plugin). For example, it might apply patches on some core 
applications (and
reverse patches in case of uninstall). Now our standard plugins do not
touch applications or framework, but since we are introducing this 
feature
I'm trying to also combine a unified solution for all plugins (Apache
supported and 3rd party). So in one shot we have both ease of use 
for the
existing components and at the same time a general purpose plugin 
system.
We might even have a task like say "updatePlugin" in the future and 
it is
also possible to introduce rudimentary dependency management (Gradle is
really good at this).

Finally, what to do about specialpurpose is something we should 
definitely
tackle, however what I am suggesting right now is some foundational 
work
that gives you easy choices when you need to make them, and it has the
added bonus of introducing a plugin system for OFBiz which is badly 
needed
to protect the core framework and applications and to provide an 
eco-system
around it. I'm trying to reach a win-win solution if you will.

Regards,

Taher Alkhateeb

On Wed, Jul 20, 2016 at 1:18 AM, Jacques Le Roux <
jacques.le.r...@les7arts.com> wrote:

Le 19/07/2016 à 22:57, Jacques Le Roux a écrit :

the graph needs to be checked/amended to possibly remove components
dependencies only introduced by the data model

Sorry, I have noticed I have the bad tendency of using the word
"introduced" instead of "put" or "add" (due to "introduire" false 
friend in
French) please replace for me when you see it, thanks! :)
Here the right word would have been "due to" instead of "introduced 
by"

Jacques

PS: http://www.etymonline.com/index.php?term=introduction