Initially ecommerce was part of the "core" applications, then it was moved to specialpurpose because as it it is a "template" for the implementation of an ecommerce store rather than a ready to be used application. I must admit that the same could apply to the other backend applications so there is definitely a grey area... For the short term we could consider to move the demo data up the stack.
Jacopo On Wed, Jul 27, 2016 at 5:10 PM, Taher Alkhateeb <slidingfilame...@gmail.com > wrote: > 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 > > > >>> > > > >>> > > > >>> > > > >>> > > > >>> > > > >>> > > > >>> > > > >>> > > > > > > > > > >
