Maven NBM comments

Revision as of 11:13, 6 January 2010 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). http://fisheye.codehaus.org/changelog/mojo/?cs=11406

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 Let me rephrase: not a documentation problem; there simply does not appear to be any public repo for betas or dev builds. Building from sources is not a reasonable option for most people.Betas and dev builds are mostly relevant to IDE module devs. The platform crowd is usually happy with releases. Tracked under [1]

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. But then why the bogus display category? And why no comment in the localizing bundle explaining this system? It's bogus as it's not worth prompting the users for real value in the archetype. And it might be required by the plugin manager (but not sure about it)

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. There is an open RFE for an apisupport template to create an empty layer file.

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 - https://netbeans.org/bugzilla/show_bug.cgi?id=97170 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/application-1.0-SNAPSHOT.zip - 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) Building the ZIP during install phase would be fine so long as the routine edit - compile - debug cycle does not depend on it.

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.. The update_tracking dir is not physically present in an NBM but can be trivially reconstructed from the contents of an NBM, as Auto Update does and as jtulach's recently created Ant task does.Well, why bother creating it in the first place then? MNBMODULE-72

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.
------------------------------------------------------------------------
[ERROR]BUILD FAILURE
------------------------------------------------------------------------
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 described 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. It would have to be some sort of api support specific codebase. It's not offered because it's not indexed (not yet built), but the Open projects tab should list it. Drag and drop doesn't work in most places as it's additional work with the paste types.. Most nodes in the IDE don't support it..

No obvious place to configure public packages of a module. I guess you have to manually edit manifest.mf? nbm-maven-plugin configuration in pom This should be handled in a GUI. Sure, as many other stuff visually editable in ant apisupport..

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. Seems like a bug in the IDE wizard implementation. I call it heuristics. We cannot create modules depending on the current IDE, we need to anchor on some existing version. And it should be the version used by the project (to avoid having some deps against 6.8 and some 6.7.

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 INSANE is clearly in the repository, since adding an explicit dep on it works. I see. It seems to be connected to the maven-compile/nb-runtime dependency tree problem. all modules with public packages get dropped in o.n.api groupId, and get the o.n.modules groupIds cut.. Works fine for main sources, but I guess fails for test environment.

"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