The perception is growing that 2 different solutions are mixed into one... One solution is about jump starting development, the other is about on-boarding existing components into an OFBiz deployment.
If this plugin API/solution was intended for components existing outside of the OFBiz repo (either publicly available in repos like GitHub, or in private repos), I would understand the need for it. But when code is already available in the OFBiz repo - and made available through releases - such an enabler/disabler is as much overkill to an adopter as a convenience script to download JDBC libraries (to paraphrase another contributor). Best regards, Pierre Smits ORRTIZ.COM <http://www.orrtiz.com> OFBiz based solutions & services OFBiz Extensions Marketplace http://oem.ofbizci.net/oci-2/ On Sat, Jul 23, 2016 at 7:44 PM, Taher Alkhateeb <slidingfilame...@gmail.com > wrote: > Hi Gil, > > Thank you for sharing past experiences. It seems we are tackling something > that was attempted multiple times before. I am a bit optimistic though > because having the plugin system integrated into the build system is a > different approach that solves multiple problems I think. > > I would like to note that I think it is okay to use the same plugin system > even for proprietary customer solutions. In fact I think customers would > understand it more easily than the concept of hot-deploy. Even if the > solution is for one customer and not intended to be shared you can still > have a sensible command like ./gradlew installPlugin > -PpluginName=customerPlugin -Prepository=localFileSystem. > > Having one solution instead of two solutions I think would unify efforts > and thinking processes and terminology used. We have only one way of > extending OFBiz which is called plugins, and any changes we do happen in > this unified architecture. > > So ... food for thought. > > Taher Alkhateeb > > On Jul 23, 2016 7:34 PM, "gil portenseigne" <gil.portensei...@nereide.fr> > wrote: > > > Hi all, > > > > First, I like the idea of gradle being the plugin solution endebbed > within > > OFBiz. > > > > This could allow OFBiz integrators to share their specific improvments > > with a easy to use, OOTB tool (thinking about OfbizExtra addons or > Pierre's > > OEM initiatives to name a few). > > > > Then, from what i understand about what Nicolas said, is that it'd be > good > > to keep hot-deploy and create-component tasks for customer projects. > > > > Why not using plugin into customer project ? It is because that is a > > private, specific and complete new application using core and plugin > > functionnalities. It has to be separated since it is not a plugin (not > > intended to be shared). The plugin dependency could be solved with a > > build.gradle within the hot-deploy component, checking the installation > > state of the dependent plugin (and installing if needed). > > > > And last, for your information, Nereide do not use addons anymore, this > > system created more problems than it helped, the original idea was good, > > but some design flaws did showed up... > > Gil > > > > > > > > Le 23/07/2016 à 12:35, Jacques Le Roux a écrit : > > > > > > > > Le 22/07/2016 à 15:31, Nicolas Malin a écrit : > > > > Hi, > > > > Taher I like you proposal, and I wish to add some complement :) > > > > hot-deploy is to manage specific customer site component with the > business > > logic specific to each, Apache OFBiz can help to prepare this but do not > > more (I will like to have this as best practice) > > > > > > I think plugins could do that also > > > > > > I agree to add a new directory plugins and structure it for the future > > vision : > > * add capacity to download a plugin from the asf repo > > * support extension to download from a third plateform (like the > > /etc/apt/source.list on debian) > > * manage namespace and as you said dependencies. Need give some coding > > contions > > > > > > This should be in the specifications indeed, Taher already answered > > > > > > We can create the plugins directory, and keep specialpurpose on a first > > step and move step by step each component present. > > > > > > This is a very important point and we have to be very careful about the > > transition! > > > > Jacques > > > > > > I imagine a process like this : > > * ./gradlew installPlugin org.apache.ofbiz.framework.birt : > > -> check if birt is present on the plugins directory, if not download > > from > > > svn.apache.org/repos/asf/ofbiz-pulgins/branches/relatedRelease/org/apache/ofbiz/framework/birt > > -> enable it on component-load > > -> compile, load init date and run init service > > > > When you run ./gradlew installAllPlugin : > > * Realize installPlugin on all know plugins, with the official apache > > ofbiz release, only plugins present on > > > svn.apache.org/repos/asf/ofbiz-pulgins/branches/relatedRelease/org/apache/ofbiz/ > > > > Nicolas > > > > Le 20/07/2016 à 07:29, Taher Alkhateeb a écrit : > > > > Hi Pierre, all, > > > > I think perhaps my proposal was short and therefore your understanding of > > it is a bit different than what I had in mind. So I list below more > > specifically what I mean about each point from the ones you mentioned > > above > > to further fine-tune the discussion. > > > > - The difference between createComponent and createPlugin is that the > > plugin resides in /plugins instead of hot-deploy and added to > > component-load.xml and also contains a build.gradle file designed > > specifically for plugins. This script contains standard tasks like > > install, > > uninstall, perhaps even upgrade. The magic work for plugins will be in > > their build scripts to integrate tightly with OFBiz. > > > > - The activate/deactivate tasks are just a little convenience tasks that > > add/remove components to the component-load.xml instead of editing it by > > hand so it is just using what exists. Gradle completely ignores a > > component > > if it does not exist in component-load.xml and would not even compile it. > > So you can think of this as just providing more ease to the end-user, > > similar to your suggestion with the createComponent. > > > > - The install/uninstall tasks are not just a copy-paste of folders. It > > actually executes business logic (optionally) for any plugin author who > > wishes to execute it (by calling specific tasks in build.gradle for that > > plugin). For example, it might apply patches on some core applications > > (and > > reverse patches in case of uninstall). Now our standard plugins do not > > touch applications or framework, but since we are introducing this > feature > > I'm trying to also combine a unified solution for all plugins (Apache > > supported and 3rd party). So in one shot we have both ease of use for the > > existing components and at the same time a general purpose plugin system. > > We might even have a task like say "updatePlugin" in the future and it is > > also possible to introduce rudimentary dependency management (Gradle is > > really good at this). > > > > Finally, what to do about specialpurpose is something we should > definitely > > tackle, however what I am suggesting right now is some foundational work > > that gives you easy choices when you need to make them, and it has the > > added bonus of introducing a plugin system for OFBiz which is badly > needed > > to protect the core framework and applications and to provide an > > eco-system > > around it. I'm trying to reach a win-win solution if you will. > > > > Regards, > > > > Taher Alkhateeb > > > > On Wed, Jul 20, 2016 at 1:18 AM, Jacques Le Roux < > > jacques.le.r...@les7arts.com> wrote: > > > > Le 19/07/2016 à 22:57, Jacques Le Roux a écrit : > > > > the graph needs to be checked/amended to possibly remove components > > dependencies only introduced by the data model > > > > Sorry, I have noticed I have the bad tendency of using the word > > "introduced" instead of "put" or "add" (due to "introduire" false friend > > in > > French) please replace for me when you see it, thanks! :) > > Here the right word would have been "due to" instead of "introduced by" > > > > Jacques > > > > PS: http://www.etymonline.com/index.php?term=introduction > > > > > > > > > > > > > > >
