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 <s...@pekinsoft.com
<mailto:s...@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
