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