Q6: Could we get rid of the protocol/ folder? I'm trying to avoid some copy-paste with the protocol sub-modules. This happens because relative paths (to, say, the NOTICE file) will be different from the relative paths of components and core/.
One approach would be to add another parent pom just for the protocol/ modules. This parent pom would still inherit from the main parent pom. A minor downside is that this would change the parent pom that was used so far in the basic Maven poms from res/maven/. Another approach would be to just move all protocol modules at the same level as all the others. (Either move the folders are they are: ftp, http or move and rename them to protocol-ftp, protocol-http). I think getting rid of the protocol/ folder and using protocol-ftp/, protocol-http, etc. (or ftp/, http/) would be cleaner, but I probably don't know all the benefits and history of the current layout. --emi On Wed, Jul 12, 2017 at 12:30 AM, Emilian Bold <[email protected]> wrote: > 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.
