Hi Pierre and Everyone, I gather you might be currently preoccupied to work on this JIRA. If my understanding is correct, then may I suggest to close this JIRA and other similar JIRAs and allow those interested in implementing the work to create their own JIRAs for the following reasons:
1- It is confusing to have too many JIRAs open that no one is working on which is likely to create duplicates. 2- I think it is fair for those who make the effort of designing, implementing, testing and patching to have their name on the JIRA as the Reporter as a recognition of their efforts. Taher Alkhateeb On Wed, Jul 27, 2016 at 6:39 PM, Taher Alkhateeb <slidingfilame...@gmail.com > wrote: > Would you be willing to take care of that task Pierre? > > On Jul 27, 2016 6:36 PM, "Pierre Smits" <pierre.sm...@gmail.com> wrote: > >> 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 >> > > > > >>> >> > > > > >>> >> > > > > >>> >> > > > > >>> >> > > > > >>> >> > > > > >>> >> > > > > >>> >> > > > > >>> >> > > > > > >> > > > > >> > > > >> > > >> > >> >
