Gradle documentation and migration status

Previous Topic Next Topic
 
classic Classic list List threaded Threaded
6 messages Options
Reply | Threaded
Open this post in threaded view
|

Gradle documentation and migration status

Jacques Le Roux
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

Reply | Threaded
Open this post in threaded view
|

Re: Gradle documentation and migration status

Jacques Le Roux
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

Reply | Threaded
Open this post in threaded view
|

Re: Gradle documentation and migration status

Michael Brohl-3
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
Reply | Threaded
Open this post in threaded view
|

Re: Gradle documentation and migration status

Jacques Le Roux
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

Reply | Threaded
Open this post in threaded view
|

Re: Gradle documentation and migration status

Hans Bakker
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
Reply | Threaded
Open this post in threaded view
|

Re: Gradle documentation and migration status

Jacques Le Roux
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
>>
>>
>