FYI, I have thought of taking on that project. About a year ago I
converted the entire netbeans contrib repository to Maven -
https://github.com/timboudreau/netbeans-contrib
95% of it was automated, with manual cleanup frequently needed. The
tooling I used for it is basically my personal pile of Maven refactoring
tools I started writing in 2012 when converting a giant legacy Ant project
to Maven, and have added to whenever I had something that required
modifying hundreds of POM files (which is actually not an infrequent task
for me - things like library groupId changes, ensuring dependency versions
are all handled by to topmost parent's dependencyManagement across a tree
of projects, bulk updating versions with caveats, globally adding scm and
developer coordinates across a ton of projects, stuff like that).
It's all in Java - lots of XPath and DOM node chewing, but it works. But I
will say, it's kind of hideous - every refactoring I've ever needed to do
is commented out in its main method, and so forth. But it does contain
tools to read NetBeans build system project.xml files, figure out the
dependencies (with some hacked up mapping of NetBeans names for "external"
binaries to maven coordinates), and even generate the pom with the granular
specification-version dependencies the nbm-maven-plugin allows, which will
allow modules to load in a version that is "older" than the RELEASE*
version the Maven dependency specifies, so code that was compatible with
some older version of NetBeans stays compatible with it; and generates a
parent POM with a good <dependencyManagement> section for handling relative
dependencies.
Basically you need to:
- Find projects
- Read their project.xml's
- Read their manifests
- Find their bundle files if present so you can give the projects
human-friendly names off their localization info
- Generate POMs based on the project.xml contents (they basically express
the same things, so it's mostly a matter of mapping one system's quirks to
another one's)
- Specifically important to get right: compiler args, junit version
expected
- Move files into the right places (e.g. $basedir/manifest.mf ->
$basedir/src/main/nbm/manifest.mf, $basedir/test/unit -> $basedir/test/java
- Find all non-Java sources under src/ and move them to equivalent places
in resource directories
Most projects built upon conversion; the main pain point I recall was
getting unit tests working (in the case of contrib, many hadn't been
maintained in years and were incompatible with the code they tested); and
the fact that NetBeans mapping of groupId to "org.netbeans.api" vs.
"org.netbeans.modules" isn't very sane (things grow an API that didn't
originally have one, but for backward compatibility the groupId remains
"org.netbeans.modules"), though there is code that maps these correctly for
every module used by something in contrib.
The hard parts I'd imagine with the main NetBeans codebase are likely to be:
- A lot of custom Ant tasks - it might well be MORE work to generate code
to do those things using the antrun plugin than to figure out what they do
and write a maven plugin to do it - particularly the early parts of
bootstrapping the entire Ant build system - not to mention, you'd wind up
with pom files that are 80% embedded Ant stuff
- Integration UI tests (I wouldn't prioritize that) using Jemmy / Jelly
- Building the real application structure - the nbm-maven-plugin is far
more limited and won't help you much (if I want to "run" one module in a
multi-plugin project, there is no way to do that in-place - I have to have
a separate nbm-application packaging project that I'm constantly updating
the dependencies on, with a deathly slow build time, which needs to be
rebuilt from scratch every time I want to run it with updated modules)
- For real world use, Maven's idea of dependency versioning is pretty
inadequate to address NetBeans versioning coordinates, which involve
separate version-like fields for optional release-version, specification
version (closest to Maven versions...and not what the Maven plugins use),
implementation version (used for friend dependencies) and build number (the
default implementation version unless you specify something else)
So part of the question is, do you want to do this to say "hey cool, see,
it can be done" or so that the result actually *becomes* the NetBeans build
system? You'll make different choices based on the answer to that question.
If it would be helpful, I could share it, just bear in mind it ain't pretty
- it was written for personal use, and grew like a weed from there. Every
now and then I think I ought to clean it up and make a "Maven refactoring"
plugin for NetBeans, and in fact just this week I used some bits of it to
rewrite the Antlr plugin's Maven project support to not depend on Maven's
(goshawful and unweildy) API to chew on POMs. Let me know.
-Tim
