Maven NBM comments

Revision as of 08:26, 27 November 2009 by Mkleint (Talk | contribs)

Mostly writing down problems here, since the benefits of using Maven are the usual: easy access to remote dependencies, smooth integration of sources & Javadoc, etc.

Obsolete JUnit 3.8.1 is used as a dep by default. Should be using newest (currently 4.7).

Default value of ${brandingToken} in master POM is foo for some reason, and default cluster is foobar. Should be taken from app name. Historically it was a customizable parameter of the archetype, I've decided to default to something. Defaulting to archetype's artifactId sounds good, needs verification that chars allowed in artifactId are also allowed in branding token

org.netbeans.cluster:platform10:... is not a good artifact coordinate. Should use platform with no number.Agreed. A bug/unfinished item in nbm:populate-repository goal. MNBMODULE-67

Used NB release 6.7 as default platform. Not obvious how to build against 6.8 betas, 6.9 dev builds, etc. This should be reasonably obvious to people fluent with Maven who have read the nbm-maven-plugin documentation

Archetype refers to a nonexistent license file. Bug. See MNBMODULE-68 for more comments.

Initially created localizing bundle has only bogus entry OpenIDE-Module-Display-Category=foobar. Does not even set OpenIDE-Module-Name! Anyway this ought to be kept in synch with pom.xml#/project/name, perhaps by a build-time substitution. It seems this in fact happens, meaning the localizing bundle in sources is not used by default.Considered a feature. We create the loc bundle as a hint towards correct procedure. But If someone doesn't do it just now, as a convention we populate missing manifest entries from the pom.xml file.

Important Files and Project Files ought to be merged. Possibly. Not sure the layer file is actually a project file in terms of a maven project.

Should not create an XML layer by default. Disagree. Having it empty only triggers a warning at runtime that can be polished later, but correct creation of the layer file is not obvious. Unfortunately we don't have a convention-based location for the file (like we do have not for the generated one.

src/main/nbm dir is odd. These things do not feel like "sources". The module manifest could probably just be generated (with the NBM plugin config in the POM controlling some options) and module.xml would more naturally just be parts of the POM. The module file is deprecated, but unfortunately still necessary for some stuff. MNBMODULE-69

The branding module includes test packages, oddly. Even the source packages are empty so it's not clear why the dir even exists. There is no apparent GUI to customize the branding as in a suite app. test packages appearing is a consequence this issue - and is done in the IDE. Missing UI for any branding is an unfortunate fact.

It's not clear from the GUI where you should add dependencies. The nbm-application project has a lot of nbm-file dependencies (missing the rich dependency customization GUI found in regular suite projects); the nbm project has jar dependencies. If you add a dep to the nbm project which is missing from the app, you get an error dialog when you run the project. Adding a matching dep to the nbm-application project is not intuitive because you need to select an nbm-file dependency and the dialog does not offer this option; you need to add the type manually in the POM. All this should be made much more automatic, perhaps along the lines of EnhancedConfigurationOfNBRCPProjects#Jesse.27s .28more or less unrelated.29_proposal for dependency-based module includes.

The POM project being distinct from the nbm-application project is confusing. You cannot "Run" the POM project. If you "Run" the nbm-application project immediately after creating it, you get missing dependency problems... you need to first "Build" the POM project. Surely Maven could figure out that sibling projects need to be built first? And since the POM project is set as "main", Run Main Project does not work. Nor can I "Run" one of the nbm projects in the suite, so if I make a change to some module, I have to "Build" it (or the POM project), then "Run" the whole app - poor workflow. "Build with dependencies" works on the app project, though there is no global action binding for this.

Building is pretty slow - 14 seconds to build a hello-world app? Irritating that I have to build target/ - and copy it to my local repo - just to have the app built to the point that I can run it. With the Ant projects, you only build the final ZIP when it is really asked for. Maybe this could be moved into some kind of "distribution" phase, or maybe there can be some faster way to run the app in test mode.

The unpacked NBM artifacts included in the target installation dir and in the ZIP omit the update_tracking dir, so you would not be able to use Plugin Manager on the platform modules.

Handling of transitive dependencies is not very intuitive. I add org.netbeans.core.ide to a module, and a bunch of deps including org.openide.nodes appear. I write something using AbstractNode, build, and get (including spelling errors):

[ERROR]Project uses classes from transtive module
  org.netbeans.api:org-openide-nodes:jar:RELEASE67 which will
  not be accessible at runtime.
See above for failures in runtime NebBeans dependencies verification.

How do I correct this? The project already shows org.openide.nodes as a dep in the Libraries list. I have to add it "again"; it is not clear from the Libraries display that now it is a "real" dependency, not just transitively included. ("Transitive Dependency" under the artifact node's property sheet is still checked!) This whole system will be baffling to Maven users accustomed to transitive dependency management.

Output from annotation processors omitted from Maven output. (Known & filed Maven bug.)

Unit test utilities from NB modules ought to be in the repo as module test JARs, e.g. MockLookup.

If you add a new module under the POM project, no dep is added to the app project, so it is not included in the app by default. And it is not offered as a dep in the Add dialog. Nor does drag-and-drop work. Confusing.

No obvious place to configure public packages of a module. I guess you have to manually edit nbm-maven-plugin configuration in pom

Why do newly created modules get an automatic dependency on org.openide.util? Because of the IDE's wizards. These add dependencies to the project and we need an existing dependency present to have an anchor for version.

If you add org.netbeans.modules.nbjunit as a test dep to a module, NbTestCases will fail at runtime with a NCDFE; you need to also add org.netbeans.insane, which you might have thought would be included automatically as a transitive dependency. could be an issue with the populate-repository goal. or the insane module is just not present in the official distro

"This layer in context" does not show entries from sibling modules even if they are in the dependency list (and have been rebuilt after the layer modification and the IDE restarted). Anyway the GUI should probably be redesigned to put the context view on the app project. yes, context of layer files is confusing. If on nbm-application project, can be only read-only.

Not logged in. Log in, Register

By use of this website, you agree to the NetBeans Policies and Terms of Use. © 2012, Oracle Corporation and/or its affiliates. Sponsored by Oracle logo