Re: removing the "new project" support for Ant projects

[Christoph Theis]

On 23.04.2021 16:17, Emma Atkinson wrote:

Christoph
The guide suggests Ant and Gradle builds coexist until one has
confidence that both build tools produce the same things.


That was what I intended and why I choose the Gradle-path, but I could
not make it work. A tool doing the heavy lifting of the conversion may
have helped though. But with Ivy I got dependency management an easier way.


--
Christoph

-
To unsubscribe, e-mail: users-unsubscr...@netbeans.apache.org
For additional commands, e-mail: users-h...@netbeans.apache.org

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

Re: removing the "new project" support for Ant projects

[Laszlo Kishalmi]

While Ivy is an excellent tool to manage dependencies. It has a niche 
market. So unless somebody steps for it and implements a better support 
for that, I fear voting for it won't do that much.


On 4/23/21 9:27 AM, Oliver Rettig wrote:


+1 for better ivy integration

> On 23.04.2021 15:22, Laszlo Kishalmi wrote:

> > Ant projects can be fairly simply can be migrated to Gradle. It can

> > support your current folder structure. Your file/directory based 
library


> > dependencies, and occasional customization you made.

>

> Been there, tried that, and failed.

> If you have a working Ant project keep it. To convert it to Gradle only

> because it is the new-kid-on-the-block is, in my opinion, a wrong move.

>

> I considered to convert to Gradle to get dependency management but in

> the end it was easier to add Ivy instead of working out how to convert

> some tweaks and tricks, if possible at all. And I would love to have a

> better Ivy integration in NB instead of making Ant a 2nd-class citizen.

>

> Just my 2 cent.

>

>

> --

> Christoph

>

> -

> To unsubscribe, e-mail: users-unsubscr...@netbeans.apache.org

> For additional commands, e-mail: users-h...@netbeans.apache.org

>

> For further information about the NetBeans mailing lists, visit:

> https://cwiki.apache.org/confluence/display/NETBEANS/Mailing+lists

Re: removing the "new project" support for Ant projects

[Oliver Rettig]

+1 for better ivy integration
> On 23.04.2021 15:22, Laszlo Kishalmi wrote:
> > Ant projects can be fairly simply can be migrated to Gradle. It can
> > support your current folder structure. Your file/directory based library
> > dependencies, and occasional customization you made.
> 
> Been there, tried that, and failed.
> If you have a working Ant project keep it. To convert it to Gradle only
> because it is the new-kid-on-the-block is, in my opinion, a wrong move.
> 
> I considered to convert to Gradle to get dependency management but in
> the end it was easier to add Ivy instead of working out how to convert
> some tweaks and tricks, if possible at all. And I would love to have a
> better Ivy integration in NB instead of making Ant a 2nd-class citizen.
> 
> Just my 2 cent.
> 
> 
> --
> Christoph
> 
> -
> To unsubscribe, e-mail: users-unsubscr...@netbeans.apache.org
> For additional commands, e-mail: users-h...@netbeans.apache.org
> 
> For further information about the NetBeans mailing lists, visit:
> https://cwiki.apache.org/confluence/display/NETBEANS/Mailing+lists

Re: removing the "new project" support for Ant projects

[Emma Atkinson]

Christoph

It so happens I have just read a migration guide that looks reasonable and
do-able.  It's at

https://docs.gradle.org/current/userguide/migrating_from_ant.html

and addresses option for Ant and mentions Ivy.

The guide suggests Ant and Gradle builds coexist until one has confidence
that both build tools produce the same things.  I'm not yet sure I can
foresee how Netbeans IDE might play along with or assist the approach
suggested.

One thing they do not cover is how to switch NB-IDE project configuration
to a standard Gradle project. I definitely do not know how to do that
without making a mess.


On Fri, 23 Apr 2021, 15:35 Christoph Theis,  wrote:

> On 23.04.2021 15:22, Laszlo Kishalmi wrote:
> > Ant projects can be fairly simply can be migrated to Gradle. It can
> > support your current folder structure. Your file/directory based library
> > dependencies, and occasional customization you made.
>
> Been there, tried that, and failed.
> If you have a working Ant project keep it. To convert it to Gradle only
> because it is the new-kid-on-the-block is, in my opinion, a wrong move.
>
> I considered to convert to Gradle to get dependency management but in
> the end it was easier to add Ivy instead of working out how to convert
> some tweaks and tricks, if possible at all. And I would love to have a
> better Ivy integration in NB instead of making Ant a 2nd-class citizen.
>
> Just my 2 cent.
>
>
> --
> Christoph
>
> -
> To unsubscribe, e-mail: users-unsubscr...@netbeans.apache.org
> For additional commands, e-mail: users-h...@netbeans.apache.org
>
> For further information about the NetBeans mailing lists, visit:
> https://cwiki.apache.org/confluence/display/NETBEANS/Mailing+lists
>
>
>

Re: removing the "new project" support for Ant projects

[Christoph Theis]

On 23.04.2021 15:22, Laszlo Kishalmi wrote:

Ant projects can be fairly simply can be migrated to Gradle. It can
support your current folder structure. Your file/directory based library
dependencies, and occasional customization you made.


Been there, tried that, and failed.
If you have a working Ant project keep it. To convert it to Gradle only
because it is the new-kid-on-the-block is, in my opinion, a wrong move.

I considered to convert to Gradle to get dependency management but in
the end it was easier to add Ivy instead of working out how to convert
some tweaks and tricks, if possible at all. And I would love to have a
better Ivy integration in NB instead of making Ant a 2nd-class citizen.

Just my 2 cent.


--
Christoph

-
To unsubscribe, e-mail: users-unsubscr...@netbeans.apache.org
For additional commands, e-mail: users-h...@netbeans.apache.org

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

Re: removing the "new project" support for Ant projects

[Neil C Smith]

On Fri, 23 Apr 2021 at 15:23, Laszlo Kishalmi  wrote:
> Ant projects can be fairly simply can be migrated to Gradle.

Well, I've often said Gradle is just Ant with slightly better syntax! :-)

Joking aside, good point, and I'd be interested to see a converter too.

Best wishes,

Neil

-
To unsubscribe, e-mail: users-unsubscr...@netbeans.apache.org
For additional commands, e-mail: users-h...@netbeans.apache.org

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

Re: removing the "new project" support for Ant projects

[Laszlo Kishalmi]

If someone has a well establised Ant project and he would migrate that 
to Maven, then he/she is looking at the wrong direction.


Ant projects can be fairly simply can be migrated to Gradle. It can 
support your current folder structure. Your file/directory based library 
dependencies, and occasional customization you made.


Theoretically it is possible to write a module that would convert 
NetBeans Generated Ant projects to Gradle. Might do that one day.


On 4/21/21 10:40 AM, Will Hartung wrote:



On Wed, Apr 21, 2021 at 4:51 AM Sean Carrick > wrote:


You have given a very well thought out answer to my message and I
appreciate that. Now, let me ask you this: do you maintain legacy
systems that were built with the Swing Application Framework? If
so, were you able to convert them to using Maven?


No, I have not used SAF. I looked into it, but it was after it's "use 
by date", so the links and what not weren't really appropriate for 
someone trying it today. For some reason I really struggle with GUIs.


I can not speak to any direct SAF support NB had at an IDE level. I 
can only posit that, in the end, the SAF is "just a jar file", and at 
that level, adding SAF support to a Maven project is simply a matter 
of importing it into your local repository. This is straightforward 
(and we can discuss it off line if you like). If you have a project 
you're willing to let me see, I can try and port it for you and 
document the steps.


While I remain an "Ant devotee," The easiest workaround for
dealing with libraries and teams is to simply set the project up
from the very start to use a dedicated folder for storing
libraries. When that is done, there is a `lib` folder created in
the top-level project directory. Anytime that you or someone else
on the team adds a library to the project, that library is copied
to that `lib` folder. If your team is using a repository (if not,
I want to know how changes are tracked ;-)), that `lib` folder is
also on the root of the repository and is copied to any machine
that clones the library.


Back when we were doing this, we simply checked the libraries into SVN 
so that the project could be mostly stand alone and have a single 
source of truth.


I actually introduced Ant to our group back in the day, at that time I 
was doing everything in Emacs, and folks were still trying to shoehorn 
Java projects in to make, which is a bad idea. I had to run around 
with a wiffle ball bat to prevent developers from just shoving stuff 
on to the classpath to get stuff to run. We weren't packaging things 
properly, relying on the CLASSPATH env variable for stuff, etc. It was 
awful. Ant didn't cause this, but I will say that with Maven and 
modern packaging, it is rare and far between that I have classpath 
problems, especially as it was back in the day. I certainly enjoy not 
having to mess with classpaths.


Also, you said, "My pom.xml file lists 13 direct dependencies. The
actual number of jars that get imported is closer to 50." To me,
that is not a feature, but rather it is a pain in the rear. I want
to know, and I mean /*know*/, /exactly/ what my project's
dependencies are. My goal when designing software is to keep
external dependencies at a bare minimum. No, I do not try to
reinvent the wheel in each project, but I like to have absolute
control over dependencies. To that end, when using Any, I have
that control.

You have that control with Maven, but it's more of a "don't include 
this, and this, and this" vs 'just use this and that and the other". 
It's more exception based (and the IDE makes this process really easy, 
as you can just prune entire branches off of the dependency graph in 
the UI). Maven offers all of that control, I just find I rarely need 
to exercise it. Which is great when you just want to lazily get stuff 
done.


As a comparison, I have created a simple "Hello World" project
that contains a single `JFrame` class, using Ant and using Maven.
From the finishing of the New Project Wizard until the project was
ready to be run for the first time, the Ant project took just a
few seconds, whereas the Maven project took well over a minute to
complete the background scanning. When I compiled them into Jar
files, the Ant application weighed in at around 30 KiB, whereas
the Maven application weighed in at just over 1 MiB. So, the Maven
project included some "dependencies" that I did not need. I felt
like I had no control at all.


I can't speak to that, I don't know what projects you used. I created 
a new Java Application, added a New JFrame Form, dragged a label on to 
it, and, in the end, the jar file I had was < 5K. Plus there are 
nuances missing from the Maven discussion about default artifacts and 
how it starts. But, safe to say, my eventual jar file had the 
NewJFrame class, a manifest and the pom. We 

Re: removing the "new project" support for Ant projects

[Oliver Rettig]

+1
> On Thu, 22 Apr 2021 at 08:15, Geertjan Wielenga
> 
>  wrote:
> > should we consider downplaying the prominence of Ant by removing from
> > NetBeans the ability to create new Ant projects
> -1 from me.  I think we made the right steps previously, and perhaps
> should look at whether particular templates need updating or removing
> entirely.  But Ant still has its place, particularly with regard to
> the platform.
> 
> I'd also prefer an unopinionated IDE.  And from an ASF perspective,
> Ant is still an active project here - Apache's IDE should possibly not
> be deciding when it's time to retire it! :-)
> 
> Best wishes,
> 
> Neil
> 
> -
> To unsubscribe, e-mail: users-unsubscr...@netbeans.apache.org
> For additional commands, e-mail: users-h...@netbeans.apache.org
> 
> For further information about the NetBeans mailing lists, visit:
> https://cwiki.apache.org/confluence/display/NETBEANS/Mailing+lists

Re: removing the "new project" support for Ant projects

[Sean Carrick]

> -1 from me.  I think we made the right steps previously, and perhaps
> should look at whether particular templates need updating or removing
> entirely.  But Ant still has its place, particularly with regard to
> the platform.
>
> I'd also prefer an unopinionated IDE.  And from an ASF perspective,
> Ant is still an active project here - Apache's IDE should possibly not
> be deciding when it's time to retire it! :-)

+1 to Neil's comment! An IDE should remain a tool and not a ruler.

We should reach out to the Apache Ant (and other Apache projects) for
collaboration with us.

> In an ideal world, the Apache Ant community would be developing and
> promoting the Apache Ant features in Apache NetBeans.
Another +1 to GJ's comment. Darn right that the Apache Ant community
should be promoting and */touting/* the Apache Ant features in NB! I
believe, if I am remembering correctly, that NB was one of the first
Java IDEs to provide integrated support for Apache Ant. And the IDE
integration for it has always be top-notch...
/*
*/
-SC

Re: removing the "new project" support for Ant projects

[Geertjan Wielenga]

Good point, Neil. :-)

We should reach out to the Apache Ant (and other Apache projects) for
collaboration with us.

In an ideal world, the Apache Ant community would be developing and
promoting the Apache Ant features in Apache NetBeans.

Gj

On Thu, 22 Apr 2021 at 10:17, Neil C Smith  wrote:

> On Thu, 22 Apr 2021 at 08:15, Geertjan Wielenga
>  wrote:
> > should we consider downplaying the prominence of Ant by removing from
> NetBeans the ability to create new Ant projects
>
> -1 from me.  I think we made the right steps previously, and perhaps
> should look at whether particular templates need updating or removing
> entirely.  But Ant still has its place, particularly with regard to
> the platform.
>
> I'd also prefer an unopinionated IDE.  And from an ASF perspective,
> Ant is still an active project here - Apache's IDE should possibly not
> be deciding when it's time to retire it! :-)
>
> Best wishes,
>
> Neil
>

Re: removing the "new project" support for Ant projects

[Neil C Smith]

On Thu, 22 Apr 2021 at 08:15, Geertjan Wielenga
 wrote:
> should we consider downplaying the prominence of Ant by removing from 
> NetBeans the ability to create new Ant projects

-1 from me.  I think we made the right steps previously, and perhaps
should look at whether particular templates need updating or removing
entirely.  But Ant still has its place, particularly with regard to
the platform.

I'd also prefer an unopinionated IDE.  And from an ASF perspective,
Ant is still an active project here - Apache's IDE should possibly not
be deciding when it's time to retire it! :-)

Best wishes,

Neil

-
To unsubscribe, e-mail: users-unsubscr...@netbeans.apache.org
For additional commands, e-mail: users-h...@netbeans.apache.org

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

Re: removing the "new project" support for Ant projects

[Owen Thomas]

On Thu, 22 Apr 2021 at 17:15, Geertjan Wielenga
 wrote:

> I don’t think we’re going to resolve this, several people in this
> discussion don’t understand the key point with which this thread started:
> should we consider downplaying the prominence of Ant by removing from
> NetBeans the ability to create new Ant projects (while keeping all other
> Ant functionality).
>

I think you're saying that Ant isn't the best choice of build tool for
modern development methodologies, and I would agree with this sentiment. I
still use Ant for my projects because I created them a long time ago with
Ant, they don't make use of third party stuff, and... admittedly... no one
else works with me, so I've never felt the compulsion to move.

I think Ant is still a good option to do relatively lightweight and
experimental work. I've created more than 100 projects using Ant - most of
which have an active life of about 20 minutes, and many of which don't even
compile. Perhaps I'd put it further down the list of options available from
the create projects menu (I have indeed noticed this has happened in the
12.2 version of NB that I'm using at the moment) but removing it from the
options seems to be an unnecessary snub.

I suppose I've just got to move with the times.

Done... probably.

  Owen.

Re: [External] : Re: removing the "new project" support for Ant projects

[John Mc]

Just keep it simple:

"Apache NetBeans recommends for beginners creating new projects with modern
build/dependency frameworks like Maven or Gradle"

I wouldn't include a reference, warning of its potential removal, since
that's not been the common consensus here...

Regards

John

On Thu, 22 Apr 2021 at 08:32, Ewan Slater  wrote:

> I think a warning message that:
>
>1. Recommends Maven or Gradle
>2. Warns that Ant project creating may be removed in a future release.
>
> My €0.02
> --
> *From:* Geertjan Wielenga 
> *Sent:* 22 April 2021 08:15
> *Cc:* users@netbeans.apache.org 
> *Subject:* [External] : Re: removing the "new project" support for Ant
> projects
>
> Hi all,
>
> I don’t think we’re going to resolve this, several people in this
> discussion don’t understand the key point with which this thread started:
> should we consider downplaying the prominence of Ant by removing from
> NetBeans the ability to create new Ant projects (while keeping all other
> Ant functionality).
>
> The previous time we had this discussion we solved it by moving Maven and
> Gradle projects above Ant projects, as descrbed here:
>
>
> https://blogs.apache.org/netbeans/entry/restructuring-of-project-templates-in
> <https://urldefense.com/v3/__https://blogs.apache.org/netbeans/entry/restructuring-of-project-templates-in__;!!GqivPVa7Brio!LQDr-KpHS2hxY2ax5tglMFZL-rulMUbLx82cooIabKwml29tmmysmLxcouF-mrjO$>
>
> A next step (very simple) could be to change all the desciptions of Ant
> projects in the New Project wizard to a warning message stating that
> NetBeans recommends usage of Maven or Gradle instead of Ant.
>
> Thanks,
>
> Gj
>
> On Thu, 22 Apr 2021 at 08:30, Bilu  wrote:
>
> +1 for not removing Ant support or Ant New project creation.
>
> I personnally still use Ant for my projects
> Le 22/04/2021 à 03:40, Owen Thomas a écrit :
>
> If one wants to create an Ant project from within NetBeans, then one
> should be able to do that.
>
> I've encountered both Maven and Gradle (Gradle when developing for Android
> on IntelliJ... another anecdote about frustration), and I can see their use
> when one has to manage one's code base against differing versions of third
> party libraries. That's great, but if one is merely doing something small,
> especially something that might showcase some feature of SE without
> bringing in functionality of third party libraries, Ant leaves the
> developer alone to do that. All the stuff that Gradle and Maven introduce
> to one's build script becomes useless boilerplate - a distraction
> especially when one merely wants to demonstrate or learn a feature of the
> SE API and perhaps even to grasp some of the necessity of the build script
> itself.
>
> It's not difficult to move a project to Maven or Gradle or any other build
> script. Copy one's /src directory from the Ant project to the appropriate
> directory of the destination project (maybe set a main class) and off you
> go. Novice developers can easily be scared into withdrawal by
> considerations that are not salient to their aims, and the distractions
> that Maven/Gradle build scripts introduce can only encourage withdrawal
> into those developers who are trying to navigate this world alone. I would
> consider it a backward step if NB were to adopt the position of other IDEs
> and appropriate an air of superiority around the choice of build script.
> Because nothing more than an air of superiority is projected by an IDE that
> doesn't permit the creation of Ant projects.
>
> I like Ant. Ant is good. Leave Ant alone.
>
> Done.
>
>   Owen.
>
>

Re: [External] : Re: removing the "new project" support for Ant projects

[Ewan Slater]

