You are viewing a plain text version of this content. The canonical link for it is here.
Posted to users@netbeans.apache.org by ps...@throwarock.com on 2021/04/20 16:57:31 UTC
removing the "new project" support for Ant projects
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
Posted by Emma Atkinson <em...@gmail.com>.
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 , <ps...@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 <
> wayne@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
Posted by Bradley Willcott <op...@gmail.com>.
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 <pszudzik@throwarock.com
>> <ma...@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
>>> <wayne@connect-mobile.co.za <ma...@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
Posted by Oliver Rettig <Ol...@orat.de>.
+1
> On Thu, 22 Apr 2021 at 08:15, Geertjan Wielenga
>
> <ge...@googlemail.com.invalid> 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-unsubscribe@netbeans.apache.org
> For additional commands, e-mail: users-help@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
Posted by Sean Carrick <se...@pekinsoft.com>.
> -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
Posted by Geertjan Wielenga <ge...@googlemail.com.INVALID>.
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 <ne...@apache.org> wrote:
> On Thu, 22 Apr 2021 at 08:15, Geertjan Wielenga
> <ge...@googlemail.com.invalid> 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
Posted by Neil C Smith <ne...@apache.org>.
On Thu, 22 Apr 2021 at 08:15, Geertjan Wielenga
<ge...@googlemail.com.invalid> 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-unsubscribe@netbeans.apache.org
For additional commands, e-mail: users-help@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
Posted by Owen Thomas <ow...@gmail.com>.
On Thu, 22 Apr 2021 at 17:15, Geertjan Wielenga
<ge...@googlemail.com.invalid> 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
Posted by John Mc <mc...@gmail.com>.
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 <ew...@oracle.com> 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 <ge...@googlemail.com.INVALID>
> *Sent:* 22 April 2021 08:15
> *Cc:* users@netbeans.apache.org <us...@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 <al...@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: [External] : Re: removing the "new project" support for Ant
projects
Posted by Ewan Slater <ew...@oracle.com>.
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 <ge...@googlemail.com.INVALID>
Sent: 22 April 2021 08:15
Cc: users@netbeans.apache.org <us...@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 <al...@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
Posted by Geertjan Wielenga <ge...@googlemail.com.INVALID>.
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 <al...@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
Posted by Bilu <al...@gmail.com>.
+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
Posted by Owen Thomas <ow...@gmail.com>.
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
Posted by Scott Palmer <sw...@gmail.com>.
> On Apr 21, 2021, at 2:15 AM, Owen Thomas <ow...@gmail.com> 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-unsubscribe@netbeans.apache.org
For additional commands, e-mail: users-help@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
Posted by Owen Thomas <ow...@gmail.com>.
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 <wi...@gmail.com> wrote:
>
>
> On Tue, Apr 20, 2021 at 9:32 PM Sean Carrick <se...@pekinsoft.com> 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 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...
>>
> We worked with NB ant builds and libraries for many years, but it was
> better for the team when we switched to Maven. The value it brought far
> outweighed the costs of adoption and continued use. For my personal
> projects, I still use it. Even if every now and then, I shake my fist at
> it, like anything else today.
>
> Regards,
>
> Will Hartung
>
>
Re: removing the "new project" support for Ant projects
Posted by Sean Carrick <se...@pekinsoft.com>.
> 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
Posted by Geertjan Wielenga <ge...@googlemail.com.INVALID>.
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 <se...@pekinsoft.com> 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
Posted by Sean Carrick <se...@pekinsoft.com>.
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
Posted by Geertjan Wielenga <ge...@googlemail.com.INVALID>.
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 <se...@pekinsoft.com> 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 <se...@pekinsoft.com> 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 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...
>>
> We worked with NB ant builds and libraries for many years, but it was
> better for the team when we switched to Maven. The value it brought far
> outweighed the costs of adoption and continued use. For my personal
> projects, I still use it. Even if every now and then, I shake my fist at
> it, like anything else today.
>
> Regards,
>
> Will Hartung
>
>
Re: removing the "new project" support for Ant projects
Posted by Laszlo Kishalmi <la...@gmail.com>.
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-unsubscribe@netbeans.apache.org
>
> > For additional commands, e-mail: users-help@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
Posted by Oliver Rettig <Ol...@orat.de>.
+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-unsubscribe@netbeans.apache.org
> For additional commands, e-mail: users-help@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
Posted by Neil C Smith <ne...@apache.org>.
On Fri, 23 Apr 2021 at 15:23, Laszlo Kishalmi <la...@gmail.com> 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-unsubscribe@netbeans.apache.org
For additional commands, e-mail: users-help@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
Posted by Christoph Theis <th...@gmx.at>.
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-unsubscribe@netbeans.apache.org
For additional commands, e-mail: users-help@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
Posted by Emma Atkinson <em...@gmail.com>.
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, <th...@gmx.at> 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-unsubscribe@netbeans.apache.org
> For additional commands, e-mail: users-help@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
Posted by Christoph Theis <th...@gmx.at>.
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-unsubscribe@netbeans.apache.org
For additional commands, e-mail: users-help@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
Posted by Laszlo Kishalmi <la...@gmail.com>.
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 <sean@pekinsoft.com
> <ma...@pekinsoft.com>> 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 and
> into the Maven realm...
>
> Honestly, this is a great opportunity to delve a bit deeper into
> Maven. Simply, if you plan on breathing a little life into SAF,
> publishing it as a Maven artifact to Maven Central opens it up to an
> astonishing number of developers. Do not discount how easy it is for
> folks to fire up "hello world" projects using Maven.
>
> Regards,
>
> Will Hartung
>
Re: removing the "new project" support for Ant projects
Posted by Will Hartung <wi...@gmail.com>.
On Wed, Apr 21, 2021 at 4:51 AM Sean Carrick <se...@pekinsoft.com> 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 and into the Maven realm...
>
Honestly, this is a great opportunity to delve a bit deeper into Maven.
Simply, if you plan on breathing a little life into SAF, publishing it as a
Maven artifact to Maven Central opens it up to an astonishing number of
developers. Do not discount how easy it is for folks to fire up "hello
world" projects using Maven.
Regards,
Will Hartung
Re: removing the "new project" support for Ant projects
Posted by Sean Carrick <se...@pekinsoft.com>.
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 <sean@pekinsoft.com
> <ma...@pekinsoft.com>> 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 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...
>
> We worked with NB ant builds and libraries for many years, but it was
> better for the team when we switched to Maven. The value it brought
> far outweighed the costs of adoption and continued use. For my
> personal projects, I still use it. Even if every now and then, I shake
> my fist at it, like anything else today.
>
> Regards,
>
> Will Hartung
>
Re: removing the "new project" support for Ant projects
Posted by Will Hartung <wi...@gmail.com>.
On Tue, Apr 20, 2021 at 9:32 PM Sean Carrick <se...@pekinsoft.com> 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 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...
>
We worked with NB ant builds and libraries for many years, but it was
better for the team when we switched to Maven. The value it brought far
outweighed the costs of adoption and continued use. For my personal
projects, I still use it. Even if every now and then, I shake my fist at
it, like anything else today.
Regards,
Will Hartung
Re: removing the "new project" support for Ant projects
Posted by Emma Atkinson <em...@gmail.com>.
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, <
wayne@connect-mobile.co.za> wrote:
> On Wed, 21 Apr 2021 at 06:32, Sean Carrick <se...@pekinsoft.com> 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
Posted by Sean Carrick <se...@pekinsoft.com>.
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
Posted by Wayne Gemmell | Connect <wa...@connect-mobile.co.za>.
On Wed, 21 Apr 2021 at 06:32, Sean Carrick <se...@pekinsoft.com> 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
Posted by Sean Carrick <se...@pekinsoft.com>.
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
Posted by Carl Mosca <ca...@gmail.com>.
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 <sw...@gmail.com> wrote:
>
> > On Apr 20, 2021, at 1:10 PM, Lisa Ruby <lb...@protonmail.com.invalid>
> 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-unsubscribe@netbeans.apache.org
> For additional commands, e-mail: users-help@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
Posted by Scott Palmer <sw...@gmail.com>.
> On Apr 20, 2021, at 1:10 PM, Lisa Ruby <lb...@protonmail.com.invalid> 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-unsubscribe@netbeans.apache.org
For additional commands, e-mail: users-help@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
Posted by Don <do...@gmail.com>.
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-unsubscribe@netbeans.apache.org
For additional commands, e-mail: users-help@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
Posted by Wayne Gemmell | Connect <wa...@connect-mobile.co.za>.
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
<ge...@googlemail.com.invalid> 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 <tj...@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 <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 <
>>> mitch_ml@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 <pszudzik@throwarock.com <mailto:
>>> pszudzik@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
>>>
>>> >>> <wayne@connect-mobile.co.za <ma...@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
>>>
>>> >>
>>>
>>>
>>> ---------------------------------------------------------------------
>>>
>>> To unsubscribe, e-mail: users-unsubscribe@netbeans.apache.org
>>>
>>> For additional commands, e-mail: users-help@netbeans.apache.org
>>>
>>>
>>> For further information about the NetBeans mailing lists, visit:
>>>
>>> https://cwiki.apache.org/confluence/display/NETBEANS/Mailing+lists
>>>
>>>
>>>
>>>
>>> ---------------------------------------------------------------------
>>> To unsubscribe, e-mail: users-unsubscribe@netbeans.apache.org
>>> For additional commands, e-mail: users-help@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
Posted by Eric Bresie <eb...@gmail.com>.
I’m not sure why everyone hates ant so much. I know it’s not perfect but what build tool really is.
If the preference is not to use ant in the future...when is Netbeans going to formally change from ant to maven? I know some work has been done in the branches which assume may have involved some tools to do some of the conversions so could whatever was use be used to automate the batch conversion?
For reference on converting (1) (2) (3) (4)
(1) https://blog.idrsolutions.com/2016/01/convert-ant-based-netbeans-project-to-a-maven-project/
(2) https://blog.sonatype.com/2009/04/how-to-convert-from-ant-to-maven-in-5-minutes/?hs_amp=true
(3) https://stackoverflow.com/questions/4029501/how-to-convert-ant-project-to-maven-project
(4) https://stackoverflow.com/questions/4029501/how-to-convert-ant-project-to-maven-project
Eric Bresie
Ebresie@gmail.com (mailto:Ebresie@gmail.com)
> On April 20, 2021 at 7:24:39 PM CDT, Emilio Gallardo Cantella <rareitor9@gmail.com (mailto:rareitor9@gmail.com)> wrote:
>
> To be honest, I think removing new projects in Ant might be too drastic a change altogether. From my perspective, a good lot of people that might still be using old Netbeans and the straightforward Ant support might not even know Ant IS an actual thing in the IDE, more so that their projects just work. I spent a few years doing Java and C/C++ projects on Netbeans for uni, and never had to nor was encouraged to touch the build system (Ant, make, cmake). You could argue that it might be a deficiency of the curriculum, but in terms of function it is not a requirement for learning a language or practicing it.
>
>
>
> Maven and Gradle are nice, but they require additional steps to work right now, and are not as straightforward, which most users and specially novices would find friendlier. The actual closest to get-up-and-go is Gradle, not Maven at all, from both a completely clean install or build of Netbeans - and I have tested it multiple times.
>
>
> What I would suggest is grabbing the whole set Ant-based functions, projects and modules and disable them by default, but introduce a way for users, and a prompt for example, to allow them to activate that set of projects from within the New Project Dialog. As an example, instead of the "Java with Ant" category, maybe there could be a "Legacy" folder icon that when selected displays in the "Projects" subwindow a prompt to activate Java with Ant, along with a small blurb about that having been the old standard for projects. Moreover, to make it more friendly, the blurb could say something like "if you cannot open/Netbeans does not recognize your old Projects, activate this and see if it works"
>
>
> I know this might be a bit beyond the topic of this thread, but this seems something a bit too drastic to do piecemeal such as disabling new projects for Ant at all
>
>
> Thanks,
>
>
> Emilio G.C.
>
>
>
> On 4/20/2021 17:28, Sean Carrick wrote:
> >
> > 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 (x-apple-data-detectors://6), Thomas Wolf <tjwolf@gmail.com (mailto:tjwolf@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 <marco@markreds.it (mailto:marco@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 (x-apple-data-detectors://11), Mitch Claborn <mitch_ml@claborn.net (mailto:mitch_ml@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 <pszudzik@throwarock.com (mailto:pszudzik@throwarock.com) <ma...@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
> > > > > > >>> <wayne@connect-mobile.co.za (mailto:wayne@connect-mobile.co.za) <ma...@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
> > > > > > >>
> > > > > >
> > > > > > ---------------------------------------------------------------------
> > > > > > To unsubscribe, e-mail: users-unsubscribe@netbeans.apache.org (mailto:users-unsubscribe@netbeans.apache.org)
> > > > > > For additional commands, e-mail: users-help@netbeans.apache.org (mailto:users-help@netbeans.apache.org)
> > > > > >
> > > > > > For further information about the NetBeans mailing lists, visit:
> > > > > > https://cwiki.apache.org/confluence/display/NETBEANS/Mailing+lists
> > > > > >
> > > > >
> > > > >
> > > > > ---------------------------------------------------------------------
> > > > > To unsubscribe, e-mail: users-unsubscribe@netbeans.apache.org (mailto:users-unsubscribe@netbeans.apache.org)
> > > > > For additional commands, e-mail: users-help@netbeans.apache.org (mailto:users-help@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
Posted by Emilio Gallardo Cantella <ra...@gmail.com>.
To be honest, I think removing new projects in Ant might be too drastic
a change altogether. From my perspective, a good lot of people that
might still be using old Netbeans and the straightforward Ant support
might not even know Ant IS an actual thing in the IDE, more so that
their projects just work. I spent a few years doing Java and C/C++
projects on Netbeans for uni, and never had to nor was encouraged to
touch the build system (Ant, make, cmake). You could argue that it might
be a deficiency of the curriculum, but in terms of function it is not a
requirement for learning a language or practicing it.
Maven and Gradle are nice, but they require additional steps to work
right now, and are not as straightforward, which most users and
specially novices would find friendlier. The actual closest to
get-up-and-go is Gradle, not Maven at all, from both a completely clean
install or build of Netbeans - and I have tested it multiple times.
What I would suggest is grabbing the whole set Ant-based functions,
projects and modules and disable them by default, but introduce a way
for users, and a prompt for example, to allow them to activate that set
of projects from within the New Project Dialog. As an example, instead
of the "Java with Ant" category, maybe there could be a "Legacy" folder
icon that when selected displays in the "Projects" subwindow a prompt to
activate Java with Ant, along with a small blurb about that having been
the old standard for projects. Moreover, to make it more friendly, the
blurb could say something like "if you cannot open/Netbeans does not
recognize your old Projects, activate this and see if it works"
I know this might be a bit beyond the topic of this thread, but this
seems something a bit too drastic to do piecemeal such as disabling new
projects for Ant at all
Thanks,
Emilio G.C.
On 4/20/2021 17:28, Sean Carrick wrote:
>
> 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 <tjwolf@gmail.com
>> <ma...@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 <marco@markreds.it
>> <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
>>> <mitch_ml@claborn.net <ma...@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 <pszudzik@throwarock.com
>>> <ma...@throwarock.com>
>>> <mailto:pszudzik@throwarock.com
>>> <ma...@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
>>> >>> <wayne@connect-mobile.co.za
>>> <ma...@connect-mobile.co.za>
>>> <mailto:wayne@connect-mobile.co.za
>>> <ma...@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
>>> >>
>>>
>>> ---------------------------------------------------------------------
>>> To unsubscribe, e-mail:
>>> users-unsubscribe@netbeans.apache.org
>>> <ma...@netbeans.apache.org>
>>> For additional commands, e-mail:
>>> users-help@netbeans.apache.org
>>> <ma...@netbeans.apache.org>
>>>
>>> For further information about the NetBeans mailing lists, visit:
>>> https://cwiki.apache.org/confluence/display/NETBEANS/Mailing+lists
>>> <https://cwiki.apache.org/confluence/display/NETBEANS/Mailing+lists>
>>>
>>
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: users-unsubscribe@netbeans.apache.org
>> <ma...@netbeans.apache.org>
>> For additional commands, e-mail:
>> users-help@netbeans.apache.org
>> <ma...@netbeans.apache.org>
>>
>> For further information about the NetBeans mailing lists, visit:
>> https://cwiki.apache.org/confluence/display/NETBEANS/Mailing+lists
>> <https://cwiki.apache.org/confluence/display/NETBEANS/Mailing+lists>
>>
Re: removing the "new project" support for Ant projects
Posted by Sean Carrick <se...@pekinsoft.com>.
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 <tjwolf@gmail.com
> <ma...@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 <marco@markreds.it
> <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
>> <mitch_ml@claborn.net <ma...@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 <pszudzik@throwarock.com
>> <ma...@throwarock.com>
>> <mailto:pszudzik@throwarock.com
>> <ma...@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
>> >>> <wayne@connect-mobile.co.za
>> <ma...@connect-mobile.co.za>
>> <mailto:wayne@connect-mobile.co.za
>> <ma...@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
>> >>
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: users-unsubscribe@netbeans.apache.org
>> <ma...@netbeans.apache.org>
>> For additional commands, e-mail:
>> users-help@netbeans.apache.org
>> <ma...@netbeans.apache.org>
>>
>> For further information about the NetBeans mailing lists, visit:
>> https://cwiki.apache.org/confluence/display/NETBEANS/Mailing+lists
>>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@netbeans.apache.org
> <ma...@netbeans.apache.org>
> For additional commands, e-mail:
> users-help@netbeans.apache.org
> <ma...@netbeans.apache.org>
>
> For further information about the NetBeans mailing lists, visit:
> https://cwiki.apache.org/confluence/display/NETBEANS/Mailing+lists
>
Fwd: Delivery Status Notification (Failure)
Posted by Will Hartung <wi...@gmail.com>.
---------- Forwarded message ---------
From: Mail Delivery Subsystem <ma...@googlemail.com>
Date: Tue, Apr 20, 2021 at 1:33 PM
Subject: Delivery Status Notification (Failure)
To: <wi...@gmail.com>
[image: Error Icon]
Address not found
Your message wasn't delivered to *geertjan.wielenga@googlemail.com.invalid*
because the domain googlemail.com.invalid couldn't be found. Check for
typos or unnecessary spaces and try again.
The response was:
DNS Error: 4858257 DNS type 'mx' lookup of googlemail.com.invalid responded
with code NXDOMAIN Domain name not found: googlemail.com.invalid
---------- Forwarded message ----------
From: Will Hartung <wi...@gmail.com>
To: Geertjan Wielenga <ge...@googlemail.com.invalid>
Cc:
Bcc:
Date: Tue, 20 Apr 2021 13:33:34 -0700
Subject: Re: removing the "new project" support for Ant projects
On Tue, Apr 20, 2021 at 12:33 PM Geertjan Wielenga
<ge...@googlemail.com.invalid> wrote:
> No one is suggesting removing support for Ant altogether.
>
> The suggestion is to remove the possibility of creating new Ant projects.
>
And to be fair, the problem is not with Ant per se. The problem is simply
that the Ant projects and wizards within the IDE are not being supported.
And that lack of support leads to bad experiences, especially with new
users. And by new users, I mean folks new to Java, new to NB, or just new
to whatever tech they want to try ("Gee, what's it like writing a web
service?").
I have nothing against Ant, I don't like the bad experiences in precisely
the place where a bad experience can be quite disrupting -- first contact
with the IDE.
As the paraphrase goes: "Patches welcome". If someone would like to chime
in, step up, and audit and update the Ant projects, then the door is wide
open.
But having them linger in limbo just isn't satisfactory to me, but I don't
think someone would want me (or anyone) to just make a pull request yanking
them out.
Regards,
Will Hartung
Re: removing the "new project" support for Ant projects
Posted by Geertjan Wielenga <ge...@googlemail.com.INVALID>.
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 <tj...@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 <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 <
>> mitch_ml@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 <pszudzik@throwarock.com <mailto:
>> pszudzik@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
>>
>> >>> <wayne@connect-mobile.co.za <ma...@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
>>
>> >>
>>
>>
>> ---------------------------------------------------------------------
>>
>> To unsubscribe, e-mail: users-unsubscribe@netbeans.apache.org
>>
>> For additional commands, e-mail: users-help@netbeans.apache.org
>>
>>
>> For further information about the NetBeans mailing lists, visit:
>>
>> https://cwiki.apache.org/confluence/display/NETBEANS/Mailing+lists
>>
>>
>>
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: users-unsubscribe@netbeans.apache.org
>> For additional commands, e-mail: users-help@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
Posted by Thomas Wolf <tj...@gmail.com>.
+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 <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 <mi...@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 <pszudzik@throwarock.com <mailto:
> pszudzik@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
>
> >>> <wayne@connect-mobile.co.za <ma...@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
>
> >>
>
>
> ---------------------------------------------------------------------
>
> To unsubscribe, e-mail: users-unsubscribe@netbeans.apache.org
>
> For additional commands, e-mail: users-help@netbeans.apache.org
>
>
> For further information about the NetBeans mailing lists, visit:
>
> https://cwiki.apache.org/confluence/display/NETBEANS/Mailing+lists
>
>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@netbeans.apache.org
> For additional commands, e-mail: users-help@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
Posted by Bayless Kirtley <bk...@cox.net>.
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 <mi...@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 <pszudzik@throwarock.com <ma...@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
>>>>> <wayne@connect-mobile.co.za <ma...@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
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: users-unsubscribe@netbeans.apache.org
>> For additional commands, e-mail: users-help@netbeans.apache.org
>>
>> For further information about the NetBeans mailing lists, visit:
>> https://cwiki.apache.org/confluence/display/NETBEANS/Mailing+lists
>>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@netbeans.apache.org
> For additional commands, e-mail: users-help@netbeans.apache.org
>
> For further information about the NetBeans mailing lists, visit:
> https://cwiki.apache.org/confluence/display/NETBEANS/Mailing+lists
>
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@netbeans.apache.org
For additional commands, e-mail: users-help@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
Posted by Will Hartung <wi...@gmail.com>.
On Tue, Apr 20, 2021 at 11:43 PM Thomas Kellerer <sh...@gmx.net> 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
Posted by Thomas Kellerer <sh...@gmx.net>.
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 <mi...@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 <pszudzik@throwarock.com <ma...@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-unsubscribe@netbeans.apache.org
For additional commands, e-mail: users-help@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
Posted by Owen Thomas <ow...@gmail.com>.
Crikey! Looks like I'll have to migrate to Maven then. When in Rome.
On Wed, 21 Apr 2021 at 19:20, John Burgess
<Jo...@riskdecisions.com.invalid> wrote:
> +1 also for me to not eliminating Ant support for new (or existing)
> projects.
>
> -----Original Message-----
> From: Marco Rossi <ma...@markreds.it>
> Sent: 20 April 2021 20:10
> To: Mitch Claborn <mi...@claborn.net>
> 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_ml@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 <pszudzik@throwarock.com <mailto:
> pszudzik@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
> >>>> <wayne@connect-mobile.co.za <ma...@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
> >>>
> >
> > ---------------------------------------------------------------------
> > To unsubscribe, e-mail: users-unsubscribe@netbeans.apache.org
> > For additional commands, e-mail: users-help@netbeans.apache.org
> >
> > For further information about the NetBeans mailing lists, visit:
> > https://cwiki.apache.org/confluence/display/NETBEANS/Mailing+lists
> >
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@netbeans.apache.org
> For additional commands, e-mail: users-help@netbeans.apache.org
>
> For further information about the NetBeans mailing lists, visit:
> https://cwiki.apache.org/confluence/display/NETBEANS/Mailing+lists
>
> Terms & Conditions<
> http://www.riskdecisions.com/risk-decisions-terms-and-conditions>
> Unsubscribe<
> https://riskdecisions.us16.list-manage.com/unsubscribe?u=e2d6b14eee9707f9d08914b88&id=494a0816dd>
> to stop receiving communications from Risk Decisions
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@netbeans.apache.org
> For additional commands, e-mail: users-help@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
Posted by John Burgess <Jo...@riskdecisions.com.INVALID>.
+1 also for me to not eliminating Ant support for new (or existing) projects.
-----Original Message-----
From: Marco Rossi <ma...@markreds.it>
Sent: 20 April 2021 20:10
To: Mitch Claborn <mi...@claborn.net>
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 <mi...@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 <pszudzik@throwarock.com <ma...@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
>>>> <wayne@connect-mobile.co.za <ma...@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
>>>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@netbeans.apache.org
> For additional commands, e-mail: users-help@netbeans.apache.org
>
> For further information about the NetBeans mailing lists, visit:
> https://cwiki.apache.org/confluence/display/NETBEANS/Mailing+lists
>
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@netbeans.apache.org
For additional commands, e-mail: users-help@netbeans.apache.org
For further information about the NetBeans mailing lists, visit:
https://cwiki.apache.org/confluence/display/NETBEANS/Mailing+lists
Terms & Conditions<http://www.riskdecisions.com/risk-decisions-terms-and-conditions>
Unsubscribe<https://riskdecisions.us16.list-manage.com/unsubscribe?u=e2d6b14eee9707f9d08914b88&id=494a0816dd> to stop receiving communications from Risk Decisions
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@netbeans.apache.org
For additional commands, e-mail: users-help@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
Posted by Marco Rossi <ma...@markreds.it>.
+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 <mi...@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 <pszudzik@throwarock.com <ma...@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
>>>> <wayne@connect-mobile.co.za <ma...@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
>>>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@netbeans.apache.org
> For additional commands, e-mail: users-help@netbeans.apache.org
>
> For further information about the NetBeans mailing lists, visit:
> https://cwiki.apache.org/confluence/display/NETBEANS/Mailing+lists
>
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@netbeans.apache.org
For additional commands, e-mail: users-help@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
Posted by Mitch Claborn <mi...@claborn.net>.
+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 <pszudzik@throwarock.com
>> <ma...@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
>>> <wayne@connect-mobile.co.za <ma...@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
>>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@netbeans.apache.org
For additional commands, e-mail: users-help@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
Posted by John Burgess <Jo...@riskdecisions.com.INVALID>.
Completely agree. Ant works and doesn’t require you to write plugins just to customise the build process.
From: David <dj...@start.ca>
Sent: 20 April 2021 23:04
To: Lisa Ruby <lb...@protonmail.com>; users@netbeans.apache.org
Subject: Re: removing the "new project" support for Ant projects
+1!
On Tue, 2021-04-20 at 17:10 +0000, 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 <ps...@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 <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
Terms & Conditions<http://www.riskdecisions.com/risk-decisions-terms-and-conditions>
Unsubscribe<https://riskdecisions.us16.list-manage.com/unsubscribe?u=e2d6b14eee9707f9d08914b88&id=494a0816dd> to stop receiving communications from Risk Decisions
Re: removing the "new project" support for Ant projects
Posted by David <dj...@start.ca>.
+1!
On Tue, 2021-04-20 at 17:10 +0000, 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 <ps...@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 <
> > > > wayne@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
Posted by Jerome Lelasseux <le...@yahoo.com.INVALID>.
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 <wi...@gmail.com> a écrit :
On Tue, Apr 20, 2021 at 10:10 AM Lisa Ruby <lb...@protonmail.com.invalid> 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
Posted by Will Hartung <wi...@gmail.com>.
On Tue, Apr 20, 2021 at 10:10 AM Lisa Ruby <lb...@protonmail.com.invalid>
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
Posted by Lisa Ruby <lb...@protonmail.com.INVALID>.
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 <ps...@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 <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
Posted by Sean Carrick <se...@pekinsoft.com>.
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 <pszudzik@throwarock.com
> <ma...@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
>> <wayne@connect-mobile.co.za <ma...@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
Posted by Geertjan Wielenga <ge...@googlemail.com.INVALID>.
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 <ps...@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 <
> wayne@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
>
>
>