Hi Taher, Like I said earlier: I need to be able to see it working. Could you upload your solution as a patch to the issue you created earlier?
Best regards, Pierre Smits ORRTIZ.COM <http://www.orrtiz.com> OFBiz based solutions & services OFBiz Extensions Marketplace http://oem.ofbizci.net/oci-2/ On Mon, Aug 29, 2016 at 8:51 AM, Taher Alkhateeb <slidingfilame...@gmail.com > wrote: > 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 > > > >> > > > >> > > > > > > > > > >
