jmeter-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Philippe Mouawad <philippe.moua...@gmail.com>
Subject Re: JMeter project structure and IDEs support
Date Sat, 08 Jul 2017 08:36:17 GMT
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
  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message