I think a warning message that:

  1.  Recommends Maven or Gradle
  2.  Warns that Ant project creating may be removed in a future release.

My €0.02

From: Geertjan Wielenga 
Sent: 22 April 2021 08:15
Cc: users@netbeans.apache.org 
Subject: [External] : Re: removing the "new project" support for Ant projects

Hi all,

I don’t think we’re going to resolve this, several people in this discussion 
don’t understand the key point with which this thread started: should we 
consider downplaying the prominence of Ant by removing from NetBeans the 
ability to create new Ant projects (while keeping all other Ant functionality).

The previous time we had this discussion we solved it by moving Maven and 
Gradle projects above Ant projects, as descrbed here:

https://blogs.apache.org/netbeans/entry/restructuring-of-project-templates-in<https://urldefense.com/v3/__https://blogs.apache.org/netbeans/entry/restructuring-of-project-templates-in__;!!GqivPVa7Brio!LQDr-KpHS2hxY2ax5tglMFZL-rulMUbLx82cooIabKwml29tmmysmLxcouF-mrjO$>

A next step (very simple) could be to change all the desciptions of Ant 
projects in the New Project wizard to a warning message stating that NetBeans 
recommends usage of Maven or Gradle instead of Ant.

Thanks,

Gj

On Thu, 22 Apr 2021 at 08:30, Bilu 
mailto:albi...@gmail.com>> wrote:

+1 for not removing Ant support or Ant New project creation.

I personnally still use Ant for my projects

Le 22/04/2021 à 03:40, Owen Thomas a écrit :
If one wants to create an Ant project from within NetBeans, then one should be 
able to do that.

I've encountered both Maven and Gradle (Gradle when developing for Android on 
IntelliJ... another anecdote about frustration), and I can see their use when 
one has to manage one's code base against differing versions of third party 
libraries. That's great, but if one is merely doing something small, especially 
something that might showcase some feature of SE without bringing in 
functionality of third party libraries, Ant leaves the developer alone to do 
that. All the stuff that Gradle and Maven introduce to one's build script 
becomes useless boilerplate - a distraction especially when one merely wants to 
demonstrate or learn a feature of the SE API and perhaps even to grasp some of 
the necessity of the build script itself.

It's not difficult to move a project to Maven or Gradle or any other build 
script. Copy one's /src directory from the Ant project to the appropriate 
directory of the destination project (maybe set a main class) and off you go. 
Novice developers can easily be scared into withdrawal by considerations that 
are not salient to their aims, and the distractions that Maven/Gradle build 
scripts introduce can only encourage withdrawal into those developers who are 
trying to navigate this world alone. I would consider it a backward step if NB 
were to adopt the position of other IDEs and appropriate an air of superiority 
around the choice of build script. Because nothing more than an air of 
superiority is projected by an IDE that doesn't permit the creation of Ant 
projects.

I like Ant. Ant is good. Leave Ant alone.

Done.

  Owen.

Re: removing the "new project" support for Ant projects

[Geertjan Wielenga]

Hi all,

I don’t think we’re going to resolve this, several people in this
discussion don’t understand the key point with which this thread started:
should we consider downplaying the prominence of Ant by removing from
NetBeans the ability to create new Ant projects (while keeping all other
Ant functionality).

The previous time we had this discussion we solved it by moving Maven and
Gradle projects above Ant projects, as descrbed here:

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

A next step (very simple) could be to change all the desciptions of Ant
projects in the New Project wizard to a warning message stating that
NetBeans recommends usage of Maven or Gradle instead of Ant.

Thanks,

Gj

On Thu, 22 Apr 2021 at 08:30, Bilu  wrote:

> +1 for not removing Ant support or Ant New project creation.
>
> I personnally still use Ant for my projects
> Le 22/04/2021 à 03:40, Owen Thomas a écrit :
>
> If one wants to create an Ant project from within NetBeans, then one
> should be able to do that.
>
> I've encountered both Maven and Gradle (Gradle when developing for Android
> on IntelliJ... another anecdote about frustration), and I can see their use
> when one has to manage one's code base against differing versions of third
> party libraries. That's great, but if one is merely doing something small,
> especially something that might showcase some feature of SE without
> bringing in functionality of third party libraries, Ant leaves the
> developer alone to do that. All the stuff that Gradle and Maven introduce
> to one's build script becomes useless boilerplate - a distraction
> especially when one merely wants to demonstrate or learn a feature of the
> SE API and perhaps even to grasp some of the necessity of the build script
> itself.
>
> It's not difficult to move a project to Maven or Gradle or any other build
> script. Copy one's /src directory from the Ant project to the appropriate
> directory of the destination project (maybe set a main class) and off you
> go. Novice developers can easily be scared into withdrawal by
> considerations that are not salient to their aims, and the distractions
> that Maven/Gradle build scripts introduce can only encourage withdrawal
> into those developers who are trying to navigate this world alone. I would
> consider it a backward step if NB were to adopt the position of other IDEs
> and appropriate an air of superiority around the choice of build script.
> Because nothing more than an air of superiority is projected by an IDE that
> doesn't permit the creation of Ant projects.
>
> I like Ant. Ant is good. Leave Ant alone.
>
> Done.
>
>   Owen.
>
>

Re: removing the "new project" support for Ant projects

[Bilu]

+1 for not removing Ant support or Ant New project creation.

I personnally still use Ant for my projects

Le 22/04/2021 à 03:40, Owen Thomas a écrit :
> If one wants to create an Ant project from within NetBeans, then one
> should be able to do that.
>
> I've encountered both Maven and Gradle (Gradle when developing for
> Android on IntelliJ... another anecdote about frustration), and I can
> see their use when one has to manage one's code base against differing
> versions of third party libraries. That's great, but if one is merely
> doing something small, especially something that might showcase some
> feature of SE without bringing in functionality of third party
> libraries, Ant leaves the developer alone to do that. All the stuff
> that Gradle and Maven introduce to one's build script becomes useless
> boilerplate - a distraction especially when one merely wants to
> demonstrate or learn a feature of the SE API and perhaps even to grasp
> some of the necessity of the build script itself.
>
> It's not difficult to move a project to Maven or Gradle or any other
> build script. Copy one's /src directory from the Ant project to the
> appropriate directory of the destination project (maybe set a main
> class) and off you go. Novice developers can easily be scared into
> withdrawal by considerations that are not salient to their aims, and
> the distractions that Maven/Gradle build scripts introduce can only
> encourage withdrawal into those developers who are trying to navigate
> this world alone. I would consider it a backward step if NB were to
> adopt the position of other IDEs and appropriate an air of superiority
> around the choice of build script. Because nothing more than an air of
> superiority is projected by an IDE that doesn't permit the creation of
> Ant projects.
>
> I like Ant. Ant is good. Leave Ant alone.
>
> Done.
>
>   Owen.

Re: removing the "new project" support for Ant projects

[Owen Thomas]

If one wants to create an Ant project from within NetBeans, then one should
be able to do that.

I've encountered both Maven and Gradle (Gradle when developing for Android
on IntelliJ... another anecdote about frustration), and I can see their use
when one has to manage one's code base against differing versions of third
party libraries. That's great, but if one is merely doing something small,
especially something that might showcase some feature of SE without
bringing in functionality of third party libraries, Ant leaves the
developer alone to do that. All the stuff that Gradle and Maven introduce
to one's build script becomes useless boilerplate - a distraction
especially when one merely wants to demonstrate or learn a feature of the
SE API and perhaps even to grasp some of the necessity of the build script
itself.

It's not difficult to move a project to Maven or Gradle or any other build
script. Copy one's /src directory from the Ant project to the appropriate
directory of the destination project (maybe set a main class) and off you
go. Novice developers can easily be scared into withdrawal by
considerations that are not salient to their aims, and the distractions
that Maven/Gradle build scripts introduce can only encourage withdrawal
into those developers who are trying to navigate this world alone. I would
consider it a backward step if NB were to adopt the position of other IDEs
and appropriate an air of superiority around the choice of build script.
Because nothing more than an air of superiority is projected by an IDE that
doesn't permit the creation of Ant projects.

I like Ant. Ant is good. Leave Ant alone.

Done.

  Owen.

Re: removing the "new project" support for Ant projects

[Scott Palmer]

> On Apr 21, 2021, at 2:15 AM, Owen Thomas  wrote:
> 
> I think Ant is lovely. Most of my projects only extend the Java SE API. I 
> don't see the need to change to a build tool that manages third party 
> libraries unless and until I need to use third party libraries.
> 
> Keep supporting Ant and keep the build process as trivial as it needs to be.

A Gradle build script for you could literally be a single line:

apply plugin: ‘java’

or

apply plugin: ‘application’   // to get support for bundling the app with 
launch scripts and stuff

Sure Gradle also manages third party libraries… but it doesn’t force you to 
include that kind of stuff in your build.gradle file if you aren’t using it.

Ant works, but it doesn’t scale well.  Just look at the complexity of the NB 
ant scripts to see.  Maven handles things a bit better than Ant, but it can 
also become cumbersome for complex projects.  If it was just a simple Java app 
with dependencies, then I would choose Ant+Ivy over Maven.. but start adding 
customizations and things get ugly fast.  The down side of Gradle is that it 
does give you enough rope to get tangled… though I’ve never outright hung 
myself ;-)


Anyway… it seems Ant support is still widely used and wanted.  So I would vote 
against removing the new project support for Ant in favour of simply 
discouraging it for new projects so newbies don’t start down that road.


Scott
-
To unsubscribe, e-mail: users-unsubscr...@netbeans.apache.org
For additional commands, e-mail: users-h...@netbeans.apache.org

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

Re: removing the "new project" support for Ant projects

[Will Hartung]

On Tue, Apr 20, 2021 at 11:43 PM Thomas Kellerer  wrote:

> Another +1 for NOT removing Ant support.
>

Nobody is talking about removing Ant support completely.

As far as the "New Project" dialog is concerned:
>
> What about creating a new category "Other" (or maybe even "Legacy") that
> in turn contains the "Java with Ant" category to make the "Ant option" less
> prominent.
>

My singular issue with this is that it simply implies that they're going to
leave stuff that "doesn't work", that they/we know "doesn't work", and have
no intentions to fix it. Having broken stuff shipped with the IDE doesn't
provide value, IMHO.

If there were actual maintainers for these, it would be less of an issue. I
can't speak for anyone else, I imagine maintaining these aren't arduous,
but they do involve ramp up time on the IDE and such. They're likely not a
quick fix. For someone familiar with the NB side of it, yea, they are all
likely pretty minor. But getting to that level is likely not quick, and
those that may have that expertise are focusing on the more difficult parts
of the IDE.

Regards,

Will Hartung

Re: removing the "new project" support for Ant projects

[Will Hartung]

On Wed, Apr 21, 2021 at 4:51 AM Sean Carrick  wrote:

> You have given a very well thought out answer to my message and I
> appreciate that. Now, let me ask you this: do you maintain legacy systems
> that were built with the Swing Application Framework? If so, were you able
> to convert them to using Maven?
>

No, I have not used SAF. I looked into it, but it was after it's "use by
date", so the links and what not weren't really appropriate for someone
trying it today. For some reason I really struggle with GUIs.

I can not speak to any direct SAF support NB had at an IDE level. I can
only posit that, in the end, the SAF is "just a jar file", and at that
level, adding SAF support to a Maven project is simply a matter of
importing it into your local repository. This is straightforward (and we
can discuss it off line if you like). If you have a project you're willing
to let me see, I can try and port it for you and document the steps.


> While I remain an "Ant devotee," The easiest workaround for dealing with
> libraries and teams is to simply set the project up from the very start to
> use a dedicated folder for storing libraries. When that is done, there is a
> `lib` folder created in the top-level project directory. Anytime that you
> or someone else on the team adds a library to the project, that library is
> copied to that `lib` folder. If your team is using a repository (if not, I
> want to know how changes are tracked ;-)), that `lib` folder is also on
> the root of the repository and is copied to any machine that clones the
> library.
>

Back when we were doing this, we simply checked the libraries into SVN so
that the project could be mostly stand alone and have a single source of
truth.

I actually introduced Ant to our group back in the day, at that time I was
doing everything in Emacs, and folks were still trying to shoehorn Java
projects in to make, which is a bad idea. I had to run around with a wiffle
ball bat to prevent developers from just shoving stuff on to the classpath
to get stuff to run. We weren't packaging things properly, relying on the
CLASSPATH env variable for stuff, etc. It was awful. Ant didn't cause this,
but I will say that with Maven and modern packaging, it is rare and far
between that I have classpath problems, especially as it was back in the
day. I certainly enjoy not having to mess with classpaths.

> Also, you said, "My pom.xml file lists 13 direct dependencies. The actual
> number of jars that get imported is closer to 50." To me, that is not a
> feature, but rather it is a pain in the rear. I want to know, and I mean
> *know*, *exactly* what my project's dependencies are. My goal when
> designing software is to keep external dependencies at a bare minimum. No,
> I do not try to reinvent the wheel in each project, but I like to have
> absolute control over dependencies. To that end, when using Any, I have
> that control.
>
You have that control with Maven, but it's more of a "don't include this,
and this, and this" vs 'just use this and that and the other". It's more
exception based (and the IDE makes this process really easy, as you can
just prune entire branches off of the dependency graph in the UI). Maven
offers all of that control, I just find I rarely need to exercise it. Which
is great when you just want to lazily get stuff done.


> As a comparison, I have created a simple "Hello World" project that
> contains a single `JFrame` class, using Ant and using Maven. From the
> finishing of the New Project Wizard until the project was ready to be run
> for the first time, the Ant project took just a few seconds, whereas the
> Maven project took well over a minute to complete the background scanning.
> When I compiled them into Jar files, the Ant application weighed in at
> around 30 KiB, whereas the Maven application weighed in at just over 1 MiB.
> So, the Maven project included some "dependencies" that I did not need. I
> felt like I had no control at all.
>

I can't speak to that, I don't know what projects you used. I created a new
Java Application, added a New JFrame Form, dragged a label on to it, and,
in the end, the jar file I had was < 5K. Plus there are nuances missing
from the Maven discussion about default artifacts and how it starts. But,
safe to say, my eventual jar file had the NewJFrame class, a manifest and
the pom. We can talk abou that off line if you wish as well.


> Having said all of that, I will say this: I am not a Luddite and am seeing
> the writing on the wall regarding Ant. While I will continue to use it for
> my projects, I am working on some things on the side, such as porting the
> old JSR-296 AppFramework to JDK-11 and building it based upon Maven. Taking
> a page from the BSAF project, I am adding features to that framework, such
> as a lightweight docking library (pure Java, no outside dependencies). I am
> hoping that the legacy projects built on the SAF will then be able to be
> successfully ported off of the Ant build system 

Re: removing the "new project" support for Ant projects

[Sean Carrick]

> No, those projects were not left in the lurch by NetBeans dropping
> support for it. Projects were left in the lurch by NetBeans providing
> support for it for too early.

+1

This is all too true. However, it /does/ make a nice, light-weight
library for smaller applications...

Re: removing the "new project" support for Ant projects

[Geertjan Wielenga]

No, those projects were not left in the lurch by NetBeans dropping support
for it. Projects were left in the lurch by NetBeans providing support for
it for too early.

Gj

On Wed, Apr 21, 2021 at 2:24 PM Sean Carrick  wrote:

> GJ,
>
> I think one of the biggest mistakes in the history of NetBeans was to
> provide support for the JSR 296 Swing Application Framework (SAF). We
> should have waited until it was no longer a JSR.
>
> With this statement, I could not agree more strongly with you. NB should
> have waited to support AppFramework until it was approved and included in
> JDK7 (I believe that is the version JSR-296 was targeting).
>
> It should only have been supported in NetBeans once it became part of the
> JDK. Since it in the end didn't become part of the JDK, it was essentially
> dead.
>
> I do not like the phrase "essentially dead." I am only saying that because
> I have recently procured a copy of the original source code and have been
> in contact with Hans regarding it. I am in the process of bringing it up to
> the JDK11 LTS and trying (!) to have it be Maven based.
>
> The problem isn't that SAF uses Ant and not Maven: instead, the problem is
> that you're using a framework that was planned to be included in the JDK
> but in the end wasn't, so is completely dead.
>
> Just because the framework was *planned* to be included in the JDK, but
> in the end was not, does not mean that it is a problem that someone is
> using it. The problem actually is that, while it had included (maybe
> incorrectly) support in a very popular IDE, it was used and adapted by
> quite a few projects over the years between NB6 through NB8.2. Then, once
> those projects were using that framework, the popular IDE dropped
> "out-of-the-box" support for it and all of those project were kind of left
> in the lurch. However, Hans did a good job on that framework, at least to
> the point that he brought it. It has solid principles and has quality
> design. Also, that framework provides some application plumbing that is
> perfect for smaller projects, as, sometimes, the NBP is just too much
> framework for a project.
>
> Anyway, that is just my thoughts on it. Do not forget, GJ, you owe me a
> slap when you see me. ;-)
>
> -SC
>

Re: removing the "new project" support for Ant projects

[Sean Carrick]

GJ,

> I think one of the biggest mistakes in the history of NetBeans was to
> provide support for the JSR 296 Swing Application Framework (SAF). We
> should have waited until it was no longer a JSR.
With this statement, I could not agree more strongly with you. NB should
have waited to support AppFramework until it was approved and included
in JDK7 (I believe that is the version JSR-296 was targeting).
> It should only have been supported in NetBeans once it became part of
> the JDK. Since it in the end didn't become part of the JDK, it was
> essentially dead.
I do not like the phrase "essentially dead." I am only saying that
because I have recently procured a copy of the original source code and
have been in contact with Hans regarding it. I am in the process of
bringing it up to the JDK11 LTS and trying (!) to have it be Maven based.
> The problem isn't that SAF uses Ant and not Maven: instead, the
> problem is that you're using a framework that was planned to be
> included in the JDK but in the end wasn't, so is completely dead.

Just because the framework was /planned/ to be included in the JDK, but
in the end was not, does not mean that it is a problem that someone is
using it. The problem actually is that, while it had included (maybe
incorrectly) support in a very popular IDE, it was used and adapted by
quite a few projects over the years between NB6 through NB8.2. Then,
once those projects were using that framework, the popular IDE dropped
"out-of-the-box" support for it and all of those project were kind of
left in the lurch. However, Hans did a good job on that framework, at
least to the point that he brought it. It has solid principles and has
quality design. Also, that framework provides some application plumbing
that is perfect for smaller projects, as, sometimes, the NBP is just too
much framework for a project.

