Hi everyone, In continuation with the above discussion, I just made a little experiment which gave me scary results. What did I do?
1 - Disabled all specialpurpose components (except example, to make it a valid XML file) in specialpurpose/component-load.xml 2 - Attempted ./gradlew cleanAll loadDefault testIntegration 3 - Got 100 failing tests So upon investigating a little I believe these tests fail due to multiple issues: - When we disable specialpurpose, the dependency graph for Jars changes and that breaks some system behavior - I suspect also some data loading is disabled which fails some of the tests - hidden dependencies exist from framework / applications to specialpurpose. What does that mean? It means our framework is brittle and depends on specialpurpose, and without it being active the system does not run properly. If we are serious about improving the system and making it modular, then I find it very important to start with disabling all specialpurpose components or at least having a second build in buildbot for those components in isolation of the framework. I don't think this is a luxury, I highly recommend that we stop the specialpurpose components from being active by default to protect and isolate the framework and core applications. Actually we need help from everyone who is willing to help to volunteer in getting a working build with tests passing while all specialpurpose components are disabled. Taher Alkhateeb On Sat, Jul 23, 2016 at 10:32 PM, Jacques Le Roux < jacques.le.r...@les7arts.com> wrote: > Hi Taher, Gil, > > Exactly my thoughts. Nothing (ethically and technically) should force an > user to share his/her/its personal plugins. This assumption must be part of > the specifications (assumption as in a theory) > > Thanks Taher! > > > > Le 23/07/2016 à 19:44, Taher Alkhateeb a écrit : > >> 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 >>> >>> >>> >>> >>> >>> >>> >>> >
