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 23:04:12 GMT
Q6: Could we get rid of the protocol/ folder?

I'm trying to avoid some copy-paste with the protocol sub-modules.
This happens because relative paths (to, say, the NOTICE file) will be
different from the relative paths of components and core/.

One approach would be to add another parent pom just for the protocol/
modules. This parent pom would still inherit from the main parent pom.
A minor downside is that this would change the parent pom that was
used so far in the basic Maven poms from res/maven/.

Another approach would be to just move all protocol modules at the
same level as all the others. (Either move the folders are they are:
ftp, http or move and rename them to protocol-ftp, protocol-http).

I think getting rid of the protocol/ folder and using protocol-ftp/,
protocol-http, etc. (or ftp/, http/) would be cleaner, but I probably
don't know all the benefits and history of the current layout.

--emi


On Wed, Jul 12, 2017 at 12:30 AM, Emilian Bold <emilian.bold@gmail.com> wrote:
> 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