jmeter-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Andrey Pokhilko <a...@ya.ru>
Subject Re: Migrating build system to Gradle
Date Thu, 21 Feb 2019 14:06:27 GMT
++1 from me. Any change to modern is better, contributors will
appreciate the good modern tooling. As for plugins, source layout does
not affect them, as long as lib+lib/ext are kept for libs and plugins in
distribution structure.

--

Andrey Pokhilko

21.02.2019 13:00, Antonio Gomes Rodrigues пишет:
> 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
View raw message