Re: Deployment Tutorial Source Files

[antonio]

You are welcome!

If this is linked from a tutorial you may want:

a) To update the link in the tutorial page (you can modify it in github 
using the "edit" button).


b) To upload the sample somewhere (github? gitlab?) and then send a link 
to the repository.


By doing so the next person will have it easy to find the samples.

Cheers,
Antonio

El 21/4/21 a las 23:31, Peter escribió:

Perfect! Thank you.

On 2021/04/21 21:00:55, antonio  wrote:

Yep

http://web.archive.org/web/2012060100*/https://netbeans.org/projects/samples/downloads/download/Samples%2FJava%2FDeploymentTutorial.zip

El 21/4/21 a las 20:16, Peter Ream escribió:

I am looking at the netbeans website “Java SE Learning Trail”,
specifically “Packaging and Distributing Java Desktop Application.”
There is a reference to “Deployment Tutorial Source Files” :

https://netbeans.org/projects/samples/downloads/download/Samples%252FJava%252FDeploymentTutorial.zip


Does this zip file exist somewhere since decommissioning netbeans.org
?

Thank you.



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

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




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

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



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

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

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

[Owen Thomas]

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

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

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

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

Done.

  Owen.

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

[Scott Palmer]

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

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

apply plugin: ‘java’

or

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

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

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


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


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

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

Re: Deployment Tutorial Source Files

[Peter]

Perfect! Thank you.

On 2021/04/21 21:00:55, antonio  wrote: 
> Yep
> 
> http://web.archive.org/web/2012060100*/https://netbeans.org/projects/samples/downloads/download/Samples%2FJava%2FDeploymentTutorial.zip
> 
> El 21/4/21 a las 20:16, Peter Ream escribió:
> > I am looking at the netbeans website “Java SE Learning Trail”, 
> > specifically “Packaging and Distributing Java Desktop Application.” 
> > There is a reference to “Deployment Tutorial Source Files” :
> > 
> > https://netbeans.org/projects/samples/downloads/download/Samples%252FJava%252FDeploymentTutorial.zip
> >  
> > 
> > 
> > Does this zip file exist somewhere since decommissioning netbeans.org 
> > ?
> > 
> > Thank you.
> > 
> 
> -
> To unsubscribe, e-mail: users-unsubscr...@netbeans.apache.org
> For additional commands, e-mail: users-h...@netbeans.apache.org
> 
> For further information about the NetBeans mailing lists, visit:
> https://cwiki.apache.org/confluence/display/NETBEANS/Mailing+lists
> 
> 

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

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

Re: Deployment Tutorial Source Files

[antonio]

Yep

http://web.archive.org/web/2012060100*/https://netbeans.org/projects/samples/downloads/download/Samples%2FJava%2FDeploymentTutorial.zip

El 21/4/21 a las 20:16, Peter Ream escribió:
I am looking at the netbeans website “Java SE Learning Trail”, 
specifically “Packaging and Distributing Java Desktop Application.” 
There is a reference to “Deployment Tutorial Source Files” :


https://netbeans.org/projects/samples/downloads/download/Samples%252FJava%252FDeploymentTutorial.zip 



Does this zip file exist somewhere since decommissioning netbeans.org 
?


Thank you.



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

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

Deployment Tutorial Source Files

[Peter Ream]

I am looking at the netbeans website “Java SE Learning Trail”, specifically
“Packaging and Distributing Java Desktop Application.” There is a reference
to “Deployment Tutorial Source Files” :

https://netbeans.org/projects/samples/downloads/download/Samples%252FJava%252FDeploymentTutorial.zip

Does this zip file exist somewhere since decommissioning netbeans.org?

Thank you.

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

[Will Hartung]

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

> Another +1 for NOT removing Ant support.
>

Nobody is talking about removing Ant support completely.

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

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

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

Regards,

Will Hartung

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

[Will Hartung]

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

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

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

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


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

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

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

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


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

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


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

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

[Sean Carrick]

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

+1

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

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

[Geertjan Wielenga]

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

Gj

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

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

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

[Sean Carrick]

GJ,

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

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

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

-SC



signature.asc
Description: OpenPGP digital signature

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

[Sean Carrick]

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

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

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

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

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

-SC

Re: Netbeans plugins site is down rendering netbeans useless

[antonio]

Hi all,

This message is in violation of the Apache Software Foundation Code of 
Conduct.


We expect participants in our community to meet these standards in all 
their interactions and to help others to do so as well.


Thanks,
Antonio


[1]
https://www.apache.org/foundation/policies/conduct

On 21/04/2021 11:01, Som Lima wrote:

I don't know why you bother responding to this kind of gutter criticism.

It is just  the way these Indians try to   impose their "expertise" in IT.

By finding faults. Solutions which is beyond their control.



On Wed, 21 Apr 2021, 09:43 Geertjan Wielenga, 
 wrote:


