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 <slidingfilame...@gmail.com > 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 < > jacques.le.r...@les7arts.com> 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 > >> > >> > > >