Anyway, that is just my thoughts on it. Do not forget, GJ, you owe me a
slap when you see me. ;-)

-SC



signature.asc
Description: OpenPGP digital signature

Re: removing the "new project" support for Ant projects

[Sean Carrick]

Wayne,
>
> Another issue is that you can't keep it in version control and deploy
> to multiple team members very easily. Minor filesystem differences
> make that sort of thing impossible to do out of the box.
>
This is easily handled in an Ant project when you create the project at
the beginning. In the New Project Wizard:

Then, your initial project folder structure will look like this:

That `lib` folder is where any and all library dependencies will be
copied by anyone on the team who adds a library dependency. When changes
are committed and pushed to the remote repository, that `lib` folder
will be committed and pushed as well.

By setting up the project in this way from the beginning, you do not run
into the issues that you mentioned, as no library will ever have a
hard-coded path that goes outside of the project structure:

As you can see in the project properties in this convoluted example, the
library dependency for JTattoo has a /relative path that does not go
outside of the project folder structure/, instead of a hard-coded path
to some location on my computer. This is how you prevent having the
issue you perceived about not being able to have the project in a
repository for a team...

-SC

Re: removing the "new project" support for Ant projects

[Don]

I have used Netbeans longer than it has been called Netbeans.  It has 
been remarkably stable and some of my projects rely on its ability to 
include other projects.  All of the included projects are Ant-based.  
Dropping support for Ant probably won't hurt since I can always keep the 
existing version (I have tended to treat the .0 releases as LTS). But 
I'm getting to the point where it is not practical to learn a new build 
technology and I'm getting ready to retire.


-
To unsubscribe, e-mail: users-unsubscr...@netbeans.apache.org
For additional commands, e-mail: users-h...@netbeans.apache.org

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

Re: removing the "new project" support for Ant projects

[Geertjan Wielenga]

I think one of the biggest mistakes in the history of NetBeans was to
provide support for the JSR 296 Swing Application Framework (SAF). We
should have waited until it was no longer a JSR. It should only have been
supported in NetBeans once it became part of the JDK. Since it in the end
didn't become part of the JDK, it was essentially dead. The problem isn't
that SAF uses Ant and not Maven: instead, the problem is that you're using
a framework that was planned to be included in the JDK but in the end
wasn't, so is completely dead.

Gj

On Wed, Apr 21, 2021 at 1:52 PM Sean Carrick  wrote:

> Will,
>
> You have given a very well thought out answer to my message and I
> appreciate that. Now, let me ask you this: do you maintain legacy systems
> that were built with the Swing Application Framework? If so, were you able
> to convert them to using Maven?
>
> I have a couple of legacy applications that I maintain that use the SAF
> and I copied one of the project folders to a new location, just to see if I
> could switch it over to Maven and once I did so, nothing in that project
> worked any longer. If you happen to know of a way to make those legacy
> projects play nice in the Maven space, I am all ears.
>
> While I remain an "Ant devotee," The easiest workaround for dealing with
> libraries and teams is to simply set the project up from the very start to
> use a dedicated folder for storing libraries. When that is done, there is a
> `lib` folder created in the top-level project directory. Anytime that you
> or someone else on the team adds a library to the project, that library is
> copied to that `lib` folder. If your team is using a repository (if not, I
> want to know how changes are tracked ;-)), that `lib` folder is also on
> the root of the repository and is copied to any machine that clones the
> library.
>
> Also, you said, "My pom.xml file lists 13 direct dependencies. The actual
> number of jars that get imported is closer to 50." To me, that is not a
> feature, but rather it is a pain in the rear. I want to know, and I mean
> *know*, *exactly* what my project's dependencies are. My goal when
> designing software is to keep external dependencies at a bare minimum. No,
> I do not try to reinvent the wheel in each project, but I like to have
> absolute control over dependencies. To that end, when using Any, I have
> that control.
>
> As a comparison, I have created a simple "Hello World" project that
> contains a single `JFrame` class, using Ant and using Maven. From the
> finishing of the New Project Wizard until the project was ready to be run
> for the first time, the Ant project took just a few seconds, whereas the
> Maven project took well over a minute to complete the background scanning.
> When I compiled them into Jar files, the Ant application weighed in at
> around 30 KiB, whereas the Maven application weighed in at just over 1 MiB.
> So, the Maven project included some "dependencies" that I did not need. I
> felt like I had no control at all.
>
> Having said all of that, I will say this: I am not a Luddite and am seeing
> the writing on the wall regarding Ant. While I will continue to use it for
> my projects, I am working on some things on the side, such as porting the
> old JSR-296 AppFramework to JDK-11 and building it based upon Maven. Taking
> a page from the BSAF project, I am adding features to that framework, such
> as a lightweight docking library (pure Java, no outside dependencies). I am
> hoping that the legacy projects built on the SAF will then be able to be
> successfully ported off of the Ant build system and into the Maven realm...
>
> Anyway, once again, thank you for your well-thought out and coherent
> discussion.
>
> -SC
> On 4/21/21 12:56 AM, Will Hartung wrote:
>
>
>
> On Tue, Apr 20, 2021 at 9:32 PM Sean Carrick  wrote:
>
>> Explain to me, Scott, why I **need** to learn Maven and dump Ant. Ant
>> has served me very well all of these years and has never given me one
>> single bit of trouble. Speed? Ant is fast enough for me and my projects.
>> Keeping libraries "up-to-date"? That is just another way of saying "stay on
>> the bleeding edge." Why should I learn Maven and dump Ant? Explain it with
>> facts and reasoning, and without resorting to expressions such as "sticking
>> your head in the sand."
>>
>
> I have a project using JavaFX, JPA, CDI, and Derby. My pom.xml file lists
> 13 direct dependencies. The actual number of jars that get imported is
> closer to 50.
>
> There's a really cool project out there used to write REST based micro web
> services called dropwizard. To use it, you add a single dependency to you
> pom.xml.
>
> When your project builds, it downloads and imports about 90 other jar
> files.
>
> Nowhere on their site will you see this list of jar files that it requires
> to run.
>
> Using the IDE, with two mouse clicks, I can have not just the jars
> downloaded, but all of the available javadoc and source files. Once it's
> all caught up, I have 

Re: removing the "new project" support for Ant projects

[Sean Carrick]

Will,

You have given a very well thought out answer to my message and I
appreciate that. Now, let me ask you this: do you maintain legacy
systems that were built with the Swing Application Framework? If so,
were you able to convert them to using Maven?

I have a couple of legacy applications that I maintain that use the SAF
and I copied one of the project folders to a new location, just to see
if I could switch it over to Maven and once I did so, nothing in that
project worked any longer. If you happen to know of a way to make those
legacy projects play nice in the Maven space, I am all ears.

While I remain an "Ant devotee," The easiest workaround for dealing with
libraries and teams is to simply set the project up from the very start
to use a dedicated folder for storing libraries. When that is done,
there is a `lib` folder created in the top-level project directory.
Anytime that you or someone else on the team adds a library to the
project, that library is copied to that `lib` folder. If your team is
using a repository (if not, I want to know how changes are tracked ;-)),
that `lib` folder is also on the root of the repository and is copied to
any machine that clones the library.

Also, you said, "My pom.xml file lists 13 direct dependencies. The
actual number of jars that get imported is closer to 50." To me, that is
not a feature, but rather it is a pain in the rear. I want to know, and
I mean /*know*/, /exactly/ what my project's dependencies are. My goal
when designing software is to keep external dependencies at a bare
minimum. No, I do not try to reinvent the wheel in each project, but I
like to have absolute control over dependencies. To that end, when using
Any, I have that control.

As a comparison, I have created a simple "Hello World" project that
contains a single `JFrame` class, using Ant and using Maven. From the
finishing of the New Project Wizard until the project was ready to be
run for the first time, the Ant project took just a few seconds, whereas
the Maven project took well over a minute to complete the background
scanning. When I compiled them into Jar files, the Ant application
weighed in at around 30 KiB, whereas the Maven application weighed in at
just over 1 MiB. So, the Maven project included some "dependencies" that
I did not need. I felt like I had no control at all.

Having said all of that, I will say this: I am not a Luddite and am
seeing the writing on the wall regarding Ant. While I will continue to
use it for my projects, I am working on some things on the side, such as
porting the old JSR-296 AppFramework to JDK-11 and building it based
upon Maven. Taking a page from the BSAF project, I am adding features to
that framework, such as a lightweight docking library (pure Java, no
outside dependencies). I am hoping that the legacy projects built on the
SAF will then be able to be successfully ported off of the Ant build
system and into the Maven realm...

Anyway, once again, thank you for your well-thought out and coherent
discussion.

-SC

On 4/21/21 12:56 AM, Will Hartung wrote:
>
>
> On Tue, Apr 20, 2021 at 9:32 PM Sean Carrick  > wrote:
>
> Explain to me, Scott, why I **need** to learn Maven and dump Ant.
> Ant has served me very well all of these years and has never given
> me one single bit of trouble. Speed? Ant is fast enough for me and
> my projects. Keeping libraries "up-to-date"? That is just another
> way of saying "stay on the bleeding edge." Why should I learn
> Maven and dump Ant? Explain it with facts and reasoning, and
> without resorting to expressions such as "sticking your head in
> the sand."
>
>
> I have a project using JavaFX, JPA, CDI, and Derby. My pom.xml file
> lists 13 direct dependencies. The actual number of jars that get
> imported is closer to 50.
>
> There's a really cool project out there used to write REST based micro
> web services called dropwizard. To use it, you add a single dependency
> to you pom.xml.
>
> When your project builds, it downloads and imports about 90 other jar
> files.
>
> Nowhere on their site will you see this list of jar files that it
> requires to run. 
>
> Using the IDE, with two mouse clicks, I can have not just the jars
> downloaded, but all of the available javadoc and source files. Once
> it's all caught up, I have access to all of that within the IDE.
>
> The key point is, that in the modern Java community, projects are
> shared using Maven artifacts. Many sites start their "quick start"
> instructions with "plop this dependency into your project file". From
> there, magic happens. Gradle relies on Maven repositories. Ivy for Ant
> relies on them also. I think there are other Java build tools that do
> also.
>
> Finally, NB, Eclipse, IDEA, and even Emacs all have first class
> support for Maven projects and pom files. With those pom files, all of
> the autocomplete works MUCH better, and painlessly. This works very
> well in offices with mixed 

Re: removing the "new project" support for Ant projects

[Owen Thomas]

Crikey! Looks like I'll have to migrate to Maven then. When in Rome.

On Wed, 21 Apr 2021 at 19:20, John Burgess
 wrote:

> +1 also for me to not eliminating Ant support for new (or existing)
> projects.
>
> -Original Message-
> From: Marco Rossi 
> Sent: 20 April 2021 20:10
> To: Mitch Claborn 
> Cc: users@netbeans.apache.org
> Subject: Re: removing the "new project" support for Ant projects
>
> +1 also for me to not eliminating Ant support for new (or existing)
> projects.
>
> Mark Reds
>
> > Il giorno 20 apr 2021, alle ore 20:08, Mitch Claborn <
> mitch...@claborn.net> ha scritto:
> >
> > +1 for not eliminating Ant support for new (or existing) projects. We've
> been using Ant for a long time, and it still works just fine for us, so
> there is no payback in converting to Maven.
> >
> >
> > Mitch
> >
> > On 4/20/21 12:10 PM, Lisa Ruby wrote:
> >> For those of you who have used Maven for a long time it may seem simple
> and straightforward, but for those of us who haven't it's not. I've
> struggled to try and understand it and figure out how to use it for my
> software project and gave up. And it's a huge amount of overhead, extra
> disk space usage, and more bits and pieces to keep track of that isn't
> justifiable for small simple projects. ANT works just fine for me, and I
> will keep using it for as long as I possibly can. I need to focus my time
> on getting my software out, not on the tools I have to use to do it.
> >> Lisa
> >> On 4/20/2021 10:00 AM, Geertjan Wielenga wrote:
> >>> I agree, the Ant-based project creation should be removed and I
> disagree that there should be any kind of conversion between Ant and Maven
> -- that simply will never work and we'll spend the rest of our days fixing
> bugs in that. To convert from Ant to Maven: create a new Maven project and
> copy the Java source files from your Ant project into it.
> >>>
> >>> Gj
> >>>
> >>> On Tue, Apr 20, 2021 at 6:58 PM  pszud...@throwarock.com>> wrote:
> >>>
> >>>Honestly, I think NB should have an internal conversation about
> >>>removing the "new project" support for Ant projects, while still
> >>>being able to open existing ones. It just confuses a lot of people
> >>>if they're not going to be supported.
> >>>
> >>>I agree, if and ONLY if you provide at least a rudimentary way to
> >>>convert ANT projects to Maven projects.   I have been struggling
> >>>with this issue too long.  I have hundreds of Ant based projects
> >>>that I would love to turn over immediately to Maven... but I can't
> >>>, am struggling, and haven't coded a darn line in two months...  I
> >>>used to code 10 hours a day ... and now... embarrassed by my
> >>>inability to convert.,.
> >>>
> >>>I exaggerate a bit, I still code in "Old" Netbeans 8.2, but I know
> >>>the days are numbered...
> >>>
> >>>
> >>>
> >>>On 2021-04-20 08:23, Will Hartung wrote:
> >>>
> >>>>
> >>>>On Mon, Apr 19, 2021 at 12:55 AM Wayne Gemmell | Connect
> >>>>mailto:wa...@connect-mobile.co.za>>
> >>>>wrote:
> >>>>
> >>>>Is the perception that nobody does Maven EAR's anymore or
> >>>>that nobody uses EARs? I have a web app that has given me no
> >>>>shortage of issuse with ant.
> >>>>I'm trying to move it to Maven. If nobody is using maven then
> >>>>I need to move to something else. If nobody is using EAR's
> >>>>anymore then I'm pretty stuck figuring out this Maven issue.
> >>>>
> >>>>Well, it's several things.
> >>>>EARs are less popular because their necessity has been greatly
> >>>>reduced. Session beans can be placed in WARs now, so for many use
> >>>>cases, a WAR is completely adequate to the task.
> >>>>However, it's not suitable for all use cases.
> >>>>Notably, MDBs can not be deployed in WARs. But only as an EJB
> >>>>either deployed standalone, or bundled within an EAR.
> >>>>With the hue and cry over micro services and "down with the
> >>>>monolith", just the idea of a large application bundled in a EAR
> >>>>is falling out of favor.
> >>>>Also, the

RE: removing the "new project" support for Ant projects

[John Burgess]

+1 also for me to not eliminating Ant support for new (or existing) projects.

-Original Message-
From: Marco Rossi 
Sent: 20 April 2021 20:10
To: Mitch Claborn 
Cc: users@netbeans.apache.org
Subject: Re: removing the "new project" support for Ant projects

+1 also for me to not eliminating Ant support for new (or existing) projects.

Mark Reds

> Il giorno 20 apr 2021, alle ore 20:08, Mitch Claborn  
> ha scritto:
>
> +1 for not eliminating Ant support for new (or existing) projects. We've been 
> using Ant for a long time, and it still works just fine for us, so there is 
> no payback in converting to Maven.
>
>
> Mitch
>
> On 4/20/21 12:10 PM, Lisa Ruby wrote:
>> For those of you who have used Maven for a long time it may seem simple and 
>> straightforward, but for those of us who haven't it's not. I've struggled to 
>> try and understand it and figure out how to use it for my software project 
>> and gave up. And it's a huge amount of overhead, extra disk space usage, and 
>> more bits and pieces to keep track of that isn't justifiable for small 
>> simple projects. ANT works just fine for me, and I will keep using it for as 
>> long as I possibly can. I need to focus my time on getting my software out, 
>> not on the tools I have to use to do it.
>> Lisa
>> On 4/20/2021 10:00 AM, Geertjan Wielenga wrote:
>>> I agree, the Ant-based project creation should be removed and I disagree 
>>> that there should be any kind of conversion between Ant and Maven -- that 
>>> simply will never work and we'll spend the rest of our days fixing bugs in 
>>> that. To convert from Ant to Maven: create a new Maven project and copy the 
>>> Java source files from your Ant project into it.
>>>
>>> Gj
>>>
>>> On Tue, Apr 20, 2021 at 6:58 PM >> <mailto:pszud...@throwarock.com>> wrote:
>>>
>>>Honestly, I think NB should have an internal conversation about
>>>removing the "new project" support for Ant projects, while still
>>>being able to open existing ones. It just confuses a lot of people
>>>if they're not going to be supported.
>>>
>>>I agree, if and ONLY if you provide at least a rudimentary way to
>>>convert ANT projects to Maven projects.   I have been struggling
>>>with this issue too long.  I have hundreds of Ant based projects
>>>that I would love to turn over immediately to Maven... but I can't
>>>, am struggling, and haven't coded a darn line in two months...  I
>>>used to code 10 hours a day ... and now... embarrassed by my
>>>inability to convert.,.
>>>
>>>I exaggerate a bit, I still code in "Old" Netbeans 8.2, but I know
>>>the days are numbered...
>>>
>>>
>>>
>>>On 2021-04-20 08:23, Will Hartung wrote:
>>>
>>>>
>>>>On Mon, Apr 19, 2021 at 12:55 AM Wayne Gemmell | Connect
>>>>mailto:wa...@connect-mobile.co.za>>
>>>>wrote:
>>>>
>>>>Is the perception that nobody does Maven EAR's anymore or
>>>>that nobody uses EARs? I have a web app that has given me no
>>>>shortage of issuse with ant.
>>>>I'm trying to move it to Maven. If nobody is using maven then
>>>>I need to move to something else. If nobody is using EAR's
>>>>anymore then I'm pretty stuck figuring out this Maven issue.
>>>>
>>>>Well, it's several things.
>>>>EARs are less popular because their necessity has been greatly
>>>>reduced. Session beans can be placed in WARs now, so for many use
>>>>cases, a WAR is completely adequate to the task.
>>>>However, it's not suitable for all use cases.
>>>>Notably, MDBs can not be deployed in WARs. But only as an EJB
>>>>either deployed standalone, or bundled within an EAR.
>>>>With the hue and cry over micro services and "down with the
>>>>monolith", just the idea of a large application bundled in a EAR
>>>>is falling out of favor.
>>>>Also, there's a history of advocacy underlying this. Sun used
>>>>NetBeans as a mechanism to advocate for Java and Java EE. It
>>>>behooved them to have something like NetBeans to make Java EE
>>>>development easier. So, it was important for NetBeans to have
>>>>really first class Java EE support. Bundling the Java EE wizards
>>>>and templates along wit

