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 f
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 m
Yes
On Mon, Jul 10, 2017 at 11:53 PM, Emilian Bold
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
> 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 wrote:
> Q3: Source split up.
>
> I see build.xml does some .class filtering when cr
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
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
wrote:
> Hello Emilian,
> I agree with you
>
> Regards
>
> On Sat, Ju
Hello Emilian,
I agree with you
Regards
On Sat, Jul 8, 2017 at 10:33 AM, Emilian Bold
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 o
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, Ph
On Sat, Jul 8, 2017 at 9:05 AM, Emilian Bold 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 gro
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.
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>a
What customization is needed?
As of now I'm able to build JMeter (components, core, functions,
jorphan, protocol/*) and with a little tweak run it as-is from
NetBeans.
One separate aspect is that I see the canonical source is under
Subversion. So even if I make a Git patch (or pull request), all
Hello,
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.
also project may be hard to mavenize knowing all the customization needed.
But if there is a volunteer , let's
As far as I can remember, the current agreement with "mavenization" is:
1) JMeter is ok with having some pom.xml files in the repository if they
would help to load the project with IDE
2) ant must stay the master build system
#2 implies that:
implication 1) dependencies are to be managed by ant bu
Great
Antonio
2017-07-07 15:29 GMT+02:00 Emilian Bold :
> OK, I'll Mavenize the project and keep you posted.
>
> --emi
>
>
> On Fri, Jul 7, 2017 at 4:04 PM, Antonio Gomes Rodrigues
> wrote:
> > Hi,
> >
> > Using Maven have been considered, unfortunately we don't have enough time
> > to work on
Thanks Emilian .
On Fri, Jul 7, 2017 at 3:29 PM, Emilian Bold wrote:
> OK, I'll Mavenize the project and keep you posted.
>
> --emi
>
>
> On Fri, Jul 7, 2017 at 4:04 PM, Antonio Gomes Rodrigues
> wrote:
> > Hi,
> >
> > Using Maven have been considered, unfortunately we don't have enough time
OK, I'll Mavenize the project and keep you posted.
--emi
On Fri, Jul 7, 2017 at 4:04 PM, Antonio Gomes Rodrigues
wrote:
> Hi,
>
> Using Maven have been considered, unfortunately we don't have enough time
> to work on it
> Feel free to do it
>
> Antonio
>
> 2017-07-07 12:34 GMT+02:00 Emilian Bol
Hi,
Using Maven have been considered, unfortunately we don't have enough time
to work on it
Feel free to do it
Antonio
2017-07-07 12:34 GMT+02:00 Emilian Bold :
> Hello,
>
> I see that officially only Eclipse is a supported IDE
> http://jmeter.apache.org/building.html
>
> I would like to add at
Hello,
I see that officially only Eclipse is a supported IDE
http://jmeter.apache.org/building.html
I would like to add at least Apache NetBeans support too.
I'm able to run the project, but I'm creating a single JAR for all the
src/ submodules instead a multiple JARs.
It might be a silly quest
19 matches
Mail list logo
