I think that the core reason for the failure is that most of the tests need the demo data that is loaded with the ecommerce component; if you disable it the data is not loaded. Could you please try to enable ecommerce and run them again?
Thanks, Jacopo On Wed, Jul 27, 2016 at 1:21 PM, Taher Alkhateeb <slidingfilame...@gmail.com > wrote: > 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 > >>> > >>> > >>> > >>> > >>> > >>> > >>> > >>> > > >
