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 <[email protected]> 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 <[email protected]> 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 >> <[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.
