Maven NBM comments

Revision as of 02:39, 27 November 2009 by Jglick (Talk | contribs)

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.

org.netbeans.cluster:platform10:... is not a good artifact coordinate. Should use platform with no number.

Used NB release 6.7 as default platform. Not obvious how to build against 6.8 betas, 6.9 dev builds, etc.

Archetype refers to a nonexistent license file.

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.

Important Files and Project Files ought to be merged.

Should not create an XML layer by default.

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 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.

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.

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.)

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