You need to move away from 11.1.

When you do that, this problem will be solved. Ideally, use 12.3,
the latest release.

Gj

On Wed, 21 Apr 2021 at 10:36, Pradyut Bhattacharya
mailto:prad...@yandex.com>> wrote:

I'm using Netbeans 11.1 and need to a open a JS file in my project.

I need to install the Oracle JS Parser for Netbeans which I
cannot do so because the site - plugins.netbeans.org
 is down.

I'm getting this error - "Networking problem in

http://plugins.netbeans.org/nbpluginportal/files/nbms/1552395301_org-netbeans-libs-oracle-jsparser.nbm


 "

Is there anyway I can install it manually otherwise I cannot
resume work with Netbeans rendering it useless.
Regards,
Pradyut Bhattacharya


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

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


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




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

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

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

[Don]

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


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

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

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

[Geertjan Wielenga]

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

Gj

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

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

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

[Sean Carrick]

Will,

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

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

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

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

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

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

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

-SC

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

Re: Netbeans plugins site is down rendering netbeans useless

[Geertjan Wielenga]

No, you don't, for the Oracle JS Parser, if you have a problem with that,
it means you're using an old version of NetBeans. Currently that parser is
bundled with NetBeans, so installing it or downloading it separately is not
needed.

Gj

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

> I need to install the Oracle JS Parser for Netbeans which I cannot do so
> because the site - plugins.netbeans.org is down.
>
> You need to go to: https://plugins.netbeans.apache.org/
>
> The netbeans.org site was decommissioned last month...
>
> -SC
>

Re: Netbeans plugins site is down rendering netbeans useless

[Sean Carrick]

I need to install the Oracle JS Parser for Netbeans which I cannot
do so because the site - plugins.netbeans.org is down.

You need to go to: https://plugins.netbeans.apache.org/

The netbeans.org site was decommissioned last month...

-SC

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

[Owen Thomas]

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

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

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

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

[John Burgess]

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

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

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

Mark Reds

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

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

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

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

Re: Netbeans plugins site is down rendering netbeans useless

[Geertjan Wielenga]

Speaking of gutter criticism, no more e-mails like this to this mailing
list, Som Lima: we want nothing like this at all here (or anywhere).

Gj

On Wed, 21 Apr 2021 at 11:01, Som Lima  wrote:

> I don't know why you bother responding to this kind of gutter criticism.
>
> It is just  the way these Indians try to   impose their "expertise" in IT.
>
> By finding faults. Solutions which is beyond their control.
>
>
>
> On Wed, 21 Apr 2021, 09:43 Geertjan Wielenga,
>  wrote:
>
>> You need to move away from 11.1.
>>
>> When you do that, this problem will be solved. Ideally, use 12.3, the
>> latest release.
>>
>> Gj
>>
>> On Wed, 21 Apr 2021 at 10:36, Pradyut Bhattacharya 
>> wrote:
>>
>>> I'm using Netbeans 11.1 and need to a open a JS file in my project.
>>>
>>> I need to install the Oracle JS Parser for Netbeans which I cannot do so
>>> because the site - plugins.netbeans.org is down.
>>>
>>>
>>>
>>> I'm getting this error - "Networking problem in
>>> http://plugins.netbeans.org/nbpluginportal/files/nbms/1552395301_org-netbeans-libs-oracle-jsparser.nbm
>>>  "
>>>
>>>
>>> Is there anyway I can install it manually otherwise I cannot resume work
>>> with Netbeans rendering it useless.
>>>
>>>
>>> Regards,
>>> Pradyut Bhattacharya
>>>
>>>
>>>
>>>
>>> -
>>> To unsubscribe, e-mail: users-unsubscr...@netbeans.apache.org
>>> For additional commands, e-mail: users-h...@netbeans.apache.org
>>>
>>> For further information about the NetBeans mailing lists, visit:
>>> https://cwiki.apache.org/confluence/display/NETBEANS/Mailing+lists
>>
>>

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

[John Burgess]

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

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

+1!

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

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

Gj

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

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


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

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





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


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


Well, it's several things.

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

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

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

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

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

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

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

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

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

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

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

Regards,

Will Hartung



Terms & 

Re: Netbeans plugins site is down rendering netbeans useless

[Som Lima]

I don't know why you bother responding to this kind of gutter criticism.

It is just  the way these Indians try to   impose their "expertise" in IT.

By finding faults. Solutions which is beyond their control.



On Wed, 21 Apr 2021, 09:43 Geertjan Wielenga,
 wrote:

> You need to move away from 11.1.
>
> When you do that, this problem will be solved. Ideally, use 12.3, the
> latest release.
>
> Gj
>
> On Wed, 21 Apr 2021 at 10:36, Pradyut Bhattacharya 
> wrote:
>
>> I'm using Netbeans 11.1 and need to a open a JS file in my project.
>>
>> I need to install the Oracle JS Parser for Netbeans which I cannot do so
>> because the site - plugins.netbeans.org is down.
>>
>>
>>
>> I'm getting this error - "Networking problem in
>> http://plugins.netbeans.org/nbpluginportal/files/nbms/1552395301_org-netbeans-libs-oracle-jsparser.nbm
>>  "
>>
>>
>> Is there anyway I can install it manually otherwise I cannot resume work
>> with Netbeans rendering it useless.
>>
>>
>> Regards,
>> Pradyut Bhattacharya
>>
>>
>>
>>
>> -
>> To unsubscribe, e-mail: users-unsubscr...@netbeans.apache.org
>> For additional commands, e-mail: users-h...@netbeans.apache.org
>>
>> For further information about the NetBeans mailing lists, visit:
>> https://cwiki.apache.org/confluence/display/NETBEANS/Mailing+lists
>
>

Re: Netbeans plugins site is down rendering netbeans useless

[Geertjan Wielenga]

You need to move away from 11.1.

When you do that, this problem will be solved. Ideally, use 12.3, the
latest release.

Gj

On Wed, 21 Apr 2021 at 10:36, Pradyut Bhattacharya 
wrote:

> I'm using Netbeans 11.1 and need to a open a JS file in my project.
>
> I need to install the Oracle JS Parser for Netbeans which I cannot do so
> because the site - plugins.netbeans.org is down.
>
>
>
> I'm getting this error - "Networking problem in
> http://plugins.netbeans.org/nbpluginportal/files/nbms/1552395301_org-netbeans-libs-oracle-jsparser.nbm
>  "
>
>
> Is there anyway I can install it manually otherwise I cannot resume work
> with Netbeans rendering it useless.
>
>
> Regards,
> Pradyut Bhattacharya
>
>
>
>
> -
> To unsubscribe, e-mail: users-unsubscr...@netbeans.apache.org
> For additional commands, e-mail: users-h...@netbeans.apache.org
>
> For further information about the NetBeans mailing lists, visit:
> https://cwiki.apache.org/confluence/display/NETBEANS/Mailing+lists

Netbeans plugins site is down rendering netbeans useless

[Pradyut Bhattacharya]

I'm using Netbeans 11.1 and need to a open a JS file in my project.I need to install the Oracle JS Parser for Netbeans which I cannot do so because the site - plugins.netbeans.org is down. I'm getting this error - "Networking problem in http://plugins.netbeans.org/nbpluginportal/files/nbms/1552395301_org-netbeans-libs-oracle-jsparser.nbm " Is there anyway I can install it manually otherwise I cannot resume work with Netbeans rendering it useless.  Regards,Pradyut Bhattacharya  
-
To unsubscribe, e-mail: users-unsubscr...@netbeans.apache.org
For additional commands, e-mail: users-h...@netbeans.apache.org

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

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

[Emma Atkinson]

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

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

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

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

Big thank you from me for all providing support.

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

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

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

[Thomas Kellerer]

Another +1 for NOT removing Ant support.

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

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

Just my 0.02€

Thomas

Marco Rossi schrieb am 20.04.2021 um 21:10:
> +1 also for me to not eliminating Ant support for new (or existing) projects.
>
> Mark Reds
>
>> Il giorno 20 apr 2021, alle ore 20:08, Mitch Claborn  
>> ha scritto:
>>
>> +1 for not eliminating Ant support for new (or existing) projects. We've 
>> been using Ant for a long time, and it still works just fine for us, so 
>> there is no payback in converting to Maven.
>>
>>
>> Mitch
>>
>> On 4/20/21 12:10 PM, Lisa Ruby wrote:
>>> For those of you who have used Maven for a long time it may seem simple and 
>>> straightforward, but for those of us who haven't it's not. I've struggled 
>>> to try and understand it and figure out how to use it for my software 
>>> project and gave up. And it's a huge amount of overhead, extra disk space 
>>> usage, and more bits and pieces to keep track of that isn't justifiable for 
>>> small simple projects. ANT works just fine for me, and I will keep using it 
>>> for as long as I possibly can. I need to focus my time on getting my 
>>> software out, not on the tools I have to use to do it.
>>> Lisa
>>> On 4/20/2021 10:00 AM, Geertjan Wielenga wrote:
 I agree, the Ant-based project creation should be removed and I disagree 
 that there should be any kind of conversion between Ant and Maven -- that 
 simply will never work and we'll spend the rest of our days fixing bugs in 
 that. To convert from Ant to Maven: create a new Maven project and copy 
 the Java source files from your Ant project into it.

 Gj

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

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

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

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

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

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

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

[Bradley Willcott]

I agree with a lot of what has been said:

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

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


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."(# 
).


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 > wrote:


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

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

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



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



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

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

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

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

[Owen Thomas]

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

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

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

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