RE: removing the "new project" support for Ant projects

[John Burgess]

Completely agree.  Ant works and doesn’t require you to write plugins just to 
customise the build process.

From: David 
Sent: 20 April 2021 23:04
To: Lisa Ruby ; users@netbeans.apache.org
Subject: Re: removing the "new project" support for Ant projects

+1!

On Tue, 2021-04-20 at 17:10 +, Lisa Ruby wrote:
For those of you who have used Maven for a long time it may seem simple and 
straightforward, but for those of us who haven't it's not. I've struggled to 
try and understand it and figure out how to use it for my software project and 
gave up. And it's a huge amount of overhead, extra disk space usage, and more 
bits and pieces to keep track of that isn't justifiable for small simple 
projects. ANT works just fine for me, and I will keep using it for as long as I 
possibly can. I need to focus my time on getting my software out, not on the 
tools I have to use to do it.

Lisa
On 4/20/2021 10:00 AM, Geertjan Wielenga wrote:
I agree, the Ant-based project creation should be removed and I disagree that 
there should be any kind of conversion between Ant and Maven -- that simply 
will never work and we'll spend the rest of our days fixing bugs in that. To 
convert from Ant to Maven: create a new Maven project and copy the Java source 
files from your Ant project into it.

Gj

On Tue, Apr 20, 2021 at 6:58 PM 
mailto:pszud...@throwarock.com>> wrote:

Honestly, I think NB should have an internal conversation about removing the 
"new project" support for Ant projects, while still being able to open existing 
ones. It just confuses a lot of people if they're not going to be supported.


I agree, if and ONLY if you provide at least a rudimentary way to convert ANT 
projects to Maven projects.   I have been struggling with this issue too long.  
I have hundreds of Ant based projects that I would love to turn over 
immediately to Maven... but I can't , am struggling, and haven't coded a darn 
line in two months...  I used to code 10 hours a day ... and now... embarrassed 
by my inability to convert.,.

I exaggerate a bit, I still code in "Old" Netbeans 8.2, but I know the days are 
numbered...





On 2021-04-20 08:23, Will Hartung wrote:


On Mon, Apr 19, 2021 at 12:55 AM Wayne Gemmell | Connect 
mailto:wa...@connect-mobile.co.za>> wrote:
Is the perception that nobody does Maven EAR's anymore or that nobody uses 
EARs? I have a web app that has given me no shortage of issuse with ant.
I'm trying to move it to Maven. If nobody is using maven then I need to move to 
something else. If nobody is using EAR's anymore then I'm pretty stuck figuring 
out this Maven issue.


Well, it's several things.

EARs are less popular because their necessity has been greatly reduced. Session 
beans can be placed in WARs now, so for many use cases, a WAR is completely 
adequate to the task.

However, it's not suitable for all use cases.

Notably, MDBs can not be deployed in WARs. But only as an EJB either deployed 
standalone, or bundled within an EAR.

With the hue and cry over micro services and "down with the monolith", just the 
idea of a large application bundled in a EAR is falling out of favor.

Also, there's a history of advocacy underlying this. Sun used NetBeans as a 
mechanism to advocate for Java and Java EE. It behooved them to have something 
like NetBeans to make Java EE development easier. So, it was important for 
NetBeans to have really first class Java EE support. Bundling the Java EE 
wizards and templates along with Glassfish all helped promote that.

Of course, now, with the great Java Diaspora out of Oracle, the goals and 
drivers are different.

For your project, if all you have is a web app and some session beans, then a 
simple WAR file is good to go. The Ant projects seem to essentially be 
deprecated now, so I would not rely on those for anything. If practical, 
especially if your project is young, I would migrate it to Maven. The Maven WAR 
is a pretty simple project and seems to work ok. Maven isn't going away any 
time soon, Gradle, it's primary competitor, doesn't really have the traction to 
overcome it yet, and it's been going for some time. If nothing else, the 
pom.xml file has become a de facto portable project format if, for nothing 
else, to capture dependencies.

Honestly, I think NB should have an internal conversation about removing the 
"new project" support for Ant projects, while still being able to open existing 
ones. It just confuses a lot of people if they're not going to be supported.

And I still haven't heard any concrete position the project has on 
internalizing Maven archetypes used for project wizards, or the process of 
adopting that.

Legacy archetypes that used to work in NB 8 are now failing because they've 
vanished from Maven central. So, an external dependency broke an internal 
feature.

Feel free to follow up with specific questions about getting your project to 
work and/or converted

Re: removing the "new project" support for Ant projects

[Emma Atkinson]

Surely the issue with any feature or function or tool is whether there is
sufficient Dev support to fix emerging bugs, properly adapt to latest
versions of Java lang, JFX, JLink etc and answer tricky questions from
users.

If Ant Dev expertise and time is getting harder to find it makes sense to
plan a migration to a new preferred build tool(s) for new projects and new
NB-IDE users.

Assuming an easy to use alternative is available, labelling Ant projects
legacy or deprecated might be all that is required for now.  Keep Ant
support running and when dev support availability falls behind the bleeding
edge put a warning somewhere obvious to users when creating new projects or
migrating to an unsupported versions of Java lang, JFX, Jlink etc.

Is Ant at that stage? I don't know because I don't develop often enough.
Any problems always come as a surprise. I take these problems, language
advances and the terminology that enters over time as the usual friction in
getting a quick programming job done.

Big thank you from me for all providing support.

On Wed, 21 Apr 2021, 08:26 Wayne Gemmell | Connect, <
wa...@connect-mobile.co.za> wrote:

> On Wed, 21 Apr 2021 at 06:32, Sean Carrick  wrote:
>
>> Actually, I have always been of the philosophy that "if it ain't broke,
>> don't fix it." This seems to be a philosophy lost in today's modern world.
>> Your comments show your bias toward always being on the bleeding edge of
>> technology. Personally, I do not care what anyone chooses to use for a
>> build tool or a programming language. What gets to me is that someone (or
>> group of someones) somewhere decides that a certain technology is "too
>> old", so they are wanting to kill it. It does not seem to matter that there
>> are hundreds, thousands, or millions of people who use that specific
>> technology throughout the world. They just decide it needs to be killed and
>> everyone should just get on-board with their decision.
>>
> Ant may not be broken but when something does go wrong it's almost
> impossible to debug. That said, it may be the obscure Netbeans
> implementation that is the issue, not Ant itself.
>
> Another issue is that you can't keep it in version control and deploy to
> multiple team members very easily. Minor filesystem differences make that
> sort of thing impossible to do out of the box.
>
> Searching out the correct version of a library when spinning up someone
> elses project is also ridicuiously difficult. Especially if the author
> included sim links instead of the actually jar name with the version in it.
>
> Being old school myself I remember getting a coffee while my 486 booted so
> as long as I expect Maven to take a while then it isn't an issue, not
> knowing you will need to wait is a bit disconcerting.
>
> All that said, I'm not actually advocating for Maven, I'm just at the
> "anything but Ant" point of my life. The hours I've spent dealing with that
> obscure crap are hours I can't get back.
>
> Wayne
>

Re: removing the "new project" support for Ant projects

[Thomas Kellerer]

Another +1 for NOT removing Ant support.

As far as the "New Project" dialog is concerned:

What about creating a new category "Other" (or maybe even "Legacy") that in 
turn contains the "Java with Ant" category to make the "Ant option" less 
prominent.

Just my 0.02€

Thomas

Marco Rossi schrieb am 20.04.2021 um 21:10:
> +1 also for me to not eliminating Ant support for new (or existing) projects.
>
> Mark Reds
>
>> Il giorno 20 apr 2021, alle ore 20:08, Mitch Claborn  
>> ha scritto:
>>
>> +1 for not eliminating Ant support for new (or existing) projects. We've 
>> been using Ant for a long time, and it still works just fine for us, so 
>> there is no payback in converting to Maven.
>>
>>
>> Mitch
>>
>> On 4/20/21 12:10 PM, Lisa Ruby wrote:
>>> For those of you who have used Maven for a long time it may seem simple and 
>>> straightforward, but for those of us who haven't it's not. I've struggled 
>>> to try and understand it and figure out how to use it for my software 
>>> project and gave up. And it's a huge amount of overhead, extra disk space 
>>> usage, and more bits and pieces to keep track of that isn't justifiable for 
>>> small simple projects. ANT works just fine for me, and I will keep using it 
>>> for as long as I possibly can. I need to focus my time on getting my 
>>> software out, not on the tools I have to use to do it.
>>> Lisa
>>> On 4/20/2021 10:00 AM, Geertjan Wielenga wrote:
>>>> I agree, the Ant-based project creation should be removed and I disagree 
>>>> that there should be any kind of conversion between Ant and Maven -- that 
>>>> simply will never work and we'll spend the rest of our days fixing bugs in 
>>>> that. To convert from Ant to Maven: create a new Maven project and copy 
>>>> the Java source files from your Ant project into it.
>>>>
>>>> Gj
>>>>
>>>> On Tue, Apr 20, 2021 at 6:58 PM >>> <mailto:pszud...@throwarock.com>> wrote:
>>>>
>>>>Honestly, I think NB should have an internal conversation about
>>>>removing the "new project" support for Ant projects, while still
>>>>being able to open existing ones. It just confuses a lot of people
>>>>if they're not going to be supported.
>>>>
>>>>I agree, if and ONLY if you provide at least a rudimentary way to
>>>>convert ANT projects to Maven projects.   I have been struggling
>>>>with this issue too long.  I have hundreds of Ant based projects
>>>>that I would love to turn over immediately to Maven... but I can't
>>>>, am struggling, and haven't coded a darn line in two months...  I
>>>>used to code 10 hours a day ... and now... embarrassed by my
>>>>inability to convert.,.
>>>>
>>>>I exaggerate a bit, I still code in "Old" Netbeans 8.2, but I know
>>>>the days are numbered...

-
To unsubscribe, e-mail: users-unsubscr...@netbeans.apache.org
For additional commands, e-mail: users-h...@netbeans.apache.org

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

Re: removing the "new project" support for Ant projects

[Bradley Willcott]

I agree with a lot of what has been said:

 * Deprecate ANT - New Project (don't remove)
 * Keep ANT for existing projects

Also, I agree that Maven can seem quite overwhelming at first.  I have 
been using it for only about a year now, and still remember the OMG 
experience when I first looked at Maven.  However, with a little 
persistence, and a lot of research, I was able to get past that.  IT WAS 
WORTH IT!  Maven is NOT "the be all and end all". But it does work.  I 
have been using it for many small projects, including my own libraries 
and a number of open source projects (https://github.com/bewillcott 
<https://github.com/bewillcott>).


My environment:

 * ASUS Laptop
 * I7
 * 12Gb RAM
 * 1 Tb SSD
 * Fedora Linux 32
 * JDK 15
 * NB 12.1

I first had a problem with the unpacking of the Maven index when I only 
had 4Gb RAM, as Linux was set-up with /tmp as a RAM Drive using only 1Gb 
of RAM.  However once I upgraded the RAM I had no further problems.  NB 
is set to update the Maven index once a week, so this is not a problem 
either.


The benefits of using Maven are as extensive as the Maven repository.  
Once you know what the dependencies are that you need, adding then is 
quite simple.  I believe that someone just starting out would greatly 
benefit from going straight into Maven, by-passing Ant altogether.  
Further, the process of converting existing projects would be of long 
term benefit, and would simplify the on-going support of the project.


I would like to offer my assistance in the conversion process - as an 
example/training exercise so that you will know how to do it yourself - 
"If you give a man a fish, he eats for a day; If you teach a man to 
fish, he eats for a lifetime."(# 
<https://www.phrases.org.uk/meanings/give-a-man-a-fish.html>).


Brad.

On 21/4/21 1:10 am, Lisa Ruby wrote:
For those of you who have used Maven for a long time it may seem 
simple and straightforward, but for those of us who haven't it's not. 
I've struggled to try and understand it and figure out how to use it 
for my software project and gave up. And it's a huge amount of 
overhead, extra disk space usage, and more bits and pieces to keep 
track of that isn't justifiable for small simple projects. ANT works 
just fine for me, and I will keep using it for as long as I possibly 
can. I need to focus my time on getting my software out, not on the 
tools I have to use to do it.


Lisa

On 4/20/2021 10:00 AM, Geertjan Wielenga wrote:
I agree, the Ant-based project creation should be removed and I 
disagree that there should be any kind of conversion between Ant and 
Maven -- that simply will never work and we'll spend the rest of our 
days fixing bugs in that. To convert from Ant to Maven: create a new 
Maven project and copy the Java source files from your Ant project 
into it.


Gj

On Tue, Apr 20, 2021 at 6:58 PM <mailto:pszud...@throwarock.com>> wrote:


Honestly, I think NB should have an internal conversation about
    removing the "new project" support for Ant projects, while still
being able to open existing ones. It just confuses a lot of
people if they're not going to be supported.

I agree, if and ONLY if you provide at least a rudimentary way to
convert ANT projects to Maven projects.   I have been struggling
with this issue too long.  I have hundreds of Ant based projects
that I would love to turn over immediately to Maven... but I
can't , am struggling, and haven't coded a darn line in two
months...  I used to code 10 hours a day ... and now...
embarrassed by my inability to convert.,.

I exaggerate a bit, I still code in "Old" Netbeans 8.2, but I
know the days are numbered...



On 2021-04-20 08:23, Will Hartung wrote:



On Mon, Apr 19, 2021 at 12:55 AM Wayne Gemmell | Connect
mailto:wa...@connect-mobile.co.za>>
wrote:

Is the perception that nobody does Maven EAR's anymore or
that nobody uses EARs? I have a web app that has given me no
shortage of issuse with ant.
I'm trying to move it to Maven. If nobody is using maven
then I need to move to something else. If nobody is using
EAR's anymore then I'm pretty stuck figuring out this Maven
issue.

Well, it's several things.
EARs are less popular because their necessity has been greatly
reduced. Session beans can be placed in WARs now, so for many
use cases, a WAR is completely adequate to the task.
However, it's not suitable for all use cases.
Notably, MDBs can not be deployed in WARs. But only as an EJB
either deployed standalone, or bundled within an EAR.
With the hue and cry over micro services and "down with the
monolith", just the idea of a large application bundled in a EAR
is falling out of favor.
Also, there's a history of advocacy underlying this. Sun used
NetBeans as a mechanism to advoca

Re: removing the "new project" support for Ant projects

[Owen Thomas]

I think Ant is lovely. Most of my projects only extend the Java SE API. I
don't see the need to change to a build tool that manages third party
libraries unless and until I need to use third party libraries.

Keep supporting Ant and keep the build process as trivial as it needs to be.

On Wed, 21 Apr 2021 at 15:56, Will Hartung  wrote:

>
>
> On Tue, Apr 20, 2021 at 9:32 PM Sean Carrick  wrote:
>
>> Explain to me, Scott, why I **need** to learn Maven and dump Ant. Ant
>> has served me very well all of these years and has never given me one
>> single bit of trouble. Speed? Ant is fast enough for me and my projects.
>> Keeping libraries "up-to-date"? That is just another way of saying "stay on
>> the bleeding edge." Why should I learn Maven and dump Ant? Explain it with
>> facts and reasoning, and without resorting to expressions such as "sticking
>> your head in the sand."
>>
>
> I have a project using JavaFX, JPA, CDI, and Derby. My pom.xml file lists
> 13 direct dependencies. The actual number of jars that get imported is
> closer to 50.
>
> There's a really cool project out there used to write REST based micro web
> services called dropwizard. To use it, you add a single dependency to you
> pom.xml.
>
> When your project builds, it downloads and imports about 90 other jar
> files.
>
> Nowhere on their site will you see this list of jar files that it requires
> to run.
>
> Using the IDE, with two mouse clicks, I can have not just the jars
> downloaded, but all of the available javadoc and source files. Once it's
> all caught up, I have access to all of that within the IDE.
>
> The key point is, that in the modern Java community, projects are shared
> using Maven artifacts. Many sites start their "quick start" instructions
> with "plop this dependency into your project file". From there, magic
> happens. Gradle relies on Maven repositories. Ivy for Ant relies on them
> also. I think there are other Java build tools that do also.
>
> Finally, NB, Eclipse, IDEA, and even Emacs all have first class support
> for Maven projects and pom files. With those pom files, all of the
> autocomplete works MUCH better, and painlessly. This works very well in
> offices with mixed development environments. Eclipse can not open a NB Ant
> project. NB can't open an IDEA project. All of them work with Maven
> projects.
>
> Maintaining the NB libraries is not a really big deal for small numbers of
> jar files. Even with a large number that's incrementally built up over
> time. But adding new projects with new dependencies that all have to be
> tracked down, I find, is a pain in the neck. I'm glad I didn't have to hunt
> down 90 dependencies to try a "hello world" dropwizard service. Now imagine
> updating the library lists across different IDE projects with different
> tools. As if teams don't have enough problems with communication and
> project drag.
>
> Maven absolutely has issues. It has innate complexity. It's slower than
> Ant for the basic Happy Path of building a project. It's reliance on
> internet connectivity sometimes has to be worked around. And any large team
> is better to jump through some hoops to set up a local repository as a
> cache and for local projects, which can be an infrastructure burden. But,
> that's it's big selling point. Maven scales much better than Ant does. And
> if you add Ivy to Ant, well, you have to deal with all of the Maven
> dependency burdens anyway.
>
> Let me give you one of my many experiences with Maven. I downloaded some
>> sample code today to see how someone was using a particular library. It
>> turned out that sample code was in a NB Maven project. I opened that
>> project at around 20:00, I just closed NB about 20 minutes ago. The whole
>> time, Maven was doing something, supposedly in the background, but it had
>> my CPUs up at 68% use and my memory at 82%. I have a Quadcore providing 8
>> threads and 8 GiB of RAM. There is absolutely no reason that Maven should
>> have been pegging my system out like that for the simple little project
>> that I had opened. Ant certainly never does that to my system.
>>
> This is quite likely the very large repository index that NB uses being
> downloaded from Maven Central. This is absolutely a potential pain point. I
> don't have a good solution to work around it. My machine stays on (sleeps)
> 24x7, and I leave NB open all the time. NB will update that index once a
> week if you let it, and it's not an incremental update, it's a complete
> reload. You can disable it after the first time, and trigger the update
> manually. As I said before, I've relaunched at lunch time or before I leave
> work in the afternoon to let this happen on its own time, and not blocking
> me. It also bloats your NB directories. If you have your NB 12.0, 12.1,
> 12.2, 12.3 versions, they all have their own copy of the index. That's
> several GB of data, likely useless in the old version directories. NB
> eventually detects and helps you clean those up, but 

Re: removing the "new project" support for Ant projects

[Will Hartung]

On Tue, Apr 20, 2021 at 9:32 PM Sean Carrick  wrote:

> Explain to me, Scott, why I **need** to learn Maven and dump Ant. Ant has
> served me very well all of these years and has never given me one single
> bit of trouble. Speed? Ant is fast enough for me and my projects. Keeping
> libraries "up-to-date"? That is just another way of saying "stay on the
> bleeding edge." Why should I learn Maven and dump Ant? Explain it with
> facts and reasoning, and without resorting to expressions such as "sticking
> your head in the sand."
>

I have a project using JavaFX, JPA, CDI, and Derby. My pom.xml file lists
13 direct dependencies. The actual number of jars that get imported is
closer to 50.

There's a really cool project out there used to write REST based micro web
services called dropwizard. To use it, you add a single dependency to you
pom.xml.

When your project builds, it downloads and imports about 90 other jar files.

Nowhere on their site will you see this list of jar files that it requires
to run.

Using the IDE, with two mouse clicks, I can have not just the jars
downloaded, but all of the available javadoc and source files. Once it's
all caught up, I have access to all of that within the IDE.

The key point is, that in the modern Java community, projects are shared
using Maven artifacts. Many sites start their "quick start" instructions
with "plop this dependency into your project file". From there, magic
happens. Gradle relies on Maven repositories. Ivy for Ant relies on them
also. I think there are other Java build tools that do also.

Finally, NB, Eclipse, IDEA, and even Emacs all have first class support for
Maven projects and pom files. With those pom files, all of the autocomplete
works MUCH better, and painlessly. This works very well in offices with
mixed development environments. Eclipse can not open a NB Ant project. NB
can't open an IDEA project. All of them work with Maven projects.

Maintaining the NB libraries is not a really big deal for small numbers of
jar files. Even with a large number that's incrementally built up over
time. But adding new projects with new dependencies that all have to be
tracked down, I find, is a pain in the neck. I'm glad I didn't have to hunt
down 90 dependencies to try a "hello world" dropwizard service. Now imagine
updating the library lists across different IDE projects with different
tools. As if teams don't have enough problems with communication and
project drag.

Maven absolutely has issues. It has innate complexity. It's slower than Ant
for the basic Happy Path of building a project. It's reliance on internet
connectivity sometimes has to be worked around. And any large team is
better to jump through some hoops to set up a local repository as a cache
and for local projects, which can be an infrastructure burden. But, that's
it's big selling point. Maven scales much better than Ant does. And if you
add Ivy to Ant, well, you have to deal with all of the Maven dependency
burdens anyway.

Let me give you one of my many experiences with Maven. I downloaded some
> sample code today to see how someone was using a particular library. It
> turned out that sample code was in a NB Maven project. I opened that
> project at around 20:00, I just closed NB about 20 minutes ago. The whole
> time, Maven was doing something, supposedly in the background, but it had
> my CPUs up at 68% use and my memory at 82%. I have a Quadcore providing 8
> threads and 8 GiB of RAM. There is absolutely no reason that Maven should
> have been pegging my system out like that for the simple little project
> that I had opened. Ant certainly never does that to my system.
>
This is quite likely the very large repository index that NB uses being
downloaded from Maven Central. This is absolutely a potential pain point. I
don't have a good solution to work around it. My machine stays on (sleeps)
24x7, and I leave NB open all the time. NB will update that index once a
week if you let it, and it's not an incremental update, it's a complete
reload. You can disable it after the first time, and trigger the update
manually. As I said before, I've relaunched at lunch time or before I leave
work in the afternoon to let this happen on its own time, and not blocking
me. It also bloats your NB directories. If you have your NB 12.0, 12.1,
12.2, 12.3 versions, they all have their own copy of the index. That's
several GB of data, likely useless in the old version directories. NB
eventually detects and helps you clean those up, but something to be aware
of if disk space is an issue.

> To me, it seems that more people are drawn to Maven because it tries to
> take care of library management for you. However, any developer worth their
> salt believes on managing that kind of thing by themselves. I have been
> programming since 1983 and remember the days when a compiler was an actual
> person who gathered shared libraries from various locations and manually
> linked them to your application, so that your 

Re: removing the "new project" support for Ant projects

[Sean Carrick]

It is precisely because you want to focus on getting your software
out that you *need* to learn the modern tools for doing so. Your
Gradle project file could literally be one line, depending on your
needs. Maven is certainly more verbose (My preference is Gradle),
but the project setup is still usually a single command that will
write a basic pom.xml file for you. Either of those tools is a step
up. Sticking your head in the sand and pretending you can stick with
Ant forever is not the way to go. I get that “it works for you now”.
But this discussion is a perfect example of how that will change on you.

Actually, I have always been of the philosophy that "if it ain't broke,
don't fix it." This seems to be a philosophy lost in today's modern
world. Your comments show your bias toward always being on the bleeding
edge of technology. Personally, I do not care what anyone chooses to use
for a build tool or a programming language. What gets to me is that
someone (or group of someones) somewhere decides that a certain
technology is "too old", so they are wanting to kill it. It does not
seem to matter that there are hundreds, thousands, or millions of people
who use that specific technology throughout the world. They just decide
it needs to be killed and everyone should just get on-board with their
decision.

Explain to me, Scott, why I **need** to learn Maven and dump Ant. Ant
has served me very well all of these years and has never given me one
single bit of trouble. Speed? Ant is fast enough for me and my projects.
Keeping libraries "up-to-date"? That is just another way of saying "stay
on the bleeding edge." Why should I learn Maven and dump Ant? Explain it
with facts and reasoning, and without resorting to expressions such as
"sticking your head in the sand."

Let me give you one of my many experiences with Maven. I downloaded some
sample code today to see how someone was using a particular library. It
turned out that sample code was in a NB Maven project. I opened that
project at around 20:00, I just closed NB about 20 minutes ago. The
whole time, Maven was doing something, supposedly in the background, but
it had my CPUs up at 68% use and my memory at 82%. I have a Quadcore
providing 8 threads and 8 GiB of RAM. There is absolutely no reason that
Maven should have been pegging my system out like that for the simple
little project that I had opened. Ant certainly never does that to my
system.

To me, it seems that more people are drawn to Maven because it tries to
take care of library management for you. However, any developer worth
their salt believes on managing that kind of thing by themselves. I have
been programming since 1983 and remember the days when a compiler was an
actual person who gathered shared libraries from various locations and
manually linked them to your application, so that your application would
work properly. I do not shun all advances in technology, but when
something is as stable and useful as Ant, I just don't get why some
people just want it gone. I use automation systems whenever they make
sense for me. A lot of things, I would rather take care of myself so
that I can be sure the stuff is the way I planned it and want it. Old
school, I know, but I am who I am...

-SC

Re: removing the "new project" support for Ant projects

[Carl Mosca]

On what I hope is a lighter note...I recall being in a session at a JavaOne
years ago when a presenter asked if we knew the difference between Ant and
Maven.

The answer was "the guy who created Ant apologized".  (Recall that maven
was a bit slow in the early days when it was just getting popular.)

I thought it was as funny as it was intended at the time (and I still do).
It also reminds me of 1. it used to be called JavaOne and 2. I do miss
in-person conferences a bit.

FWIW, I don't hate Ant, Maven, or Gradle (but I have used Maven more than
the other two.)

Certainly, ant was very popular but moving to maven (or gradle) can
certainly be done.

Was hoping a bit of levity/good memories might be appreciated. :)

