Taher, Nicolas,
I like you plan Taher.
I had a small discussion with Nicolas by phone on this subject before he wrote his answer. I told me that he prefers to separate the OOTB things (aka
specialpurpose now) from the outside things (aka hot-deploy now)
I still think that if we have real plugins (a sole plugins folder with sub-folders for plugins - still to be clearly defined -, ie not current
components) he does not make sense to separate these two aspects.
But I'd need Nicolas to clarify why he thinks so.
Is it for legacy reasons (due to Neereides addons for instance)?
Does he has another plan?
Or does he have other reasons?
I know Nicolas has a long experience with addons, so it's worth to listen his
opinion before engaging to specify OFBiz plugins.
IIRW Neereides addons were using Ivy and patches, and we are proposing something new with Gradle and its jars dependencies engine + a specific DSL +
Groovy and the possibility to call Ant targets (eg for legacy transition). Did I miss something :) ?
Thanks
Jacques
Le 22/07/2016 à 15:58, Taher Alkhateeb a écrit :
Hi Nicolas,
Actually as I was discussing this with Jacques in one of the JIRAs he
mentioned something which I found very interesting:
If we create a full plugin API for creating a new plugin from templates and
we provide everything necessary for updating then perhaps hot-deploy is
even not that necessary anymore! it could simply be replaced with ./gradlew
installPlugin -PpluginName=thePluginExistingInFolder.
Also .. a lot of customization can be done with flags. So using your
example we can perhaps say something like:
./gradlew installPlugin -PpluginName=birt -Prepository=org.apache.ofbiz
or
./gradlew installPlugin -PpluginName=MyPlugin -Prepository=local
or
./gradlew installPlugin -PpluginName=commercialPlugin
-Prepository=com.someCompany
first one is default which is official OFBiz plugin, second one is local
file system, third one is commercial plugin for a company. Also we can
define a task in every plugin called "installDependencies" or something
like that which checks for dependent plugins and install them.
We can go crazy with this :) A lot of ideas are ringing in my head.
Taher Alkhateeb
On Friday, 22 July 2016, Nicolas Malin <nicolas.ma...@nereide.fr> wrote:
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 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
We can create the plugins directory, and keep specialpurpose on a first
step and move step by step each component present.
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
