jmeter-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Emilian Bold <emilian.b...@gmail.com>
Subject Re: JMeter project structure and IDEs support
Date Sat, 08 Jul 2017 09:22:30 GMT
Could we use this opportunity to remove the junit/test.jar sample,
related Maven pom.xml, ant task and perhaps the src/junit/test and
src/junit/woolfel folders entirely?

--emi


On Sat, Jul 8, 2017 at 11:36 AM, Philippe Mouawad
<philippe.mouawad@gmail.com> wrote:
> Hello Emilian,
> I agree with you
>
> Regards
>
> On Sat, Jul 8, 2017 at 10:33 AM, Emilian Bold <emilian.bold@gmail.com>
> wrote:
>
>> Q2: ApacheJMeter_junit-test seems redundant to me. It only contains
>> the src/junit/test and src/junit/woolfel sample test cases which are
>> basically a small JUnit tutorial. They make sense to have on the
>> website but why have them as public Maven artifacts?
>>
>> --emi
>>
>>
>> On Sat, Jul 8, 2017 at 10:07 AM, Philippe Mouawad
>> <philippe.mouawad@gmail.com> wrote:
>> > On Sat, Jul 8, 2017 at 9:05 AM, Emilian Bold <emilian.bold@gmail.com>
>> wrote:
>> >
>> >> Q1: Maven artifact and group IDs?
>> >>
>> >> Currently I see in res/maven some basic Maven poms for central
>> >> deployment. These use the org.apache.jmeter groupId and
>> >> ApacheJMeter_parent, ApacheJMeter_http, ApacheJMeter_core artifact Ids
>> >>
>> >> The groupId org.apache.jmeter is fine to me but the artifactID look odd.
>> >>
>> >> Instead of ApacheJMeter_core I would just use 'core',
>> >> ApacheJMeter_http would become protocol-http, etc.
>> >>
>> >> Still, since these artifactIDs are already public I assume we have to
>> >> continue using them, no?
>> >>
>> >
>> > Yes please.
>> >
>> >>
>> >>
>> >> --emi
>> >>
>> >>
>> >> On Sat, Jul 8, 2017 at 9:21 AM, Vladimir Sitnikov
>> >> <sitnikov.vladimir@gmail.com> wrote:
>> >> > Philippe>The decision for no maven in project was due to the fact
that
>> >> > nobody had
>> >> > time to work on it and as project has a lot of other work needed, we
>> >> wanted
>> >> > to put efforts in other fields.
>> >> >
>> >> > Oh, really?
>> >> > What about moving files around in order to better follow "default
>> maven
>> >> > convention"?
>> >> >
>> >> > Philippe>also project may be hard to mavenize knowing all the
>> >> customization
>> >> > needed.
>> >> >
>> >> > I do get that, and I am fine with the challenge provided one day that
>> >> would
>> >> > become the master build script for the project.
>> >> >
>> >> >
>> >> > I thought sebb was against Maven as:
>> >> > 1) it is slower to build. That is true, Maven has non-zero per-module
>> >> > overhead.
>> >> > 2) "it adds no value". Well, I would argue that having Maven-first
>> makes
>> >> > JMeter presence in Maven Central much more solid, and it greatly
>> >> simplifies
>> >> > use of JMeter as a dependency.
>> >> > 3) "it makes builds more complicated"
>> >> >
>> >> > I know file rearrangements will hurt "svn blame" kind of scenarios
a
>> bit,
>> >> > however default layout conventions do help IDEs to work with the
>> project.
>> >> >
>> >> > PS. Currently Gradle is the thing, and it is more flexible when it
>> comes
>> >> to
>> >> > multi-module configurations. It is has faster build times (it might
be
>> >> even
>> >> > faster than current Ant builds), so I guess we might want to try
>> Gradle
>> >> if
>> >> > the build speed is an issue.
>> >> >
>> >> > PPS. I've did mavenization / code relayout for pgjdbc, and I do
>> release
>> >> > pgjdbc, so it (me speaking of mavenization) is not something
>> theoretical.
>> >> >
>> >> > PPPS. I've not used Gradle extensively. So, even if I would try adding
>> >> > Gradle build scripts, I would like someone to check those for the
>> sanity.
>> >> >
>> >> > Vladimir
>> >>
>> >
>> >
>> >
>> > --
>> > Cordialement.
>> > Philippe Mouawad.
>>
>
>
>
> --
> Cordialement.
> Philippe Mouawad.

Mime
View raw message