Happy coding.

On Tue, Apr 20, 2021 at 9:38 PM Scott Palmer  wrote:

>
> > On Apr 20, 2021, at 1:10 PM, Lisa Ruby 
> wrote:
> >
> >  For those of you who have used Maven for a long time it may seem
> simple and straightforward, but for those of us who haven't it's not. I've
> struggled to try and understand it and figure out how to use it for my
> software project and gave up. And it's a huge amount of overhead, extra
> disk space usage, and more bits and pieces to keep track of that isn't
> justifiable for small simple projects. ANT works just fine for me, and I
> will keep using it for as long as I possibly can. I need to focus my time
> on getting my software out, not on the tools I have to use to do it.
> >
> > Lisa
>
> It is precisely because you want to focus on getting your software out
> that you *need* to learn the modern tools for doing so.
>
> Your Gradle project file could literally be one line, depending on your
> needs.
>
> Maven is certainly more verbose (My preference is Gradle), but the project
> setup is still usually a single command that will write a basic pom.xml
> file for you.
>
> Either of those tools is a step up. Sticking your head in the sand and
> pretending you can stick with Ant forever is not the way to go.
>
> I get that “it works for you now”. But this discussion is a perfect
> example of how that will change on you.
>
> Cheers,
>
> Scott
>
>
> -
> To unsubscribe, e-mail: users-unsubscr...@netbeans.apache.org
> For additional commands, e-mail: users-h...@netbeans.apache.org
>
> For further information about the NetBeans mailing lists, visit:
> https://cwiki.apache.org/confluence/display/NETBEANS/Mailing+lists
>
>

-- 
Carl J. Mosca

Re: removing the "new project" support for Ant projects

[Scott Palmer]

> On Apr 20, 2021, at 1:10 PM, Lisa Ruby  wrote:
> 
>  For those of you who have used Maven for a long time it may seem simple and 
> straightforward, but for those of us who haven't it's not. I've struggled to 
> try and understand it and figure out how to use it for my software project 
> and gave up. And it's a huge amount of overhead, extra disk space usage, and 
> more bits and pieces to keep track of that isn't justifiable for small simple 
> projects. ANT works just fine for me, and I will keep using it for as long as 
> I possibly can. I need to focus my time on getting my software out, not on 
> the tools I have to use to do it. 
> 
> Lisa 

It is precisely because you want to focus on getting your software out that you 
*need* to learn the modern tools for doing so. 

Your Gradle project file could literally be one line, depending on your needs. 

Maven is certainly more verbose (My preference is Gradle), but the project 
setup is still usually a single command that will write a basic pom.xml file 
for you. 

Either of those tools is a step up. Sticking your head in the sand and 
pretending you can stick with Ant forever is not the way to go. 

I get that “it works for you now”. But this discussion is a perfect example of 
how that will change on you. 

Cheers,

Scott


-
To unsubscribe, e-mail: users-unsubscr...@netbeans.apache.org
For additional commands, e-mail: users-h...@netbeans.apache.org

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

Re: Re: removing the "new project" support for Ant projects

[Eric Bresie]

gt; > > > +1 also for me to not eliminating Ant support for new (or existing) 
> > > > > projects.
> > > > >
> > > > > Mark Reds
> > > > >
> > > > > > Il giorno 20 apr 2021, alle ore 20:08 
> > > > > > (x-apple-data-detectors://11), Mitch Claborn  > > > > > (mailto:mitch...@claborn.net)> ha scritto:
> > > > > >
> > > > > > +1 for not eliminating Ant support for new (or existing) projects. 
> > > > > > We've been using Ant for a long time, and it still works just fine 
> > > > > > for us, so there is no payback in converting to Maven.
> > > > > >
> > > > > >
> > > > > > Mitch
> > > > > >
> > > > > > On 4/20/21 12:10 PM, Lisa Ruby wrote:
> > > > > > > For those of you who have used Maven for a long time it may seem 
> > > > > > > simple and straightforward, but for those of us who haven't it's 
> > > > > > > not. I've struggled to try and understand it and figure out how 
> > > > > > > to use it for my software project and gave up. And it's a huge 
> > > > > > > amount of overhead, extra disk space usage, and more bits and 
> > > > > > > pieces to keep track of that isn't justifiable for small simple 
> > > > > > > projects. ANT works just fine for me, and I will keep using it 
> > > > > > > for as long as I possibly can. I need to focus my time on getting 
> > > > > > > my software out, not on the tools I have to use to do it.
> > > > > > > Lisa
> > > > > > > On 4/20/2021 10:00 AM, Geertjan Wielenga wrote:
> > > > > > >> I agree, the Ant-based project creation should be removed and I 
> > > > > > >> disagree that there should be any kind of conversion between Ant 
> > > > > > >> and Maven -- that simply will never work and we'll spend the 
> > > > > > >> rest of our days fixing bugs in that. To convert from Ant to 
> > > > > > >> Maven: create a new Maven project and copy the Java source files 
> > > > > > >> from your Ant project into it.
> > > > > > >>
> > > > > > >> Gj
> > > > > > >>
> > > > > > >> On Tue, Apr 20, 2021 at 6:58 PM  > > > > > >> (mailto:pszud...@throwarock.com) 
> > > > > > >> <mailto:pszud...@throwarock.com>> wrote:
> > > > > > >>
> > > > > > >> Honestly, I think NB should have an internal conversation about
> > > > > > >> removing the "new project" support for Ant projects, while still
> > > > > > >> being able to open existing ones. It just confuses a lot of 
> > > > > > >> people
> > > > > > >> if they're not going to be supported.
> > > > > > >>
> > > > > > >> I agree, if and ONLY if you provide at least a rudimentary way to
> > > > > > >> convert ANT projects to Maven projects. I have been struggling
> > > > > > >> with this issue too long. I have hundreds of Ant based projects
> > > > > > >> that I would love to turn over immediately to Maven... but I 
> > > > > > >> can't
> > > > > > >> , am struggling, and haven't coded a darn line in two months... I
> > > > > > >> used to code 10 hours a day ... and now... embarrassed by my
> > > > > > >> inability to convert.,.
> > > > > > >>
> > > > > > >> I exaggerate a bit, I still code in "Old" Netbeans 8.2, but I 
> > > > > > >> know
> > > > > > >> the days are numbered...
> > > > > > >>
> > > > > > >>
> > > > > > >>
> > > > > > >> On 2021-04-20 08:23, Will Hartung wrote:
> > > > > > >>
> > > > > > >>>
> > > > > > >>> On Mon, Apr 19, 2021 at 12:55 AM Wayne Gemmell | Connect
> > > > > > >>> mailto:wa...@connect-mobile.co.za) 
> > > > > > >>> <mailto:wa...@connect-mobile.co.za>>
> > > > > > >>> wrote:
> > > > > > >>>
> > &

Re: removing the "new project" support for Ant projects

[Emilio Gallardo Cantella]

warock.com>
<mailto:pszud...@throwarock.com
<mailto:pszud...@throwarock.com>>> wrote:
    >>
    >>    Honestly, I think NB should have an internal
conversation about
>>    removing the "new project" support for Ant projects,
while still
>>    being able to open existing ones. It just confuses a
lot of people
>>    if they're not going to be supported.
>>
>>    I agree, if and ONLY if you provide at least a
rudimentary way to
>>    convert ANT projects to Maven projects.   I have been
struggling
>>    with this issue too long.  I have hundreds of Ant
based projects
>>    that I would love to turn over immediately to Maven...
but I can't
>>    , am struggling, and haven't coded a darn line in two
months...  I
>>    used to code 10 hours a day ... and now... embarrassed
by my
>>    inability to convert.,.
>>
>>    I exaggerate a bit, I still code in "Old" Netbeans
8.2, but I know
>>    the days are numbered...
>>
>>
>>
>>    On 2021-04-20 08:23, Will Hartung wrote:
>>
>>>
>>>    On Mon, Apr 19, 2021 at 12:55 AM Wayne Gemmell | Connect
>>>    mailto:wa...@connect-mobile.co.za>
<mailto:wa...@connect-mobile.co.za
<mailto:wa...@connect-mobile.co.za>>>
>>>    wrote:
>>>
>>>    Is the perception that nobody does Maven EAR's
anymore or
>>>    that nobody uses EARs? I have a web app that has
given me no
>>>    shortage of issuse with ant.
>>>    I'm trying to move it to Maven. If nobody is
using maven then
>>>    I need to move to something else. If nobody is
using EAR's
>>>    anymore then I'm pretty stuck figuring out this
Maven issue.
>>>
>>>    Well, it's several things.
>>>    EARs are less popular because their necessity has
been greatly
>>>    reduced. Session beans can be placed in WARs now, so
for many use
>>>    cases, a WAR is completely adequate to the task.
>>>    However, it's not suitable for all use cases.
>>>    Notably, MDBs can not be deployed in WARs. But only
as an EJB
>>>    either deployed standalone, or bundled within an EAR.
>>>    With the hue and cry over micro services and "down
with the
>>>    monolith", just the idea of a large application
bundled in a EAR
>>>    is falling out of favor.
>>>    Also, there's a history of advocacy underlying this.
Sun used
>>>    NetBeans as a mechanism to advocate for Java and Java
EE. It
>>>    behooved them to have something like NetBeans to make
Java EE
>>>    development easier. So, it was important for NetBeans
to have
>>>    really first class Java EE support. Bundling the Java
EE wizards
>>>    and templates along with Glassfish all helped promote
that.
>>>    Of course, now, with the great Java Diaspora out of
Oracle, the
>>>    goals and drivers are different.
>>>    For your project, if all you have is a web app and
some session
>>>    beans, then a simple WAR file is good to go. The Ant
projects
>>>    seem to essentially be deprecated now, so I would not
rely on
>>>    those for anything. If practical, especially if your
project is
>>>    young, I would migrate it to Maven. The Maven WAR is
a pretty
>>>    simple project and seems to work ok. Maven isn't
going away any
>>>    time soon, Gradle, it's primary competitor, doesn't
really have
>>>    the traction to overcome it yet, and it's been going
for some
>>>    time. If nothing else, the pom.xml file has become a
de facto
>>>    portable project format if, for nothing else, to capture
>>>    dependencies.
>>>    Honestly, I think NB should have an internal
conversation about
>>>    removing the "new project" support for Ant projects,
while still
>

Re: removing the "new project" support for Ant projects

[Sean Carrick]

GJ,

My apologies! It seems I kicked off more than I expected with my
comments. Feel free to slap me if you ever see me...

-SC

