jmeter-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Antonio Gomes Rodrigues <ra0...@gmail.com>
Subject Re: Migrating build system to Gradle
Date Thu, 21 Feb 2019 10:00:10 GMT
Hi,

No experience in Gradle, but ++1 (Binding) to replace ant

Antonio

Le jeu. 21 févr. 2019 à 10:48, Vladimir Sitnikov <
sitnikov.vladimir@gmail.com> a écrit :

> sebb> Whoever wants to switch should show that it can replace the current
> sebb> Ant build system without causing disruption.
> sebb> It needs to support all of the existing Ant targets.
>
> Ok, I read that as you agree to replace Ant with Gradle.
> So far the only technical justification (see
> https://www.apache.org/foundation/voting.html#Veto ) I see is "Gradle
> might
> fail to implement some of current build logic".
> Of course the only way to prove that "Gradle fails to implement the
> required tasks" is to actually implement the tasks. I agree there might be
> issues, however I'm sure this fear alone does not qualify as "technical
> justification".
>
> So far
> ++1 (Binding): Vladimir Sitnikov
> ++1 (Binding): Philippe Mouawad
>
> Vetos: none
>
> sebb> (The Ant scripts don't change that often, so that should not be too
> difficult).
>
> Maintenance of multiple build systems at once is always a time consuming
> task.
> We don't seem to have funding for that, so I suggest we just implement
> Gradle build as a branch, and merge that in a single go.
>
> sebb> Why use a build system that all but forces a change on you?
>
> Sebb, I don't suggest Gradle just because it forces to move files around.
> I suggest Gradle since it simplifies day-to-day coding activities like:
> 1) loading JMeter project to IDE
> 2) building JMeter
> 3) testing JMeter
> 4) dependency management
> 5) other
>
> On top of that, there are good reasons for certain folder layout.
> For instance, Gradle encourages to keep dependency jar files in a
> completely separate folder (outside of the project).
> This prevents accidentally putting multi-megabyte blobs under source
> control like in
>
> https://github.com/apache/jmeter/commit/c9a4d557f9a8e213ccc93215264a254dfb2bc50a
>
> Then it makes sense to keep test classes close to the relevant code.
> Otherwise the codebase looks like a single module which really takes time
> to comprehend.
> Currently all the test code is located in a single folder/structure, and it
> is not clear which tests are related to which jars.
>
> So moving files around it not just to make Gradle happy, but it is more to
> make developers who read and maintain the code happy.
>
> sebb> Note that the current Ant build relies on some Beanshell scripting
> and
> sebb> Maven integration.
>
> Gradle approach there would be to use Java (or Kotlin) code and place it in
> buildSrc folder.
> Gradle builds buildSrc code at build script initialization, and buildSrc
> code can represent whatever build logic is required
> Doc:
>
> https://docs.gradle.org/current/userguide/organizing_gradle_projects.html#sec:build_sources
>
> Apparently, Java/Kotlin code is way better than Beanshell. Should I
> elaborate?
>
> Vladimir
>

Mime
  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message