Great, I'll continue discussion over there referring to this conversation. On Thu, Jul 28, 2016 at 10:03 AM, Sharan Foga <sharan.f...@gmail.com> wrote:
> Hi > > If we are talking about Jira and ways to handle or improve it for the > project then I did start a discussion thread a few days ago (link below) > > > https://lists.apache.org/thread.html/61d310a85759c89ca2aa2a18bdca945a9868caf5a1bff2fb72a774d8@%3Cdev.ofbiz.apache.org%3E > > It might be good to take this suggestion into that thread rather than > start an off-topic discussion here. > > Thanks > Sharan > > > On 28/07/16 08:54, Taher Alkhateeb wrote: > >> 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 >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> >
