Status of Ant vs Maven

[Will Hartung <wi...@gmail.com>]

Ant has been the historic underlying build tool for Netbeans projects, but
over the years, not only has NB been a very good companion with Maven,
Maven is also much more popular industry wide.

There was a comment on the user list recently about Java FX, and one reply
was, paraphrasing, "the best way to use Java FX was to use Maven".

I was also looking at the legacy NB Platform tutorials, which use Ant, but
certainly need some updating.

But that brought the question. Should one style of build be promoted over
the other, are both systems "faithfully and fully supported", or is Ant
going to perhaps slowly die on the vine of disinterest?

Is there any internal mandate of ensuring compatibility between the two
build system, especially in terms of ensuring high level things like
wizards and whatnot work for both systems? If someone adds a new feature,
contrived, "Create a Microprofile web service", is the project obligated
(as much as it's obligated to do anything) to create a wizard for both Ant
and Maven, or is it acceptable to only use one mechanism?

Just curious if there's any formal position on the two systems and their
status within the NB environment today.

Re: Re: Speed of Maven build

[Eric Bresie <eb...@gmail.com>]

Would multi threading/multi core parameters help speed things up?

https://stackoverflow.com/questions/32368976/ways-to-make-maven-build-faster/44646756#44646756

Or other speedups like limiting some activities or profile the builds?

https://medium.com/@alex_collins/10x-faster-maven-builds-at-intuit-5b7bb60c65e6

Eric Bresie
Ebresie@gmail.com

> On August 25, 2020 at 12:27:02 AM CDT, Jaroslav Tulach <ja...@gmail.com> wrote:
> > And it's Apache Maven, over the corner at https://maven.apache.org/ so
> > I suppose that community would be happy to get such contributions.
> >
> > -Bertrand
>
> You are right, Bertrand. Why not ask!
>
> Hello Maven guys,
> we had a discussion on the NetBeans mailing list recently and here is a
> summary:
> * Apache NetBeans IDE is delegating most of its work directly to Maven
> * Users however complain that the speed isn't great
> * One of the ideas was to launch a "zombie" instance of Maven in advance
> * then actions like build, exec or test would be faster
>
> Have you thought about something like this already? Any advices?
>
> Best regards.
> Jaroslav Tulach
> NetBeans Platform Architect
>
> ne 23. 8. 2020 v 9:06 odesílatel Jaroslav Tulach <ja...@gmail.com>
> napsal:
>
> > > I agree with others, Ant is much faster day to day. But the pom.xml has
> > > become the universal project file for Java,
> >
> > Thank you all for sharing your thoughts. I know Maven start is slower, but
> > I
> > learned to live with it. It is interesting to hear that some of you
> > maintain a
> > dual Ant based copy of your project metadata. Once we were trying a
> > different
> > approach:
> >
> > There is a way to speed Maven in the IDE. Launch Maven, let it read all
> > XML &
> > co. files and stop it. As soon as we need to build/run/test, wake up this
> > zombie Maven process, tell it what to do and let it continue. If the XML
> > files
> > are modified, throw the process away and initialize it again. Tomáš Stupka
> > implemented a prototype of this and there were no issues, as far as I know
> > (nobody tested it thoroughly however).
> >
> > Maybe the support is even in and there is a property to turn it on. If the
> > Maven startup is the biggest problem for you guys, we shall investigate
> > how to
> > turn Tomáš's work on...
> >
> > -jt
> >
> >
> >
> >
> >
> >

Re: Re: Speed of Maven build

[Eric Bresie <eb...@gmail.com>]

Would multi threading/multi core parameters help speed things up?

https://stackoverflow.com/questions/32368976/ways-to-make-maven-build-faster/44646756#44646756

Or other speedups like limiting some activities or profile the builds?

https://medium.com/@alex_collins/10x-faster-maven-builds-at-intuit-5b7bb60c65e6

Eric Bresie
Ebresie@gmail.com

> On August 25, 2020 at 12:27:02 AM CDT, Jaroslav Tulach <ja...@gmail.com> wrote:
> > And it's Apache Maven, over the corner at https://maven.apache.org/ so
> > I suppose that community would be happy to get such contributions.
> >
> > -Bertrand
>
> You are right, Bertrand. Why not ask!
>
> Hello Maven guys,
> we had a discussion on the NetBeans mailing list recently and here is a
> summary:
> * Apache NetBeans IDE is delegating most of its work directly to Maven
> * Users however complain that the speed isn't great
> * One of the ideas was to launch a "zombie" instance of Maven in advance
> * then actions like build, exec or test would be faster
>
> Have you thought about something like this already? Any advices?
>
> Best regards.
> Jaroslav Tulach
> NetBeans Platform Architect
>
> ne 23. 8. 2020 v 9:06 odesílatel Jaroslav Tulach <ja...@gmail.com>
> napsal:
>
> > > I agree with others, Ant is much faster day to day. But the pom.xml has
> > > become the universal project file for Java,
> >
> > Thank you all for sharing your thoughts. I know Maven start is slower, but
> > I
> > learned to live with it. It is interesting to hear that some of you
> > maintain a
> > dual Ant based copy of your project metadata. Once we were trying a
> > different
> > approach:
> >
> > There is a way to speed Maven in the IDE. Launch Maven, let it read all
> > XML &
> > co. files and stop it. As soon as we need to build/run/test, wake up this
> > zombie Maven process, tell it what to do and let it continue. If the XML
> > files
> > are modified, throw the process away and initialize it again. Tomáš Stupka
> > implemented a prototype of this and there were no issues, as far as I know
> > (nobody tested it thoroughly however).
> >
> > Maybe the support is even in and there is a property to turn it on. If the
> > Maven startup is the biggest problem for you guys, we shall investigate
> > how to
> > turn Tomáš's work on...
> >
> > -jt
> >
> >
> >
> >
> >
> >

Re: Speed of Maven build

[Jaroslav Tulach <ja...@gmail.com>]

Dne úterý 25. srpna 2020 13:26:33 CEST, Jeff Jensen napsal(a):
> In case this helps, Jason Dillon has a "Maven Shell" that does what you
> seek for CLI - launches a Maven instance and runs interactive commands with
> it, saving the startup time.
> https://github.com/jdillon/mvnsh

Thanks Jeff. The idea seems fine. Too bad the project doesn't even build: 
https://github.com/jdillon/mvnsh/issues/38 

-jt


> 
> 
> On Tue, Aug 25, 2020 at 12:27 AM Jaroslav Tulach <ja...@gmail.com>
> wrote:
> > > And it's Apache Maven, over the corner at https://maven.apache.org/ so
> > > I suppose that community would be happy to get such contributions.
> > > 
> > > -Bertrand
> > 
> > You are right, Bertrand. Why not ask!
> > 
> > Hello Maven guys,
> > we had a discussion on the NetBeans mailing list recently and here is a
> > summary:
> > * Apache NetBeans IDE is delegating most of its work directly to Maven
> > * Users however complain that the speed isn't great
> > * One of the ideas was to launch a "zombie" instance of Maven in advance
> > * then actions like build, exec or test would be faster
> > 
> > Have you thought about something like this already? Any advices?
> > 
> > Best regards.
> > Jaroslav Tulach
> > NetBeans Platform Architect
> > 
> > ne 23. 8. 2020 v 9:06 odesílatel Jaroslav Tulach <
> > jaroslav.tulach@gmail.com>
> > 
> > napsal:
> > > > I agree with others, Ant is much faster day to day. But the pom.xml
> > > > has
> > > > become the universal project file for Java,
> > > 
> > > Thank you all for sharing your thoughts. I know Maven start is slower,
> > 
> > but
> > 
> > > I
> > > learned to live with it. It is interesting to hear that some of you
> > > maintain a
> > > dual Ant based copy of your project metadata. Once we were trying a
> > > different
> > > approach:
> > > 
> > > There is a way to speed Maven in the IDE. Launch Maven, let it read all
> > > XML &
> > > co. files and stop it. As soon as we need to build/run/test, wake up
> > > this
> > > zombie Maven process, tell it what to do and let it continue. If the XML
> > > files
> > > are modified, throw the process away and initialize it again. Tomáš
> > 
> > Stupka
> > 
> > > implemented a prototype of this and there were no issues, as far as I
> > 
> > know
> > 
> > > (nobody tested it thoroughly however).
> > > 
> > > Maybe the support is even in and there is a property to turn it on. If
> > 
> > the
> > 
> > > Maven startup is the biggest problem for you guys, we shall investigate
> > > how to
> > > turn Tomáš's work on...
> > > 
> > > -jt





---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
For additional commands, e-mail: dev-help@maven.apache.org

Re: Speed of Maven build

[Jaroslav Tulach <ja...@gmail.com>]

Dne úterý 25. srpna 2020 13:26:33 CEST, Jeff Jensen napsal(a):
> In case this helps, Jason Dillon has a "Maven Shell" that does what you
> seek for CLI - launches a Maven instance and runs interactive commands with
> it, saving the startup time.
> https://github.com/jdillon/mvnsh

Thanks Jeff. The idea seems fine. Too bad the project doesn't even build: 
https://github.com/jdillon/mvnsh/issues/38 

-jt


> 
> 
> On Tue, Aug 25, 2020 at 12:27 AM Jaroslav Tulach <ja...@gmail.com>
> wrote:
> > > And it's Apache Maven, over the corner at https://maven.apache.org/ so
> > > I suppose that community would be happy to get such contributions.
> > > 
> > > -Bertrand
> > 
> > You are right, Bertrand. Why not ask!
> > 
> > Hello Maven guys,
> > we had a discussion on the NetBeans mailing list recently and here is a
> > summary:
> > * Apache NetBeans IDE is delegating most of its work directly to Maven
> > * Users however complain that the speed isn't great
> > * One of the ideas was to launch a "zombie" instance of Maven in advance
> > * then actions like build, exec or test would be faster
> > 
> > Have you thought about something like this already? Any advices?
> > 
> > Best regards.
> > Jaroslav Tulach
> > NetBeans Platform Architect
> > 
> > ne 23. 8. 2020 v 9:06 odesílatel Jaroslav Tulach <
> > jaroslav.tulach@gmail.com>
> > 
> > napsal:
> > > > I agree with others, Ant is much faster day to day. But the pom.xml
> > > > has
> > > > become the universal project file for Java,
> > > 
> > > Thank you all for sharing your thoughts. I know Maven start is slower,
> > 
> > but
> > 
> > > I
> > > learned to live with it. It is interesting to hear that some of you
> > > maintain a
> > > dual Ant based copy of your project metadata. Once we were trying a
> > > different
> > > approach:
> > > 
> > > There is a way to speed Maven in the IDE. Launch Maven, let it read all
> > > XML &
> > > co. files and stop it. As soon as we need to build/run/test, wake up
> > > this
> > > zombie Maven process, tell it what to do and let it continue. If the XML
> > > files
> > > are modified, throw the process away and initialize it again. Tomáš
> > 
> > Stupka
> > 
> > > implemented a prototype of this and there were no issues, as far as I
> > 
> > know
> > 
> > > (nobody tested it thoroughly however).
> > > 
> > > Maybe the support is even in and there is a property to turn it on. If
> > 
> > the
> > 
> > > Maven startup is the biggest problem for you guys, we shall investigate
> > > how to
> > > turn Tomáš's work on...
> > > 
> > > -jt





---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@netbeans.apache.org
For additional commands, e-mail: dev-help@netbeans.apache.org

For further information about the NetBeans mailing lists, visit:
https://cwiki.apache.org/confluence/display/NETBEANS/Mailing+lists

Re: Speed of Maven build

[Michael Bien <mb...@gmail.com>]

this would be an interesting use case for a native image, but the 
modular nature of maven is at the same time also the worst case scenario 
for native images :)

best regards,
-michael

On 06.09.20 06:43, Jaroslav Tulach wrote:
> Thanks Jesse, Tim.
> I've modified https://issues.apache.org/jira/browse/NETBEANS-4746 with links to
> your posts - I assume both are part of the problem: cold JVM for small
> projects, a lot of I/O for large project structures.
>
> -jt
>
> Dne pátek 4. září 2020 5:26:21 CEST, Tim Boudreau napsal(a):
>> For larger multi-module projects, I'd tend to suspect that a substantial
>> chunk of the time is I/O-bound, parsing
>> XML - build one project with a substantial dependency tree.  How many POM
>> files both in the project and
>> under ~/.m2 need to parsed?  It would be interesting to instrument Maven
>> and get some timings out of that.
>>
>> My fairly sprawling Antlr-IDE-support +
>> build-ide-plugins-with-a-compiled-antlr-grammar-and-some-annotations
>> framework clocks in at 68 pom files (probably 20 of these are projects for
>> tests to run against and test-support
>> libraries).  Certainly there are other in-the-ide performance issues
>> (change the version of one thing in the
>> dependency management section of the parent POM and plan not to use the IDE
>> for a few minutes while
>> scanning the universe brings the IDE to its knees).
>>
>> It would be worth doing some measurements of.  I'd imagine if that proves
>> to be a root cause, some sort of
>> fast and queriable binary cache not unlike those the IDE uses for layer
>> contents and such in its cache
>> directory could be very helpful.  The trick would be identifying those
>> changes to POM files that do *not* require
>> invalidating the cached POM of every project that depends on it.
>>
>> The 1.5 second improvement of a warm VM would be helpful on small projects,
>> but in any large tree of projects
>> where a build can take several minutes, it's not going to be significant.
>>
>> I don't know if small monolithic single-pom projects are the common case,
>> or multi-module projects.  If multi-module
>> projects are the more common case, the warm-VM approach may not be worth
>> the engineering effort, given the
>> things that can go wrong and the effort required to defend against them.
>> You could have it internally cache and
>> keep hot information about dependencies to avoid I/O on subsequent builds,
>> but that could start to have a
>> substantial memory footprint.
>>
>> My experience running with, say, -T 8 can have a substantial impact on
>> build times, but it appears not to take
>> into account test dependencies when sorting the projects into a build
>> order, so if you run tests, at some point
>> you wind up running against something that is in the process of being built
>> and it crashes.
>>
>> -Tim
>>
>> On Thu, Sep 3, 2020 at 4:10 PM Jesse Glick <ty...@gmail.com> wrote:
>>> On Thu, Aug 27, 2020 at 1:30 AM Jaroslav Tulach
>>>
>>> <ja...@gmail.com> wrote:
>>>> Hypothesis: Probably different Ant and Maven integration into the
>>> NetBeans IDE.
>>>
>>>> While Ant is executed in the same JVM as the IDE in an isolated
>>> classloader,
>>>
>>>> Maven is probably always started as a separate process.
>>> Yes this likely accounts for a lot of the difference.
>>>
>>> For a regular edit-test-edit-test cycle you can use the misleadingly
>>> named “compile on save” feature to save time, but in the case of Maven
>>> projects it still does launch `mvn`, just with a minimal set of mojos.
>>> At one point Maven CoS used the IDE’s built-in test runner
>>> (incidentally implemented with in-JVM Ant), just passing along the
>>> classpath introspected from the POM, but we switched to launching
>>> actual Maven to get better compatibility with projects with subtler
>>> configuration (IIRC).
>>>
>>> At any rate, I like the idea of reusing a JVM in the style of `mvnsh`
>>> for repeated Maven invocations in routine developer workflows. It
>>> would be important to keep not only Maven core loaded, but mojo class
>>> loaders, since these are often large and expensive to initialize. You
>>> would have to tune it in various ways, for example
>>>
>>> · Shut down automatically after some idle period.
>>> · Avoid sharing an instance between projects.
>>> · Run a regular forked `mvn` for executions that smell production-y,
>>> such as anything using the `clean` or `install` phases.
>>>
>>> It is possible that given a warm JVM, we could dispense with any
>>> special CoS tricks and still get reasonable performance from the stock
>>> lifecycle up to the `test` phase. It depends in part on the project
>>> config: if your POM is requesting a ton of plugins run in earlier
>>> phases (CheckStyle, etc.), there will still be lots of overhead unless
>>> the IDE passes a bunch of `-DskipSomething` properties.
>>>
>>> ---------------------------------------------------------------------
>>> To unsubscribe, e-mail: dev-unsubscribe@netbeans.apache.org
>>> For additional commands, e-mail: dev-help@netbeans.apache.org
>>>
>>> For further information about the NetBeans mailing lists, visit:
>>> https://cwiki.apache.org/confluence/display/NETBEANS/Mailing+lists
>
>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@netbeans.apache.org
> For additional commands, e-mail: dev-help@netbeans.apache.org
>
> For further information about the NetBeans mailing lists, visit:
> https://cwiki.apache.org/confluence/display/NETBEANS/Mailing+lists
>
>
>


---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@netbeans.apache.org
For additional commands, e-mail: dev-help@netbeans.apache.org

