jmeter-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Emilian Bold <emilian.b...@gmail.com>
Subject Mavenization [WAS: Re: JMeter project structure and IDEs support]
Date Sun, 09 Jul 2017 16:43:44 GMT
Q3: Source split up.

I see build.xml does some .class filtering when creating the JARs.

For example:

* the JMeter launch jar (ApacheJMeter.jar) is made from
src/core/**/NewDriver*, src/core/**/DynamicClassLoader*,
src/core/**/ShutdownClient.*

I suggest we split up the launcher to a separate src/launcher folder
which would hold these classes.

* the BeanShell Client (bshclient.jar) is made from
src/core/**/BeanShellClient*.java

This should also be a separate src/bshclient folder.

* like I mentioned in the other thread, the junit/test.jar sample is
redundant and we should create no such Maven artifacts anymore. I
suggest to go even further and remove the ant task too and the related
stub test classes from the src/junit/test and src/junit/woolfel
folders.

PS: I'm publishing commits on
https://github.com/emilianbold/jmeter/commits/emilianbold-mavenization
So far only the resources rename is there, next will come the pom.xml
files.

Note how build.xml already treats the resources differently and
switching to the Maven layout is rather harmless:
https://github.com/emilianbold/jmeter/commit/a194bbd8458116ea229692b6d3c461ca0f07c8e9

I assume the same will be when I move the sources too.

--emi


On Sat, Jul 8, 2017 at 12:22 PM, Emilian Bold <emilian.bold@gmail.com> wrote:
> 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