You are viewing a plain text version of this content. The canonical link for it is here.
Posted to server-dev@james.apache.org by Eugen Stan <eu...@netdava.com> on 2020/06/23 19:42:53 UTC
Gradle migration proposal - take 1
Hello,
This is a request for early feedback on the Gradle migration.
I'm assuming we are going to adopt Gradle since IMO it does deliver on
it's promises and opens us for new possibilities.
TLDR:
The migration will be ready for review in ~2 days; when it's done,
please try it out and give feedback.
If no blockers, let's push for Gradle build by default in the next 2 weeks.
== Long version
As we discussed, I started working on a Gradle migration proposal that I
hope we make sooner rather than later.
The main goals of this migrations is to improve the developer experience
and also the change-build-test feedback loop.
See https://issues.apache.org/jira/browse/JAMES-3260 and related issues.
Please go through my observations and the code changes, build it locally
and provide feedback.
The work is IN PROGRESS but does most of what it promises.
To try out, checkout the branch and build with ./gradlew build .
== Current status
I worked on a git branch and created a PR
https://github.com/apache/james-project/pull/217 and
https://github.com/apache/james-project/tree/JAMES-3260-gradle-poc .
I followed the migration guide at
https://docs.gradle.org/current/userguide/migrating_from_maven.html :
- I ran the maven build scan - took 2h+ to build james and it failed at
the end
- Ran gradle init and I got the first gradle structure
- Started the build - check - update loop to make sure the whole project
builds.
At the moment I'm able to build most of the components - up to webadmin
and guice application modules.
I believe in 1-2 days we will be able to build all of James-project with
Gradle.
== We need You to help out !
I believe that Gradle delivers on it's promises to make the build faster.
I would like for you to help out and test it.
The migration will require quite some work and collaboration.
Bellow there are some things we need, please add others, choose one and
work on it (we need to sync, so let everyone know)
- We need to make sure the current developers are onboard - please do
your part and check the build locally.
- We need a checklist to verify the builds produce similar output / the
same arifacts
- We need to make sure we can release with Gradle - OFBiz does that - we
can ask there (some others projects also do)
- We need to add ASF copyright headers to all gradle files (Intellij has
a nice feature. Also Search and replace can be of good help).
- We need documentation for developers on how to work with the new
builds system
Let's make this happen.
Please share your feedback,
--
Eugen Stan
+40720 898 747 / netdava.com
Re: Gradle migration proposal - take 1
Posted by Eugen Stan <eu...@netdava.com>.
Thanks for testing Benoit,
Some good news.
The PR is ready for review
https://github.com/apache/james-project/pull/217 .
I had to disable running the test for some integration modules because
of a claspath issue.
I suspect there are different versions of guice and another library that
end up on the classpath and cause them to fail.
Please help with that, you can find them by " git grep 'enabled =
false' "
They are also marked with // TODO: @ieugen .
I'll take a break from this for a couple of days since it took me ~5
full days to make it happen.
I'll be available for messaging, but will not do work so please chip in
so we can make this happen.
Issue PR's against that PR and once we are happy we can merg it in master.
Regards,
La 24.06.2020 14:32, Tellier Benoit a scris:
>
> Le 24/06/2020 à 02:42, Eugen Stan a écrit :
>> Hello,
>>
>> This is a request for early feedback on the Gradle migration.
>>
>> I'm assuming we are going to adopt Gradle since IMO it does deliver on
>> it's promises and opens us for new possibilities.
>>
>>
>> TLDR:
>>
>> The migration will be ready for review in ~2 days; when it's done,
>> please try it out and give feedback.
>>
>> If no blockers, let's push for Gradle build by default in the next 2 weeks.
> +1
>
>> == Long version
>>
> [...]
>
>> == We need You to help out !
>>
>> I believe that Gradle delivers on it's promises to make the build faster.
>>
>> I would like for you to help out and test it.
>>
>> The migration will require quite some work and collaboration.
> We will allocate a task in our next Sprint (starting next week) about
> the gradle migration, mostly about CI runs & controlling that tests are
> well played.
>
> Don't hesitate if help is needed.
>
>> Bellow there are some things we need, please add others, choose one and
>> work on it (we need to sync, so let everyone know)
>>
>> - We need to make sure the current developers are onboard - please do
>> your part and check the build locally.
> René Cordier did build things without issues. Other Linagora
> contributors should try this in the coming days.
>
>> - We need a checklist to verify the builds produce similar output / the
>> same arifacts
> I think I miss-understood the question as part of my answer in JAMES-3273
>
> I will list the artifact we build.
>
>> - We need to make sure we can release with Gradle - OFBiz does that - we
>> can ask there (some others projects also do)
> IMO release should not be a blocker, +1 for checking.
>
>> - We need to add ASF copyright headers to all gradle files (Intellij has
>> a nice feature. Also Search and replace can be of good help).
>>
>> - We need documentation for developers on how to work with the new
>> builds system
>>
>>
>> Let's make this happen.
>>
>> Please share your feedback,
>>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: server-dev-unsubscribe@james.apache.org
> For additional commands, e-mail: server-dev-help@james.apache.org
>
--
Eugen Stan
+40720 898 747 / netdava.com
Re: Gradle migration proposal - take 1
Posted by Tellier Benoit <bt...@apache.org>.
Le 24/06/2020 à 02:42, Eugen Stan a écrit :
> Hello,
>
> This is a request for early feedback on the Gradle migration.
>
> I'm assuming we are going to adopt Gradle since IMO it does deliver on
> it's promises and opens us for new possibilities.
>
>
> TLDR:
>
> The migration will be ready for review in ~2 days; when it's done,
> please try it out and give feedback.
>
> If no blockers, let's push for Gradle build by default in the next 2 weeks.
+1
>
> == Long version
>
[...]
>
> == We need You to help out !
>
> I believe that Gradle delivers on it's promises to make the build faster.
>
> I would like for you to help out and test it.
>
> The migration will require quite some work and collaboration.
We will allocate a task in our next Sprint (starting next week) about
the gradle migration, mostly about CI runs & controlling that tests are
well played.
Don't hesitate if help is needed.
>
> Bellow there are some things we need, please add others, choose one and
> work on it (we need to sync, so let everyone know)
>
> - We need to make sure the current developers are onboard - please do
> your part and check the build locally.
René Cordier did build things without issues. Other Linagora
contributors should try this in the coming days.
>
> - We need a checklist to verify the builds produce similar output / the
> same arifacts
I think I miss-understood the question as part of my answer in JAMES-3273
I will list the artifact we build.
>
> - We need to make sure we can release with Gradle - OFBiz does that - we
> can ask there (some others projects also do)
IMO release should not be a blocker, +1 for checking.
>
> - We need to add ASF copyright headers to all gradle files (Intellij has
> a nice feature. Also Search and replace can be of good help).
>
> - We need documentation for developers on how to work with the new
> builds system
>
>
> Let's make this happen.
>
> Please share your feedback,
>
---------------------------------------------------------------------
To unsubscribe, e-mail: server-dev-unsubscribe@james.apache.org
For additional commands, e-mail: server-dev-help@james.apache.org