Yes On Mon, Jul 10, 2017 at 11:53 PM, Emilian Bold <[email protected]> wrote:
> 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. > -- Cordialement. Philippe Mouawad.
