Hi Pierre, - The system can and does work with zip and tar.gz and normal folders. - The maven repo provides everything we need especially dependency management. I think upgrading from from your solution to the one I suggested below might be difficult once an ecosystem builds around the plug-in system. - I prefer specialpurpose over hot-deploy becauae of the added value of activating deactivating components (also easily automated) - The publishPlugin task takes care of all the details in making your plugin published as a maven artifact, so you don't do anything by hand.
So I have a solution that works and tested in code. The implementation is not big because of utilizing established standards like maven and gradle embedded plugins. Taher Alkhateeb On Aug 29, 2016 9:37 AM, "Pierre Smits" <pierre.sm...@gmail.com> wrote: > 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 > > >> > > >> > > > > > >
