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