For further information about the NetBeans mailing lists, visit:
https://cwiki.apache.org/confluence/display/NETBEANS/Mailing+lists

Re: Speed of Maven build

[Jaroslav Tulach <ja...@gmail.com>]

Thanks Jesse, Tim.
I've modified https://issues.apache.org/jira/browse/NETBEANS-4746 with links to 
your posts - I assume both are part of the problem: cold JVM for small 
projects, a lot of I/O for large project structures.

-jt

Dne pátek 4. září 2020 5:26:21 CEST, Tim Boudreau napsal(a):
> For larger multi-module projects, I'd tend to suspect that a substantial
> chunk of the time is I/O-bound, parsing
> XML - build one project with a substantial dependency tree.  How many POM
> files both in the project and
> under ~/.m2 need to parsed?  It would be interesting to instrument Maven
> and get some timings out of that.
> 
> My fairly sprawling Antlr-IDE-support +
> build-ide-plugins-with-a-compiled-antlr-grammar-and-some-annotations
> framework clocks in at 68 pom files (probably 20 of these are projects for
> tests to run against and test-support
> libraries).  Certainly there are other in-the-ide performance issues
> (change the version of one thing in the
> dependency management section of the parent POM and plan not to use the IDE
> for a few minutes while
> scanning the universe brings the IDE to its knees).
> 
> It would be worth doing some measurements of.  I'd imagine if that proves
> to be a root cause, some sort of
> fast and queriable binary cache not unlike those the IDE uses for layer
> contents and such in its cache
> directory could be very helpful.  The trick would be identifying those
> changes to POM files that do *not* require
> invalidating the cached POM of every project that depends on it.
> 
> The 1.5 second improvement of a warm VM would be helpful on small projects,
> but in any large tree of projects
> where a build can take several minutes, it's not going to be significant.
> 
> I don't know if small monolithic single-pom projects are the common case,
> or multi-module projects.  If multi-module
> projects are the more common case, the warm-VM approach may not be worth
> the engineering effort, given the
> things that can go wrong and the effort required to defend against them.
> You could have it internally cache and
> keep hot information about dependencies to avoid I/O on subsequent builds,
> but that could start to have a
> substantial memory footprint.
> 
> My experience running with, say, -T 8 can have a substantial impact on
> build times, but it appears not to take
> into account test dependencies when sorting the projects into a build
> order, so if you run tests, at some point
> you wind up running against something that is in the process of being built
> and it crashes.
> 
> -Tim
> 
> On Thu, Sep 3, 2020 at 4:10 PM Jesse Glick <ty...@gmail.com> wrote:
> > On Thu, Aug 27, 2020 at 1:30 AM Jaroslav Tulach
> > 
> > <ja...@gmail.com> wrote:
> > > Hypothesis: Probably different Ant and Maven integration into the
> > 
> > NetBeans IDE.
> > 
> > > While Ant is executed in the same JVM as the IDE in an isolated
> > 
> > classloader,
> > 
> > > Maven is probably always started as a separate process.
> > 
> > Yes this likely accounts for a lot of the difference.
> > 
> > For a regular edit-test-edit-test cycle you can use the misleadingly
> > named “compile on save” feature to save time, but in the case of Maven
> > projects it still does launch `mvn`, just with a minimal set of mojos.
> > At one point Maven CoS used the IDE’s built-in test runner
> > (incidentally implemented with in-JVM Ant), just passing along the
> > classpath introspected from the POM, but we switched to launching
> > actual Maven to get better compatibility with projects with subtler
> > configuration (IIRC).
> > 
> > At any rate, I like the idea of reusing a JVM in the style of `mvnsh`
> > for repeated Maven invocations in routine developer workflows. It
> > would be important to keep not only Maven core loaded, but mojo class
> > loaders, since these are often large and expensive to initialize. You
> > would have to tune it in various ways, for example
> > 
> > · Shut down automatically after some idle period.
> > · Avoid sharing an instance between projects.
> > · Run a regular forked `mvn` for executions that smell production-y,
> > such as anything using the `clean` or `install` phases.
> > 
> > It is possible that given a warm JVM, we could dispense with any
> > special CoS tricks and still get reasonable performance from the stock
> > lifecycle up to the `test` phase. It depends in part on the project
> > config: if your POM is requesting a ton of plugins run in earlier
> > phases (CheckStyle, etc.), there will still be lots of overhead unless
> > the IDE passes a bunch of `-DskipSomething` properties.
> > 
> > ---------------------------------------------------------------------
> > To unsubscribe, e-mail: dev-unsubscribe@netbeans.apache.org
> > For additional commands, e-mail: dev-help@netbeans.apache.org
> > 
> > For further information about the NetBeans mailing lists, visit:
> > https://cwiki.apache.org/confluence/display/NETBEANS/Mailing+lists





---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@netbeans.apache.org
For additional commands, e-mail: dev-help@netbeans.apache.org

For further information about the NetBeans mailing lists, visit:
https://cwiki.apache.org/confluence/display/NETBEANS/Mailing+lists

Re: Speed of Maven build

[Tim Boudreau <ni...@gmail.com>]

For larger multi-module projects, I'd tend to suspect that a substantial
chunk of the time is I/O-bound, parsing
XML - build one project with a substantial dependency tree.  How many POM
files both in the project and
under ~/.m2 need to parsed?  It would be interesting to instrument Maven
and get some timings out of that.

My fairly sprawling Antlr-IDE-support +
build-ide-plugins-with-a-compiled-antlr-grammar-and-some-annotations
framework clocks in at 68 pom files (probably 20 of these are projects for
tests to run against and test-support
libraries).  Certainly there are other in-the-ide performance issues
(change the version of one thing in the
dependency management section of the parent POM and plan not to use the IDE
for a few minutes while
scanning the universe brings the IDE to its knees).

It would be worth doing some measurements of.  I'd imagine if that proves
to be a root cause, some sort of
fast and queriable binary cache not unlike those the IDE uses for layer
contents and such in its cache
directory could be very helpful.  The trick would be identifying those
changes to POM files that do *not* require
invalidating the cached POM of every project that depends on it.

The 1.5 second improvement of a warm VM would be helpful on small projects,
but in any large tree of projects
where a build can take several minutes, it's not going to be significant.

I don't know if small monolithic single-pom projects are the common case,
or multi-module projects.  If multi-module
projects are the more common case, the warm-VM approach may not be worth
the engineering effort, given the
things that can go wrong and the effort required to defend against them.
You could have it internally cache and
keep hot information about dependencies to avoid I/O on subsequent builds,
but that could start to have a
substantial memory footprint.

My experience running with, say, -T 8 can have a substantial impact on
build times, but it appears not to take
into account test dependencies when sorting the projects into a build
order, so if you run tests, at some point
you wind up running against something that is in the process of being built
and it crashes.

-Tim

On Thu, Sep 3, 2020 at 4:10 PM Jesse Glick <ty...@gmail.com> wrote:

> On Thu, Aug 27, 2020 at 1:30 AM Jaroslav Tulach
> <ja...@gmail.com> wrote:
> > Hypothesis: Probably different Ant and Maven integration into the
> NetBeans IDE.
> > While Ant is executed in the same JVM as the IDE in an isolated
> classloader,
> > Maven is probably always started as a separate process.
>
> Yes this likely accounts for a lot of the difference.
>
> For a regular edit-test-edit-test cycle you can use the misleadingly
> named “compile on save” feature to save time, but in the case of Maven
> projects it still does launch `mvn`, just with a minimal set of mojos.
> At one point Maven CoS used the IDE’s built-in test runner
> (incidentally implemented with in-JVM Ant), just passing along the
> classpath introspected from the POM, but we switched to launching
> actual Maven to get better compatibility with projects with subtler
> configuration (IIRC).
>
> At any rate, I like the idea of reusing a JVM in the style of `mvnsh`
> for repeated Maven invocations in routine developer workflows. It
> would be important to keep not only Maven core loaded, but mojo class
> loaders, since these are often large and expensive to initialize. You
> would have to tune it in various ways, for example
>
> · Shut down automatically after some idle period.
> · Avoid sharing an instance between projects.
> · Run a regular forked `mvn` for executions that smell production-y,
> such as anything using the `clean` or `install` phases.
>
> It is possible that given a warm JVM, we could dispense with any
> special CoS tricks and still get reasonable performance from the stock
> lifecycle up to the `test` phase. It depends in part on the project
> config: if your POM is requesting a ton of plugins run in earlier
> phases (CheckStyle, etc.), there will still be lots of overhead unless
> the IDE passes a bunch of `-DskipSomething` properties.
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@netbeans.apache.org
> For additional commands, e-mail: dev-help@netbeans.apache.org
>
> For further information about the NetBeans mailing lists, visit:
> https://cwiki.apache.org/confluence/display/NETBEANS/Mailing+lists
>
>
>
>

-- 
http://timboudreau.com

Re: Speed of Maven build

[Jesse Glick <ty...@gmail.com>]

On Thu, Aug 27, 2020 at 1:30 AM Jaroslav Tulach
<ja...@gmail.com> wrote:
> Hypothesis: Probably different Ant and Maven integration into the NetBeans IDE.
> While Ant is executed in the same JVM as the IDE in an isolated classloader,
> Maven is probably always started as a separate process.

Yes this likely accounts for a lot of the difference.

For a regular edit-test-edit-test cycle you can use the misleadingly
named “compile on save” feature to save time, but in the case of Maven
projects it still does launch `mvn`, just with a minimal set of mojos.
At one point Maven CoS used the IDE’s built-in test runner
(incidentally implemented with in-JVM Ant), just passing along the
classpath introspected from the POM, but we switched to launching
actual Maven to get better compatibility with projects with subtler
configuration (IIRC).

At any rate, I like the idea of reusing a JVM in the style of `mvnsh`
for repeated Maven invocations in routine developer workflows. It
would be important to keep not only Maven core loaded, but mojo class
loaders, since these are often large and expensive to initialize. You
would have to tune it in various ways, for example

· Shut down automatically after some idle period.
· Avoid sharing an instance between projects.
· Run a regular forked `mvn` for executions that smell production-y,
such as anything using the `clean` or `install` phases.

It is possible that given a warm JVM, we could dispense with any
special CoS tricks and still get reasonable performance from the stock
lifecycle up to the `test` phase. It depends in part on the project
config: if your POM is requesting a ton of plugins run in earlier
phases (CheckStyle, etc.), there will still be lots of overhead unless
the IDE passes a bunch of `-DskipSomething` properties.

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@netbeans.apache.org
For additional commands, e-mail: dev-help@netbeans.apache.org

For further information about the NetBeans mailing lists, visit:
https://cwiki.apache.org/confluence/display/NETBEANS/Mailing+lists

Re: Speed of Maven build

[Martin Kanters <ma...@apache.org>]

Hi Jaroslav, nice analysis. In the maven-integration-testing repository [1]
Maven can be started fully independently or embedded in the same JDK. The
latter is activated with the Maven profile "embedded".
This also gives a huge performance boost, running tests in tenths of a
second instead of seconds.

Martin

[1] https://github.com/apache/maven-integration-testing/

Op do 27 aug. 2020 om 07:30 schreef Jaroslav Tulach <
jaroslav.tulach@gmail.com>:

> Dne středa 26. srpna 2020 10:01:33 CEST, Davide Grandi napsal(a):
> > Sorry to be late, but
> >      there is a project test case for Maven "slowlyness" ?
>
> This is a great question, thanks Davide!
>
> I've just tried to create such project:
> https://issues.apache.org/jira/browse/NETBEANS-4746
> and yes, Maven is slower (see the instructions in the issue):
>
> ```bash
> justtest$ mvn -quiet -Dtest=MainTest process-test-classes surefire:test
> justtest$ ant -q test-single
> ```
>
> However only 2.6s vs. 1.9s and that cannot be the problem NetBeans users
> complain about.
>
> I guess the real problem is when people open the projects in the NetBeans
> IDE.
>
> Try to remove `pom.xml` and open the folder in NetBeans IDE 12.x - it
> opens as
> an Ant project. Select `MainTest.java` class and press Ctrl+F6 - repeat -
> at
> the end it takes less then 1s!
>
> Repeat again from scratch, but remove `build.xml` file and `nbproject`
> directory. Then the project opens as Maven. Select `MainTest.java` class
> and
> press Ctrl+F6 - takes more than 2s - repeat - takes more than 2s again.
>
> What cases the difference?
>
> Hypothesis: Probably different Ant and Maven integration into the NetBeans
> IDE.
> While Ant is executed in the same JVM as the IDE in an isolated
> classloader,
> Maven is probably always started as a separate process. Given a regular
> JDK
> doesn't do anything useful for first 1-1.5s of execution we might have
> found
> the difference. Ant code is reused again and again and warms up over time.
> Maven always starts from scratch and JDK's warming delay causes the wrong
> impression.
>
> Consider verifying my claims and observations.
> -jt
>
>
> >
> > I mean : a project for which there's a time gap between
> >
> > - nb/command line mvn invocations
> > - or between ant / mavn builds (I know : how many projects have TWO
> > build files ? ...)
> >
> > for routinely rebuilds of big projects I often activate the "quiet" and
> > "parallel" build params
> > and keep an eye at mvn java memory params.
> > Usual network and I/O tricks may apply.
> >
> > bye,
> >
> >      Davide
> >
> > On 25/08/2020 07:27, Jaroslav Tulach wrote:
> > >> And it's Apache Maven, over the corner at https://maven.apache.org/
> so
> > >> I suppose that community would be happy to get such contributions.
> > >>
> > >> -Bertrand
> > >
> > > You are right, Bertrand. Why not ask!
> > >
> > > Hello Maven guys,
> > > we had a discussion on the NetBeans mailing list recently and here is a
> > > summary:
> > > * Apache NetBeans IDE is delegating most of its work directly to Maven
> > > * Users however complain that the speed isn't great
> > > * One of the ideas was to launch a "zombie" instance of Maven in
> advance
> > > * then actions like build, exec or test would be faster
> > >
> > > Have you thought about something like this already? Any advices?
> > >
> > > Best regards.
> > > Jaroslav Tulach
> > > NetBeans Platform Architect
> > >
> > > ne 23. 8. 2020 v 9:06 odesílatel Jaroslav Tulach
> > > <ja...@gmail.com>>
> > > napsal:
> > >>> I agree with others, Ant is much faster day to day. But the pom.xml
> has
> > >>> become the universal project file for Java,
> > >>
> > >> Thank you all for sharing your thoughts. I know Maven start is slower,
> > >> but
> > >> I
> > >> learned to live with it. It is interesting to hear that some of you
> > >> maintain a
> > >> dual Ant based copy of your project metadata. Once we were trying a
> > >> different
> > >> approach:
> > >>
> > >> There is a way to speed Maven in the IDE. Launch Maven, let it read
> all
> > >> XML &
> > >> co. files and stop it. As soon as we need to build/run/test, wake up
> this
> > >> zombie Maven process, tell it what to do and let it continue. If the
> XML
> > >> files
> > >> are modified, throw the process away and initialize it again. Tomáš
> > >> Stupka
> > >> implemented a prototype of this and there were no issues, as far as I
> > >> know
> > >> (nobody tested it thoroughly however).
> > >>
> > >> Maybe the support is even in and there is a property to turn it on. If
> > >> the
> > >> Maven startup is the biggest problem for you guys, we shall
> investigate
> > >> how to
> > >> turn Tomáš's work on...
> > >>
> > >> -jt
>
>
>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
> For additional commands, e-mail: dev-help@maven.apache.org
>
>

Re: Speed of Maven build

[Davide Grandi <da...@email.it>]

I think that your conclusions are reasonable.
I've built your test project, that confirms the startup delay hypothesis.

However performances must be evaluated on specific test cases :
building a 10 *.java program is different from building CXF (maven) or
derby (ant).

Maybe that also the goals are different :
Maven stress repeatability of builds, even offering that some plugin
run in separate java process.
In some cases I run mvn asking for a new local repository, re-downloading
all plugins and dependencies.

So ... if the final goal is to keep nb "build system agnostic" I
think that the focus is in the interfaces towards the build systems
(running mvn "in process" like ant could be an idea - for small projects)
avoiding buffer locking and display delay.

assessing expected result for different project sizes (small 10 files - 
medium 100
- big CXF) will give useful hints.

Thank-you & best regards,

     Davide

