An issue regarding the move of data up the stack already exists: https://issues.apache.org/jira/browse/OFBIZ-7016
Best regards, Pierre Smits ORRTIZ.COM <http://www.orrtiz.com> OFBiz based solutions & services OFBiz Extensions Marketplace http://oem.ofbizci.net/oci-2/ On Wed, Jul 27, 2016 at 5:15 PM, Jacopo Cappellato < jacopo.cappell...@hotwaxsystems.com> wrote: > 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 > > > > >>> > > > > >>> > > > > >>> > > > > >>> > > > > >>> > > > > >>> > > > > >>> > > > > >>> > > > > > > > > > > > > > > >
