Hi Michael. If I understand your point correctly regarding ease of contribution, would it be a problem to just go to the plugin directory and issue a command like svn diff > plugin-fix.patch?
On Mon, Feb 13, 2017 at 12:54 PM, Michael Brohl <michael.br...@ecomify.de> wrote: > Hi Taher, > > inline... > > Am 13.02.17 um 06:33 schrieb Taher Alkhateeb: > >> Hi Michael, All >> >> All good points, thank you for your thoughts. So a solution that I >> proposed >> in jira to easily manage and maintain our official plugins is to have a >> gradle task named for example pullPluginSourceAll which pulls all the >> plugins in one shot for testing and development purposes. Maybe we can >> also >> add logic in this task so that it updates already downloaded plugins. >> > That's a good approach if you want to test plugins/integration within the > framework without the need to work on plugin sources under source control, > if I understand it right. This should be the default case. > > Additionally, I suggest to provide a task which creates the svn:externals > file for the case where you want the plugin sources in your project and > have them under source control. > Or, if we don't want to have such a task in the codebase, provide some > documentation on how to achieve this manually. > Maybe there are other good solutions as well. > > Else I cannot think of an easy process for a plugin developer to create > patches or make commits against the repository without hassle. > >> >> I'm sure there are other good ideas as well. My point of emphasis is to >> Simply keep the two projects clearly separated, and to avoid relying >> directly on tools not embedded within the framework like subversion. >> > I completely agree on this point and this should be the default. I just > think that we should provide some (non default) alternatives or at least > how-to's to make it easy for everyone to contribute. > We should think about different types of users and contributors. > > Regards, > > Michael > > >> On Feb 13, 2017 12:08 AM, "Michael Brohl" <michael.br...@ecomify.de> >> wrote: >> >> Hi, >>> >>> first of all: great work and many thanks to Taher, Jacques and Deepak for >>> their efforts on the repository separation this weekend. >>> >>> I think we should provide processes and support for the following cases: >>> >>> 1. separated development of the framework and core applications without >>> forced embedding of the plugins >>> >>> 2. separated development of the plugins with the support to embed the >>> framework part in the development environment >>> >>> 3. combined development of both framework and plugins. >>> >>> I think we'll need convenience tools/processes/support for these >>> combinations because we should make contributions for and use of >>> framework >>> + plugins as easy as possible without forcing the entanglement of the >>> different projects. >>> >>> As far as I understand forced use of svn:externals is contra productive >>> because it prevents the separation. We should instead describe the >>> mechanism and provide a set of svn:externals files for all users who want >>> to use it. Maybe also a gradle task which generates the needed file(s) >>> for >>> convenience. >>> >>> I think we cannot only rely on the pull plugin mechanism because combined >>> development needs to have framework and plugins in the IDE under version >>> control. >>> >>> Users and developers should have a choice (and low hurdles to >>> contribute), >>> on the other hand we should keep it lean and simple per default. >>> >>> Not sure if I could make my viewpoint clear enough, I'm currently too >>> tired to concentrate on better words :-) >>> >>> Best regards, >>> >>> Michael >>> >>> >>> Am 12.02.17 um 20:59 schrieb Taher Alkhateeb: >>> >>> Hi Sharan, >>>> >>>> I think this is not the topic under discussion, and since it seems vague >>>> to >>>> you I will try to clarify: >>>> >>>> The question now that we split framework and plugins is how to combine >>>> them. The discussion so far between myself and Jacques is as follows: >>>> - Jacques wants to use svn:externals so that subversion pulls all the >>>> plugins into the framework and keep everything as is (testing, builds, >>>> etc) >>>> the way they were. >>>> - My position is that we should use gradle to pull the plugins we need >>>> without reliance on Subversion or any other tool and to treat the two >>>> projects as two separate projects. >>>> >>>> Both reasons / concerns from me and Jacques are expressed by reading the >>>> history of this thread (that partly exists in another thread for which >>>> Deepak contributed his opinion). >>>> >>>> On Sun, Feb 12, 2017 at 10:49 PM, Sharan Foga <sha...@apache.org> >>>> wrote: >>>> >>>> Hi All >>>> >>>>> I'm not exactly completely sure what this discussion is all about. The >>>>> title talks about svn and Gradle but questions in the thread seem to >>>>> about >>>>> something different. If it is as important as you say then we need to >>>>> make >>>>> sure that everyone understands exactly what this means. >>>>> >>>>> Are you saying that because of the framework / plugin split then >>>>> committers will work only on the framework? If so, then remember that >>>>> it >>>>> was our contributors and committers that put the 'plugins' into OFBiz >>>>> in >>>>> the first place which means that people who are interested in >>>>> developing >>>>> a >>>>> particular functionality further can do it without worrying about or >>>>> breaking the framework. >>>>> >>>>> From my side I know that we also have some OFBiz application >>>>> documentation >>>>> that is sitting in docbook inside OFBiz I think would be better >>>>> implemented >>>>> as a plugin. It would be good to be able to work on and test this >>>>> separately. >>>>> >>>>> I apologise if I've misunderstood this thread but as I say - it's not >>>>> very >>>>> clear what it is all about. >>>>> >>>>> Thanks >>>>> Sharan >>>>> >>>>> On 2017-02-12 13:55 (+0100), Jacques Le Roux < >>>>> jacques.le.r...@les7arts.com> >>>>> wrote: >>>>> >>>>> Thanks Taher, >>>>>> >>>>>> I create a clean new thread to have it more prominent. >>>>>> >>>>>> This is really what needs to be discussed indeed. >>>>>> >>>>>> Are we sure that's what we want for plugins? >>>>>> >>>>>> Will they not be disregarded by committers? >>>>>> >>>>>> Will plugins follow the framework trend? >>>>>> >>>>>> This is a very important community decision. >>>>>> I hope everybody will (try to) understand the consequences and >>>>>> >>>>>> participate to this discussion, before it will be too late... >>>>> >>>>> Jacques >>>>>> >>>>>> >>>>>> Le 12/02/2017 � 13:32, Taher Alkhateeb a �crit : >>>>>> >>>>>> Let's take a look at the big picture for a moment before we decide. We >>>>>>> >>>>>>> have >>>>>> broken OFBiz into essentially two products: framework and plugins. >>>>>> >>>>>>> Why did we break it up? Why did we go through the trouble of creating >>>>>>> >>>>>>> two >>>>>> different repositories? I hope the answer is something like "because >>>>>> it is >>>>>> too big" or "because it carried a lot of non-essential functionality >>>>>> around" >>>>>> So breaking up the project brings the advantage of not having to >>>>>> _worry >>>>>> >>>>>>> about everything_ on each and every commit. These are two projects >>>>>>> >>>>>>> with two >>>>>> release cycles and they don't need to be developed together >>>>>> simultaneously. >>>>>> People can specialize and focus on different areas. >>>>>> >>>>>>> The whole idea of breaking the system up and then using gradle's >>>>>>> >>>>>>> plugin API >>>>>> for OFBiz is to remove the coupling between the two projects. If we >>>>>> >>>>>>> introduce svn externals then all we achieve is create two >>>>>>> repositories >>>>>>> only to merge them again. Why! that's pointless! >>>>>>> >>>>>>> Two products means two buildbot scripts, two releases, two >>>>>>> development >>>>>>> cycles, two different things! >>>>>>> >>>>>>> So to achieve true separation and decoupling, I suggest to avoid any >>>>>>> >>>>>>> hacks >>>>>> like svn externals. >>>>>> >>>>>>> On Sun, Feb 12, 2017 at 1:31 PM, Jacques Le Roux < >>>>>>> jacques.le.r...@les7arts.com> wrote: >>>>>>> >>>>>>> Hi All, >>>>>>> >>>>>>>> This discussion already happened at OFBIZ-9182, but only between >>>>>>>> >>>>>>>> Taher, >>>>>>> >>>>>> Nicolas and I. >>>>>> >>>>>>> The question is simple, below reflects it, and the subject summarises >>>>>>>> >>>>>>>> it. >>>>>>> >>>>>> So what are your thoughts and opinions? >>>>>> >>>>>>> Also when answering I guess we can remove '(was Re: Proposal to >>>>>>>> >>>>>>>> create a >>>>>>> >>>>>> separate svn repository for the OFBiz official plugins)' from the >>>>>> >>>>>>> subject >>>>>>> >>>>>> (I was just "lazy" here) >>>>>> >>>>>>> Thanks >>>>>>>> >>>>>>>> Jacques >>>>>>>> >>>>>>>> >>>>>>>> Le 12/02/2017 � 11:22, Jacques Le Roux a �crit : >>>>>>>> >>>>>>>> Sincerely I hardly see the benefit, but I see the disadvantages when >>>>>>>> I >>>>>>>> >>>>>>> remember what happened with R13.07. I mean how and by who will be >>>>>> >>>>>>> maintained the OOTB plugins? >>>>>>>>> >>>>>>>>> I think this should be more discussed, and maybe voted, here >>>>>>>>> >>>>>>>>> Jacques >>>>>>>>> >>>>>>>>> >>>>>>>>> Le 12/02/2017 � 11:18, Deepak Dixit a �crit : >>>>>>>>> >>>>>>>>> Hi Jacques, >>>>>>>>> >>>>>>>>>> We can add gradle task to pull all plugins from remote. As we are >>>>>>>>>> de-coupling plugins from core so I think its good idea to keep >>>>>>>>>> them >>>>>>>>>> separate. If any committer or developer want he can use gradle >>>>>>>>>> task >>>>>>>>>> >>>>>>>>>> for >>>>>>>>> >>>>>>>> the >>>>>> >>>>>>> same. >>>>>>>>>> >>>>>>>>>> Thanks & Regards >>>>>>>>>> -- >>>>>>>>>> Deepak Dixit >>>>>>>>>> www.hotwaxsystems.com >>>>>>>>>> >>>>>>>>>> On Sun, Feb 12, 2017 at 3:43 PM, Jacques Le Roux < >>>>>>>>>> jacques.le.r...@les7arts.com> wrote: >>>>>>>>>> >>>>>>>>>> Yes this is the idea, why should we not? How else committers will >>>>>>>>>> >>>>>>>>>> easily >>>>>>>>> >>>>>>>> maintain the plugins? >>>>>> >>>>>>> Jacques >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> Le 12/02/2017 � 10:25, Deepak Dixit a �crit : >>>>>>>>>>> >>>>>>>>>>> Hi Jacques, >>>>>>>>>>> >>>>>>>>>>> I think if wesvn:external on trunk, then it will always checkout >>>>>>>>>>>> >>>>>>>>>>>> the >>>>>>>>>>> >>>>>>>>>> plugins with trunk >>>>>> >>>>>>> >>>>>>>>>>>> Thanks & Regards >>>>>>>>>>>> -- >>>>>>>>>>>> Deepak Dixit >>>>>>>>>>>> www.hotwaxsystems.com >>>>>>>>>>>> >>>>>>>>>>>> On Sun, Feb 12, 2017 at 2:52 PM, Deepak Dixit < >>>>>>>>>>>> deepak.di...@hotwaxsystems.com> wrote: >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> >>> > >
