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 <[email protected]> wrote: > On Sat, Jul 8, 2017 at 9:05 AM, Emilian Bold <[email protected]> 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 >> <[email protected]> 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.
