Yup sure, I'll fine tune some issues and upload a patch just as was done in Gradle. Wanted initial feedback first on the idea.
On Aug 29, 2016 10:10 AM, "Pierre Smits" <[email protected]> wrote: > 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 < > [email protected] > > 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" <[email protected]> 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 < > > > [email protected] > > > > 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 < > > > > [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 > > > > >> > > > > >> > > > > > > > > > > > > > > >
