Hi Jacopo, You got it 100% right, it was indeed the ecommerce component. Wow! This means one of two things should happen, either we move ecommerce as a core application, or we untangle this mess. I'm not very familiar with the history, is there a reason why ecommerce is a specialpurpose application? it seems to be highly integrated within the framework.
Taher Alkhateeb On Wed, Jul 27, 2016 at 4:01 PM, Jacopo Cappellato < jacopo.cappell...@hotwaxsystems.com> wrote: > 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 > > >>> > > >>> > > >>> > > >>> > > >>> > > >>> > > >>> > > >>> > > > > > >