On 27/08/2020 07:30, Jaroslav Tulach wrote:
> Dne středa 26. srpna 2020 10:01:33 CEST, Davide Grandi napsal(a):
>> Sorry to be late, but
>>       there is a project test case for Maven "slowlyness" ?
> This is a great question, thanks Davide!
>
> I've just tried to create such project:
> https://issues.apache.org/jira/browse/NETBEANS-4746
> and yes, Maven is slower (see the instructions in the issue):
>
> ```bash
> justtest$ mvn -quiet -Dtest=MainTest process-test-classes surefire:test
> justtest$ ant -q test-single
> ```
>
> However only 2.6s vs. 1.9s and that cannot be the problem NetBeans users
> complain about.
>
> I guess the real problem is when people open the projects in the NetBeans IDE.
>
> Try to remove `pom.xml` and open the folder in NetBeans IDE 12.x - it opens as
> an Ant project. Select `MainTest.java` class and press Ctrl+F6 - repeat - at
> the end it takes less then 1s!
>
> Repeat again from scratch, but remove `build.xml` file and `nbproject`
> directory. Then the project opens as Maven. Select `MainTest.java` class and
> press Ctrl+F6 - takes more than 2s - repeat - takes more than 2s again.
>
> What cases the difference?
>
> Hypothesis: Probably different Ant and Maven integration into the NetBeans IDE.
> While Ant is executed in the same JVM as the IDE in an isolated classloader,
> Maven is probably always started as a separate process. Given a regular JDK
> doesn't do anything useful for first 1-1.5s of execution we might have found
> the difference. Ant code is reused again and again and warms up over time.
> Maven always starts from scratch and JDK's warming delay causes the wrong
> impression.
>
> Consider verifying my claims and observations.
> -jt
>
>> I mean : a project for which there's a time gap between
>>
>> - nb/command line mvn invocations
>> - or between ant / mavn builds (I know : how many projects have TWO
>> build files ? ...)
>>
>> for routinely rebuilds of big projects I often activate the "quiet" and
>> "parallel" build params
>> and keep an eye at mvn java memory params.
>> Usual network and I/O tricks may apply.
>>
>> bye,
>>
>>       Davide
>>
>> On 25/08/2020 07:27, Jaroslav Tulach wrote:
>>>> And it's Apache Maven, over the corner at https://maven.apache.org/ so
>>>> I suppose that community would be happy to get such contributions.
>>>>
>>>> -Bertrand
>>> You are right, Bertrand. Why not ask!
>>>
>>> Hello Maven guys,
>>> we had a discussion on the NetBeans mailing list recently and here is a
>>> summary:
>>> * Apache NetBeans IDE is delegating most of its work directly to Maven
>>> * Users however complain that the speed isn't great
>>> * One of the ideas was to launch a "zombie" instance of Maven in advance
>>> * then actions like build, exec or test would be faster
>>>
>>> Have you thought about something like this already? Any advices?
>>>
>>> Best regards.
>>> Jaroslav Tulach
>>> NetBeans Platform Architect
>>>
>>> ne 23. 8. 2020 v 9:06 odesílatel Jaroslav Tulach
>>> <ja...@gmail.com>>
>>> napsal:
>>>>> I agree with others, Ant is much faster day to day. But the pom.xml has
>>>>> become the universal project file for Java,
>>>> Thank you all for sharing your thoughts. I know Maven start is slower,
>>>> but
>>>> I
>>>> learned to live with it. It is interesting to hear that some of you
>>>> maintain a
>>>> dual Ant based copy of your project metadata. Once we were trying a
>>>> different
>>>> approach:
>>>>
>>>> There is a way to speed Maven in the IDE. Launch Maven, let it read all
>>>> XML &
>>>> co. files and stop it. As soon as we need to build/run/test, wake up this
>>>> zombie Maven process, tell it what to do and let it continue. If the XML
>>>> files
>>>> are modified, throw the process away and initialize it again. Tomáš
>>>> Stupka
>>>> implemented a prototype of this and there were no issues, as far as I
>>>> know
>>>> (nobody tested it thoroughly however).
>>>>
>>>> Maybe the support is even in and there is a property to turn it on. If
>>>> the
>>>> Maven startup is the biggest problem for you guys, we shall investigate
>>>> how to
>>>> turn Tomáš's work on...
>>>>
>>>> -jt

-- 
Ing. Davide Grandi
email    : davide.grandi@email.it
mobile   : +39 339 7468 778
linkedin : http://linkedin.com/in/davidegrandi


---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@netbeans.apache.org
For additional commands, e-mail: dev-help@netbeans.apache.org

For further information about the NetBeans mailing lists, visit:
https://cwiki.apache.org/confluence/display/NETBEANS/Mailing+lists

Re: Speed of Maven build

[Jaroslav Tulach <ja...@gmail.com>]

Dne středa 26. srpna 2020 10:01:33 CEST, Davide Grandi napsal(a):
> Sorry to be late, but
>      there is a project test case for Maven "slowlyness" ?

This is a great question, thanks Davide!

I've just tried to create such project: 
https://issues.apache.org/jira/browse/NETBEANS-4746
and yes, Maven is slower (see the instructions in the issue):

```bash
justtest$ mvn -quiet -Dtest=MainTest process-test-classes surefire:test
justtest$ ant -q test-single
```

However only 2.6s vs. 1.9s and that cannot be the problem NetBeans users 
complain about.

I guess the real problem is when people open the projects in the NetBeans IDE. 

Try to remove `pom.xml` and open the folder in NetBeans IDE 12.x - it opens as 
an Ant project. Select `MainTest.java` class and press Ctrl+F6 - repeat - at 
the end it takes less then 1s!

Repeat again from scratch, but remove `build.xml` file and `nbproject` 
directory. Then the project opens as Maven. Select `MainTest.java` class and 
press Ctrl+F6 - takes more than 2s - repeat - takes more than 2s again.

What cases the difference? 

Hypothesis: Probably different Ant and Maven integration into the NetBeans IDE. 
While Ant is executed in the same JVM as the IDE in an isolated classloader, 
Maven is probably always started as a separate process. Given a regular JDK 
doesn't do anything useful for first 1-1.5s of execution we might have found 
the difference. Ant code is reused again and again and warms up over time. 
Maven always starts from scratch and JDK's warming delay causes the wrong 
impression.

Consider verifying my claims and observations.
-jt


> 
> I mean : a project for which there's a time gap between
> 
> - nb/command line mvn invocations
> - or between ant / mavn builds (I know : how many projects have TWO
> build files ? ...)
> 
> for routinely rebuilds of big projects I often activate the "quiet" and
> "parallel" build params
> and keep an eye at mvn java memory params.
> Usual network and I/O tricks may apply.
> 
> bye,
> 
>      Davide
> 
> On 25/08/2020 07:27, Jaroslav Tulach wrote:
> >> And it's Apache Maven, over the corner at https://maven.apache.org/ so
> >> I suppose that community would be happy to get such contributions.
> >> 
> >> -Bertrand
> > 
> > You are right, Bertrand. Why not ask!
> > 
> > Hello Maven guys,
> > we had a discussion on the NetBeans mailing list recently and here is a
> > summary:
> > * Apache NetBeans IDE is delegating most of its work directly to Maven
> > * Users however complain that the speed isn't great
> > * One of the ideas was to launch a "zombie" instance of Maven in advance
> > * then actions like build, exec or test would be faster
> > 
> > Have you thought about something like this already? Any advices?
> > 
> > Best regards.
> > Jaroslav Tulach
> > NetBeans Platform Architect
> > 
> > ne 23. 8. 2020 v 9:06 odesílatel Jaroslav Tulach
> > <ja...@gmail.com>> 
> > napsal:
> >>> I agree with others, Ant is much faster day to day. But the pom.xml has
> >>> become the universal project file for Java,
> >> 
> >> Thank you all for sharing your thoughts. I know Maven start is slower,
> >> but
> >> I
> >> learned to live with it. It is interesting to hear that some of you
> >> maintain a
> >> dual Ant based copy of your project metadata. Once we were trying a
> >> different
> >> approach:
> >> 
> >> There is a way to speed Maven in the IDE. Launch Maven, let it read all
> >> XML &
> >> co. files and stop it. As soon as we need to build/run/test, wake up this
> >> zombie Maven process, tell it what to do and let it continue. If the XML
> >> files
> >> are modified, throw the process away and initialize it again. Tomáš
> >> Stupka
> >> implemented a prototype of this and there were no issues, as far as I
> >> know
> >> (nobody tested it thoroughly however).
> >> 
> >> Maybe the support is even in and there is a property to turn it on. If
> >> the
> >> Maven startup is the biggest problem for you guys, we shall investigate
> >> how to
> >> turn Tomáš's work on...
> >> 
> >> -jt





---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@netbeans.apache.org
For additional commands, e-mail: dev-help@netbeans.apache.org

For further information about the NetBeans mailing lists, visit:
https://cwiki.apache.org/confluence/display/NETBEANS/Mailing+lists

Re: Speed of Maven build

[Jaroslav Tulach <ja...@gmail.com>]

Dne středa 26. srpna 2020 10:01:33 CEST, Davide Grandi napsal(a):
> Sorry to be late, but
>      there is a project test case for Maven "slowlyness" ?

This is a great question, thanks Davide!

I've just tried to create such project: 
https://issues.apache.org/jira/browse/NETBEANS-4746
and yes, Maven is slower (see the instructions in the issue):

```bash
justtest$ mvn -quiet -Dtest=MainTest process-test-classes surefire:test
justtest$ ant -q test-single
```

However only 2.6s vs. 1.9s and that cannot be the problem NetBeans users 
complain about.

I guess the real problem is when people open the projects in the NetBeans IDE. 

Try to remove `pom.xml` and open the folder in NetBeans IDE 12.x - it opens as 
an Ant project. Select `MainTest.java` class and press Ctrl+F6 - repeat - at 
the end it takes less then 1s!

Repeat again from scratch, but remove `build.xml` file and `nbproject` 
directory. Then the project opens as Maven. Select `MainTest.java` class and 
press Ctrl+F6 - takes more than 2s - repeat - takes more than 2s again.

What cases the difference? 

Hypothesis: Probably different Ant and Maven integration into the NetBeans IDE. 
While Ant is executed in the same JVM as the IDE in an isolated classloader, 
Maven is probably always started as a separate process. Given a regular JDK 
doesn't do anything useful for first 1-1.5s of execution we might have found 
the difference. Ant code is reused again and again and warms up over time. 
Maven always starts from scratch and JDK's warming delay causes the wrong 
impression.

Consider verifying my claims and observations.
-jt


> 
> I mean : a project for which there's a time gap between
> 
> - nb/command line mvn invocations
> - or between ant / mavn builds (I know : how many projects have TWO
> build files ? ...)
> 
> for routinely rebuilds of big projects I often activate the "quiet" and
> "parallel" build params
> and keep an eye at mvn java memory params.
> Usual network and I/O tricks may apply.
> 
> bye,
> 
>      Davide
> 
> On 25/08/2020 07:27, Jaroslav Tulach wrote:
> >> And it's Apache Maven, over the corner at https://maven.apache.org/ so
> >> I suppose that community would be happy to get such contributions.
> >> 
> >> -Bertrand
> > 
> > You are right, Bertrand. Why not ask!
> > 
> > Hello Maven guys,
> > we had a discussion on the NetBeans mailing list recently and here is a
> > summary:
> > * Apache NetBeans IDE is delegating most of its work directly to Maven
> > * Users however complain that the speed isn't great
> > * One of the ideas was to launch a "zombie" instance of Maven in advance
> > * then actions like build, exec or test would be faster
> > 
> > Have you thought about something like this already? Any advices?
> > 
> > Best regards.
> > Jaroslav Tulach
> > NetBeans Platform Architect
> > 
> > ne 23. 8. 2020 v 9:06 odesílatel Jaroslav Tulach
> > <ja...@gmail.com>> 
> > napsal:
> >>> I agree with others, Ant is much faster day to day. But the pom.xml has
> >>> become the universal project file for Java,
> >> 
> >> Thank you all for sharing your thoughts. I know Maven start is slower,
> >> but
> >> I
> >> learned to live with it. It is interesting to hear that some of you
> >> maintain a
> >> dual Ant based copy of your project metadata. Once we were trying a
> >> different
> >> approach:
> >> 
> >> There is a way to speed Maven in the IDE. Launch Maven, let it read all
> >> XML &
> >> co. files and stop it. As soon as we need to build/run/test, wake up this
> >> zombie Maven process, tell it what to do and let it continue. If the XML
> >> files
> >> are modified, throw the process away and initialize it again. Tomáš
> >> Stupka
> >> implemented a prototype of this and there were no issues, as far as I
> >> know
> >> (nobody tested it thoroughly however).
> >> 
> >> Maybe the support is even in and there is a property to turn it on. If
> >> the
> >> Maven startup is the biggest problem for you guys, we shall investigate
> >> how to
> >> turn Tomáš's work on...
> >> 
> >> -jt





---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
For additional commands, e-mail: dev-help@maven.apache.org

Re: Speed of Maven build

[Davide Grandi <da...@email.it>]

Sorry to be late, but
     there is a project test case for Maven "slowlyness" ?

I mean : a project for which there's a time gap between

- nb/command line mvn invocations
- or between ant / mavn builds (I know : how many projects have TWO 
build files ? ...)

for routinely rebuilds of big projects I often activate the "quiet" and 
"parallel" build params
and keep an eye at mvn java memory params.
Usual network and I/O tricks may apply.

bye,

     Davide

On 25/08/2020 07:27, Jaroslav Tulach wrote:
>> And it's Apache Maven, over the corner at https://maven.apache.org/ so
>> I suppose that community would be happy to get such contributions.
>>
>> -Bertrand
> You are right, Bertrand. Why not ask!
>
> Hello Maven guys,
> we had a discussion on the NetBeans mailing list recently and here is a
> summary:
> * Apache NetBeans IDE is delegating most of its work directly to Maven
> * Users however complain that the speed isn't great
> * One of the ideas was to launch a "zombie" instance of Maven in advance
> * then actions like build, exec or test would be faster
>
> Have you thought about something like this already? Any advices?
>
> Best regards.
> Jaroslav Tulach
> NetBeans Platform Architect
>
> ne 23. 8. 2020 v 9:06 odesílatel Jaroslav Tulach <ja...@gmail.com>
> napsal:
>
>>> I agree with others, Ant is much faster day to day. But the pom.xml has
>>> become the universal project file for Java,
>> Thank you all for sharing your thoughts. I know Maven start is slower, but
>> I
>> learned to live with it. It is interesting to hear that some of you
>> maintain a
>> dual Ant based copy of your project metadata. Once we were trying a
>> different
>> approach:
>>
>> There is a way to speed Maven in the IDE. Launch Maven, let it read all
>> XML &
>> co. files and stop it. As soon as we need to build/run/test, wake up this
>> zombie Maven process, tell it what to do and let it continue. If the XML
>> files
>> are modified, throw the process away and initialize it again. Tomáš Stupka
>> implemented a prototype of this and there were no issues, as far as I know
>> (nobody tested it thoroughly however).
>>
>> Maybe the support is even in and there is a property to turn it on. If the
>> Maven startup is the biggest problem for you guys, we shall investigate
>> how to
>> turn Tomáš's work on...
>>
>> -jt

-- 
Ing. Davide Grandi
email    : davide.grandi@email.it
linkedin : http://linkedin.com/in/davidegrandi


---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@netbeans.apache.org
For additional commands, e-mail: dev-help@netbeans.apache.org

For further information about the NetBeans mailing lists, visit:
https://cwiki.apache.org/confluence/display/NETBEANS/Mailing+lists

Re: Speed of Maven build

[Falko Modler <f....@gmx.net>]

Maybe slightly offtopic but if you have (many) submodules, you might
want to consider automatic incremental builds (based on SCM changes)
with https://github.com/vackosar/gitflow-incremental-builder

Don't be scared by the name. You do not actually need a gitflow branch
layout.

Disclaimer: I am maintaining gitflow-incremental-builder.

Cheers,

Falko

PS: IIRC, a few months ago someone on this mailing list came up with an
idea to "cache" build results with Maven. Not sure what happened to that
idea.

