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 08:33:40 GMT
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.

Mime
View raw message