On 4/20/21 2:33 PM, Geertjan Wielenga wrote:
> No one is suggesting removing support for Ant altogether.
>
> The suggestion is to remove the possibility of creating new Ant projects.
>
> Gj
>
> On Tue, 20 Apr 2021 at 21:32, Thomas Wolf  <mailto:tjw...@gmail.com>> wrote:
>
> +1 for not removing ant support for me as well.  I’m admittedly an
> old-timer.  My first exposure to a ‘modern’ build tool was on my
> last job - the company used gradle.  With a background in make and
> ant, I found its syntax hard to grok.    NB devs clearly like
> Maven - its syntax seems straight-forward enough, but the tool
> seems relatively slow and if you have an existing ant-based
> project whose directory structure doesn’t match maven’s desired
> one, moving to maven may not be as straight forward as some
> suggest.  And, how is the uptake of Ivy?  Isn’t that (in
> combination with ant) considered a modern build tool?  If NB
> removes support for ant altogether, it would not be able to handle
> ivy-based projects, no?
>
> tom
>
>
> On Apr 20, 2021 at 3:10:04 PM, Marco Rossi  <mailto:ma...@markreds.it>> wrote:
>
> +1 also for me to not eliminating Ant support for new (or
> existing) projects.
>
> Mark Reds
>
>> Il giorno 20 apr 2021, alle ore 20:08, Mitch Claborn
>> mailto:mitch...@claborn.net>> ha scritto:
>>
>> +1 for not eliminating Ant support for new (or existing)
>> projects. We've been using Ant for a long time, and it still
>> works just fine for us, so there is no payback in converting
>> to Maven.
>>
>>
>> Mitch
>>
>> On 4/20/21 12:10 PM, Lisa Ruby wrote:
>> > For those of you who have used Maven for a long time it may
>> seem simple and straightforward, but for those of us who
>> haven't it's not. I've struggled to try and understand it and
>> figure out how to use it for my software project and gave up.
>> And it's a huge amount of overhead, extra disk space usage,
>> and more bits and pieces to keep track of that isn't
>> justifiable for small simple projects. ANT works just fine
>> for me, and I will keep using it for as long as I possibly
>> can. I need to focus my time on getting my software out, not
>> on the tools I have to use to do it.
>> > Lisa
>> > On 4/20/2021 10:00 AM, Geertjan Wielenga wrote:
>> >> I agree, the Ant-based project creation should be removed
>> and I disagree that there should be any kind of conversion
>> between Ant and Maven -- that simply will never work and
>> we'll spend the rest of our days fixing bugs in that. To
>> convert from Ant to Maven: create a new Maven project and
>> copy the Java source files from your Ant project into it.
>> >>
>>     >> Gj
>>     >>
>>     >> On Tue, Apr 20, 2021 at 6:58 PM > <mailto:pszud...@throwarock.com>
>> <mailto:pszud...@throwarock.com
>> <mailto:pszud...@throwarock.com>>> wrote:
>> >>
>> >>    Honestly, I think NB should have an internal
>> conversation about
>> >>    removing the "new project" support for Ant projects,
>> while still
>> >>    being able to open existing ones. It just confuses a
>> lot of people
>> >>    if they're not going to be supported.
>> >>
>> >>    I agree, if and ONLY if you provide at least a
>> rudimentary way to
>> >>    convert ANT projects to Maven projects.   I have been
>> struggling
>> >>    with this issue too long.  I have hundreds of Ant based
>> projects
>> >>    that I would love to turn over immediately to Maven...
>> but I can't
>> >>    , am struggling, and haven't coded a darn line in two
>> months...  I
>> >>    used to code 10 hours a day ... and now... embarrassed
>> by my
>> >>    inability to convert.,.
>> >>
>> >>    I exaggerate a bit, I still code in "Old" Netbeans 8.2,
>> but I know
>>  

Re: removing the "new project" support for Ant projects

[David]

+1!

On Tue, 2021-04-20 at 17:10 +, Lisa Ruby wrote:
> 
> For those of you who have used Maven for a long time it may seem
> simple and straightforward, but for those of us who haven't it's
> not. I've struggled to try and understand it and figure out how
> to
> use it for my software project and gave up. And it's a huge
> amount
> of overhead, extra disk space usage, and more bits and pieces to
> keep track of that isn't justifiable for small simple projects.
> ANT
> works just fine for me, and I will keep using it for as long as I
> possibly can. I need to focus my time on getting my software out,
> not on the tools I have to use to do it. 
> 
> 
> 
> Lisa 
> 
> 
> 
> On 4/20/2021 10:00 AM, Geertjan
>   Wielenga wrote:
> 
> 
> 
> >   
> >   I agree, the Ant-based project creation should be
> > removed and I disagree that there should be any kind of
> > conversion between Ant and Maven -- that simply will never
> > work
> > and we'll spend the rest of our days fixing bugs in that.
> > To
> > convert from Ant to Maven: create a new Maven project and
> > copy
> > the Java source files from your Ant project into it.
> > 
> > 
> > 
> > Gj
> >   
> >   
> > 
> >   
> > On Tue, Apr 20, 2021 at 6:58
> >   PM 
> >   wrote:
> > 
> >     
> > 
> > >   
> > > Honestly, I think NB
> > > should have an internal conversation about
> > > removing the
> > > "new project" support for Ant projects, while
> > > still
> > > being able to open existing ones. It just
> > > confuses a lot
> > > of people if they're not going to be supported.
> > >  
> > > I agree, if and ONLY if you provide at least a
> > >   rudimentary way to convert ANT projects to Maven
> > >   projects.   I have been struggling with this issue
> > > too
> > >   long.  I have hundreds of Ant based projects that I
> > > would
> > >   love to turn over immediately to Maven... but I
> > > can't , am
> > >   struggling, and haven't coded a darn line in two
> > >   months...  I used to code 10 hours a day ... and
> > > now...
> > >   embarrassed by my inability to convert.,.
> > > I exaggerate a bit, I still code in "Old" Netbeans
> > > 8.2,
> > >   but I know the days are numbered...
> > > 
> > > 
> > > 
> > > 
> > > 
> > > 
> > > On 2021-04-20 08:23, Will Hartung wrote:
> > > 
> > > >   
> > > >  
> > > > 
> > > > 
> > > > 
> > > >   On Mon, Apr 19, 2021
> > > > at 12:55 AM Wayne Gemmell | Connect <
> > > > wa...@connect-mobile.co.za>
> > > > wrote:
> > > >   
> > > > > Is the perception that nobody does
> > > > >   Maven EAR's anymore or that nobody uses
> > > > > EARs? I
> > > > >   have a web app that has given me no
> > > > > shortage of
> > > > >   issuse with ant. 
> > > > >   I'm trying to move it to Maven. If
> > > > > nobody is
> > > > > using maven then I need to move to
> > > > > something
> > > > > else. If nobody is using EAR's
> > > > > anymore then I'm
> > > > > pretty stuck figuring out this Maven
> > > > > issue. 
> > > > > 
> > > > >   
> > > > 
> > > >
> > > >   Well, it's several things.
> > > >
> > > >   EARs are less popular because their necessity
> > > > has
> > > > been greatl

Re: removing the "new project" support for Ant projects

[Wayne Gemmell | Connect]

A compromise could be just to have Ant projects marked as depricated and to
have a working alternative.

Wayne

On Tue, 20 Apr 2021 at 21:33, Geertjan Wielenga
 wrote:

> No one is suggesting removing support for Ant altogether.
>
> The suggestion is to remove the possibility of creating new Ant projects.
>
> Gj
>
> On Tue, 20 Apr 2021 at 21:32, Thomas Wolf  wrote:
>
>> +1 for not removing ant support for me as well.  I’m admittedly an
>> old-timer.  My first exposure to a ‘modern’ build tool was on my last job -
>> the company used gradle.  With a background in make and ant, I found its
>> syntax hard to grok.NB devs clearly like Maven - its syntax seems
>> straight-forward enough, but the tool seems relatively slow and if you have
>> an existing ant-based project whose directory structure doesn’t match
>> maven’s desired one, moving to maven may not be as straight forward as some
>> suggest.  And, how is the uptake of Ivy?  Isn’t that (in combination with
>> ant) considered a modern build tool?  If NB removes support for ant
>> altogether, it would not be able to handle ivy-based projects, no?
>>
>> tom
>>
>>
>> On Apr 20, 2021 at 3:10:04 PM, Marco Rossi  wrote:
>>
>>> +1 also for me to not eliminating Ant support for new (or existing)
>>> projects.
>>>
>>> Mark Reds
>>>
>>> Il giorno 20 apr 2021, alle ore 20:08, Mitch Claborn <
>>> mitch...@claborn.net> ha scritto:
>>>
>>>
>>> +1 for not eliminating Ant support for new (or existing) projects. We've
>>> been using Ant for a long time, and it still works just fine for us, so
>>> there is no payback in converting to Maven.
>>>
>>>
>>>
>>> Mitch
>>>
>>>
>>> On 4/20/21 12:10 PM, Lisa Ruby wrote:
>>>
>>> > For those of you who have used Maven for a long time it may seem
>>> simple and straightforward, but for those of us who haven't it's not. I've
>>> struggled to try and understand it and figure out how to use it for my
>>> software project and gave up. And it's a huge amount of overhead, extra
>>> disk space usage, and more bits and pieces to keep track of that isn't
>>> justifiable for small simple projects. ANT works just fine for me, and I
>>> will keep using it for as long as I possibly can. I need to focus my time
>>> on getting my software out, not on the tools I have to use to do it.
>>>
>>> > Lisa
>>>
>>> > On 4/20/2021 10:00 AM, Geertjan Wielenga wrote:
>>>
>>> >> I agree, the Ant-based project creation should be removed and I
>>> disagree that there should be any kind of conversion between Ant and Maven
>>> -- that simply will never work and we'll spend the rest of our days fixing
>>> bugs in that. To convert from Ant to Maven: create a new Maven project and
>>> copy the Java source files from your Ant project into it.
>>>
>>> >>
>>>
>>> >> Gj
>>>
>>> >>
>>>
>>> >> On Tue, Apr 20, 2021 at 6:58 PM >> pszud...@throwarock.com>> wrote:
>>>
>>> >>
>>>
>>> >>Honestly, I think NB should have an internal conversation about
>>>
>>> >>removing the "new project" support for Ant projects, while still
>>>
>>> >>being able to open existing ones. It just confuses a lot of people
>>>
>>> >>if they're not going to be supported.
>>>
>>> >>
>>>
>>> >>I agree, if and ONLY if you provide at least a rudimentary way to
>>>
>>> >>convert ANT projects to Maven projects.   I have been struggling
>>>
>>> >>with this issue too long.  I have hundreds of Ant based projects
>>>
>>> >>that I would love to turn over immediately to Maven... but I can't
>>>
>>> >>, am struggling, and haven't coded a darn line in two months...  I
>>>
>>> >>used to code 10 hours a day ... and now... embarrassed by my
>>>
>>> >>inability to convert.,.
>>>
>>> >>
>>>
>>> >>I exaggerate a bit, I still code in "Old" Netbeans 8.2, but I know
>>>
>>> >>the days are numbered...
>>>
>>> >>
>>>
>>> >>
>>>
>>> >>
>>>
>>> >>On 2021-04-20 08:23, Will Hartung wrote:
>>>
&g

Re: removing the "new project" support for Ant projects

[Geertjan Wielenga]

No one is suggesting removing support for Ant altogether.

The suggestion is to remove the possibility of creating new Ant projects.

Gj

On Tue, 20 Apr 2021 at 21:32, Thomas Wolf  wrote:

> +1 for not removing ant support for me as well.  I’m admittedly an
> old-timer.  My first exposure to a ‘modern’ build tool was on my last job -
> the company used gradle.  With a background in make and ant, I found its
> syntax hard to grok.NB devs clearly like Maven - its syntax seems
> straight-forward enough, but the tool seems relatively slow and if you have
> an existing ant-based project whose directory structure doesn’t match
> maven’s desired one, moving to maven may not be as straight forward as some
> suggest.  And, how is the uptake of Ivy?  Isn’t that (in combination with
> ant) considered a modern build tool?  If NB removes support for ant
> altogether, it would not be able to handle ivy-based projects, no?
>
> tom
>
>
> On Apr 20, 2021 at 3:10:04 PM, Marco Rossi  wrote:
>
>> +1 also for me to not eliminating Ant support for new (or existing)
>> projects.
>>
>> Mark Reds
>>
>> Il giorno 20 apr 2021, alle ore 20:08, Mitch Claborn <
>> mitch...@claborn.net> ha scritto:
>>
>>
>> +1 for not eliminating Ant support for new (or existing) projects. We've
>> been using Ant for a long time, and it still works just fine for us, so
>> there is no payback in converting to Maven.
>>
>>
>>
>> Mitch
>>
>>
>> On 4/20/21 12:10 PM, Lisa Ruby wrote:
>>
>> > For those of you who have used Maven for a long time it may seem simple
>> and straightforward, but for those of us who haven't it's not. I've
>> struggled to try and understand it and figure out how to use it for my
>> software project and gave up. And it's a huge amount of overhead, extra
>> disk space usage, and more bits and pieces to keep track of that isn't
>> justifiable for small simple projects. ANT works just fine for me, and I
>> will keep using it for as long as I possibly can. I need to focus my time
>> on getting my software out, not on the tools I have to use to do it.
>>
>> > Lisa
>>
>> > On 4/20/2021 10:00 AM, Geertjan Wielenga wrote:
>>
>> >> I agree, the Ant-based project creation should be removed and I
>> disagree that there should be any kind of conversion between Ant and Maven
>> -- that simply will never work and we'll spend the rest of our days fixing
>> bugs in that. To convert from Ant to Maven: create a new Maven project and
>> copy the Java source files from your Ant project into it.
>>
>> >>
>>
>> >> Gj
>>
>> >>
>>
>> >> On Tue, Apr 20, 2021 at 6:58 PM > pszud...@throwarock.com>> wrote:
>>
>> >>
>>
>> >>Honestly, I think NB should have an internal conversation about
>>
>> >>removing the "new project" support for Ant projects, while still
>>
>> >>being able to open existing ones. It just confuses a lot of people
>>
>> >>if they're not going to be supported.
>>
>> >>
>>
>> >>I agree, if and ONLY if you provide at least a rudimentary way to
>>
>> >>convert ANT projects to Maven projects.   I have been struggling
>>
>> >>with this issue too long.  I have hundreds of Ant based projects
>>
>> >>that I would love to turn over immediately to Maven... but I can't
>>
>> >>, am struggling, and haven't coded a darn line in two months...  I
>>
>> >>used to code 10 hours a day ... and now... embarrassed by my
>>
>> >>inability to convert.,.
>>
>> >>
>>
>> >>I exaggerate a bit, I still code in "Old" Netbeans 8.2, but I know
>>
>> >>the days are numbered...
>>
>> >>
>>
>> >>
>>
>> >>
>>
>> >>On 2021-04-20 08:23, Will Hartung wrote:
>>
>> >>
>>
>> >>>
>>
>> >>>On Mon, Apr 19, 2021 at 12:55 AM Wayne Gemmell | Connect
>>
>> >>>mailto:wa...@connect-mobile.co.za>>
>>
>> >>>wrote:
>>
>> >>>
>>
>> >>>Is the perception that nobody does Maven EAR's anymore or
>>
>> >>>that nobody uses EARs? I have a web app that has given me no
>>
>> >>>shortage of issuse with ant.
>>
>> >>>I'm trying to move it to Maven. If

Re: removing the "new project" support for Ant projects

[Thomas Wolf]

 +1 for not removing ant support for me as well.  I’m admittedly an
old-timer.  My first exposure to a ‘modern’ build tool was on my last job -
the company used gradle.  With a background in make and ant, I found its
syntax hard to grok.NB devs clearly like Maven - its syntax seems
straight-forward enough, but the tool seems relatively slow and if you have
an existing ant-based project whose directory structure doesn’t match
maven’s desired one, moving to maven may not be as straight forward as some
suggest.  And, how is the uptake of Ivy?  Isn’t that (in combination with
ant) considered a modern build tool?  If NB removes support for ant
altogether, it would not be able to handle ivy-based projects, no?

tom


On Apr 20, 2021 at 3:10:04 PM, Marco Rossi  wrote:

> +1 also for me to not eliminating Ant support for new (or existing)
> projects.
>
> Mark Reds
>
> Il giorno 20 apr 2021, alle ore 20:08, Mitch Claborn 
> ha scritto:
>
>
> +1 for not eliminating Ant support for new (or existing) projects. We've
> been using Ant for a long time, and it still works just fine for us, so
> there is no payback in converting to Maven.
>
>
>
> Mitch
>
>
> On 4/20/21 12:10 PM, Lisa Ruby wrote:
>
> > For those of you who have used Maven for a long time it may seem simple
> and straightforward, but for those of us who haven't it's not. I've
> struggled to try and understand it and figure out how to use it for my
> software project and gave up. And it's a huge amount of overhead, extra
> disk space usage, and more bits and pieces to keep track of that isn't
> justifiable for small simple projects. ANT works just fine for me, and I
> will keep using it for as long as I possibly can. I need to focus my time
> on getting my software out, not on the tools I have to use to do it.
>
> > Lisa
>
> > On 4/20/2021 10:00 AM, Geertjan Wielenga wrote:
>
> >> I agree, the Ant-based project creation should be removed and I
> disagree that there should be any kind of conversion between Ant and Maven
> -- that simply will never work and we'll spend the rest of our days fixing
> bugs in that. To convert from Ant to Maven: create a new Maven project and
> copy the Java source files from your Ant project into it.
>
> >>
>
> >> Gj
>
> >>
>
> >> On Tue, Apr 20, 2021 at 6:58 PM  pszud...@throwarock.com>> wrote:
>
> >>
>
> >>Honestly, I think NB should have an internal conversation about
>
> >>removing the "new project" support for Ant projects, while still
>
> >>being able to open existing ones. It just confuses a lot of people
>
> >>if they're not going to be supported.
>
> >>
>
> >>I agree, if and ONLY if you provide at least a rudimentary way to
>
> >>convert ANT projects to Maven projects.   I have been struggling
>
> >>with this issue too long.  I have hundreds of Ant based projects
>
> >>that I would love to turn over immediately to Maven... but I can't
>
> >>, am struggling, and haven't coded a darn line in two months...  I
>
> >>used to code 10 hours a day ... and now... embarrassed by my
>
> >>inability to convert.,.
>
> >>
>
> >>I exaggerate a bit, I still code in "Old" Netbeans 8.2, but I know
>
> >>the days are numbered...
>
> >>
>
> >>
>
> >>
>
> >>On 2021-04-20 08:23, Will Hartung wrote:
>
> >>
>
> >>>
>
> >>>On Mon, Apr 19, 2021 at 12:55 AM Wayne Gemmell | Connect
>
> >>>mailto:wa...@connect-mobile.co.za>>
>
> >>>wrote:
>
> >>>
>
> >>>Is the perception that nobody does Maven EAR's anymore or
>
> >>>that nobody uses EARs? I have a web app that has given me no
>
> >>>shortage of issuse with ant.
>
> >>>I'm trying to move it to Maven. If nobody is using maven then
>
> >>>I need to move to something else. If nobody is using EAR's
>
> >>>anymore then I'm pretty stuck figuring out this Maven issue.
>
> >>>
>
> >>>Well, it's several things.
>
> >>>EARs are less popular because their necessity has been greatly
>
> >>>reduced. Session beans can be placed in WARs now, so for many use
>
> >>>cases, a WAR is completely adequate to the task.
>
> >>>However, it's not suitable for all use cases.
>
> >>>Notably, MDBs can not be deployed in WARs. But only as an EJB
>
> >>>  