Am 25.08.2020 um 23:07 schrieb Manfred Moser:
> Also the M2Eclipse integration does basically embed maven and make the Maven build incremental.
>
> The Takari plugin does that on the commandline with the eclipse compiler
>
> And the VS code integration from Red Hat might also do something along those lines.
>
> Others can chime in with more details.
>
> Manfred
>
> John Patrick wrote on 2020-08-25 13:29 (GMT -07:00):
>
>> Are you planning to create a baseline project or selecting a range of
>> projects to be used as a baseline, so that perceived improvements can
>> be monitored? So that anyone wanting to help out or give feedback can
>> submit their own build performance.
>>
>> i.e.
>> 1. Equipment OS, Ram, CPU, physical, virtual, docker, openshift, other
>> 2. Java version
>> 3. Maven version
>> 4. Speedtest results
>> 5. Direct Internet Connection or via Http Proxy or via Nexus/Artifactory
>> 6. Clean/Fresh Local Repo Execution Time
>> 7. 2nd Execution Time, after everything downloaded
>>
>> As using Maven since 2005, I've found each new release has gotten
>> faster and faster, and most performance issues have been around what
>> OS I'm using, SSD vs HDD and also do you have enough free RAM etc.
>>
>> As I'm surprised how quickly my builds are running at the moment, the
>> only issue is when I see maven perform internet connections
>> downloading new dependencies or say the versions plugin to check. Any
>> thoughts about adding a HTTP/2 Server Push support so if it's Maven
>> Aware and you request the pom it can also push back the hashes and
>> maybe the jar too.
>>
>> Regarding a "zombie" maven instance, it should be opt in so i need to
>> explicitly enable it as often i'm jumping around between lots of
>> projects so don't want each having a "zombie" progress and i might not
>> be building that project again for another week maybe.
>>
>> John
>>
>> On Tue, 25 Aug 2020 at 12:27, Jeff Jensen
>> <je...@upstairstechnology.com> wrote:
>>> In case this helps, Jason Dillon has a "Maven Shell" that does what you
>>> seek for CLI - launches a Maven instance and runs interactive commands with
>>> it, saving the startup time.
>>> https://github.com/jdillon/mvnsh
>>>
>>>
>>> On Tue, Aug 25, 2020 at 12:27 AM Jaroslav Tulach <ja...@gmail.com>
>>> wrote:
>>>
>>>>> And it's Apache Maven, over the corner at https://maven.apache.org/ so
>>>>> I suppose that community would be happy to get such contributions.
>>>>>
>>>>> -Bertrand
>>>> You are right, Bertrand. Why not ask!
>>>>
>>>> Hello Maven guys,
>>>> we had a discussion on the NetBeans mailing list recently and here is a
>>>> summary:
>>>> * Apache NetBeans IDE is delegating most of its work directly to Maven
>>>> * Users however complain that the speed isn't great
>>>> * One of the ideas was to launch a "zombie" instance of Maven in advance
>>>> * then actions like build, exec or test would be faster
>>>>
>>>> Have you thought about something like this already? Any advices?
>>>>
>>>> Best regards.
>>>> Jaroslav Tulach
>>>> NetBeans Platform Architect
>>>>
>>>> ne 23. 8. 2020 v 9:06 odesílatel Jaroslav Tulach <
>>>> jaroslav.tulach@gmail.com>
>>>> napsal:
>>>>
>>>>>> I agree with others, Ant is much faster day to day. But the pom.xml has
>>>>>> become the universal project file for Java,
>>>>> Thank you all for sharing your thoughts. I know Maven start is slower,
>>>> but
>>>>> I
>>>>> learned to live with it. It is interesting to hear that some of you
>>>>> maintain a
>>>>> dual Ant based copy of your project metadata. Once we were trying a
>>>>> different
>>>>> approach:
>>>>>
>>>>> There is a way to speed Maven in the IDE. Launch Maven, let it read all
>>>>> XML &
>>>>> co. files and stop it. As soon as we need to build/run/test, wake up this
>>>>> zombie Maven process, tell it what to do and let it continue. If the XML
>>>>> files
>>>>> are modified, throw the process away and initialize it again. Tomáš
>>>> Stupka
>>>>> implemented a prototype of this and there were no issues, as far as I
>>>> know
>>>>> (nobody tested it thoroughly however).
>>>>>
>>>>> Maybe the support is even in and there is a property to turn it on. If
>>>> the
>>>>> Maven startup is the biggest problem for you guys, we shall investigate
>>>>> how to
>>>>> turn Tomáš's work on...
>>>>>
>>>>> -jt
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
>> For additional commands, e-mail: dev-help@maven.apache.org
>>
>>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
> For additional commands, e-mail: dev-help@maven.apache.org
>


---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
For additional commands, e-mail: dev-help@maven.apache.org

Re: Speed of Maven build

[Manfred Moser <ma...@simpligility.com>]

Mickael Istria wrote on 2020-08-25 14:17 (GMT -07:00):

> I
> 
> On Tuesday, August 25, 2020, Manfred Moser <ma...@simpligility.com> wrote:
>> And the VS code integration from Red Hat might also do something along
> those lines.
> 
> It embeds and uses m2eclipse.
> 

Haha.. thanks for confirming. I thought that to be the case but did not want to say it explicitly since I was only 80 or so percent sure.. 

manfred

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@netbeans.apache.org
For additional commands, e-mail: dev-help@netbeans.apache.org

For further information about the NetBeans mailing lists, visit:
https://cwiki.apache.org/confluence/display/NETBEANS/Mailing+lists

Re: Speed of Maven build

[Manfred Moser <ma...@simpligility.com>]

Mickael Istria wrote on 2020-08-25 14:17 (GMT -07:00):

> I
> 
> On Tuesday, August 25, 2020, Manfred Moser <ma...@simpligility.com> wrote:
>> And the VS code integration from Red Hat might also do something along
> those lines.
> 
> It embeds and uses m2eclipse.
> 

Haha.. thanks for confirming. I thought that to be the case but did not want to say it explicitly since I was only 80 or so percent sure.. 

manfred

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
For additional commands, e-mail: dev-help@maven.apache.org

Re: Speed of Maven build

[Mickael Istria <mi...@redhat.com>]

I

On Tuesday, August 25, 2020, Manfred Moser <ma...@simpligility.com> wrote:
> And the VS code integration from Red Hat might also do something along
those lines.

It embeds and uses m2eclipse.

-- 
Mickael Istria
Eclipse IDE <https://www.eclipse.org/downloads/eclipse-packages/>
developer, for Red Hat Developers <https://developers.redhat.com/>

Re: Speed of Maven build

[Mickael Istria <mi...@redhat.com>]

I

On Tuesday, August 25, 2020, Manfred Moser <ma...@simpligility.com> wrote:
> And the VS code integration from Red Hat might also do something along
those lines.

It embeds and uses m2eclipse.

-- 
Mickael Istria
Eclipse IDE <https://www.eclipse.org/downloads/eclipse-packages/>
developer, for Red Hat Developers <https://developers.redhat.com/>

Re: Speed of Maven build

[Manfred Moser <ma...@simpligility.com>]

Also the M2Eclipse integration does basically embed maven and make the Maven build incremental.

The Takari plugin does that on the commandline with the eclipse compiler

And the VS code integration from Red Hat might also do something along those lines.

Others can chime in with more details.

Manfred

John Patrick wrote on 2020-08-25 13:29 (GMT -07:00):

> Are you planning to create a baseline project or selecting a range of
> projects to be used as a baseline, so that perceived improvements can
> be monitored? So that anyone wanting to help out or give feedback can
> submit their own build performance.
> 
> i.e.
> 1. Equipment OS, Ram, CPU, physical, virtual, docker, openshift, other
> 2. Java version
> 3. Maven version
> 4. Speedtest results
> 5. Direct Internet Connection or via Http Proxy or via Nexus/Artifactory
> 6. Clean/Fresh Local Repo Execution Time
> 7. 2nd Execution Time, after everything downloaded
> 
> As using Maven since 2005, I've found each new release has gotten
> faster and faster, and most performance issues have been around what
> OS I'm using, SSD vs HDD and also do you have enough free RAM etc.
> 
> As I'm surprised how quickly my builds are running at the moment, the
> only issue is when I see maven perform internet connections
> downloading new dependencies or say the versions plugin to check. Any
> thoughts about adding a HTTP/2 Server Push support so if it's Maven
> Aware and you request the pom it can also push back the hashes and
> maybe the jar too.
> 
> Regarding a "zombie" maven instance, it should be opt in so i need to
> explicitly enable it as often i'm jumping around between lots of
> projects so don't want each having a "zombie" progress and i might not
> be building that project again for another week maybe.
> 
> John
> 
> On Tue, 25 Aug 2020 at 12:27, Jeff Jensen
> <je...@upstairstechnology.com> wrote:
>>
>> In case this helps, Jason Dillon has a "Maven Shell" that does what you
>> seek for CLI - launches a Maven instance and runs interactive commands with
>> it, saving the startup time.
>> https://github.com/jdillon/mvnsh
>>
>>
>> On Tue, Aug 25, 2020 at 12:27 AM Jaroslav Tulach <ja...@gmail.com>
>> wrote:
>>
>> > > And it's Apache Maven, over the corner at https://maven.apache.org/ so
>> > > I suppose that community would be happy to get such contributions.
>> > >
>> > > -Bertrand
>> >
>> > You are right, Bertrand. Why not ask!
>> >
>> > Hello Maven guys,
>> > we had a discussion on the NetBeans mailing list recently and here is a
>> > summary:
>> > * Apache NetBeans IDE is delegating most of its work directly to Maven
>> > * Users however complain that the speed isn't great
>> > * One of the ideas was to launch a "zombie" instance of Maven in advance
>> > * then actions like build, exec or test would be faster
>> >
>> > Have you thought about something like this already? Any advices?
>> >
>> > Best regards.
>> > Jaroslav Tulach
>> > NetBeans Platform Architect
>> >
>> > ne 23. 8. 2020 v 9:06 odesílatel Jaroslav Tulach <
>> > jaroslav.tulach@gmail.com>
>> > napsal:
>> >
>> > > > I agree with others, Ant is much faster day to day. But the pom.xml has
>> > > > become the universal project file for Java,
>> > >
>> > > Thank you all for sharing your thoughts. I know Maven start is slower,
>> > but
>> > > I
>> > > learned to live with it. It is interesting to hear that some of you
>> > > maintain a
>> > > dual Ant based copy of your project metadata. Once we were trying a
>> > > different
>> > > approach:
>> > >
>> > > There is a way to speed Maven in the IDE. Launch Maven, let it read all
>> > > XML &
>> > > co. files and stop it. As soon as we need to build/run/test, wake up this
>> > > zombie Maven process, tell it what to do and let it continue. If the XML
>> > > files
>> > > are modified, throw the process away and initialize it again. Tomáš
>> > Stupka
>> > > implemented a prototype of this and there were no issues, as far as I
>> > know
>> > > (nobody tested it thoroughly however).
>> > >
>> > > Maybe the support is even in and there is a property to turn it on. If
>> > the
>> > > Maven startup is the biggest problem for you guys, we shall investigate
>> > > how to
>> > > turn Tomáš's work on...
>> > >
>> > > -jt
>> > >
>> > >
>> > >
>> > >
>> > >
>> > >
>> >
> 
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
> For additional commands, e-mail: dev-help@maven.apache.org
> 
> 

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@netbeans.apache.org
For additional commands, e-mail: dev-help@netbeans.apache.org

For further information about the NetBeans mailing lists, visit:
https://cwiki.apache.org/confluence/display/NETBEANS/Mailing+lists

Re: Speed of Maven build

[Manfred Moser <ma...@simpligility.com>]

Also the M2Eclipse integration does basically embed maven and make the Maven build incremental.

The Takari plugin does that on the commandline with the eclipse compiler

And the VS code integration from Red Hat might also do something along those lines.

Others can chime in with more details.

Manfred

John Patrick wrote on 2020-08-25 13:29 (GMT -07:00):

> Are you planning to create a baseline project or selecting a range of
> projects to be used as a baseline, so that perceived improvements can
> be monitored? So that anyone wanting to help out or give feedback can
> submit their own build performance.
> 
> i.e.
> 1. Equipment OS, Ram, CPU, physical, virtual, docker, openshift, other
> 2. Java version
> 3. Maven version
> 4. Speedtest results
> 5. Direct Internet Connection or via Http Proxy or via Nexus/Artifactory
> 6. Clean/Fresh Local Repo Execution Time
> 7. 2nd Execution Time, after everything downloaded
> 
> As using Maven since 2005, I've found each new release has gotten
> faster and faster, and most performance issues have been around what
> OS I'm using, SSD vs HDD and also do you have enough free RAM etc.
> 
> As I'm surprised how quickly my builds are running at the moment, the
> only issue is when I see maven perform internet connections
> downloading new dependencies or say the versions plugin to check. Any
> thoughts about adding a HTTP/2 Server Push support so if it's Maven
> Aware and you request the pom it can also push back the hashes and
> maybe the jar too.
> 
> Regarding a "zombie" maven instance, it should be opt in so i need to
> explicitly enable it as often i'm jumping around between lots of
> projects so don't want each having a "zombie" progress and i might not
> be building that project again for another week maybe.
> 
> John
> 
> On Tue, 25 Aug 2020 at 12:27, Jeff Jensen
> <je...@upstairstechnology.com> wrote:
>>
>> In case this helps, Jason Dillon has a "Maven Shell" that does what you
>> seek for CLI - launches a Maven instance and runs interactive commands with
>> it, saving the startup time.
>> https://github.com/jdillon/mvnsh
>>
>>
>> On Tue, Aug 25, 2020 at 12:27 AM Jaroslav Tulach <ja...@gmail.com>
>> wrote:
>>
>> > > And it's Apache Maven, over the corner at https://maven.apache.org/ so
>> > > I suppose that community would be happy to get such contributions.
>> > >
>> > > -Bertrand
>> >
>> > You are right, Bertrand. Why not ask!
>> >
>> > Hello Maven guys,
>> > we had a discussion on the NetBeans mailing list recently and here is a
>> > summary:
>> > * Apache NetBeans IDE is delegating most of its work directly to Maven
>> > * Users however complain that the speed isn't great
>> > * One of the ideas was to launch a "zombie" instance of Maven in advance
>> > * then actions like build, exec or test would be faster
>> >
>> > Have you thought about something like this already? Any advices?
>> >
>> > Best regards.
>> > Jaroslav Tulach
>> > NetBeans Platform Architect
>> >
>> > ne 23. 8. 2020 v 9:06 odesílatel Jaroslav Tulach <
>> > jaroslav.tulach@gmail.com>
>> > napsal:
>> >
>> > > > I agree with others, Ant is much faster day to day. But the pom.xml has
>> > > > become the universal project file for Java,
>> > >
>> > > Thank you all for sharing your thoughts. I know Maven start is slower,
>> > but
>> > > I
>> > > learned to live with it. It is interesting to hear that some of you
>> > > maintain a
>> > > dual Ant based copy of your project metadata. Once we were trying a
>> > > different
>> > > approach:
>> > >
>> > > There is a way to speed Maven in the IDE. Launch Maven, let it read all
>> > > XML &
>> > > co. files and stop it. As soon as we need to build/run/test, wake up this
>> > > zombie Maven process, tell it what to do and let it continue. If the XML
>> > > files
>> > > are modified, throw the process away and initialize it again. Tomáš
>> > Stupka
>> > > implemented a prototype of this and there were no issues, as far as I
>> > know
>> > > (nobody tested it thoroughly however).
>> > >
>> > > Maybe the support is even in and there is a property to turn it on. If
>> > the
>> > > Maven startup is the biggest problem for you guys, we shall investigate
>> > > how to
>> > > turn Tomáš's work on...
>> > >
>> > > -jt
>> > >
>> > >
>> > >
>> > >
>> > >
>> > >
>> >
> 
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
> For additional commands, e-mail: dev-help@maven.apache.org
> 
> 

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
For additional commands, e-mail: dev-help@maven.apache.org

Re: Speed of Maven build

[John Patrick <nh...@gmail.com>]

Are you planning to create a baseline project or selecting a range of
projects to be used as a baseline, so that perceived improvements can
be monitored? So that anyone wanting to help out or give feedback can
submit their own build performance.

i.e.
1. Equipment OS, Ram, CPU, physical, virtual, docker, openshift, other
2. Java version
3. Maven version
4. Speedtest results
5. Direct Internet Connection or via Http Proxy or via Nexus/Artifactory
6. Clean/Fresh Local Repo Execution Time
7. 2nd Execution Time, after everything downloaded

As using Maven since 2005, I've found each new release has gotten
faster and faster, and most performance issues have been around what
OS I'm using, SSD vs HDD and also do you have enough free RAM etc.

As I'm surprised how quickly my builds are running at the moment, the
only issue is when I see maven perform internet connections
downloading new dependencies or say the versions plugin to check. Any
thoughts about adding a HTTP/2 Server Push support so if it's Maven
Aware and you request the pom it can also push back the hashes and
maybe the jar too.

Regarding a "zombie" maven instance, it should be opt in so i need to
explicitly enable it as often i'm jumping around between lots of
projects so don't want each having a "zombie" progress and i might not
be building that project again for another week maybe.

John

