@Tim Great job with the contrib. If one wants to use some of them, how should he proceed? Clone the repo, build all projects and then load the generated NBMs in its NB IDE?
Cheers On Tue, Sep 3, 2019 at 4:46 PM Robert Scholte <rfscho...@apache.org> wrote: > This is all very useful information. > > To answer this question: > > 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? > > I'd start with the first phrase. One can learn a lot from doing such > exercises. > If the result is worth donating back, I'd be happy to do so. > > thanks, > Robert > > On Tue, 03 Sep 2019 09:26:07 +0200, Tim Boudreau <niftin...@gmail.com> > wrote: > > > 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 > > --------------------------------------------------------------------- > To unsubscribe, e-mail: dev-unsubscr...@netbeans.apache.org > For additional commands, e-mail: dev-h...@netbeans.apache.org > > For further information about the NetBeans mailing lists, visit: > https://cwiki.apache.org/confluence/display/NETBEANS/Mailing+lists > > > >