Re: removing the "new project" support for Ant projects

[Bayless Kirtley]

Another +1 for me to not eliminating Ant support for new and existing 
programs. Ant works perfectly well for all my projects too.


Bayless Kirtley


On 4/20/21 2:10 PM, Marco Rossi wrote:

+1 also for me to not eliminating Ant support for new (or existing) projects.

Mark Reds


Il giorno 20 apr 2021, alle ore 20:08, Mitch Claborn  ha 
scritto:

+1 for not eliminating Ant support for new (or existing) projects. We've been 
using Ant for a long time, and it still works just fine for us, so there is no 
payback in converting to Maven.


Mitch

On 4/20/21 12:10 PM, Lisa Ruby wrote:

For those of you who have used Maven for a long time it may seem simple and 
straightforward, but for those of us who haven't it's not. I've struggled to 
try and understand it and figure out how to use it for my software project and 
gave up. And it's a huge amount of overhead, extra disk space usage, and more 
bits and pieces to keep track of that isn't justifiable for small simple 
projects. ANT works just fine for me, and I will keep using it for as long as I 
possibly can. I need to focus my time on getting my software out, not on the 
tools I have to use to do it.
Lisa
On 4/20/2021 10:00 AM, Geertjan Wielenga wrote:

I agree, the Ant-based project creation should be removed and I disagree that 
there should be any kind of conversion between Ant and Maven -- that simply 
will never work and we'll spend the rest of our days fixing bugs in that. To 
convert from Ant to Maven: create a new Maven project and copy the Java source 
files from your Ant project into it.

Gj

On Tue, Apr 20, 2021 at 6:58 PM mailto:pszud...@throwarock.com>> wrote:

Honestly, I think NB should have an internal conversation about
removing the "new project" support for Ant projects, while still
being able to open existing ones. It just confuses a lot of people
if they're not going to be supported.

I agree, if and ONLY if you provide at least a rudimentary way to
convert ANT projects to Maven projects.   I have been struggling
with this issue too long.  I have hundreds of Ant based projects
that I would love to turn over immediately to Maven... but I can't
, am struggling, and haven't coded a darn line in two months...  I
used to code 10 hours a day ... and now... embarrassed by my
inability to convert.,.

I exaggerate a bit, I still code in "Old" Netbeans 8.2, but I know
the days are numbered...



On 2021-04-20 08:23, Will Hartung wrote:


On Mon, Apr 19, 2021 at 12:55 AM Wayne Gemmell | Connect
mailto:wa...@connect-mobile.co.za>>
wrote:

Is the perception that nobody does Maven EAR's anymore or
that nobody uses EARs? I have a web app that has given me no
shortage of issuse with ant.
I'm trying to move it to Maven. If nobody is using maven then
I need to move to something else. If nobody is using EAR's
anymore then I'm pretty stuck figuring out this Maven issue.

Well, it's several things.
EARs are less popular because their necessity has been greatly
reduced. Session beans can be placed in WARs now, so for many use
cases, a WAR is completely adequate to the task.
However, it's not suitable for all use cases.
Notably, MDBs can not be deployed in WARs. But only as an EJB
either deployed standalone, or bundled within an EAR.
With the hue and cry over micro services and "down with the
monolith", just the idea of a large application bundled in a EAR
is falling out of favor.
Also, there's a history of advocacy underlying this. Sun used
NetBeans as a mechanism to advocate for Java and Java EE. It
behooved them to have something like NetBeans to make Java EE
development easier. So, it was important for NetBeans to have
really first class Java EE support. Bundling the Java EE wizards
and templates along with Glassfish all helped promote that.
Of course, now, with the great Java Diaspora out of Oracle, the
goals and drivers are different.
For your project, if all you have is a web app and some session
beans, then a simple WAR file is good to go. The Ant projects
seem to essentially be deprecated now, so I would not rely on
those for anything. If practical, especially if your project is
young, I would migrate it to Maven. The Maven WAR is a pretty
simple project and seems to work ok. Maven isn't going away any
time soon, Gradle, it's primary competitor, doesn't really have
the traction to overcome it yet, and it's been going for some
time. If nothing else, the pom.xml file has become a de facto
portable project format if, for nothing else, to capture
dependencies.
Honestly, I think NB should have an internal conversation about
    removing the "new project" support for Ant projects, while still
being able to open existing ones. It just confuses a lot of
people if they'r

Re: removing the "new project" support for Ant projects

[Marco Rossi]

+1 also for me to not eliminating Ant support for new (or existing) projects.

Mark Reds

> Il giorno 20 apr 2021, alle ore 20:08, Mitch Claborn  
> ha scritto:
> 
> +1 for not eliminating Ant support for new (or existing) projects. We've been 
> using Ant for a long time, and it still works just fine for us, so there is 
> no payback in converting to Maven.
> 
> 
> Mitch
> 
> On 4/20/21 12:10 PM, Lisa Ruby wrote:
>> For those of you who have used Maven for a long time it may seem simple and 
>> straightforward, but for those of us who haven't it's not. I've struggled to 
>> try and understand it and figure out how to use it for my software project 
>> and gave up. And it's a huge amount of overhead, extra disk space usage, and 
>> more bits and pieces to keep track of that isn't justifiable for small 
>> simple projects. ANT works just fine for me, and I will keep using it for as 
>> long as I possibly can. I need to focus my time on getting my software out, 
>> not on the tools I have to use to do it.
>> Lisa
>> On 4/20/2021 10:00 AM, Geertjan Wielenga wrote:
>>> I agree, the Ant-based project creation should be removed and I disagree 
>>> that there should be any kind of conversion between Ant and Maven -- that 
>>> simply will never work and we'll spend the rest of our days fixing bugs in 
>>> that. To convert from Ant to Maven: create a new Maven project and copy the 
>>> Java source files from your Ant project into it.
>>> 
>>> Gj
>>> 
>>> On Tue, Apr 20, 2021 at 6:58 PM >> <mailto:pszud...@throwarock.com>> wrote:
>>> 
>>>Honestly, I think NB should have an internal conversation about
>>>removing the "new project" support for Ant projects, while still
>>>being able to open existing ones. It just confuses a lot of people
>>>if they're not going to be supported.
>>> 
>>>I agree, if and ONLY if you provide at least a rudimentary way to
>>>convert ANT projects to Maven projects.   I have been struggling
>>>with this issue too long.  I have hundreds of Ant based projects
>>>that I would love to turn over immediately to Maven... but I can't
>>>, am struggling, and haven't coded a darn line in two months...  I
>>>used to code 10 hours a day ... and now... embarrassed by my
>>>inability to convert.,.
>>> 
>>>I exaggerate a bit, I still code in "Old" Netbeans 8.2, but I know
>>>the days are numbered...
>>> 
>>> 
>>> 
>>>On 2021-04-20 08:23, Will Hartung wrote:
>>> 
>>>> 
>>>>On Mon, Apr 19, 2021 at 12:55 AM Wayne Gemmell | Connect
>>>>mailto:wa...@connect-mobile.co.za>>
>>>>wrote:
>>>> 
>>>>Is the perception that nobody does Maven EAR's anymore or
>>>>that nobody uses EARs? I have a web app that has given me no
>>>>shortage of issuse with ant.
>>>>I'm trying to move it to Maven. If nobody is using maven then
>>>>I need to move to something else. If nobody is using EAR's
>>>>anymore then I'm pretty stuck figuring out this Maven issue.
>>>> 
>>>>Well, it's several things.
>>>>EARs are less popular because their necessity has been greatly
>>>>reduced. Session beans can be placed in WARs now, so for many use
>>>>cases, a WAR is completely adequate to the task.
>>>>However, it's not suitable for all use cases.
>>>>Notably, MDBs can not be deployed in WARs. But only as an EJB
>>>>either deployed standalone, or bundled within an EAR.
>>>>With the hue and cry over micro services and "down with the
>>>>monolith", just the idea of a large application bundled in a EAR
>>>>is falling out of favor.
>>>>Also, there's a history of advocacy underlying this. Sun used
>>>>NetBeans as a mechanism to advocate for Java and Java EE. It
>>>>behooved them to have something like NetBeans to make Java EE
>>>>development easier. So, it was important for NetBeans to have
>>>>really first class Java EE support. Bundling the Java EE wizards
>>>>and templates along with Glassfish all helped promote that.
>>>>Of course, now, with the great Java Diaspora out of Oracle, the
>>>>goals and drivers are different.
>>>>For your project, if all you have is a web app and some session
>&

Re: removing the "new project" support for Ant projects

[Emma Atkinson]

I develop small projects and prototypes.  I was considering migrating to
Gradle when the time comes to retire Ant support.

I have managed to get OpenJFX and linker working well enough under Ant.  It
helps that I was used to object linking in the 1980's on DEC PDP11s.

Personally, I find Maven overkill for my projects. The main concern is the
repository index is massive.  As it stands, I'll have to reconfigure the
hard drives to decompress it.


On Tue, 20 Apr 2021, 17:58 ,  wrote:

> Honestly, I think NB should have an internal conversation about removing
> the "new project" support for Ant projects, while still being able to open
> existing ones. It just confuses a lot of people if they're not going to be
> supported.
>
>
> I agree, if and ONLY if you provide at least a rudimentary way to convert
> ANT projects to Maven projects.   I have been struggling with this issue
> too long.  I have hundreds of Ant based projects that I would love to turn
> over immediately to Maven... but I can't , am struggling, and haven't coded
> a darn line in two months...  I used to code 10 hours a day ... and now...
> embarrassed by my inability to convert.,.
>
> I exaggerate a bit, I still code in "Old" Netbeans 8.2, but I know the
> days are numbered...
>
>
>
> On 2021-04-20 08:23, Will Hartung wrote:
>
>
>
> On Mon, Apr 19, 2021 at 12:55 AM Wayne Gemmell | Connect <
> wa...@connect-mobile.co.za> wrote:
>
>> Is the perception that nobody does Maven EAR's anymore or that nobody
>> uses EARs? I have a web app that has given me no shortage of issuse with
>> ant.
>> I'm trying to move it to Maven. If nobody is using maven then I need to
>> move to something else. If nobody is using EAR's anymore then I'm pretty
>> stuck figuring out this Maven issue.
>>
>
> Well, it's several things.
>
> EARs are less popular because their necessity has been greatly reduced.
> Session beans can be placed in WARs now, so for many use cases, a WAR is
> completely adequate to the task.
>
> However, it's not suitable for all use cases.
>
> Notably, MDBs can not be deployed in WARs. But only as an EJB either
> deployed standalone, or bundled within an EAR.
>
> With the hue and cry over micro services and "down with the monolith",
> just the idea of a large application bundled in a EAR is falling out of
> favor.
>
> Also, there's a history of advocacy underlying this. Sun used NetBeans as
> a mechanism to advocate for Java and Java EE. It behooved them to have
> something like NetBeans to make Java EE development easier. So, it was
> important for NetBeans to have really first class Java EE support. Bundling
> the Java EE wizards and templates along with Glassfish all helped promote
> that.
>
> Of course, now, with the great Java Diaspora out of Oracle, the goals and
> drivers are different.
>
> For your project, if all you have is a web app and some session beans,
> then a simple WAR file is good to go. The Ant projects seem to essentially
> be deprecated now, so I would not rely on those for anything. If practical,
> especially if your project is young, I would migrate it to Maven. The Maven
> WAR is a pretty simple project and seems to work ok. Maven isn't going away
> any time soon, Gradle, it's primary competitor, doesn't really have the
> traction to overcome it yet, and it's been going for some time. If nothing
> else, the pom.xml file has become a de facto portable project format if,
> for nothing else, to capture dependencies.
>
> Honestly, I think NB should have an internal conversation about removing
> the "new project" support for Ant projects, while still being able to open
> existing ones. It just confuses a lot of people if they're not going to be
> supported.
>
> And I still haven't heard any concrete position the project has on
> internalizing Maven archetypes used for project wizards, or the process of
> adopting that.
>
> Legacy archetypes that used to work in NB 8 are now failing because
> they've vanished from Maven central. So, an external dependency broke an
> internal feature.
>
> Feel free to follow up with specific questions about getting your project
> to work and/or converted to Maven.
>
> Regards,
>
> Will Hartung
>
>
>

Re: removing the "new project" support for Ant projects

[Jerome Lelasseux]

 I have an ant-based NB platform application, moving to Maven is on my to-do 
list, but I know nothing about Maven. Some time ago I tried to find relevant 
help but I just found generic "move to maven" infos, so I gave up.


> That said, perhaps we could get a write up on someone going through the 
> process on some of the common NB Ant projects to show how it's done.
That would be great. No need to be super detailed, but at least the main steps, 
so I understand the path and the traps to avoid.

I found this, but is it still valid ? (2013). And it seems for a single-module 
project 
 http://netbeans.apache.org/wiki/DevFaqMavenHowToMigrateFromANT.asciidoc


Jerome


Le mardi 20 avril 2021 à 20:19:17 UTC+2, Will Hartung 
 a écrit :  
 
 

On Tue, Apr 20, 2021 at 10:10 AM Lisa Ruby  
wrote:

  For those of you who have used Maven for a long time it may seem simple and 
straightforward, but for those of us who haven't it's not. I've struggled to 
try and understand it and figure out how to use it for my software project and 
gave up. And it's a huge amount of overhead, extra disk space usage, and more 
bits and pieces to keep track of that isn't justifiable for small simple 
projects. ANT works just fine for me, and I will keep using it for as long as I 
possibly can. I need to focus my time on getting my software out, not on the 
tools I have to use to do it. 


There are several issues, depending on your project.
If you have a "simple" Ant project, it's mostly a matter of copying your code 
over, resolving the dependencies (i.e. correlating the libraries you use to the 
ones in the repository), and building.
The singular "huge" amount of overhead for Maven is the large index that's 
routinely downloaded from Maven Central, cataloging all of the available 
libraries. It's a large download that's uncompressed on the file system (> 1GB).
Outside of that, Maven is lightweight.
Ant is faster, to be sure, but Maven is "fast enough" for most cases.
For complicated projects, anything goes. Maven is a declarative system. "This 
is what I want done" vs Ants imperative system "This is what I want to do". 
There is an absolute paradigm mismatch between the two, but that does not mean 
it's not reconcilable.
The other side of the coin is that, technically, this isn't the place for 
converting Ant to Maven. That's a "Ant" problem or "Maven" problem, not 
necessarily an IDE problem.
That said, perhaps we could get a write up on someone going through the process 
on some of the common NB Ant projects to show how it's done. An automated 
system would likely be more complicated and less effective than a list of steps 
and heuristics that someone can go through. No ideal, to be sure.
If you'd like to contact me directly with specifics about your project, maybe I 
can help you prototype a project transition.

That said, as I mentioned in the other thread, I don't think that NB should 
give up legacy support of such projects, just perhaps deprecating the "new 
projects". 

Regards,
Will Hartung
  

Re: removing the "new project" support for Ant projects

[Will Hartung]

On Tue, Apr 20, 2021 at 10:10 AM Lisa Ruby 
wrote:

> For those of you who have used Maven for a long time it may seem simple
> and straightforward, but for those of us who haven't it's not. I've
> struggled to try and understand it and figure out how to use it for my
> software project and gave up. And it's a huge amount of overhead, extra
> disk space usage, and more bits and pieces to keep track of that isn't
> justifiable for small simple projects. ANT works just fine for me, and I
> will keep using it for as long as I possibly can. I need to focus my time
> on getting my software out, not on the tools I have to use to do it.
>

There are several issues, depending on your project.

If you have a "simple" Ant project, it's mostly a matter of copying your
code over, resolving the dependencies (i.e. correlating the libraries you
use to the ones in the repository), and building.

The singular "huge" amount of overhead for Maven is the large index that's
routinely downloaded from Maven Central, cataloging all of the available
libraries. It's a large download that's uncompressed on the file system (>
1GB).

Outside of that, Maven is lightweight.

Ant is faster, to be sure, but Maven is "fast enough" for most cases.

For complicated projects, anything goes. Maven is a declarative system.
"This is what I want done" vs Ants imperative system "This is what I want
to do". There is an absolute paradigm mismatch between the two, but that
does not mean it's not reconcilable.

The other side of the coin is that, technically, this isn't the place for
converting Ant to Maven. That's a "Ant" problem or "Maven" problem, not
necessarily an IDE problem.

That said, perhaps we could get a write up on someone going through the
process on some of the common NB Ant projects to show how it's done. An
automated system would likely be more complicated and less effective than a
list of steps and heuristics that someone can go through. No ideal, to be
sure.

If you'd like to contact me directly with specifics about your project,
maybe I can help you prototype a project transition.

That said, as I mentioned in the other thread, I don't think that NB should
give up legacy support of such projects, just perhaps deprecating the "new
projects".

Regards,

Will Hartung

Re: removing the "new project" support for Ant projects

[Mitch Claborn]

+1 for not eliminating Ant support for new (or existing) projects. We've 
been using Ant for a long time, and it still works just fine for us, so 
there is no payback in converting to Maven.



Mitch

On 4/20/21 12:10 PM, Lisa Ruby wrote:
For those of you who have used Maven for a long time it may seem simple 
and straightforward, but for those of us who haven't it's not. I've 
struggled to try and understand it and figure out how to use it for my 
software project and gave up. And it's a huge amount of overhead, extra 
disk space usage, and more bits and pieces to keep track of that isn't 
justifiable for small simple projects. ANT works just fine for me, and I 
will keep using it for as long as I possibly can. I need to focus my 
time on getting my software out, not on the tools I have to use to do it.


Lisa

On 4/20/2021 10:00 AM, Geertjan Wielenga wrote:
I agree, the Ant-based project creation should be removed and I 
disagree that there should be any kind of conversion between Ant and 
Maven -- that simply will never work and we'll spend the rest of our 
days fixing bugs in that. To convert from Ant to Maven: create a new 
Maven project and copy the Java source files from your Ant project 
into it.


Gj