On Tue, 25 Aug 2020 at 12:27, Jeff Jensen
<je...@upstairstechnology.com> wrote:
>
> In case this helps, Jason Dillon has a "Maven Shell" that does what you
> seek for CLI - launches a Maven instance and runs interactive commands with
> it, saving the startup time.
> https://github.com/jdillon/mvnsh
>
>
> On Tue, Aug 25, 2020 at 12:27 AM Jaroslav Tulach <ja...@gmail.com>
> wrote:
>
> > > And it's Apache Maven, over the corner at https://maven.apache.org/ so
> > > I suppose that community would be happy to get such contributions.
> > >
> > > -Bertrand
> >
> > You are right, Bertrand. Why not ask!
> >
> > Hello Maven guys,
> > we had a discussion on the NetBeans mailing list recently and here is a
> > summary:
> > * Apache NetBeans IDE is delegating most of its work directly to Maven
> > * Users however complain that the speed isn't great
> > * One of the ideas was to launch a "zombie" instance of Maven in advance
> > * then actions like build, exec or test would be faster
> >
> > Have you thought about something like this already? Any advices?
> >
> > Best regards.
> > Jaroslav Tulach
> > NetBeans Platform Architect
> >
> > ne 23. 8. 2020 v 9:06 odesílatel Jaroslav Tulach <
> > jaroslav.tulach@gmail.com>
> > napsal:
> >
> > > > I agree with others, Ant is much faster day to day. But the pom.xml has
> > > > become the universal project file for Java,
> > >
> > > Thank you all for sharing your thoughts. I know Maven start is slower,
> > but
> > > I
> > > learned to live with it. It is interesting to hear that some of you
> > > maintain a
> > > dual Ant based copy of your project metadata. Once we were trying a
> > > different
> > > approach:
> > >
> > > There is a way to speed Maven in the IDE. Launch Maven, let it read all
> > > XML &
> > > co. files and stop it. As soon as we need to build/run/test, wake up this
> > > zombie Maven process, tell it what to do and let it continue. If the XML
> > > files
> > > are modified, throw the process away and initialize it again. Tomáš
> > Stupka
> > > implemented a prototype of this and there were no issues, as far as I
> > know
> > > (nobody tested it thoroughly however).
> > >
> > > Maybe the support is even in and there is a property to turn it on. If
> > the
> > > Maven startup is the biggest problem for you guys, we shall investigate
> > > how to
> > > turn Tomáš's work on...
> > >
> > > -jt
> > >
> > >
> > >
> > >
> > >
> > >
> >

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@netbeans.apache.org
For additional commands, e-mail: dev-help@netbeans.apache.org

For further information about the NetBeans mailing lists, visit:
https://cwiki.apache.org/confluence/display/NETBEANS/Mailing+lists

Re: Speed of Maven build

[Will Hartung <wi...@gmail.com>]

On Tue, Aug 25, 2020 at 4:37 AM Jeff Jensen <
jeffjensen@upstairstechnology.com> wrote:

> In case this helps, Jason Dillon has a "Maven Shell" that does what you
> seek for CLI - launches a Maven instance and runs interactive commands with
> it, saving the startup time.
> https://github.com/jdillon/mvnsh
>
> Is this really where the runtime for Maven goes? I always felt it was
loading the POMs, walking the dependencies, plus all the network hits
(which can be mitigated with the -o flag).

Re: Speed of Maven build

[Will Hartung <wi...@gmail.com>]

On Tue, Aug 25, 2020 at 4:37 AM Jeff Jensen <
jeffjensen@upstairstechnology.com> wrote:

> In case this helps, Jason Dillon has a "Maven Shell" that does what you
> seek for CLI - launches a Maven instance and runs interactive commands with
> it, saving the startup time.
> https://github.com/jdillon/mvnsh
>
> Is this really where the runtime for Maven goes? I always felt it was
loading the POMs, walking the dependencies, plus all the network hits
(which can be mitigated with the -o flag).

Re: Speed of Maven build

[John Patrick <nh...@gmail.com>]

Are you planning to create a baseline project or selecting a range of
projects to be used as a baseline, so that perceived improvements can
be monitored? So that anyone wanting to help out or give feedback can
submit their own build performance.

i.e.
1. Equipment OS, Ram, CPU, physical, virtual, docker, openshift, other
2. Java version
3. Maven version
4. Speedtest results
5. Direct Internet Connection or via Http Proxy or via Nexus/Artifactory
6. Clean/Fresh Local Repo Execution Time
7. 2nd Execution Time, after everything downloaded

As using Maven since 2005, I've found each new release has gotten
faster and faster, and most performance issues have been around what
OS I'm using, SSD vs HDD and also do you have enough free RAM etc.

As I'm surprised how quickly my builds are running at the moment, the
only issue is when I see maven perform internet connections
downloading new dependencies or say the versions plugin to check. Any
thoughts about adding a HTTP/2 Server Push support so if it's Maven
Aware and you request the pom it can also push back the hashes and
maybe the jar too.

Regarding a "zombie" maven instance, it should be opt in so i need to
explicitly enable it as often i'm jumping around between lots of
projects so don't want each having a "zombie" progress and i might not
be building that project again for another week maybe.

John

On Tue, 25 Aug 2020 at 12:27, Jeff Jensen
<je...@upstairstechnology.com> wrote:
>
> In case this helps, Jason Dillon has a "Maven Shell" that does what you
> seek for CLI - launches a Maven instance and runs interactive commands with
> it, saving the startup time.
> https://github.com/jdillon/mvnsh
>
>
> On Tue, Aug 25, 2020 at 12:27 AM Jaroslav Tulach <ja...@gmail.com>
> wrote:
>
> > > And it's Apache Maven, over the corner at https://maven.apache.org/ so
> > > I suppose that community would be happy to get such contributions.
> > >
> > > -Bertrand
> >
> > You are right, Bertrand. Why not ask!
> >
> > Hello Maven guys,
> > we had a discussion on the NetBeans mailing list recently and here is a
> > summary:
> > * Apache NetBeans IDE is delegating most of its work directly to Maven
> > * Users however complain that the speed isn't great
> > * One of the ideas was to launch a "zombie" instance of Maven in advance
> > * then actions like build, exec or test would be faster
> >
> > Have you thought about something like this already? Any advices?
> >
> > Best regards.
> > Jaroslav Tulach
> > NetBeans Platform Architect
> >
> > ne 23. 8. 2020 v 9:06 odesílatel Jaroslav Tulach <
> > jaroslav.tulach@gmail.com>
> > napsal:
> >
> > > > I agree with others, Ant is much faster day to day. But the pom.xml has
> > > > become the universal project file for Java,
> > >
> > > Thank you all for sharing your thoughts. I know Maven start is slower,
> > but
> > > I
> > > learned to live with it. It is interesting to hear that some of you
> > > maintain a
> > > dual Ant based copy of your project metadata. Once we were trying a
> > > different
> > > approach:
> > >
> > > There is a way to speed Maven in the IDE. Launch Maven, let it read all
> > > XML &
> > > co. files and stop it. As soon as we need to build/run/test, wake up this
> > > zombie Maven process, tell it what to do and let it continue. If the XML
> > > files
> > > are modified, throw the process away and initialize it again. Tomáš
> > Stupka
> > > implemented a prototype of this and there were no issues, as far as I
> > know
> > > (nobody tested it thoroughly however).
> > >
> > > Maybe the support is even in and there is a property to turn it on. If
> > the
> > > Maven startup is the biggest problem for you guys, we shall investigate
> > > how to
> > > turn Tomáš's work on...
> > >
> > > -jt
> > >
> > >
> > >
> > >
> > >
> > >
> >

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
For additional commands, e-mail: dev-help@maven.apache.org

Re: Speed of Maven build

[Jeff Jensen <je...@upstairstechnology.com>]

In case this helps, Jason Dillon has a "Maven Shell" that does what you
seek for CLI - launches a Maven instance and runs interactive commands with
it, saving the startup time.
https://github.com/jdillon/mvnsh


On Tue, Aug 25, 2020 at 12:27 AM Jaroslav Tulach <ja...@gmail.com>
wrote:

> > And it's Apache Maven, over the corner at https://maven.apache.org/ so
> > I suppose that community would be happy to get such contributions.
> >
> > -Bertrand
>
> You are right, Bertrand. Why not ask!
>
> Hello Maven guys,
> we had a discussion on the NetBeans mailing list recently and here is a
> summary:
> * Apache NetBeans IDE is delegating most of its work directly to Maven
> * Users however complain that the speed isn't great
> * One of the ideas was to launch a "zombie" instance of Maven in advance
> * then actions like build, exec or test would be faster
>
> Have you thought about something like this already? Any advices?
>
> Best regards.
> Jaroslav Tulach
> NetBeans Platform Architect
>
> ne 23. 8. 2020 v 9:06 odesílatel Jaroslav Tulach <
> jaroslav.tulach@gmail.com>
> napsal:
>
> > > I agree with others, Ant is much faster day to day. But the pom.xml has
> > > become the universal project file for Java,
> >
> > Thank you all for sharing your thoughts. I know Maven start is slower,
> but
> > I
> > learned to live with it. It is interesting to hear that some of you
> > maintain a
> > dual Ant based copy of your project metadata. Once we were trying a
> > different
> > approach:
> >
> > There is a way to speed Maven in the IDE. Launch Maven, let it read all
> > XML &
> > co. files and stop it. As soon as we need to build/run/test, wake up this
> > zombie Maven process, tell it what to do and let it continue. If the XML
> > files
> > are modified, throw the process away and initialize it again. Tomáš
> Stupka
> > implemented a prototype of this and there were no issues, as far as I
> know
> > (nobody tested it thoroughly however).
> >
> > Maybe the support is even in and there is a property to turn it on. If
> the
> > Maven startup is the biggest problem for you guys, we shall investigate
> > how to
> > turn Tomáš's work on...
> >
> > -jt
> >
> >
> >
> >
> >
> >
>

Re: Speed of Maven build

[Jeff Jensen <je...@upstairstechnology.com>]

In case this helps, Jason Dillon has a "Maven Shell" that does what you
seek for CLI - launches a Maven instance and runs interactive commands with
it, saving the startup time.
https://github.com/jdillon/mvnsh


On Tue, Aug 25, 2020 at 12:27 AM Jaroslav Tulach <ja...@gmail.com>
wrote:

> > And it's Apache Maven, over the corner at https://maven.apache.org/ so
> > I suppose that community would be happy to get such contributions.
> >
> > -Bertrand
>
> You are right, Bertrand. Why not ask!
>
> Hello Maven guys,
> we had a discussion on the NetBeans mailing list recently and here is a
> summary:
> * Apache NetBeans IDE is delegating most of its work directly to Maven
> * Users however complain that the speed isn't great
> * One of the ideas was to launch a "zombie" instance of Maven in advance
> * then actions like build, exec or test would be faster
>
> Have you thought about something like this already? Any advices?
>
> Best regards.
> Jaroslav Tulach
> NetBeans Platform Architect
>
> ne 23. 8. 2020 v 9:06 odesílatel Jaroslav Tulach <
> jaroslav.tulach@gmail.com>
> napsal:
>
> > > I agree with others, Ant is much faster day to day. But the pom.xml has
> > > become the universal project file for Java,
> >
> > Thank you all for sharing your thoughts. I know Maven start is slower,
> but
> > I
> > learned to live with it. It is interesting to hear that some of you
> > maintain a
> > dual Ant based copy of your project metadata. Once we were trying a
> > different
> > approach:
> >
> > There is a way to speed Maven in the IDE. Launch Maven, let it read all
> > XML &
> > co. files and stop it. As soon as we need to build/run/test, wake up this
> > zombie Maven process, tell it what to do and let it continue. If the XML
> > files
> > are modified, throw the process away and initialize it again. Tomáš
> Stupka
> > implemented a prototype of this and there were no issues, as far as I
> know
> > (nobody tested it thoroughly however).
> >
> > Maybe the support is even in and there is a property to turn it on. If
> the
> > Maven startup is the biggest problem for you guys, we shall investigate
> > how to
> > turn Tomáš's work on...
> >
> > -jt
> >
> >
> >
> >
> >
> >
>

Re: Speed of Maven build

[Jaroslav Tulach <ja...@gmail.com>]

> And it's Apache Maven, over the corner at https://maven.apache.org/ so
> I suppose that community would be happy to get such contributions.
>
> -Bertrand

You are right, Bertrand. Why not ask!

Hello Maven guys,
we had a discussion on the NetBeans mailing list recently and here is a
summary:
* Apache NetBeans IDE is delegating most of its work directly to Maven
* Users however complain that the speed isn't great
* One of the ideas was to launch a "zombie" instance of Maven in advance
* then actions like build, exec or test would be faster

Have you thought about something like this already? Any advices?

Best regards.
Jaroslav Tulach
NetBeans Platform Architect

ne 23. 8. 2020 v 9:06 odesílatel Jaroslav Tulach <ja...@gmail.com>
napsal:

> > I agree with others, Ant is much faster day to day. But the pom.xml has
> > become the universal project file for Java,
>
> Thank you all for sharing your thoughts. I know Maven start is slower, but
> I
> learned to live with it. It is interesting to hear that some of you
> maintain a
> dual Ant based copy of your project metadata. Once we were trying a
> different
> approach:
>
> There is a way to speed Maven in the IDE. Launch Maven, let it read all
> XML &
> co. files and stop it. As soon as we need to build/run/test, wake up this
> zombie Maven process, tell it what to do and let it continue. If the XML
> files
> are modified, throw the process away and initialize it again. Tomáš Stupka
> implemented a prototype of this and there were no issues, as far as I know
> (nobody tested it thoroughly however).
>
> Maybe the support is even in and there is a property to turn it on. If the
> Maven startup is the biggest problem for you guys, we shall investigate
> how to
> turn Tomáš's work on...
>
> -jt
>
>
>
>
>
>

Re: Speed of Maven build

[Jaroslav Tulach <ja...@gmail.com>]

> And it's Apache Maven, over the corner at https://maven.apache.org/ so
> I suppose that community would be happy to get such contributions.
>
> -Bertrand

You are right, Bertrand. Why not ask!

Hello Maven guys,
we had a discussion on the NetBeans mailing list recently and here is a
summary:
* Apache NetBeans IDE is delegating most of its work directly to Maven
* Users however complain that the speed isn't great
* One of the ideas was to launch a "zombie" instance of Maven in advance
* then actions like build, exec or test would be faster

Have you thought about something like this already? Any advices?

Best regards.
Jaroslav Tulach
NetBeans Platform Architect

ne 23. 8. 2020 v 9:06 odesílatel Jaroslav Tulach <ja...@gmail.com>
napsal:

> > I agree with others, Ant is much faster day to day. But the pom.xml has
> > become the universal project file for Java,
>
> Thank you all for sharing your thoughts. I know Maven start is slower, but
> I
> learned to live with it. It is interesting to hear that some of you
> maintain a
> dual Ant based copy of your project metadata. Once we were trying a
> different
> approach:
>
> There is a way to speed Maven in the IDE. Launch Maven, let it read all
> XML &
> co. files and stop it. As soon as we need to build/run/test, wake up this
> zombie Maven process, tell it what to do and let it continue. If the XML
> files
> are modified, throw the process away and initialize it again. Tomáš Stupka
> implemented a prototype of this and there were no issues, as far as I know
> (nobody tested it thoroughly however).
>
> Maybe the support is even in and there is a property to turn it on. If the
> Maven startup is the biggest problem for you guys, we shall investigate
> how to
> turn Tomáš's work on...
>
> -jt
>
>
>
>
>
>

Re: Speed of Maven build was: Status of Ant vs Maven

[Bertrand Delacretaz <bd...@apache.org>]

On Sun, Aug 23, 2020 at 9:06 AM Jaroslav Tulach
<ja...@gmail.com> wrote:
> ...If the
> Maven startup is the biggest problem for you guys, we shall investigate how to
> turn Tomáš's work on...

And it's Apache Maven, over the corner at https://maven.apache.org/ so
I suppose that community would be happy to get such contributions.

-Bertrand

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@netbeans.apache.org
For additional commands, e-mail: dev-help@netbeans.apache.org

For further information about the NetBeans mailing lists, visit:
https://cwiki.apache.org/confluence/display/NETBEANS/Mailing+lists

Speed of Maven build was: Status of Ant vs Maven

[Jaroslav Tulach <ja...@gmail.com>]

> I agree with others, Ant is much faster day to day. But the pom.xml has
> become the universal project file for Java, 

Thank you all for sharing your thoughts. I know Maven start is slower, but I 
learned to live with it. It is interesting to hear that some of you maintain a 
dual Ant based copy of your project metadata. Once we were trying a different 
approach:

There is a way to speed Maven in the IDE. Launch Maven, let it read all XML & 
co. files and stop it. As soon as we need to build/run/test, wake up this 
zombie Maven process, tell it what to do and let it continue. If the XML files 
are modified, throw the process away and initialize it again. Tomáš Stupka 
implemented a prototype of this and there were no issues, as far as I know 
(nobody tested it thoroughly however).

Maybe the support is even in and there is a property to turn it on. If the 
Maven startup is the biggest problem for you guys, we shall investigate how to 
turn Tomáš's work on...

-jt






---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@netbeans.apache.org
For additional commands, e-mail: dev-help@netbeans.apache.org

