Build installers goal

I did not notice any such message on dev@mojo.codehaus.org...?

Anyway, this would be a welcome addition to nbm-maven-plugin. People have repeatedly asked for a way to run this functionality as a regular Maven goal.

The current org.netbeans.modules.apisupport.installer.maven.actions.BuildInstallersAction does a bunch of computation and then runs Ant, which was I guess the quickest way to retrofit functionality originally designed for the Ant harness, but definitely not what we want. NBI is heavily based on Ant overall, and I do not foresee anyone refactoring it in the near future, but a Maven goal could at least pick up relevant properties from plugin configuration and use the antrun plugin to do the rest, which I guess is what your code does. BuildInstallersAction could then be deleted, and mojo-archetypes/netbeans-platform-app-archetype/src/main/resources/archetype-resources/application/pom.xml edited to run the new goal under -Pdeployment. org.netbeans.modules.apisupport.installer.maven.ui.ExtraPanel and org.netbeans.modules.apisupport.installer.ui.SuiteInstallerProjectProperties would need to be refactored to use POM configuration. I could probably find time to work on the IDE side if you can supply a patch for the plugin (or just the mojo source file).

http://netbeans.org/bugzilla/show_bug.cgi?id=202654 and http://netbeans.org/bugzilla/show_bug.cgi?id=202961 could probably be fixed cleanly this way.

This is original mojo.

Jesse, thanks for your interest and very fast reply.

Attached file contains existing mojo and all necessary resources. It should be compilable, I believe. The mojo itself precesses parameters and runs ant task to build stuff and create installers. Resources contain the complete original installer from Netbeans 6.9.1. Maybe some parts are not needed, but this pack works for me.

Following plugin dependency in the application pom makes things working:

<plugin>
<groupId>org.codehaus.mojo</groupId>
<artifactId>nbm-installers-plugin</artifactId>
<version>1.0</version>
<configuration>
<installerOsWindows>true</installerOsWindows>
<installerOsLinux>true</installerOsLinux>
<installerLicenseFile>../LICENSE.txt</installerLicenseFile>
<appIcon>../Globe48.png</appIcon>
<icon16>../Globe.png</icon16>
<instLeftCorner>../ilc.png</instLeftCorner>
<instRightCorner>../irc.png</instRightCorner>
<instWelcomeTop>../wlt.png</instWelcomeTop>
<instWelcomeBottom>../wlb.png</instWelcomeBottom>
<installerVerbose>2</installerVerbose>
</configuration>
</plugin>

Most configuration options are optional. All available settings are commented in the source mojo.

To dev@mojo.codehaus.org I guess you mean. Sorry, I read this only on occasion; filing issues in this component is more reliable.

Do not like parameters of type String which refer to files, such as appIcon; these should be of type File, in which case http://maven.apache.org/guides/plugin/guide-java-plugin-development.html#Files_and_Directories states that relative paths will be resolved by Maven itself.

Copying installer sources from a NB release into the plugin is not maintainable. Will need to find some way to include org-netbeans-libs-nbi-ant and/or org-netbeans-libs-nbi-engine from a named release.

Thanks for your comments. I will try to follow your recommendations in order to prepare a working patch to nbm-maven-plugin in a few days.

Note that trunk (3.7-SNAPSHOT) sources are actually organized into the plugin itself plus an artifact which merely wraps the harness code. Probably relevant parts of the org-netbeans-libs-nbi-* modules could be packed into the harness artifact. The setup is a little tricky because nbm-maven-harness cannot declare the NB <repository> - the enforcer rules for Maven Central would reject an attempt to upload it.

Here is the first version of the extension. All resources are unpacked in harness module. It's version should be increased or nbi resources can be collected in the third plugin.

There are two build scripts with changes included in mojo resources. The first is changed template introducing branding parameters which are not considered in the UI version.

The other script building the installer application needs simple fix to avoid random build failure due to problems with temporal files deletions.

Both script patches replacements are commented in the mojo code.

Where are the comments about script patch replacements? I do not like the idea of keeping copies of NBI code in the harness or mojo; necessary patches should be submitted upstream (to netbeans.org Bugzilla), and nbm-maven-harness/pom.xml may temporarily patch unpacked sources.

<id>>unpack-installer</id> is a typo (extra >).

The NB repo location should be defined in just one place, i.e.

<properties>
    <netbeans.repo>netbeans::default::http://bits.netbeans.org/maven2/</netbeans.repo>
</properties>
...
<remoteRepositories>${netbeans.repo}</remoteRepositories>

