Maven NBM comments

Revision as of 09:14, 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. Generic maven issue. Same applies to javaee ear projects. a pom-packaging project is the only one with allowed modules section, while it's not allowed to have a binary artifact associated with it.

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.Too bad. Maven is in general slower than ant. might be better with m3, but still will be slower as it does more. the zip file is created in "package" phase, while the assembled app is created in process-resources phase. So zipping can be eliminated for running. However it *has to* be created when running mvn install. A non-pom packaging is required to have an associated binary artifact (in this case the app's zip)

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. Is it? is the update tracking content available in the nbm files? if not, too bad. There is not other source of information about modules than it's POM and nbm file. I do find the various netbeans module system files rather confusing and overlapping..

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.THE MAJOR ISSUE with the plugin. There is inconsistence between maven compile dependency tree and the runtime netbeans dependencies. Might be fixable in maven3 when we might get complete control over the maven dependency tree resolution. For now the current rules are dewscribed in documentation.

Output from annotation processors omitted from Maven output. (Known & filed Maven bug.)Annotation processing in general not working well with maven project unfortunately.

Unit test utilities from NB modules ought to be in the repo as module test JARs, e.g. MockLookup.Possibly. The challenge is how to do it automagically with nbm:populate-repository goal.

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