JMeter project structure and IDEs support

[Emilian Bold <em...@apache.org>]

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 question, but have you considered using Maven or
Gradle or some other build system that would be sub-project aware?

This would more easily allow the project to be loaded from multiple IDEs.

It would also allow a segmentation of dependency JARs per submodule.

If dev@ is not the proper place for this I can resend the email to
some other mailing list.

--emi

Re: JMeter project structure and IDEs support

[Emilian Bold <em...@gmail.com>]

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
<ph...@gmail.com> wrote:
> Hello Emilian,
> I agree with you
>
> Regards
>
> On Sat, Jul 8, 2017 at 10:33 AM, Emilian Bold <em...@gmail.com>
> 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
>> <ph...@gmail.com> wrote:
>> > On Sat, Jul 8, 2017 at 9:05 AM, Emilian Bold <em...@gmail.com>
>> 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
>> >> <si...@gmail.com> 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.

Re: JMeter project structure and IDEs support

[Philippe Mouawad <ph...@gmail.com>]

Hello Emilian,
I agree with you

Regards

On Sat, Jul 8, 2017 at 10:33 AM, Emilian Bold <em...@gmail.com>
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
> <ph...@gmail.com> wrote:
> > On Sat, Jul 8, 2017 at 9:05 AM, Emilian Bold <em...@gmail.com>
> 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
> >> <si...@gmail.com> 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.

Re: JMeter project structure and IDEs support

[Emilian Bold <em...@gmail.com>]

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
<ph...@gmail.com> wrote:
> On Sat, Jul 8, 2017 at 9:05 AM, Emilian Bold <em...@gmail.com> 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
>> <si...@gmail.com> 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.

Re: JMeter project structure and IDEs support

[Philippe Mouawad <ph...@gmail.com>]

On Sat, Jul 8, 2017 at 9:05 AM, Emilian Bold <em...@gmail.com> 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
> <si...@gmail.com> 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.

Re: JMeter project structure and IDEs support

[Emilian Bold <em...@gmail.com>]

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?


--emi


On Sat, Jul 8, 2017 at 9:21 AM, Vladimir Sitnikov
<si...@gmail.com> 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

Re: JMeter project structure and IDEs support

[Vladimir Sitnikov <si...@gmail.com>]

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

Re: JMeter project structure and IDEs support

[Emilian Bold <em...@gmail.com>]

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 the
renames will probably have to be re-done in Subversion? I'm not sure
how Subversion handles patches that rename files.

--emi


On Sat, Jul 8, 2017 at 9:03 AM, Philippe Mouawad
<ph...@gmail.com> wrote:
> 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 move forward.
> If it ends up too hard, then an intermediate step would be to at least
> provide source and javadocs artifacts which are currently missing.
>
>
> Regards
>
> On Friday, July 7, 2017, Vladimir Sitnikov <si...@gmail.com>
> wrote:
>
>> 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 build.xml
>> implication 2) if a new dependency added, then build.xml must be updated
>> first (to reflect the change), then pom.xml might be required (if anyone
>> uses pom.xml)
>>
>> Frankly speaking, I would love to switch to Maven (I can do mavenization),
>> however I think it is just "not wanted" by the project.
>>
>> Vladimir
>>
>> пт, 7 июл. 2017 г. в 23:34, Antonio Gomes Rodrigues <ra0077@gmail.com
>> <javascript:;>>:
>>
>> > Great
>> >
>> > Antonio
>> >
>> > 2017-07-07 15:29 GMT+02:00 Emilian Bold <emilian.bold@gmail.com
>> <javascript:;>>:
>> >
>> > > OK, I'll Mavenize the project and keep you posted.
>> > >
>> > > --emi
>> > >
>> > >
>> > > On Fri, Jul 7, 2017 at 4:04 PM, Antonio Gomes Rodrigues
>> > > <ra0077@gmail.com <javascript:;>> 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 Bold <emi@apache.org
>> <javascript:;>>:
>> > > >
>> > > >> 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 question, but have you considered using Maven or
>> > > >> Gradle or some other build system that would be sub-project aware?
>> > > >>
>> > > >> This would more easily allow the project to be loaded from multiple
>> > > IDEs.
>> > > >>
>> > > >> It would also allow a segmentation of dependency JARs per submodule.
>> > > >>
>> > > >> If dev@ is not the proper place for this I can resend the email to
>> > > >> some other mailing list.
>> > > >>
>> > > >> --emi
>> > > >>
>> > >
>> >
>>
>
>
> --
> Cordialement.
> Philippe Mouawad.

Re: JMeter project structure and IDEs support

[Philippe Mouawad <ph...@gmail.com>]

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 move forward.
If it ends up too hard, then an intermediate step would be to at least
provide source and javadocs artifacts which are currently missing.


Regards

On Friday, July 7, 2017, Vladimir Sitnikov <si...@gmail.com>
wrote:

> 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 build.xml
> implication 2) if a new dependency added, then build.xml must be updated
> first (to reflect the change), then pom.xml might be required (if anyone
> uses pom.xml)
>
> Frankly speaking, I would love to switch to Maven (I can do mavenization),
> however I think it is just "not wanted" by the project.
>
> Vladimir
>
> пт, 7 июл. 2017 г. в 23:34, Antonio Gomes Rodrigues <ra0077@gmail.com
> <javascript:;>>:
>
> > Great
> >
> > Antonio
> >
> > 2017-07-07 15:29 GMT+02:00 Emilian Bold <emilian.bold@gmail.com
> <javascript:;>>:
> >
> > > OK, I'll Mavenize the project and keep you posted.
> > >
> > > --emi
> > >
> > >
> > > On Fri, Jul 7, 2017 at 4:04 PM, Antonio Gomes Rodrigues
> > > <ra0077@gmail.com <javascript:;>> 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 Bold <emi@apache.org
> <javascript:;>>:
> > > >
> > > >> 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 question, but have you considered using Maven or
> > > >> Gradle or some other build system that would be sub-project aware?
> > > >>
> > > >> This would more easily allow the project to be loaded from multiple
> > > IDEs.
> > > >>
> > > >> It would also allow a segmentation of dependency JARs per submodule.
> > > >>
> > > >> If dev@ is not the proper place for this I can resend the email to
> > > >> some other mailing list.
> > > >>
> > > >> --emi
> > > >>
> > >
> >
>


-- 
Cordialement.
Philippe Mouawad.

Re: JMeter project structure and IDEs support

[Vladimir Sitnikov <si...@gmail.com>]

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 build.xml
implication 2) if a new dependency added, then build.xml must be updated
first (to reflect the change), then pom.xml might be required (if anyone
uses pom.xml)

Frankly speaking, I would love to switch to Maven (I can do mavenization),
however I think it is just "not wanted" by the project.

Vladimir

пт, 7 июл. 2017 г. в 23:34, Antonio Gomes Rodrigues <ra...@gmail.com>:

> Great
>
> Antonio
>
> 2017-07-07 15:29 GMT+02:00 Emilian Bold <em...@gmail.com>:
>
> > OK, I'll Mavenize the project and keep you posted.
> >
> > --emi
> >
> >
> > On Fri, Jul 7, 2017 at 4:04 PM, Antonio Gomes Rodrigues
> > <ra...@gmail.com> 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 Bold <em...@apache.org>:
> > >
> > >> 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 question, but have you considered using Maven or
> > >> Gradle or some other build system that would be sub-project aware?
> > >>
> > >> This would more easily allow the project to be loaded from multiple
> > IDEs.
> > >>
> > >> It would also allow a segmentation of dependency JARs per submodule.
> > >>
> > >> If dev@ is not the proper place for this I can resend the email to
> > >> some other mailing list.
> > >>
> > >> --emi
> > >>
> >
>

Re: JMeter project structure and IDEs support

[Antonio Gomes Rodrigues <ra...@gmail.com>]

Great

Antonio

2017-07-07 15:29 GMT+02:00 Emilian Bold <em...@gmail.com>:

> OK, I'll Mavenize the project and keep you posted.
>
> --emi
>
>
> On Fri, Jul 7, 2017 at 4:04 PM, Antonio Gomes Rodrigues
> <ra...@gmail.com> 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 Bold <em...@apache.org>:
> >
> >> 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 question, but have you considered using Maven or
> >> Gradle or some other build system that would be sub-project aware?
> >>
> >> This would more easily allow the project to be loaded from multiple
> IDEs.
> >>
> >> It would also allow a segmentation of dependency JARs per submodule.
> >>
> >> If dev@ is not the proper place for this I can resend the email to
> >> some other mailing list.
> >>
> >> --emi
> >>
>

Re: JMeter project structure and IDEs support

[Philippe Mouawad <ph...@gmail.com>]

Thanks Emilian .



On Fri, Jul 7, 2017 at 3:29 PM, Emilian Bold <em...@gmail.com> wrote:

> OK, I'll Mavenize the project and keep you posted.
>
> --emi
>
>
> On Fri, Jul 7, 2017 at 4:04 PM, Antonio Gomes Rodrigues
> <ra...@gmail.com> 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 Bold <em...@apache.org>:
> >
> >> 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 question, but have you considered using Maven or
> >> Gradle or some other build system that would be sub-project aware?
> >>
> >> This would more easily allow the project to be loaded from multiple
> IDEs.
> >>
> >> It would also allow a segmentation of dependency JARs per submodule.
> >>
> >> If dev@ is not the proper place for this I can resend the email to
> >> some other mailing list.
> >>
> >> --emi
> >>
>



-- 
Cordialement.
Philippe Mouawad.

Re: JMeter project structure and IDEs support

[Emilian Bold <em...@gmail.com>]

OK, I'll Mavenize the project and keep you posted.

--emi


On Fri, Jul 7, 2017 at 4:04 PM, Antonio Gomes Rodrigues
<ra...@gmail.com> 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 Bold <em...@apache.org>:
>
>> 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 question, but have you considered using Maven or
>> Gradle or some other build system that would be sub-project aware?
>>
>> This would more easily allow the project to be loaded from multiple IDEs.
>>
>> It would also allow a segmentation of dependency JARs per submodule.
>>
>> If dev@ is not the proper place for this I can resend the email to
>> some other mailing list.
>>
>> --emi
>>

Re: JMeter project structure and IDEs support

[Antonio Gomes Rodrigues <ra...@gmail.com>]

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 <em...@apache.org>:

> 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 question, but have you considered using Maven or
> Gradle or some other build system that would be sub-project aware?
>
> This would more easily allow the project to be loaded from multiple IDEs.
>
> It would also allow a segmentation of dependency JARs per submodule.
>
> If dev@ is not the proper place for this I can resend the email to
> some other mailing list.
>
> --emi
>