None of the changes to nbm-maven-plugin/pom.xml look both necessary and desirable. The POM already includes a (compile) dep on org.apache.ant:ant:1.8.2 (which supersedes ant-nodeps in this release). ant-apache-regexp should not be necessary on any JDK 1.4+, since java.util.regex will be used automatically. The runtime dep on commons-lang is unexplained.

Finally, a dep on com.sun:tools with system scope cannot be accepted, because it will render the POM unloadable on JDKs which do not have a tools.jar in this location. Seems to be used just for native2ascii. One option would be to add this dep in a profile (conditional on the file path existing), though this is not very portable. Another would be to create a custom Native2AsciiAdapter and use it from the Ant script (patching NBI). Another would be to create a class in the mojo sun.tools.native2ascii.Main with a public boolean convert(String argv[]) method (cannot be copied from JDK sources but may use the same signature).

harness/config/Modules/*.xml should not be unpacked. Probably the same for harness/modules/*.jar and harness/modules/locale/*.jar, since it seems that everything important for the mojo is in harness/modules/ext/*.jar. TBD whether the helloworld dirs can be removed too.

When I try to use the goal on a newly created app (from archetype), I get an error Icon file .../application/icon.png does not exist. Probably default-value="icon.png" and default-value="null" are bogus; try just @parameter. (According to http://maven.apache.org/developers/mojo-api-specification.html @optional does not exist.)

installerLicenseFile should be of type File, not String.

Exceptions should be wrapped with root cause: new MojoExecutionException( "Installer creation failed: " + ex , ex )

antHome is unset in my environment, leading to an NPE. Probably this whole block can be removed, but installerbuild/nbi_all/.common/common.xml has to be fixed to use <ant inheritrefs="false"> rather than <exec executable="${ant.executable}"> which is nonportable.

props should be a Map<String,String> rather than a Properties, allowing a simpler loop with no warning:

for ( Map.Entry<String,String> e : props.entrySet() ) {
    antProject.setProperty( e.getKey(), e.getValue() );
}

build-installers-2.patch reflects Jesse's notes. More specific comments follow:

Comments concerning scripts replacements were included in the BuildInstallersMojo.java in the place where patched scripts were copied. They have been removed by the last patch and patches are made from pom as suggested. template.xml does not need patch anymore as explained below, a very simple patch of product.xml is made and commented in nbm-maven-harness/pom.xml lines 139-143. Newly, common.xml is patched to replace exec with ant task.

Typo > and Netbeans repo location have been fixed as suggested.

Unnecessary dependencies were removed from pom.

I can't find a way how to take rid of dependency on tools.jar . Even if a fake native2ascii is created, build installers ant task fails because javac needs tools.jar as well and compilation of installer application fails. Nevertheless, tools.jar has to be a part of any jdk. If tools.jar is not present in ant's classpath, javac task fails. If it is not acceptable to keep the dependency in pom, other way how to fullfill the dependency requirement has to be found. Please advice.

harness/config is not unpacked anymore. harness/modules/*.jar are needed in compile classpath when installer is compiled. helloworld is the installer application itself.

The installer branding part was completely redesigned better way, I believe. Instead of defining of branding parameters in mojo and patching the template, option of including user template was added and branding parameters were removed from mojo. User template script overwrites template.xml. Parameters provided in the userSettings map are passed to it in runtime. For example, if patched template.xml included with previous build-installers.patch is pointed by application's pom, following definition generates branded installers equal to the result of previous patch version:

<templateFile>../template.xml</templateFile>
<userSettings>
    <nbi.icon.file>${basedir}/icon48.png</nbi.icon.file>
    <nbi.icon16.file>${basedir}/icon.png</nbi.icon16.file>
    <nbi.instleftcorner.file>${basedir}/ilc.png</nbi.instleftcorner.file>
    <nbi.instrightcorner.file>${basedir}/irc.png</nbi.instrightcorner.file>
    <nbi.instwelcometop.file>${basedir}/wlt.png</nbi.instwelcometop.file>
    <nbi.instwelcomebottom.file>${basedir}/wlb.png</nbi.instwelcomebottom.file>
</userSettings>

installerLicenseFile type is now File. Nested exceptions are wrapped as suggested.

commons.xml script is patched in pom to replace exec task with ant task. The patch is a little tricky because exec parameters are passed in the original script in the compact form, -DaName=aValue as a single parameter while ant task needs <property name="aName" value="aValue" />. In addition, the task is called several times with different nb.custom.parameter setting. Proposed patch works for me, but any future change in commons.xml can lead to problems. Systematic solution would be upstream change of exec tasks to ant which is out of the scope of my possibilities, I guess.

Finally, props type is changed to Map<String,String>.

product.xml patch has been submitted to Netbeans Bugzilla:
http://netbeans.org/bugzilla/show_bug.cgi?id=207518

Sorry for the delay - I am a bit overextended! Committed your second patch as revision 15764.

Regarding tools.jar dep - if it is unavoidable, I am at least moving it into a conditional profile (revision 15765). Otherwise the POM will be unloadable on operating systems which do not have this JAR in the same location, which is a critical problem since it makes projects using the plugin also unloadable.

Now for more issues. First and foremost, the mojo does not work, at least when I make a fresh NB platform app and add <goal>build-installers</goal> to its deployment profile:

Failed to execute goal org.codehaus.mojo:nbm-maven-plugin:3.7-SNAPSHOT:build-installers (extra)
 on project MNBMODULE-155-app: Installers creation failed:
.../application/target/installer/nbi/stub/template.xml:41:
 The following error occurred while executing this line:
.../application/target/installerbuild/build.xml:165:
 java.lang.NullPointerException

Then I am wondering why installerOsWindows and the others are all false by default. I think by default you should be building installers for all available platforms, with an option to suppress some of them. It makes little sense for the default behavior to be to build nothing.

You also neglected to call MavenProjectHelper.attachArtifact, so no secondary artifact will be produced by all this work - i.e. nothing will be installed to the local repo, deployed, published as a Hudson artifact, etc.

Please submit the common.xml patch upstream.

installerVerbose should probably be implied by the Maven verbosity (-e, -X, -q).

project.name seems a strange default for installDirName. <name> (right?) would typically be something with whitespace and a pretty label, whereas an install dir should be something using a conservative character set. netbeans.branding.token seems more natural.

Finally, the mojo is lacking decent documentation. The class itself has not even a summary sentence in its Javadoc. The templateFile and userSettings parameters are critical, but I would never guess what you should pass for them.

Also please get rid of FileUrlUtils if possible - check FileUtils in org.codehaus.plexus:plexus-utils etc. for standard utilities.

build-installers-3.patch covers the easy part of changes :

• MavenProjectHelper.attachArtifact is introduced for all generated installers - thanks for the idea;
• defaults for installers generation have been changed to true for all four types;
• default for installDirName changed to netbeans.branding.token. It's configurable, anyway.

Two topics are currently in progress - FileUrlUtils and documentation - and were not yet included in this simple fix.

Can you elaborate more in detail how easily transfer Maven verbosity settings to five Ant log levels, please? Is it a good idea to do this?

Finally, the most important:

I am not able to reproduce your issue. When created a fresh NB platform application on any of my computers (Widnows, Linux), made a clean build and run nbm:build-installers custom goal, installers were created - with the new patch even without any additional pom settings (with exception of the nbm-maven-plugin version, of course). Could you, please, make a verbose output, eventually add some outputs at the critical point in installerbuild/build.xml to figure out what is the source of the problem?

Btw. Thanks for your conditional profile for tools.jar, I like it. In case a non-standard position of tools.jar will appear for any Java/OS combination, it will be easy to extend the plugin to accept it.

Committed revision 15853 to add the new mojo to the platform app archetype. Committed revision 15852 for your latest patch. I can no longer reproduce the earlier NPE; running the goal produces a working Linux installer on my test app.

Regarding verbosity level: no specific hints for implementation, just an observation that as a user I would expect verbosity to be controlled by the Maven session flags, not a particular plugin's configuration.

I would like to patch apisupport.installer.maven to work with the new mojo (once 3.7 is released) but may need some help mapping the existing nb-configuration.xml entries produced by the "Installer" panel to new mojo configuration in pom.xml. Most parameters seem obvious but ...license-type=cddl (or whatever plain name) does not obviously match installerLicenseFile.

Committed revision 15856 to take care of Ant logging; was sorely needed in CreateWebstartAppMojo anyway.

commons.xml patch has been submitted to NetBeans Bugzilla:

http://netbeans.org/bugzilla/show_bug.cgi?id=207983

Unfortunately, there is no any response at the Bug 207518 yet (simple fix on product.xml).

I added you as a contributor to the POM.

Patch to IDE to work with new mojo.

The mojo seems to basically work, and I would like to release 3.7 soon, so I am marking this fixed. If you have other code cleanups you would like to have done, just file separate issues with patches.

Sorry for delay, I am out until upcoming weekend. I would like to make more verbose documentation to the goal. I will do my best to file it until Sunday, nevertheless native English speaker review would be desirable before final publishing.

No problem. It will probably have to wait until 3.8, since I called a vote for a staged 3.7 already.

OK. It's GREAT that the new goal will be available in 3.7, regardless it's not perfect yet! Thank you for your valuable help.