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 <[email protected]> wrote: > Hello Emilian, > I agree with you > > Regards > > On Sat, Jul 8, 2017 at 10:33 AM, Emilian Bold <[email protected]> > 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 >> <[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. >> > > > > -- > Cordialement. > Philippe Mouawad.
