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 Tue, 11 Jul 2017 21:30:17 GMT
Q5: Why are org/apache/jmeter/images/{toolbar, tree}/icons-custom
folders part of src? I don't see them being used and
org/apache/jmeter/images/toolbar/icons-custom/** is expressly excluded
from ApacheJMeter_core.jar. (But oddly,
org/apache/jmeter/images/tree/icons-custom is *not*).

I suggest to move them from src/ into res/icons or something.

--emi


On Tue, Jul 11, 2017 at 11:44 PM, Philippe Mouawad
<philippe.mouawad@gmail.com> wrote:
> Yes
>
> On Mon, Jul 10, 2017 at 11:53 PM, Emilian Bold <emilian.bold@gmail.com>
> wrote:
>
>> 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.
>>
>
>
>
> --
> Cordialement.
> Philippe Mouawad.

Mime
View raw message