jmeter-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Artem Fedorov <artem.fedo...@blazemeter.com>
Subject Re: Migrating build system to Gradle
Date Thu, 21 Feb 2019 14:52:18 GMT
++1 !
> 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

Vladimir please let's do it!

--

Artem Fedorov

On Thu, Feb 21, 2019 at 5:06 PM Andrey Pokhilko <apc4@ya.ru> wrote:

> ++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
  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message