Q5: Why are org/apache/jmeter/images/{toolbar, tree}/icons-custom
folders part of src? I don't see them being used and
org/apache/jmeter/images/toolbar/icons-custom/** is expressly excluded
from ApacheJMeter_core.jar. (But oddly,
org/apache/jmeter/images/tree/icons-custom is *not*).I suggest to move them from src/ into res/icons or something. --emi On Tue, Jul 11, 2017 at 11:44 PM, Philippe Mouawad <[email protected]> wrote: > 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.
