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: Mavenization [WAS: Re: JMeter project structure and IDEs support]
Date Mon, 10 Jul 2017 21:53:06 GMT
Q4: Why do ApacheJMeter_core.jar and ApacheJMeter.jar both contain
ShutdownClient.class? I'm assuming it should only live in the lancher,
ie. ApacheJMeter.jar?

--emi


On Sun, Jul 9, 2017 at 7:43 PM, Emilian Bold <emilian.bold@gmail.com> wrote:
> 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