Administrator
|
Hi All,
I'd like to complete the Gradle documentation at OFBIZ-7677 For that AFAIK only remain the "Patch Management Using Gradle Targets" section in the Addressing Custom Requirements wiki page 1) I'd like to know if people are still using the 4 targets, to create/apply/reapply/revert patches in the OOTB source code (ie framework, applications, specialpurpose) And if they do, if they plan to migrate them to Gradle (the /framework/resources/templates/build.xml has been removed) 2) In my experience they are useful as long as you live only in a dev environment but once you are moving to production across several areas (like test, qa, pre-prod, production) they are less useful. You then need something which allows you to place different patches depending on those areas. So I'd not be against not replacing them using Gradle and drop the related documentation section. Initially when I stumbled upon the problem of different patches for different areas I created and implemented OFBIZ-5819 (also documented in the "Patch Management Using Gradle Targets" section, more info at [4]) When we migrated to Gradle, Taher did most of the work[1] and was reluctant to migrate this part[2]. Having wrote it, I can understand. I have not looked into details yet, maybe it's easier now that we use this Gradle svn plugin[3] where we have SvnCreatePatch <https://github.com/martoe/gradle-svntools-plugin/blob/master/docs/SvnCreatePatch.md> and SvnApplyPatch <https://github.com/martoe/gradle-svntools-plugin/blob/master/docs/SvnApplyPatch.md> But before diving into this task, as I don't need it at the moment, I'd like to know if somebody else is interested. I believe nowadays most developers and teams are using Git branches for the same. So I'd like a confirmation on how you are handling changes you do inside the OOTB code (framework, applications or plugins). Of course, I don't speak about poking inside the code, but putting changes apart to take care of the coming updates/upgrades... [1] https://issues.apache.org/jira/browse/OFBIZ-7534 [2] https://issues.apache.org/jira/browse/OFBIZ-7962 [3] https://github.com/martoe/gradle-svntools-plugin [4] http://markmail.org/message/vm4mefkgustubkvr ------------------------------------------------------------------------------------------------------------------------------------------------------ Also what is the status about the points below? It seems it's all OK, but I'd like a confirmation. 6. Investigate how to create a plugin repository with dependencies clearly defined, not only on external libraries but also other plugins! 7. Investigate and propose a methodology for maintaining plugins and versioning compatibility with OFBiz. 8. Investigate and propose a methodology for upgrading plugins within OFBiz Thanks Jacques |
Administrator
|
Le 10/03/2017 à 19:10, Jacques Le Roux a écrit :
> So I'd like a confirmation on how you are handling changes you do inside the OOTB code (framework, applications or plugins). Of course, I don't > speak about poking inside the code, but putting changes apart to take care of the coming updates/upgrades... OK, it's now almost 4 days and I got any answers, so I guess this is no longer something of interest for the community. So * I set OFBIZ-7962 "Migrate the patch management Ant targets" as a postponed task * I completely struck the "Patch Management Using Gradle Targets" section and will let it as is. I will see later if I need to drop or update it. * I have closed OFBIZ-7677 "Update documentation with respect to implementation of gradle as a replacement of ant" For me the Ant to Gradle documentation is completely done. BTW while looking at OFBIZ-9256 "Split the tools folder from the trunk and put it in another branch" I noticed for OFBIZ-7677 I created a documentation folder under the tools directory. I believe now, before splitting the tools, we should put it directly under the root dir and put there all generic documentation, I'll do so w/o comment before doing OFBIZ-7677 Jacques |
Hi Jacques,
> OK, it's now almost 4 days and I got any answers, so I guess this is > no longer something of interest for the community. So I don't think that this is a valid conclusion. Not everyone has the time to daily read and answer on the mailing lists. Regards, Michael smime.p7s (5K) Download Attachment |
Administrator
|
Le 14/03/2017 à 09:12, Michael Brohl a écrit :
> Hi Jacques, >> OK, it's now almost 4 days and I got any answers, so I guess this is no longer something of interest for the community. So > I don't think that this is a valid conclusion. Not everyone has the time to daily read and answer on the mailing lists. > > Regards, > Michael > > Would you say a week (a weekend included) is enough? Jacques |
In reply to this post by Jacques Le Roux
Jaques,
we keep our changes to the OFBiz code in a git branch which we merge in after every OFBiz upgrade. The three way merge process in Git is excellent and saves us a lot of time compared to using patches. Regards, Hans On 14/03/17 15:08, Jacques Le Roux wrote: > Le 10/03/2017 à 19:10, Jacques Le Roux a écrit : >> So I'd like a confirmation on how you are handling changes you do >> inside the OOTB code (framework, applications or plugins). Of course, >> I don't speak about poking inside the code, but putting changes apart >> to take care of the coming updates/upgrades... > > OK, it's now almost 4 days and I got any answers, so I guess this is no > longer something of interest for the community. So > > * I set OFBIZ-7962 "Migrate the patch management Ant targets" as a > postponed task > * I completely struck the "Patch Management Using Gradle Targets" > section and will let it as is. I will see later if I need to drop or > update it. > * I have closed OFBIZ-7677 "Update documentation with respect to > implementation of gradle as a replacement of ant" > > For me the Ant to Gradle documentation is completely done. > > BTW while looking at OFBIZ-9256 "Split the tools folder from the trunk > and put it in another branch" I noticed for OFBIZ-7677 I created a > documentation folder under the tools directory. I believe now, before > splitting the tools, we should put it directly under the root dir and > put there all generic documentation, I'll do so w/o comment before doing > OFBIZ-7677 > > Jacques > > -- Regards, Hans Bakker CEO, http://antwebsystems.com |
Administrator
|
Thanks Hans (it's JaCques ;))
Yes, I guess that's what most team do now No problems with the new Github repos setting? Jacques Le 14/03/2017 à 09:33, Hans Bakker a écrit : > Jaques, > > we keep our changes to the OFBiz code in a git branch which we merge in after every OFBiz upgrade. The three way merge process in Git is excellent > and saves us a lot of time compared to using patches. > > Regards, > Hans > > On 14/03/17 15:08, Jacques Le Roux wrote: >> Le 10/03/2017 à 19:10, Jacques Le Roux a écrit : >>> So I'd like a confirmation on how you are handling changes you do >>> inside the OOTB code (framework, applications or plugins). Of course, >>> I don't speak about poking inside the code, but putting changes apart >>> to take care of the coming updates/upgrades... >> >> OK, it's now almost 4 days and I got any answers, so I guess this is no >> longer something of interest for the community. So >> >> * I set OFBIZ-7962 "Migrate the patch management Ant targets" as a >> postponed task >> * I completely struck the "Patch Management Using Gradle Targets" >> section and will let it as is. I will see later if I need to drop or >> update it. >> * I have closed OFBIZ-7677 "Update documentation with respect to >> implementation of gradle as a replacement of ant" >> >> For me the Ant to Gradle documentation is completely done. >> >> BTW while looking at OFBIZ-9256 "Split the tools folder from the trunk >> and put it in another branch" I noticed for OFBIZ-7677 I created a >> documentation folder under the tools directory. I believe now, before >> splitting the tools, we should put it directly under the root dir and >> put there all generic documentation, I'll do so w/o comment before doing >> OFBIZ-7677 >> >> Jacques >> >> > |
Free forum by Nabble | Edit this page |