For further information about the NetBeans mailing lists, visit:
https://cwiki.apache.org/confluence/display/NETBEANS/Mailing+lists

Re: Status of Ant vs Maven

[Will Hartung <wi...@gmail.com>]

On Wed, Aug 12, 2020 at 8:00 AM Jack W. <so...@gmail.com> wrote:

> Jaroslav is probably correct, so by all means, do make NB's generator favor
> Maven, if that's the community sentiment.
>

One of the things that prompted this for me was I was considering running
through and updating the NB Platform tutorials, which can all use some
work. And one of the considerations I was having was whether to simply
clean it up, or whether they perhaps should be "redone" using the Maven
projects as a baseline rather than the Ant projects. And, also, simply, to
make sure that they even worked under Maven.

I agrees with others, Ant is much faster day to day. But the pom.xml has
become the universal project file for Java, since all of the IDEs support
it, helping ensure that a single source base can work across multiple IDEs.
And Maven has become more and more a first class citizen within the NB
system, which is why I wanted to know what the community view was on the
Ant project system and any visions for it in the future.

Re: Status of Ant vs Maven

["Jack W." <so...@gmail.com>]

On Tue, Aug 11, 2020 at 9:36 PM Jaroslav Tulach <ja...@gmail.com>
wrote:

> ...I'd say that Ant is a legacy. We don't expect new projects to be created
> with the Ant build system.


Don't underestimate the persistence of legacy code. There are maybe
millions of lines of Ant out there.

I can appreciate this, 1) as an Ant user who finds Maven overkill, and 2)
as someone who makes his living maintaining legacy systems, sometimes
touching code over 40 years old.

Jaroslav is probably correct, so by all means, do make NB's generator favor
Maven, if that's the community sentiment.

... BUT ... ("Everyone has a big 'but'." - Pee Wee Herman) ... BUT ...

Keep in mind that, most likely, Ant isn't going to fade into the shadows of
software development history before NetBeans itself fades thither.

---
Jack Woehr               # Woehr's Asymptote: The ratio of the time spent
Box 51, Golden CO 80402  # administering productivity software over the time
http://www.softwoehr.com # saved by said software eventually approximates 1.

Re: Status of Ant vs Maven

[Martin Desruisseaux <ma...@geomatys.com>]

Le 12/08/2020 à 14:10, Thomas Kellerer a écrit :

>> I also maintain an Ant project configuration in an 
>> "ide-project/NetBeans/" directory for those who wish to open the 
>> project as a NetBeans Ant project.
>>
> How is this possible? NetBeans complains if two projects share the 
> same source directory (and refuses to open either of them)
>
I must have never opened that particular project as a Maven project in 
Netbeans before (other projects are not impacted). I run Maven for that 
project on the command-line only. If by accident I have opened that 
project as a Maven project, closing Netbeans, erasing the cache 
directory and restarting Netbeans solves the problem.

     Martin



---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@netbeans.apache.org
For additional commands, e-mail: dev-help@netbeans.apache.org

For further information about the NetBeans mailing lists, visit:
https://cwiki.apache.org/confluence/display/NETBEANS/Mailing+lists

Re: Status of Ant vs Maven

[Thomas Kellerer <sh...@gmx.net>]

Martin Desruisseaux schrieb am 12.08.2020 um 13:58:
>> ...I'd say that Ant is a legacy. We don't expect new projects to be created with the Ant build system.
>>
> But Ant is faster for daily development in Netbeans. Compiling and
> running a file (with or without debugger) is instantaneous with an
> Ant project while every execution takes a perceivable delay to launch
> as a Maven project.

This is the main reason I still use Ant based projects for anything that is not shared in a development team (e.g. private projects, simple tools etc)


> I also maintain an Ant project configuration in an
> "ide-project/NetBeans/" directory for those who wish to open the
> project as a NetBeans Ant project.

How is this possible? NetBeans complains if two projects share the same source directory (and refuses to open either of them)

Thomas






---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@netbeans.apache.org
For additional commands, e-mail: dev-help@netbeans.apache.org

For further information about the NetBeans mailing lists, visit:
https://cwiki.apache.org/confluence/display/NETBEANS/Mailing+lists

Re: Status of Ant vs Maven

[Martin Desruisseaux <ma...@geomatys.com>]

Le 12/08/2020 à 05:36, Jaroslav Tulach a écrit :

> ...I'd say that Ant is a legacy. We don't expect new projects to be 
> created with the Ant build system.
>
I have a mixed point of view. Maven is convenient for automatic download 
of dependencies and for more uniform project configurations (less effort 
in understanding how to build a new project and where to find files). 
But Ant is faster for daily development in Netbeans. Compiling and 
running a file (with or without debugger) is instantaneous with an Ant 
project while every execution takes a perceivable delay to launch as a 
Maven project. The speed and flexibility of Ant compared to Maven is 
still atractive enough that I maintain two project configurations for 
Apache SIS: the "official" build system is Maven, but I also maintain an 
Ant project configuration in an "ide-project/NetBeans/" directory for 
those who wish to open the project as a NetBeans Ant project. On my 
side, having the choice between both Maven and Ant for the same project, 
I use Ant everyday for development and launch Maven only before to 
commit for making sure that my changes work with the "official" build 
system.

That said, I do not think that all functionalities should work with Ant 
projects; I'm fine with Maven being the main target. The only 
functionality that I really miss with Ant projects is JUnit 5 support.

     Martin



---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@netbeans.apache.org
For additional commands, e-mail: dev-help@netbeans.apache.org

For further information about the NetBeans mailing lists, visit:
https://cwiki.apache.org/confluence/display/NETBEANS/Mailing+lists

Re: Status of Ant vs Maven

[Jaroslav Tulach <ja...@gmail.com>]

There was some discussion...

https://issues.apache.org/jira/browse/NETBEANS-2040
https://github.com/apache/netbeans/pull/1038
https://github.com/apache/netbeans/pull/1115
https://blogs.apache.org/netbeans/entry/restructuring-of-project-templates-in

...I'd say that Ant is a legacy. We don't expect new projects to be created
with the Ant build system.

Maven is the presence. I call Apache NetBeans IDE the UI for Apache Maven.
I'd suggest to make sure all features work in Maven projects.

st 12. 8. 2020 v 4:46 odesílatel Scott Palmer <sw...@gmail.com> napsal:

> Please don’t omit Gradle from this discussion.
>

There are many gradle projects out there and it is important for the
NetBeans IDE to be able to (at least) open them up and work with the
sources.
-jt


> > On Aug 10, 2020, at 12:06 PM, Will Hartung <wi...@gmail.com>
> wrote:
> >
> > Ant has been the historic underlying build tool for Netbeans projects,
> but
> > over the years, not only has NB been a very good companion with Maven,
> > Maven is also much more popular industry wide.
> >
> > There was a comment on the user list recently about Java FX, and one
> reply
> > was, paraphrasing, "the best way to use Java FX was to use Maven".
> >
> > I was also looking at the legacy NB Platform tutorials, which use Ant,
> but
> > certainly need some updating.
> >
> > But that brought the question. Should one style of build be promoted over
> > the other, are both systems "faithfully and fully supported", or is Ant
> > going to perhaps slowly die on the vine of disinterest?
> >
> > Is there any internal mandate of ensuring compatibility between the two
> > build system, especially in terms of ensuring high level things like
> > wizards and whatnot work for both systems? If someone adds a new feature,
> > contrived, "Create a Microprofile web service", is the project obligated
> > (as much as it's obligated to do anything) to create a wizard for both
> Ant
> > and Maven, or is it acceptable to only use one mechanism?
> >
> > Just curious if there's any formal position on the two systems and their
> > status within the NB environment today.
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@netbeans.apache.org
> For additional commands, e-mail: dev-help@netbeans.apache.org
>
> For further information about the NetBeans mailing lists, visit:
> https://cwiki.apache.org/confluence/display/NETBEANS/Mailing+lists
>
>
>
>

Re: Status of Ant vs Maven

[Scott Palmer <sw...@gmail.com>]

Please don’t omit Gradle from this discussion. 

Scott

> On Aug 10, 2020, at 12:06 PM, Will Hartung <wi...@gmail.com> wrote:
> 
> Ant has been the historic underlying build tool for Netbeans projects, but
> over the years, not only has NB been a very good companion with Maven,
> Maven is also much more popular industry wide.
> 
> There was a comment on the user list recently about Java FX, and one reply
> was, paraphrasing, "the best way to use Java FX was to use Maven".
> 
> I was also looking at the legacy NB Platform tutorials, which use Ant, but
> certainly need some updating.
> 
> But that brought the question. Should one style of build be promoted over
> the other, are both systems "faithfully and fully supported", or is Ant
> going to perhaps slowly die on the vine of disinterest?
> 
> Is there any internal mandate of ensuring compatibility between the two
> build system, especially in terms of ensuring high level things like
> wizards and whatnot work for both systems? If someone adds a new feature,
> contrived, "Create a Microprofile web service", is the project obligated
> (as much as it's obligated to do anything) to create a wizard for both Ant
> and Maven, or is it acceptable to only use one mechanism?
> 
> Just curious if there's any formal position on the two systems and their
> status within the NB environment today.

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@netbeans.apache.org
For additional commands, e-mail: dev-help@netbeans.apache.org

For further information about the NetBeans mailing lists, visit:
https://cwiki.apache.org/confluence/display/NETBEANS/Mailing+lists

Re: Status of Ant vs Maven

[Laszlo Kishalmi <la...@gmail.com>]

Theoretically it is possible to create NetBeans modules with Gradle 
using Attila's NBM plugin, however that might need to be revised.

My experiment is to build NetBeans itself with Gradle. So far it looks 
feasible, but requires a lot of energy, especially to get the tests 
running as there are lot of magic being hidden in the Ant based harness 
there. Right now it is possible to compile the platform and the tests on 
a few modules are running without fail, however I'm still failing to 
launch the base platform with OSGI correctly. Maybe I need to peek into 
our Maven tooling for that one. So it is kind of promising but not top 
priority on my list of things to do.

On 8/13/20 7:57 AM, Neil C Smith wrote:
> On Thu, 13 Aug 2020 at 15:26, Will Hartung <wi...@gmail.com> wrote:
>> Well, my question has been answered. It seems that were I to go through and
>> update the NB Platform tutorials, modernizing them for NB 12 and Maven
>> should be on the list of TODOs for them. I likely would not do a parallel
>> path for any of the other build environments, especially not right out the
>> gate. I don't know if the NB Platform wizards have any aspirations to
>> support Gradle projects or not (I don't know if the build system is
>> abstract enough internally to where something like a wizard cares about it
>> or not, honestly).
> Ah, yes, ignore me - I missed the essential word "platform" amongst
> the noise! :-)
>
> For the platform then what you suggest probably makes sense.  Although
> we should ensure Ant tutorials are up-to-date where possible I guess,
> particularly where it's IDE relevant too?
>
> I think Laszlo has mentioned experimenting with Gradle and platform or
> IDE build?
>
> Best wishes,
>
> Neil
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@netbeans.apache.org
> For additional commands, e-mail: dev-help@netbeans.apache.org
>
> For further information about the NetBeans mailing lists, visit:
> https://cwiki.apache.org/confluence/display/NETBEANS/Mailing+lists
>
>
>

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@netbeans.apache.org
For additional commands, e-mail: dev-help@netbeans.apache.org

For further information about the NetBeans mailing lists, visit:
https://cwiki.apache.org/confluence/display/NETBEANS/Mailing+lists

Re: Status of Ant vs Maven

[Neil C Smith <ne...@apache.org>]

On Thu, 13 Aug 2020 at 15:26, Will Hartung <wi...@gmail.com> wrote:
> Well, my question has been answered. It seems that were I to go through and
> update the NB Platform tutorials, modernizing them for NB 12 and Maven
> should be on the list of TODOs for them. I likely would not do a parallel
> path for any of the other build environments, especially not right out the
> gate. I don't know if the NB Platform wizards have any aspirations to
> support Gradle projects or not (I don't know if the build system is
> abstract enough internally to where something like a wizard cares about it
> or not, honestly).

Ah, yes, ignore me - I missed the essential word "platform" amongst
the noise! :-)

For the platform then what you suggest probably makes sense.  Although
we should ensure Ant tutorials are up-to-date where possible I guess,
particularly where it's IDE relevant too?

I think Laszlo has mentioned experimenting with Gradle and platform or
IDE build?

Best wishes,

Neil

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@netbeans.apache.org
For additional commands, e-mail: dev-help@netbeans.apache.org

For further information about the NetBeans mailing lists, visit:
https://cwiki.apache.org/confluence/display/NETBEANS/Mailing+lists

Re: Status of Ant vs Maven

[Will Hartung <wi...@gmail.com>]

On Thu, Aug 13, 2020 at 1:36 AM Neil C Smith <ne...@apache.org> wrote:

> We've already made a decision in terms of wizard layout to make all 3
> options more clearly visible, and I hope we don't revisit that.  We
> did talk about prioritising Maven as the preferred tool for new users,
> which makes some sense in terms of how the IDE can support.  But on
> tutorials, maybe parallel tracks or alternative sections on one page
> for at least Maven and Gradle makes sense?  eg. if you look at the
> getting started in NetBeans in the OpenJFX documentation (as JavaFX
> was mentioned), it talks you through all 3 options.
>

Well, my question has been answered. It seems that were I to go through and
update the NB Platform tutorials, modernizing them for NB 12 and Maven
should be on the list of TODOs for them. I likely would not do a parallel
path for any of the other build environments, especially not right out the
gate. I don't know if the NB Platform wizards have any aspirations to
support Gradle projects or not (I don't know if the build system is
abstract enough internally to where something like a wizard cares about it
or not, honestly).

Re: Status of Ant vs Maven

[Neil C Smith <ne...@apache.org>]

On Sat, 15 Aug 2020 at 22:19, Scott Palmer <sw...@gmail.com> wrote:
> Managing dependencies through a GUI instead of editing XML, or Gradle scripts would be great, including first-class support for Ant+Ivy. This can be difficult for free-form scripts like Gradle, but NB can assist, just like browsing for artifacts on Maven Central will show you the code you need to add for various tools, NB can offer actions to inject that code, for example.

This I would definitely be interested in.  Be good with Gradle, and my
own live programming runtime (which has an IDE based on NetBeans) is
about to support runtime injection of dependencies using pkg url -
being able to reuse a lookup GUI to support that would be great.
Particularly one that doesn't require a local cache!  Like Emi's
remote Maven search -
https://github.com/emilianbold/maven.search.remote

Best wishes,

Neil

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@netbeans.apache.org
For additional commands, e-mail: dev-help@netbeans.apache.org

For further information about the NetBeans mailing lists, visit:
https://cwiki.apache.org/confluence/display/NETBEANS/Mailing+lists

Re: Status of Ant vs Maven

[Geertjan Wielenga <ge...@apache.org>]

https://blogs.apache.org/netbeans/entry/restructuring-of-project-templates-in

That should help to show how we've restructured project templates recently.

Gj

On Sat, Aug 15, 2020 at 11:19 PM Scott Palmer <sw...@gmail.com> wrote:

> "The fact is, most of us need the IDE to support all 3 build tools
> (perhaps more) well, as first class citizens.  I'll personally always
> pick Maven if I have the choice on a project, but often have to work
> with Ant and Gradle too.
> We've already made a decision in terms of wizard layout to make all 3
> options more clearly visible, and I hope we don't revisit that.”
>
> I think this is the important take-away.  The NB infrastructure for
> project wizards, building, debugging, etc. must have a good architecture to
> support various build systems, as those three are certainly not the last.
>
> That NB will open an Ant, Maven, or Gradle project out-of-the-box and
> “just work”, without going through an awkward “import” is one of the things
> I love about NetBeans. It is perhaps the number one reason that I choose to
> use it over Eclipse or Idea.  Let’s make sure that “working with your
> projects a they are” remains one of NetBeans’ great advantages.
>
> Adding and supporting deep integration (as much as possible) with
> arbitrary build tools should have decent support APIs within NB.  I am not
> familiar, maybe it is already great, but if there are difficulties
> connecting different systems, perhaps some time needs to be spent improving
> NB architecture in that area.
>
> Managing dependencies through a GUI instead of editing XML, or Gradle
> scripts would be great, including first-class support for Ant+Ivy. This can
> be difficult for free-form scripts like Gradle, but NB can assist, just
> like browsing for artifacts on Maven Central will show you the code you
> need to add for various tools, NB can offer actions to inject that code,
> for example.  IDE awareness of the configured artifact repositories and
> showing available versions, hinting when new versions fo dependencies are
> available, making the distinction (through semantic versioning) of bug-fix
> versions vs. versions with greater risk of breaking changes, etc.  Those
> are things the IDE can assist with.
>
>
>
> Cheers,
>
> Scott
>
>
>
> > On Aug 13, 2020, at 4:36 AM, Neil C Smith <ne...@apache.org> wrote:
> >
> > On Thu, 13 Aug 2020 at 07:09, Laszlo Kishalmi <la...@gmail.com>
> wrote:
> >> Even if Maven is still strong out there, I consider
> >> that as a legacy tool.
> >
> > And Gradle is just Ant with slightly better syntax! ;-)  Yes, let's
> > not - build tool flame wars are so dull, and we've had enough.  I can
> > point to multiple people around here and in the wider Java ecosystem
> > who would make the same points as you about Gradle.
> >
> > The fact is, most of us need the IDE to support all 3 build tools
> > (perhaps more) well, as first class citizens.  I'll personally always
> > pick Maven if I have the choice on a project, but often have to work
> > with Ant and Gradle too.
> >
> > We've already made a decision in terms of wizard layout to make all 3
> > options more clearly visible, and I hope we don't revisit that.  We
> > did talk about prioritising Maven as the preferred tool for new users,
> > which makes some sense in terms of how the IDE can support.  But on
> > tutorials, maybe parallel tracks or alternative sections on one page
> > for at least Maven and Gradle makes sense?  eg. if you look at the
> > getting started in NetBeans in the OpenJFX documentation (as JavaFX
> > was mentioned), it talks you through all 3 options.
> >
> > I've no idea what problems people are having with multi-module Jigsaw
> > and Maven, but working on one now, I think there are things we could
> > do better in the IDE UI to support that across build systems.
> >
> > In terms of the OP's question on new features, then having a general
> > intention of feature parity (whatever that means) makes sense, but
> > might be difficult to always achieve in practice?
> >
> > Best wishes,
> >
> > Neil
>
>

Re: Status of Ant vs Maven

[Scott Palmer <sw...@gmail.com>]

"The fact is, most of us need the IDE to support all 3 build tools
(perhaps more) well, as first class citizens.  I'll personally always
pick Maven if I have the choice on a project, but often have to work
with Ant and Gradle too.
We've already made a decision in terms of wizard layout to make all 3
options more clearly visible, and I hope we don't revisit that.”

I think this is the important take-away.  The NB infrastructure for project wizards, building, debugging, etc. must have a good architecture to support various build systems, as those three are certainly not the last.

That NB will open an Ant, Maven, or Gradle project out-of-the-box and “just work”, without going through an awkward “import” is one of the things I love about NetBeans. It is perhaps the number one reason that I choose to use it over Eclipse or Idea.  Let’s make sure that “working with your projects a they are” remains one of NetBeans’ great advantages.

Adding and supporting deep integration (as much as possible) with arbitrary build tools should have decent support APIs within NB.  I am not familiar, maybe it is already great, but if there are difficulties connecting different systems, perhaps some time needs to be spent improving NB architecture in that area.

Managing dependencies through a GUI instead of editing XML, or Gradle scripts would be great, including first-class support for Ant+Ivy. This can be difficult for free-form scripts like Gradle, but NB can assist, just like browsing for artifacts on Maven Central will show you the code you need to add for various tools, NB can offer actions to inject that code, for example.  IDE awareness of the configured artifact repositories and showing available versions, hinting when new versions fo dependencies are available, making the distinction (through semantic versioning) of bug-fix versions vs. versions with greater risk of breaking changes, etc.  Those are things the IDE can assist with.



Cheers,

Scott



> On Aug 13, 2020, at 4:36 AM, Neil C Smith <ne...@apache.org> wrote:
> 
> On Thu, 13 Aug 2020 at 07:09, Laszlo Kishalmi <la...@gmail.com> wrote:
>> Even if Maven is still strong out there, I consider
>> that as a legacy tool.
> 
> And Gradle is just Ant with slightly better syntax! ;-)  Yes, let's
> not - build tool flame wars are so dull, and we've had enough.  I can
> point to multiple people around here and in the wider Java ecosystem
> who would make the same points as you about Gradle.
> 
> The fact is, most of us need the IDE to support all 3 build tools
> (perhaps more) well, as first class citizens.  I'll personally always
> pick Maven if I have the choice on a project, but often have to work
> with Ant and Gradle too.
> 
> We've already made a decision in terms of wizard layout to make all 3
> options more clearly visible, and I hope we don't revisit that.  We
> did talk about prioritising Maven as the preferred tool for new users,
> which makes some sense in terms of how the IDE can support.  But on
> tutorials, maybe parallel tracks or alternative sections on one page
> for at least Maven and Gradle makes sense?  eg. if you look at the
> getting started in NetBeans in the OpenJFX documentation (as JavaFX
> was mentioned), it talks you through all 3 options.
> 
> I've no idea what problems people are having with multi-module Jigsaw
> and Maven, but working on one now, I think there are things we could
> do better in the IDE UI to support that across build systems.
> 
> In terms of the OP's question on new features, then having a general
> intention of feature parity (whatever that means) makes sense, but
> might be difficult to always achieve in practice?
> 
> Best wishes,
> 
> Neil

Re: Status of Ant vs Maven

[Martin Desruisseaux <ma...@geomatys.com>]

Le 13/08/2020 à 12:26, Neil C Smith a écrit :

> Yes, I'm using annotation processing. ;-) And across modules. But not 
> sure specifically what you meant by all modules together there? Do you 
> have an example?
>
If we have 3 modules, using the annotation processor with Maven will 
cause javac to be executed 3 times, is that right? If we execute javac 
from the command line instead, we can compile the 3 modules in a single 
javac invocation. I presume (but did not tested) that it results in the 
same processor instance, or at least the same JVM instance, processing 
the annotations of all modules in a single run. For many tasks it makes 
no practical difference. But for tasks wanting to do some kind of 
aggregation of information collected from all modules (such as javadoc), 
this is helpful.

Use case that I'm really considering to do: there is more than 6000 
Coordinate Reference Systems (map projections) in use around the world. 
Those reference systems are identified by codes in a database known as 
"the EPSG geodetic dataset". We may not want to bundle the EPSG database 
in end user applications, because that database is relatively big, using 
it forces application to bundle also an engine such as Derby or HSQL, 
and is generally an overkill because an application for a specific user 
will typically uses only a few (less than 5) Coordinate Reference 
Systems among the 6000. It is a little bit like localization: a software 
may be provided in 50 languages, but an application for a specific user 
will typically needs only one of those 50 languages. So I'm considering 
to define an annotation like that:

    @InjectCRS(code = "EPSG::2138")
    CoordinateReferenceSystem myMapProjection;

("EPSG::2138" is the identifier for "NAD27(CGQ77) / Quebec Lambert"). 
The annotation processor would fetch required data from an EPSG database 
(which must exist on the developer machine) and generate all necessary 
Java code for initializing the myMapProjection field with hard-coded 
values so that we don't need anymore to bundle the EPSG database with 
that application.

So far, no need to "process all modules together". But there is a 
complication: the information that we attach to the myMapProjection 
field may depend on other occurrences of the @InjectCRS annotation. If 
there is a @InjectCRS(code = "EPSG::32198") somewhere else in the code 
("EPSG::32198" is the identifier for "NAD83 / Quebec Lambert"), then the 
annotation processor needs to inject additional Java code and data not 
only for "EPSG::2138" and "EPSG::32198" taken separately, but also for 
data about how to convert from "NAD27" to "NAD83" and conversely. Those 
data may be large, so we want them only if needed. Consequently the 
annotation processor would need to know all occurrences of all 
@InjectCRS annotations in all modules; the code and data injected at a 
given @InjectCRS can not be determined in isolation of other @InjectCRS 
annotations.

Above use case, if I'm understanding correctly, would be difficult to 
implement in a Maven build, unless Maven provides for annotation 
processor a workaround similar to what they did for javadoc.

     Martin

Re: Status of Ant vs Maven

[Neil C Smith <ne...@apache.org>]

On Thu, 13 Aug 2020 at 11:15, Martin Desruisseaux
<ma...@geomatys.com> wrote:
>
> Le 13/08/2020 à 11:39, Neil C Smith a écrit :
>
> > No, this is working fine. Aggregated Javadocs are as expected with all
> > module info.
> >
> Ah? Then I may not have tested correctly. Thanks for correcting me. But
> if I remember correctly the discussion on Maven mailing list a few years
> ago (I could not find back the link),

I think it might require Javadoc plugin 3.1.0+ IIRC.

> > Not sure what exactly you mean by issues with annotation processing?
> >
> The use of javax.annotation.processing, which allows custom Java code to
> be executed when javac encounter annotations. Admittedly not widely
> used, but it still possible to want to execute a process for annotation
> in all modules together.

Yes, I'm using annotation processing. ;-)  And across modules.  But
not sure specifically what you meant by all modules together there?
Do you have an example?

Best wishes,

Neil

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@netbeans.apache.org
For additional commands, e-mail: dev-help@netbeans.apache.org

For further information about the NetBeans mailing lists, visit:
https://cwiki.apache.org/confluence/display/NETBEANS/Mailing+lists

Re: Status of Ant vs Maven

[Martin Desruisseaux <ma...@geomatys.com>]

Le 13/08/2020 à 11:39, Neil C Smith a écrit :

> No, this is working fine. Aggregated Javadocs are as expected with all 
> module info.
>
Ah? Then I may not have tested correctly. Thanks for correcting me. But 
if I remember correctly the discussion on Maven mailing list a few years 
ago (I could not find back the link), Maven aggregated javadoc had to be 
implemented with technical tricks not recommended for general use; this 
is not something that Maven does naturally.


> Not sure what exactly you mean by issues with annotation processing?
>
The use of javax.annotation.processing, which allows custom Java code to 
be executed when javac encounter annotations. Admittedly not widely 
used, but it still possible to want to execute a process for annotation 
in all modules together.

     Martin



---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@netbeans.apache.org
For additional commands, e-mail: dev-help@netbeans.apache.org

For further information about the NetBeans mailing lists, visit:
https://cwiki.apache.org/confluence/display/NETBEANS/Mailing+lists

Re: Status of Ant vs Maven

[Neil C Smith <ne...@apache.org>]

On Thu, 13 Aug 2020 at 10:11, Martin Desruisseaux
<ma...@geomatys.com> wrote:
> Aggregated Javadoc with Maven is not the same thing. It basically merges
> the content of all Maven modules and handles them as if they were
> defined in a single module. All module stuff cited in above paragraph
> disappear.

No, this is working fine.  Aggregated Javadocs are as expected with
all module info.

> Javadoc is the main use case, but the same issue happens for all Java
> tools (e.g. annotation processor).

Not sure what exactly you mean by issues with annotation processing?

Best wishes,

Neil

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@netbeans.apache.org
For additional commands, e-mail: dev-help@netbeans.apache.org

For further information about the NetBeans mailing lists, visit:
https://cwiki.apache.org/confluence/display/NETBEANS/Mailing+lists

Re: Status of Ant vs Maven

[Martin Desruisseaux <ma...@geomatys.com>]

Le 13/08/2020 à 10:36, Neil C Smith a écrit :

> I've no idea what problems people are having with multi-module Jigsaw 
> and Maven, but working on one now, I think there are things we could 
> do better in the IDE UI to support that across build systems.
>
Did you find a way to run any java tools (javac, javadoc, etc.) on more 
than one Jigsaw module at once with Maven? Javadoc is the main use case, 
but not the only one.

When running javadoc on many Jigsaw modules at once, the generated 
overview page lists all modules. We can click on one module to see the 
packages in that module. The javadoc of each class contains a "Module" 
line on top of the "Package" line telling us in which module is defined 
that class. The navigation bar contains a "Modules" item in addition of 
"Packages" item, etc.

Aggregated Javadoc with Maven is not the same thing. It basically merges 
the content of all Maven modules and handles them as if they were 
defined in a single module. All module stuff cited in above paragraph 
disappear. If we want some separation by module, we have to define 
package groups manually in Maven javadoc plugin configuration (but it 
still not modules).

Javadoc is the main use case, but the same issue happens for all Java 
tools (e.g. annotation processor). Except that Maven provides a partial 
workaround only for javadoc.

     Martin



---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@netbeans.apache.org
For additional commands, e-mail: dev-help@netbeans.apache.org

For further information about the NetBeans mailing lists, visit:
https://cwiki.apache.org/confluence/display/NETBEANS/Mailing+lists

Re: Status of Ant vs Maven

[Neil C Smith <ne...@apache.org>]

On Thu, 13 Aug 2020 at 07:09, Laszlo Kishalmi <la...@gmail.com> wrote:
> Even if Maven is still strong out there, I consider
> that as a legacy tool.

And Gradle is just Ant with slightly better syntax! ;-)  Yes, let's
not - build tool flame wars are so dull, and we've had enough.  I can
point to multiple people around here and in the wider Java ecosystem
who would make the same points as you about Gradle.

The fact is, most of us need the IDE to support all 3 build tools
(perhaps more) well, as first class citizens.  I'll personally always
pick Maven if I have the choice on a project, but often have to work
with Ant and Gradle too.

We've already made a decision in terms of wizard layout to make all 3
options more clearly visible, and I hope we don't revisit that.  We
did talk about prioritising Maven as the preferred tool for new users,
which makes some sense in terms of how the IDE can support.  But on
tutorials, maybe parallel tracks or alternative sections on one page
for at least Maven and Gradle makes sense?  eg. if you look at the
getting started in NetBeans in the OpenJFX documentation (as JavaFX
was mentioned), it talks you through all 3 options.

I've no idea what problems people are having with multi-module Jigsaw
and Maven, but working on one now, I think there are things we could
do better in the IDE UI to support that across build systems.

In terms of the OP's question on new features, then having a general
intention of feature parity (whatever that means) makes sense, but
might be difficult to always achieve in practice?

Best wishes,

Neil

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@netbeans.apache.org
For additional commands, e-mail: dev-help@netbeans.apache.org

For further information about the NetBeans mailing lists, visit:
https://cwiki.apache.org/confluence/display/NETBEANS/Mailing+lists

Re: Status of Ant vs Maven

[Oliver Rettig <Ol...@orat.de>]

> My wish for the future: please don't give up on ant. I would 
like to see
> an update to the latest version because I could use some 
of the new
> features which are missing in the one NB uses. And I would 
like to see
> some Ivy support in Netbeans.

Yes, Ivy support for ant in Netbeans would be great!

Re: Status of Ant vs Maven

[Christoph Theis <th...@gmx.at>]

My 2ct:
I have a couple of old but still maintained Java projects based on Ant,
some of them with HTML components. I tried to convert them to Gradle to
benefit of their dependency management, but failed: too many changes in
the source code layout to start with, and I didn't even came near my
build specialties. I then figured out how to add Ivy which turns out to
be not too difficult to integrate into my ant build and so I got my
dependency management.

My wish for the future: please don't give up on ant. I would like to see
an update to the latest version because I could use some of the new
features which are missing in the one NB uses. And I would like to see
some Ivy support in Netbeans.

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@netbeans.apache.org
For additional commands, e-mail: dev-help@netbeans.apache.org

For further information about the NetBeans mailing lists, visit:
https://cwiki.apache.org/confluence/display/NETBEANS/Mailing+lists

Re: Status of Ant vs Maven

[Laszlo Kishalmi <la...@gmail.com>]

Well, just to throw in my thoughts,

I was working on mostly Java (some .Net as well) builds since 2000 to  
2016 as a professional under the title of build engineer. I've handled 
simple batch files, makefiles, Ant scripts, NAnt scripts, Maven and 
Gradle and some other tools as well.

- Ant was good in the olds days, but when you need to combine all that 
dependencies even with Ivy, I would not start a project with it any 
more, unless it is a throw-away IDE generated one.

- Maven. I like the deep integration of that into NetBeans. NetBeans 
saved me not even once dealing with nasty Maven projects. I thank the 
rise of binary repositories to Maven. But I honestly think beyond that 
Maven is a big, ivory tower, design flaw and also promoting some bad 
practices. I would not start a project with Maven, unless there is no 
alternative to it. Even if Maven is still strong out there, I consider 
that as a legacy tool.

- Gradle. I've first seen it when it was version 0.4. I've tried it, 
laughed at it, then forgot that for almost a year. Next time I've tried 
that was probably 1.6. I got impressed. Yes it gives you the power to do 
anything in a build script, and with great power comes great 
responsibility on the developers. In my opinion it is the easiest , most 
efficient Java build system to start a project with. Even if that 
project would be just a throw-away one. As of an IDE our responsibility 
to promote good examples, and try to do the best when encounter bad 
practice as well.

In that light 12.1 is bringing Gradle Support out of the box with Java 
SE cluster (no Groovy would be required), I hope 12.2 will have a better 
Gradle Project Wizard (if I can pull that off)

