You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@netbeans.apache.org by Eric Bresie <eb...@gmail.com> on 2023/01/07 16:25:33 UTC
Maven/Gradle Netbean Builds [Re: JUnit 5 Generated Tests Warning/Error]
On Sat, Jan 7, 2023 at 10:13 AM Eric Bresie <eb...@gmail.com> wrote:
>
> On Sat, Dec 31, 2022 at 11:18 AM Ernie Rael <er...@raelity.com> wrote:
>
> My solution, considering that ant is essentially deprecated in NetBeans,
>> was to convert projects to Maven or Gradle.
>
>
Well when working new projects the preference seems to be "not ant" but
what about existing ant projects (i.e. Netbeans)?
That is a bigger philosophical/paradigm change here. Are there any longer
term plans to migrate the Netbeans codebase build from ant to something
other (Maven or Gradle)?
It seems like if changed then handling the "external" dependencies can be
handled a little easier via the maven or gradle means using the applicable
repos (except for any legacy dependencies no longer available)
It may allow flexibility to use the plugins available (i.e. for quality,
security, etc. checks) in the process.
I know there was a "Mavenized" branch of contribs items available (1) at
some point, but not sure anything further came of it after that.
Maybe as an interim, there are "maven" plugins and ways to allow usage of
"ant" tasks as part of the migration process (2),(3),(4),(5) . Maybe some
initial basic maven poms can be introduced and leverage on the existing ant
and over time convert clusters or items from ant to say maven.
Or leveraging gradle (6).
Thoughts?
Eric Bresie
ebresie@gmail.com
(1) https://github.com/timboudreau/netbeans-contrib
(2)
https://stackoverflow.com/questions/1456901/how-to-wrap-an-ant-build-with-maven
(3) https://maven.apache.org/guides/mini/guide-using-ant.html
(4) https://maven.apache.org/plugins/maven-antrun-plugin/
(5) https://books.sonatype.com/mcookbook/reference/ch04s03.html
(6) https://docs.gradle.org/current/userguide/ant.html
Re: Maven/Gradle Netbean Builds [Re: JUnit 5 Generated Tests Warning/Error]
Posted by Eric Bresie <eb...@gmail.com>.
Thanks for the input guys.
I'm not trying to start a "build system holy war" here, just a general
discussion on the merits...
I acknowledge this is not something that would be done overnight (i.e. long
term project)...
A few thoughts below (EB>)...
Eric Bresie
ebresie@gmail.com
On Sat, Jan 7, 2023 at 2:24 PM Laszlo Kishalmi <la...@gmail.com>
wrote:
>
> On 1/7/23 08:47, Matthias Bläsing wrote:
> > Am Samstag, dem 07.01.2023 um 10:25 -0600 schrieb Eric Bresie:
> >> That is a bigger philosophical/paradigm change here. Are there any
> >> longer term plans to migrate the Netbeans codebase build from ant to
> >> something other (Maven or Gradle)?
>
EB> I want to say up front and agree with others, that ant has done well in
this context
> > I have to ask: What problem do you try to fix? Sure when the build is
>
EB> The problem is usage of an "older build" system instead of leveraging a
new build system as is common in java ecosystems.
EB> For example, from the original thread
On Sat, Dec 31, 2022 at 11:18 AM Ernie Rael <er...@raelity.com> wrote:
> My solution, considering that ant is essentially deprecated in NetBeans,
was to convert projects to Maven or Gradle.
EB> I know this is probably more in context of "creating new projects" as
opposed to existing projects but still when the trend in usage in the IDE
is to "not use ant" and/or this functionality is deprecated, it seems then
an alternative may be a way forward.
EB> In the same way, why update Netbeans code base to use a newer java
version and not just stick with an older one? Here I assume it's to adapt
to the changing ecosystem and to accommodate benefits of new features and
not get stagnant.
> converted to another build system the problems will magically go away.
> > Except they don't. Gradle has its own set of WTF elements, the same is
> > true for maven.
EB> I agree as with any system, they all have their quirks and
idiosyncrasies. Ant does as well.
EB> If migrated to another system then there would be a lot of up front
growing pains to get over
EB> I never said a migration would be doable overnight (i.e. did ask for a
"long term plan"), that was kind of why I suggested a "phased" approach
doing smaller batches.
> Well, I have a long term plan for that (doing a Gradle migration). This
> is not that easy. NetBeans build is an
> incredible peace of art. Replacing that with something else is hard,
> especially in the core platform. I had some wins, being able to compile
> the platform cluster with Gradle, though compiling is just one thing,
> and that's probably on the easier side.
>
> It is still in my mind, I see benefits of that effort.
>
> Though I have to admit, that what we have with Ant is good enough. Until
> someone really put the effort, and proves that it could be done, we
> shall not make a move.
>
EB> Tim converted over a lot of the "contrib" plugins previously so I think
in theory it's possible...but as mentioned it would require a lot of work.
Not sure if maybe he had any netbeans-tools or other mechanisms out there
to help in transition.
> > There are three things missing before changes could be done:
> >
> > - arguments why it is benefical to switch
>
EB> Ant is an older build system with the current java development
ecosystem moving more towards other build systems.
EB> Maven (and Gradle; going forward will reference Maven but can still
include Gradle as well) established a common convention for project
development across java ecosystem
EB> Maven provides built in dependency management capabilities (I know ant
may provide this indirectly with Ivy or the build infrastructure leveraging
the "external/binary-lists"; but these are kind of "patched on" instead of
internal to the build systems)
EB> Maven provides a plugin mechanism that provides a wealth of useful
code quality, security, test, assembly, and related functionality.
EB> Maven provides the means to monitor dependencies versioning (i.e. can
identify newer versions available, can identify dependencies with security
issues in need of updates, etc.)
EB> Maven, as with Ant, are "Apache" projects so leveraging this is always
a win-win for the Apache organization
> - preparations to counter all possible "what ifs"
>
EB> I'm not 100% sure what these "what ifs" might be but will try and think
of a few
EB> * What if some of the internal ant logic / targets do not migrate
easily?
EB> -> I would assume initially some of the "ant - maven" plugins may
allow continued usage of existing ant build configuration and over time the
individual portions can be migrated in phases
EB> -> In the event of something not fully accounted for, then may also be
able to further expand existing nb maven plugin adding additional goals /
functionality as needed
> - someone who takes up the fight and does the work
>
EB> Yes that is the big hurdle. My main reason for bringing it up was to
see if anyone has started thinking of this.
EB> Given my limited time (I'm having a hard enough time developing my
python plugin) and lack of expertise in the historical ant build I'm aware
that while I may be able to help some, not sure I'm necessarily the
best...we all have our day jobs...
> What is IMHO not a solution is a half migration, creating a hybrid
> > build using ant and gradle/maven. This was done by liferay and IMHO it
> > is a failure (oh for fun they also did not use plain gradle, they
> > patched their chosen gradle version...).
>
EB> Yeah I can see that as being another hurdle.
EB> My thinking was to phase it in, initially (1) leverage the ant-maven
mechanism at the starting point (2) transition small clusters/projects over
time (3) when all have transitioned then deprecate the ant-maven plugins
and leverage full maven usage. If work stops mid way then yes that risks a
"half migration"
> > Seriously: If you just want unittests, go with the existing solution.
> > If the pain is to high, add support for Junit 5, and if you want a
> > lifetime job, switch build systems.
> +1 on that one.
>
That is another problem for another discussion. I figured the build system
migration discussion was out of context of that JUnit discussion which is
why I moved it here.
Re: Maven/Gradle Netbean Builds [Re: JUnit 5 Generated Tests Warning/Error]
Posted by Laszlo Kishalmi <la...@gmail.com>.
On 1/7/23 08:47, Matthias Bläsing wrote:
> Hi,
>
> Am Samstag, dem 07.01.2023 um 10:25 -0600 schrieb Eric Bresie:
>> That is a bigger philosophical/paradigm change here. Are there any
>> longer term plans to migrate the Netbeans codebase build from ant to
>> something other (Maven or Gradle)?
> I have to ask: What problem do you try to fix? Sure when the build is
> converted to another build system the problems will magically go away.
> Except they don't. Gradle has its own set of WTF elements, the same is
> true for maven.
Well, I have a long term plan for that (doing a Gradle migration). This
is not that easy. NetBeans build is an
incredible peace of art. Replacing that with something else is hard,
especially in the core platform. I had some wins, being able to compile
the platform cluster with Gradle, though compiling is just one thing,
and that's probably on the easier side.
It is still in my mind, I see benefits of that effort.
Though I have to admit, that what we have with Ant is good enough. Until
someone really put the effort, and proves that it could be done, we
shall not make a move.
> There are three things missing before changes could be done:
>
> - arguments why it is benefical to switch
> - preparations to counter all possible "what ifs"
> - someone who takes up the fight and does the work
>
> What is IMHO not a solution is a half migration, creating a hybrid
> build using ant and gradle/maven. This was done by liferay and IMHO it
> is a failure (oh for fun they also did not use plain gradle, they
> patched their chosen gradle version...).
>
> Seriously: If you just want unittests, go with the existing solution.
> If the pain is to high, add support for Junit 5, and if you want a
> lifetime job, switch build systems.
+1 on that one.
>
> Greetings
>
> Matthias
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@netbeans.apache.org
> For additional commands, e-mail: dev-help@netbeans.apache.org
>
> For further information about the NetBeans mailing lists, visit:
> https://cwiki.apache.org/confluence/display/NETBEANS/Mailing+lists
>
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@netbeans.apache.org
For additional commands, e-mail: dev-help@netbeans.apache.org
For further information about the NetBeans mailing lists, visit:
https://cwiki.apache.org/confluence/display/NETBEANS/Mailing+lists
Re: Maven/Gradle Netbean Builds [Re: JUnit 5 Generated Tests Warning/Error]
Posted by Matthias Bläsing <mb...@doppel-helix.eu.INVALID>.
Hi,
Am Samstag, dem 07.01.2023 um 10:25 -0600 schrieb Eric Bresie:
> That is a bigger philosophical/paradigm change here. Are there any
> longer term plans to migrate the Netbeans codebase build from ant to
> something other (Maven or Gradle)?
I have to ask: What problem do you try to fix? Sure when the build is
converted to another build system the problems will magically go away.
Except they don't. Gradle has its own set of WTF elements, the same is
true for maven.
There are three things missing before changes could be done:
- arguments why it is benefical to switch
- preparations to counter all possible "what ifs"
- someone who takes up the fight and does the work
What is IMHO not a solution is a half migration, creating a hybrid
build using ant and gradle/maven. This was done by liferay and IMHO it
is a failure (oh for fun they also did not use plain gradle, they
patched their chosen gradle version...).
Seriously: If you just want unittests, go with the existing solution.
If the pain is to high, add support for Junit 5, and if you want a
lifetime job, switch build systems.
Greetings
Matthias
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@netbeans.apache.org
For additional commands, e-mail: dev-help@netbeans.apache.org
For further information about the NetBeans mailing lists, visit:
https://cwiki.apache.org/confluence/display/NETBEANS/Mailing+lists