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: JMeter project structure and IDEs support
Date Sat, 08 Jul 2017 07:05:28 GMT
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?


--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

Mime
View raw message