On Tue, Apr 20, 2021 at 6:58 PM <mailto:pszud...@throwarock.com>> wrote:


Honestly, I think NB should have an internal conversation about
    removing the "new project" support for Ant projects, while still
being able to open existing ones. It just confuses a lot of people
if they're not going to be supported.

I agree, if and ONLY if you provide at least a rudimentary way to
convert ANT projects to Maven projects.   I have been struggling
with this issue too long.  I have hundreds of Ant based projects
that I would love to turn over immediately to Maven... but I can't
, am struggling, and haven't coded a darn line in two months...  I
used to code 10 hours a day ... and now... embarrassed by my
inability to convert.,.

I exaggerate a bit, I still code in "Old" Netbeans 8.2, but I know
the days are numbered...



On 2021-04-20 08:23, Will Hartung wrote:



On Mon, Apr 19, 2021 at 12:55 AM Wayne Gemmell | Connect
mailto:wa...@connect-mobile.co.za>>
wrote:

Is the perception that nobody does Maven EAR's anymore or
that nobody uses EARs? I have a web app that has given me no
shortage of issuse with ant.
I'm trying to move it to Maven. If nobody is using maven then
I need to move to something else. If nobody is using EAR's
anymore then I'm pretty stuck figuring out this Maven issue.

Well, it's several things.
EARs are less popular because their necessity has been greatly
reduced. Session beans can be placed in WARs now, so for many use
cases, a WAR is completely adequate to the task.
However, it's not suitable for all use cases.
Notably, MDBs can not be deployed in WARs. But only as an EJB
either deployed standalone, or bundled within an EAR.
With the hue and cry over micro services and "down with the
monolith", just the idea of a large application bundled in a EAR
is falling out of favor.
Also, there's a history of advocacy underlying this. Sun used
NetBeans as a mechanism to advocate for Java and Java EE. It
behooved them to have something like NetBeans to make Java EE
development easier. So, it was important for NetBeans to have
really first class Java EE support. Bundling the Java EE wizards
and templates along with Glassfish all helped promote that.
Of course, now, with the great Java Diaspora out of Oracle, the
goals and drivers are different.
For your project, if all you have is a web app and some session
beans, then a simple WAR file is good to go. The Ant projects
seem to essentially be deprecated now, so I would not rely on
those for anything. If practical, especially if your project is
young, I would migrate it to Maven. The Maven WAR is a pretty
simple project and seems to work ok. Maven isn't going away any
time soon, Gradle, it's primary competitor, doesn't really have
the traction to overcome it yet, and it's been going for some
time. If nothing else, the pom.xml file has become a de facto
portable project format if, for nothing else, to capture
dependencies.
Honestly, I think NB should have an internal conversation about
    removing the "new project" support for Ant projects, while still
being able to open existing ones. It just confuses a lot of
people if they're not going to be supported.
And I still haven't heard any concrete position the project has
on internalizing Maven archetypes used for project wizards, or
the process of adopting that.
Legacy archetypes that used to work in NB 8 are now failing
because they've vanished from Maven central. So, an external
dependenc

Re: removing the "new project" support for Ant projects

[Lisa Ruby]

For those of you who have used Maven for a long time it may seem simple and 
straightforward, but for those of us who haven't it's not. I've struggled to 
try and understand it and figure out how to use it for my software project and 
gave up. And it's a huge amount of overhead, extra disk space usage, and more 
bits and pieces to keep track of that isn't justifiable for small simple 
projects. ANT works just fine for me, and I will keep using it for as long as I 
possibly can. I need to focus my time on getting my software out, not on the 
tools I have to use to do it.

Lisa

On 4/20/2021 10:00 AM, Geertjan Wielenga wrote:

> I agree, the Ant-based project creation should be removed and I disagree that 
> there should be any kind of conversion between Ant and Maven -- that simply 
> will never work and we'll spend the rest of our days fixing bugs in that. To 
> convert from Ant to Maven: create a new Maven project and copy the Java 
> source files from your Ant project into it.
>
> Gj
>
> On Tue, Apr 20, 2021 at 6:58 PM  wrote:
>
>> Honestly, I think NB should have an internal conversation about removing the 
>> "new project" support for Ant projects, while still being able to open 
>> existing ones. It just confuses a lot of people if they're not going to be 
>> supported.
>>
>> I agree, if and ONLY if you provide at least a rudimentary way to convert 
>> ANT projects to Maven projects. I have been struggling with this issue too 
>> long. I have hundreds of Ant based projects that I would love to turn over 
>> immediately to Maven... but I can't , am struggling, and haven't coded a 
>> darn line in two months... I used to code 10 hours a day ... and now... 
>> embarrassed by my inability to convert.,.
>>
>> I exaggerate a bit, I still code in "Old" Netbeans 8.2, but I know the days 
>> are numbered...
>>
>> On 2021-04-20 08:23, Will Hartung wrote:
>>
>>> On Mon, Apr 19, 2021 at 12:55 AM Wayne Gemmell | Connect 
>>>  wrote:
>>>
>>>> Is the perception that nobody does Maven EAR's anymore or that nobody uses 
>>>> EARs? I have a web app that has given me no shortage of issuse with ant.
>>>> I'm trying to move it to Maven. If nobody is using maven then I need to 
>>>> move to something else. If nobody is using EAR's anymore then I'm pretty 
>>>> stuck figuring out this Maven issue.
>>>
>>> Well, it's several things.
>>>
>>> EARs are less popular because their necessity has been greatly reduced. 
>>> Session beans can be placed in WARs now, so for many use cases, a WAR is 
>>> completely adequate to the task.
>>>
>>> However, it's not suitable for all use cases.
>>>
>>> Notably, MDBs can not be deployed in WARs. But only as an EJB either 
>>> deployed standalone, or bundled within an EAR.
>>>
>>> With the hue and cry over micro services and "down with the monolith", just 
>>> the idea of a large application bundled in a EAR is falling out of favor.
>>>
>>> Also, there's a history of advocacy underlying this. Sun used NetBeans as a 
>>> mechanism to advocate for Java and Java EE. It behooved them to have 
>>> something like NetBeans to make Java EE development easier. So, it was 
>>> important for NetBeans to have really first class Java EE support. Bundling 
>>> the Java EE wizards and templates along with Glassfish all helped promote 
>>> that.
>>>
>>> Of course, now, with the great Java Diaspora out of Oracle, the goals and 
>>> drivers are different.
>>>
>>> For your project, if all you have is a web app and some session beans, then 
>>> a simple WAR file is good to go. The Ant projects seem to essentially be 
>>> deprecated now, so I would not rely on those for anything. If practical, 
>>> especially if your project is young, I would migrate it to Maven. The Maven 
>>> WAR is a pretty simple project and seems to work ok. Maven isn't going away 
>>> any time soon, Gradle, it's primary competitor, doesn't really have the 
>>> traction to overcome it yet, and it's been going for some time. If nothing 
>>> else, the pom.xml file has become a de facto portable project format if, 
>>> for nothing else, to capture dependencies.
>>>
>>> Honestly, I think NB should have an internal conversation about removing 
>>> the "new project" support for Ant projects, while still being able to open 
>>> existing ones. It just confuses a lot of people if they're not going to be 
>>> supported.
>>>
>>> And I still haven't heard any concrete position the project has on 
>>> internalizing Maven archetypes used for project wizards, or the process of 
>>> adopting that.
>>>
>>> Legacy archetypes that used to work in NB 8 are now failing because they've 
>>> vanished from Maven central. So, an external dependency broke an internal 
>>> feature.
>>>
>>> Feel free to follow up with specific questions about getting your project 
>>> to work and/or converted to Maven.
>>>
>>> Regards,
>>>
>>> Will Hartung

Re: removing the "new project" support for Ant projects

[Sean Carrick]

GJ,

While I get where you are coming from, there are still a bunch of legacy
applications out there built on the AppFramework, which I do not believe
will be able to be converted to Maven. People are still using NB <= 8.2
simply for the AppFramework IDE integration to maintain those legacy
applications...

I know some of those folks and they were completely shocked when NB
removed the AppFramework integration support, even though it has not
been developed since (when?), something like 2007 or so? Still, there
are applications and developers maintaining them that should not be left
behind.

Would it be possible to have a fork or variant of the current NB that
would still provide that support, even if development of that support is
stopped? I mean, make a fork that receives updates to the NBP and all of
the other tools, but still has the legacy support in it that just
collects dust for those who still need it. At least then the NB team can
honestly say that they have left no one behind...

Just my thoughts on the matter, so take them as you will.

-SC

On 4/20/21 12:00 PM, Geertjan Wielenga wrote:
> I agree, the Ant-based project creation should be removed and I
> disagree that there should be any kind of conversion between Ant and
> Maven -- that simply will never work and we'll spend the rest of our
> days fixing bugs in that. To convert from Ant to Maven: create a new
> Maven project and copy the Java source files from your Ant project
> into it.
>
> Gj
>
> On Tue, Apr 20, 2021 at 6:58 PM  <mailto:pszud...@throwarock.com>> wrote:
>
> Honestly, I think NB should have an internal conversation about
> removing the "new project" support for Ant projects, while still
> being able to open existing ones. It just confuses a lot of people
> if they're not going to be supported.
>
>  
>
> I agree, if and ONLY if you provide at least a rudimentary way to
> convert ANT projects to Maven projects.   I have been struggling
> with this issue too long.  I have hundreds of Ant based projects
> that I would love to turn over immediately to Maven... but I can't
> , am struggling, and haven't coded a darn line in two months...  I
> used to code 10 hours a day ... and now... embarrassed by my
> inability to convert.,.
>
> I exaggerate a bit, I still code in "Old" Netbeans 8.2, but I know
> the days are numbered...
>
>
>
> On 2021-04-20 08:23, Will Hartung wrote:
>
>>  
>>
>> On Mon, Apr 19, 2021 at 12:55 AM Wayne Gemmell | Connect
>> mailto:wa...@connect-mobile.co.za>>
>> wrote:
>>
>> Is the perception that nobody does Maven EAR's anymore or
>> that nobody uses EARs? I have a web app that has given me no
>> shortage of issuse with ant. 
>> I'm trying to move it to Maven. If nobody is using maven then
>> I need to move to something else. If nobody is using EAR's
>> anymore then I'm pretty stuck figuring out this Maven issue.
>>
>>  
>> Well, it's several things.
>>  
>> EARs are less popular because their necessity has been greatly
>> reduced. Session beans can be placed in WARs now, so for many use
>> cases, a WAR is completely adequate to the task.
>>  
>> However, it's not suitable for all use cases.
>>  
>> Notably, MDBs can not be deployed in WARs. But only as an EJB
>> either deployed standalone, or bundled within an EAR.
>>  
>> With the hue and cry over micro services and "down with the
>> monolith", just the idea of a large application bundled in a EAR
>> is falling out of favor.
>>  
>> Also, there's a history of advocacy underlying this. Sun used
>> NetBeans as a mechanism to advocate for Java and Java EE. It
>> behooved them to have something like NetBeans to make Java EE
>> development easier. So, it was important for NetBeans to have
>> really first class Java EE support. Bundling the Java EE wizards
>> and templates along with Glassfish all helped promote that.
>>  
>> Of course, now, with the great Java Diaspora out of Oracle, the
>> goals and drivers are different.
>>  
>> For your project, if all you have is a web app and some session
>> beans, then a simple WAR file is good to go. The Ant projects
>> seem to essentially be deprecated now, so I would not rely on
>> those for anything. If practical, especially if your project is
>> young, I would migrate it to Maven. The Maven WAR is a pretty
>> simple project and seems to work ok. Maven isn't goin

Re: removing the "new project" support for Ant projects

[Geertjan Wielenga]

I agree, the Ant-based project creation should be removed and I disagree
that there should be any kind of conversion between Ant and Maven -- that
simply will never work and we'll spend the rest of our days fixing bugs in
that. To convert from Ant to Maven: create a new Maven project and copy the
Java source files from your Ant project into it.

Gj

On Tue, Apr 20, 2021 at 6:58 PM  wrote:

> Honestly, I think NB should have an internal conversation about removing
> the "new project" support for Ant projects, while still being able to open
> existing ones. It just confuses a lot of people if they're not going to be
> supported.
>
>
> I agree, if and ONLY if you provide at least a rudimentary way to convert
> ANT projects to Maven projects.   I have been struggling with this issue
> too long.  I have hundreds of Ant based projects that I would love to turn
> over immediately to Maven... but I can't , am struggling, and haven't coded
> a darn line in two months...  I used to code 10 hours a day ... and now...
> embarrassed by my inability to convert.,.
>
> I exaggerate a bit, I still code in "Old" Netbeans 8.2, but I know the
> days are numbered...
>
>
>
> On 2021-04-20 08:23, Will Hartung wrote:
>
>
>
> On Mon, Apr 19, 2021 at 12:55 AM Wayne Gemmell | Connect <
> wa...@connect-mobile.co.za> wrote:
>
>> Is the perception that nobody does Maven EAR's anymore or that nobody
>> uses EARs? I have a web app that has given me no shortage of issuse with
>> ant.
>> I'm trying to move it to Maven. If nobody is using maven then I need to
>> move to something else. If nobody is using EAR's anymore then I'm pretty
>> stuck figuring out this Maven issue.
>>
>
> Well, it's several things.
>
> EARs are less popular because their necessity has been greatly reduced.
> Session beans can be placed in WARs now, so for many use cases, a WAR is
> completely adequate to the task.
>
> However, it's not suitable for all use cases.
>
> Notably, MDBs can not be deployed in WARs. But only as an EJB either
> deployed standalone, or bundled within an EAR.
>
> With the hue and cry over micro services and "down with the monolith",
> just the idea of a large application bundled in a EAR is falling out of
> favor.
>
> Also, there's a history of advocacy underlying this. Sun used NetBeans as
> a mechanism to advocate for Java and Java EE. It behooved them to have
> something like NetBeans to make Java EE development easier. So, it was
> important for NetBeans to have really first class Java EE support. Bundling
> the Java EE wizards and templates along with Glassfish all helped promote
> that.
>
> Of course, now, with the great Java Diaspora out of Oracle, the goals and
> drivers are different.
>
> For your project, if all you have is a web app and some session beans,
> then a simple WAR file is good to go. The Ant projects seem to essentially
> be deprecated now, so I would not rely on those for anything. If practical,
> especially if your project is young, I would migrate it to Maven. The Maven
> WAR is a pretty simple project and seems to work ok. Maven isn't going away
> any time soon, Gradle, it's primary competitor, doesn't really have the
> traction to overcome it yet, and it's been going for some time. If nothing
> else, the pom.xml file has become a de facto portable project format if,
> for nothing else, to capture dependencies.
>
> Honestly, I think NB should have an internal conversation about removing
> the "new project" support for Ant projects, while still being able to open
> existing ones. It just confuses a lot of people if they're not going to be
> supported.
>
> And I still haven't heard any concrete position the project has on
> internalizing Maven archetypes used for project wizards, or the process of
> adopting that.
>
> Legacy archetypes that used to work in NB 8 are now failing because
> they've vanished from Maven central. So, an external dependency broke an
> internal feature.
>
> Feel free to follow up with specific questions about getting your project
> to work and/or converted to Maven.
>
> Regards,
>
> Will Hartung
>
>
>

removing the "new project" support for Ant projects

[pszudzik]

Honestly, I think NB should have an internal conversation about removing
the "new project" support for Ant projects, while still being able to
open existing ones. It just confuses a lot of people if they're not
going to be supported.

I agree, if and ONLY if you provide at least a rudimentary way to
convert ANT projects to Maven projects.   I have been struggling with
this issue too long.  I have hundreds of Ant based projects that I would
love to turn over immediately to Maven... but I can't , am struggling,
and haven't coded a darn line in two months...  I used to code 10 hours
a day ... and now... embarrassed by my inability to convert.,. 

I exaggerate a bit, I still code in "Old" Netbeans 8.2, but I know the
days are numbered... 

On 2021-04-20 08:23, Will Hartung wrote:

> On Mon, Apr 19, 2021 at 12:55 AM Wayne Gemmell | Connect 
>  wrote: 
> 
>> Is the perception that nobody does Maven EAR's anymore or that nobody uses 
>> EARs? I have a web app that has given me no shortage of issuse with ant.  
>> I'm trying to move it to Maven. If nobody is using maven then I need to move 
>> to something else. If nobody is using EAR's anymore then I'm pretty stuck 
>> figuring out this Maven issue.
> 
> Well, it's several things. 
> 
> EARs are less popular because their necessity has been greatly reduced. 
> Session beans can be placed in WARs now, so for many use cases, a WAR is 
> completely adequate to the task. 
> 
> However, it's not suitable for all use cases. 
> 
> Notably, MDBs can not be deployed in WARs. But only as an EJB either deployed 
> standalone, or bundled within an EAR. 
> 
> With the hue and cry over micro services and "down with the monolith", just 
> the idea of a large application bundled in a EAR is falling out of favor. 
> 
> Also, there's a history of advocacy underlying this. Sun used NetBeans as a 
> mechanism to advocate for Java and Java EE. It behooved them to have 
> something like NetBeans to make Java EE development easier. So, it was 
> important for NetBeans to have really first class Java EE support. Bundling 
> the Java EE wizards and templates along with Glassfish all helped promote 
> that. 
> 
> Of course, now, with the great Java Diaspora out of Oracle, the goals and 
> drivers are different. 
> 
> For your project, if all you have is a web app and some session beans, then a 
> simple WAR file is good to go. The Ant projects seem to essentially be 
> deprecated now, so I would not rely on those for anything. If practical, 
> especially if your project is young, I would migrate it to Maven. The Maven 
> WAR is a pretty simple project and seems to work ok. Maven isn't going away 
> any time soon, Gradle, it's primary competitor, doesn't really have the 
> traction to overcome it yet, and it's been going for some time. If nothing 
> else, the pom.xml file has become a de facto portable project format if, for 
> nothing else, to capture dependencies. 
> 
> Honestly, I think NB should have an internal conversation about removing the 
> "new project" support for Ant projects, while still being able to open 
> existing ones. It just confuses a lot of people if they're not going to be 
> supported. 
> 
> And I still haven't heard any concrete position the project has on 
> internalizing Maven archetypes used for project wizards, or the process of 
> adopting that. 
> 
> Legacy archetypes that used to work in NB 8 are now failing because they've 
> vanished from Maven central. So, an external dependency broke an internal 
> feature. 
> 
> Feel free to follow up with specific questions about getting your project to 
> work and/or converted to Maven. 
> 
> Regards, 
> 
> Will Hartung