On 8/12/20 4:55 PM, Scott Palmer wrote:
>>>> On Aug 12, 2020, at 4:12 PM, Tim Boudreau <ni...@gmail.com> wrote:
>>> My 2c:
>>>
>>> - Ant and Ant-based projects are never going away, the same way that
>>> Makefiles are never going away - even if nobody uses them for new projects
>>> anymore, the need to interoperate with legacy code will not disappear
>>> - I'd be in favor of making Maven projects the default thing that's
>>> pre-selected when users create a new project, and updating tutorials to
>>> focus on it - I don't think Ant makes sense to push people towards for new
>>> projects
>
> No argument. (Even though I will never again make a new Maven project. It has bit me in the ass one too many times and there are various things I loath about it.)
>
>> - Gradle is neat;  the fact that it targets native build systems as a
>> first-class thing is a really good thing (ever tried to incorporate
>> building some C libraries into a Maven project build with a bunch of
>> Jenkins slaves on different OS's and bundle the artifacts?  I have.  It
>> ain't pretty).
> Exactly. Maven works okay when it works (and I’m not the one writing the tedious mountains of XML), but it doesn’t take long to hit a project where Maven just can’t handle what you need to do in a reasonable way.
> Referring to your example, I would love to see support for native projects in Netbeans via Gradle.  A major project I work on is all about authoring many modules that have both a Java and a C++ component.
> Gradle can be much easier to use than either Ant or Maven, but it is also requires more discipline. You can get yourself into trouble. If the IDE can help that would be great.
>
>> Gradle's scriptability aims the evolution of a project's build squarely at
>> the bad old days of needing magic properties files in special locations,
>> and things like that:
> I disagree. It may enable that, but doesn’t aim for it or encourage it.  Bad practices are possible with any tool.  It’s similar to how you can’t code everything in Java, some projects need a native side. ‘C’ gives you the power to make a lot of mistakes, but it is often the simplest solution to a particular problem.
>
>> - basically,
>> whenever possible, the workflow to onboarding with a new project should be
>> "git clone foo; cd foo; do-the-build"
> I agree. Though it should be “hg clone foo”, Why make things harder than they need to be :-)
> Do-the-build should be one of:
> “ant”
> “make”
> “mvn install”
> “gradle”
> (Or similar, whatever tool is used)
>
>> IMO an
>> IDE should encourage the path of user-doesn't-hit-themselves-with-hammer as
>> the path of least resistance.
> Agree.
>
> I don’t see that as a reason to not offer an excellent level of support for Gradle-based projects though. Wizards to start new Gradle-based projects with a reasonable build script that follows best practices and all that.
>
>>   If there are a lot of head-hammer-hittters
>> out there, maybe supplement that with some head pillows, but don't hand
>> them the hammer.
> Software engineering eventually requires the pounding of a few nails. That’s why Maven doesn’t work well for many complex real-world projects... no hammer (or its hammer is much harder to use).
>
> But back to NB... Gradle projects are for certain going to be impossible to integrate at the same level as Maven because the level of uniformity just isn’t there.  It’s both Gradle’s advantage and disadvantage at the same time.
> That said, it’s not likely to go away either and is very popular. It should still be well supported.
>
>
> Cheers,
>
> Scott
>
>>>> On Mon, Aug 10, 2020 at 12:06 PM Will Hartung <wi...@gmail.com> wrote:
>>> Ant has been the historic underlying build tool for Netbeans projects, but
>>> over the years, not only has NB been a very good companion with Maven,
>>> Maven is also much more popular industry wide.
>>> There was a comment on the user list recently about Java FX, and one reply
>>> was, paraphrasing, "the best way to use Java FX was to use Maven".
>>> I was also looking at the legacy NB Platform tutorials, which use Ant, but
>>> certainly need some updating.
>>> But that brought the question. Should one style of build be promoted over
>>> the other, are both systems "faithfully and fully supported", or is Ant
>>> going to perhaps slowly die on the vine of disinterest?
>>> Is there any internal mandate of ensuring compatibility between the two
>>> build system, especially in terms of ensuring high level things like
>>> wizards and whatnot work for both systems? If someone adds a new feature,
>>> contrived, "Create a Microprofile web service", is the project obligated
>>> (as much as it's obligated to do anything) to create a wizard for both Ant
>>> and Maven, or is it acceptable to only use one mechanism?
>>> Just curious if there's any formal position on the two systems and their
>>> status within the NB environment

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@netbeans.apache.org
For additional commands, e-mail: dev-help@netbeans.apache.org

For further information about the NetBeans mailing lists, visit:
https://cwiki.apache.org/confluence/display/NETBEANS/Mailing+lists

Re: Status of Ant vs Maven

[Will Hartung <wi...@gmail.com>]

On Wed, Aug 12, 2020 at 4:56 PM Scott Palmer <sw...@gmail.com> wrote:

> I agree. Though it should be “hg clone foo”, Why make things harder than
> they need to be :-)
> Do-the-build should be one of:
> “ant”
> “make”
> “mvn install”
> “gradle”
>

I can't speak to gradle, but the distinct difference, most of the time,
between "mvn install", and the rest, is that "mvn install" includes all of
the dependencies. Type "mvn install" and the internet downloads
automagically.

Honestly, this is the primary reason I use maven on my projects. Being able
to add a single dependency and have maven suck down all the rest.

I tolerate it for that reason. I find it unwieldy, I find it slow, I find
it expensive. But it works for my lazy gene, and I can send a pom.xml and a
10 line sample java file to a friend, and they can build it quickly even if
it needs to pull down half the internet in dependencies.

That said, we shant discuss the crushing expense of downloading the Maven
index and unpacking it...

Re: Status of Ant vs Maven

[Scott Palmer <sw...@gmail.com>]

>>> On Aug 12, 2020, at 4:12 PM, Tim Boudreau <ni...@gmail.com> wrote:
>> My 2c:
>> 
>> - Ant and Ant-based projects are never going away, the same way that
>> Makefiles are never going away - even if nobody uses them for new projects
>> anymore, the need to interoperate with legacy code will not disappear
>> - I'd be in favor of making Maven projects the default thing that's
>> pre-selected when users create a new project, and updating tutorials to
>> focus on it - I don't think Ant makes sense to push people towards for new
>> projects


No argument. (Even though I will never again make a new Maven project. It has bit me in the ass one too many times and there are various things I loath about it.)

> - Gradle is neat;  the fact that it targets native build systems as a
> first-class thing is a really good thing (ever tried to incorporate
> building some C libraries into a Maven project build with a bunch of
> Jenkins slaves on different OS's and bundle the artifacts?  I have.  It
> ain't pretty).

Exactly. Maven works okay when it works (and I’m not the one writing the tedious mountains of XML), but it doesn’t take long to hit a project where Maven just can’t handle what you need to do in a reasonable way. 
Referring to your example, I would love to see support for native projects in Netbeans via Gradle.  A major project I work on is all about authoring many modules that have both a Java and a C++ component. 
Gradle can be much easier to use than either Ant or Maven, but it is also requires more discipline. You can get yourself into trouble. If the IDE can help that would be great. 

> Gradle's scriptability aims the evolution of a project's build squarely at
> the bad old days of needing magic properties files in special locations,
> and things like that:

I disagree. It may enable that, but doesn’t aim for it or encourage it.  Bad practices are possible with any tool.  It’s similar to how you can’t code everything in Java, some projects need a native side. ‘C’ gives you the power to make a lot of mistakes, but it is often the simplest solution to a particular problem. 

> - basically,
> whenever possible, the workflow to onboarding with a new project should be
> "git clone foo; cd foo; do-the-build"

I agree. Though it should be “hg clone foo”, Why make things harder than they need to be :-)
Do-the-build should be one of:
“ant”
“make”
“mvn install”
“gradle”
(Or similar, whatever tool is used)

> IMO an
> IDE should encourage the path of user-doesn't-hit-themselves-with-hammer as
> the path of least resistance.

Agree. 

I don’t see that as a reason to not offer an excellent level of support for Gradle-based projects though. Wizards to start new Gradle-based projects with a reasonable build script that follows best practices and all that.

>  If there are a lot of head-hammer-hittters
> out there, maybe supplement that with some head pillows, but don't hand
> them the hammer.

Software engineering eventually requires the pounding of a few nails. That’s why Maven doesn’t work well for many complex real-world projects... no hammer (or its hammer is much harder to use).

But back to NB... Gradle projects are for certain going to be impossible to integrate at the same level as Maven because the level of uniformity just isn’t there.  It’s both Gradle’s advantage and disadvantage at the same time. 
That said, it’s not likely to go away either and is very popular. It should still be well supported. 


Cheers, 

Scott

>>> On Mon, Aug 10, 2020 at 12:06 PM Will Hartung <wi...@gmail.com> wrote:
>> Ant has been the historic underlying build tool for Netbeans projects, but
>> over the years, not only has NB been a very good companion with Maven,
>> Maven is also much more popular industry wide.
>> There was a comment on the user list recently about Java FX, and one reply
>> was, paraphrasing, "the best way to use Java FX was to use Maven".
>> I was also looking at the legacy NB Platform tutorials, which use Ant, but
>> certainly need some updating.
>> But that brought the question. Should one style of build be promoted over
>> the other, are both systems "faithfully and fully supported", or is Ant
>> going to perhaps slowly die on the vine of disinterest?
>> Is there any internal mandate of ensuring compatibility between the two
>> build system, especially in terms of ensuring high level things like
>> wizards and whatnot work for both systems? If someone adds a new feature,
>> contrived, "Create a Microprofile web service", is the project obligated
>> (as much as it's obligated to do anything) to create a wizard for both Ant
>> and Maven, or is it acceptable to only use one mechanism?
>> Just curious if there's any formal position on the two systems and their
>> status within the NB environment 

Re: Status of Ant vs Maven

["Jack W." <so...@gmail.com>]

On Wed, Aug 12, 2020 at 2:12 PM Tim Boudreau <ni...@gmail.com> wrote:

https://timboudreau.com/blog/maven/read
>

Nice article, led me on one of those breadcrumb trails thru many essays.

---
Jack Woehr               # Woehr's Asymptote: The ratio of the time spent
Box 51, Golden CO 80402  # administering productivity software over the time
http://www.softwoehr.com # saved by said software eventually approximates 1.

Re: Status of Ant vs Maven

[Martin Desruisseaux <ma...@geomatys.com>]

Le 12/08/2020 à 22:12, Tim Boudreau a écrit :

> - Maven is here to stay. Yes, it's slower than Ant, but as hardware 
> gets faster, that is less and less relevant. And probably there are 
> tons of optimizations that could be done to Maven to make it much faster
>
But it is not just about raw speed. Netbeans Ant projects are more 
fine-grained. The Ant file generated by Netbeans has a lot of targets 
for very specific tasks, which is probably a reason why daily work with 
Ant is faster. For example we can easily recompile a specific file (by 
pressing F9 key) before executing a main(String[]) method, which I find 
useful for quick tests without being forced to fix immediately 
compilation errors in files not used by that test. By contrast, Maven 
apparently can only build the whole module (even if it can skip 
unmodified files); the F9 key has no effect. So there is design choices 
impacting not only what can be fixed by optimization, but also the way 
we work.

We way argue that Maven approach reduces the risk of mistakes by new 
users. But it also reduces (admittedly only slightly) productivity of 
experimented developers. This drawback is also illustrated by Maven 
counter-intuitive <useIncrementalCompilation> option, which must 
actually be set to false for enabling incremental (and consequently 
faster) compilation [1].


> (…snip…) Gradle's scriptability aims the evolution of a project's 
> build squarely at the bad old days of needing magic properties files 
> in special locations, and things like that:  
> https://timboudreau.com/blog/maven/read - basically, whenever 
> possible, the workflow to onboarding with a new project should be "git 
> clone foo; cd foo; do-the-build"
>
Yes I agree that scriptability is a problem when it makes the build more 
difficult than above steps. But Maven rigidity is also a problem when it 
makes difficult to follow industry evolution. In particular Maven is 
currently not very Jigsaw-friendly. For example we can not build a 
Jigsaw multi-modules Javadoc (Maven aggregated javadoc is not a Jigsaw 
multi-module javadoc). The same problem happens with other tools such 
asannotation processors, which (to my knowledge) can not be executed in 
a Jigsaw multi-modules project with Maven.

More generally javac, javadoc, etc. can work on many Jigsaw modules 
together, but this capability is ignored by Maven which builds each 
module separately. Aggregated javadoc simulates the effect of building 
modules together, but the result is not the same and (in my 
understanding) the process uses hacks not generalizable to e.g. an 
aggregated annotation processor. Improving that situation would require 
that we break some Maven assumptions (e.g. "1 Maven module = 1 Jigsaw 
module"), but that would require modifications in Maven plugins. By 
contrast scriptable build systems allow easier evolution. Indeed the 
first projects that I have see moving to Jigsaw (e.g. Apache Derby) are 
Ant-based. NetBeans also provided quickly an Ant-based form for Jigsaw 
projects, while I still see no equivalent in Maven world. Today, I'm not 
aware of a way other than Ant for creating a "real" Jigsaw multi-modules 
project in NetBeans (i.e. a project on which we can generate a "real" 
multi-modules javadoc).

I created two years ago a wiki page with some thought about possible 
solution [2], but never had the time to start the work yet. Also it is 
quite possible that my analysis is wrong.

     Regards,

         Martin

[1] https://issues.apache.org/jira/browse/MCOMPILER-209
[2] https://github.com/Geomatys/maven-plugins/wiki

Re: Status of Ant vs Maven

[Tim Boudreau <ni...@gmail.com>]

My 2c:

 - Ant and Ant-based projects are never going away, the same way that
Makefiles are never going away - even if nobody uses them for new projects
anymore, the need to interoperate with legacy code will not disappear
 - I'd be in favor of making Maven projects the default thing that's
pre-selected when users create a new project, and updating tutorials to
focus on it - I don't think Ant makes sense to push people towards for new
projects
 - Maven is here to stay.  Yes, it's slower than Ant, but as hardware gets
faster, that is less and less relevant.  And probably there are tons of
optimizations that could be done to Maven to make it much faster, so maybe
that's a place to contribute if it annoys you.
 - Gradle is neat;  the fact that it targets native build systems as a
first-class thing is a really good thing (ever tried to incorporate
building some C libraries into a Maven project build with a bunch of
Jenkins slaves on different OS's and bundle the artifacts?  I have.  It
ain't pretty).
  - However, in terms of ease of setup - say, you're a new developer on a
large existing project - how much coaching is it going to take from the
*one* person who understands the build system (because there always is one,
and rarely more than one) to get your system set up to build things?
Gradle's scriptability aims the evolution of a project's build squarely at
the bad old days of needing magic properties files in special locations,
and things like that:  https://timboudreau.com/blog/maven/read - basically,
whenever possible, the workflow to onboarding with a new project should be
"git clone foo; cd foo; do-the-build"

I once chatted for an hour or two with Hans Doktor (gradle creator) in
their office in San Francisco - it could be summed up as Me: "You're kind
of encouraging people to engage in practices that are known to cause long
term problems"; Hans: "Yup, and our customers like it."  The bottom line
from my perspective:  If you have a cohort of people that are really into
hitting themselves in the head with hammers, you can make good money
selling helmets and head pillows to make that practice cause less harm -
and if your goal is to make money, it's probably smart business to do
that.  If your goal is to improve the state of the art of engineering so
that there are less people in the world who ever want to hit themselves in
the head with a hammer, head-pillows probably aren't your thing.  IMO an
IDE should encourage the path of user-doesn't-hit-themselves-with-hammer as
the path of least resistance.  If there are a lot of head-hammer-hittters
out there, maybe supplement that with some head pillows, but don't hand
them the hammer.

-Tim


On Mon, Aug 10, 2020 at 12:06 PM Will Hartung <wi...@gmail.com> wrote:

> Ant has been the historic underlying build tool for Netbeans projects, but
> over the years, not only has NB been a very good companion with Maven,
> Maven is also much more popular industry wide.
>
> There was a comment on the user list recently about Java FX, and one reply
> was, paraphrasing, "the best way to use Java FX was to use Maven".
>
> I was also looking at the legacy NB Platform tutorials, which use Ant, but
> certainly need some updating.
>
> But that brought the question. Should one style of build be promoted over
> the other, are both systems "faithfully and fully supported", or is Ant
> going to perhaps slowly die on the vine of disinterest?
>
> Is there any internal mandate of ensuring compatibility between the two
> build system, especially in terms of ensuring high level things like
> wizards and whatnot work for both systems? If someone adds a new feature,
> contrived, "Create a Microprofile web service", is the project obligated
> (as much as it's obligated to do anything) to create a wizard for both Ant
> and Maven, or is it acceptable to only use one mechanism?
>
> Just curious if there's any formal position on the two systems and their
> status within the NB environment today.
>


-- 
http://timboudreau.com