NBP: How to brand a Maven-based NB platform application using resource-filtering

Based on a discussion in the mailing list the following FAQ entry has been created. 

http://wiki.netbeans.org/DevFaqVersionNumber#How_do_I_set_the_version_number_automatically_in_maven-based_applications.3F
It explains how use the maven-resource-plugin to replace content in the bundles. The example there shows you how to set the title of your NB platform application based on the version in the pom.xml. 

Quicktip: How to customize the names of Maven project nodes

Since NetBeans 7.4 you can configure the name of Maven-based project via options at “Tools|Options|Java|Maven|Appearance”. No additional plugin is required.

Mavenprojectnodenamecustomization

For other useful features have a look at the “New and Noteworthy” pages at http://wiki.netbeans.org/NewAndNoteWorthy

Quicktip: Maven-based NBM development and the user-dir

When you develop a NetBeans module using the Maven-approach, every time you “Clean & build” your module the userdir, which is placed in the target-directory by default, will be deleted. “Clean & Build” is necessary if you’re altering the layer.xml directly or indirectly by using annotations like @ActionReferences.  So after that you have to reconfigure your target platform again, f.e. by opening the same projects and files to restore the previous state. That is annoying, but easy to fix.

Add a profile to your settings.xml

<profile>
    <id>userdir</id>
    <properties>
        <netbeans.userdir>../userdir</netbeans.userdir>
    </properties>
</profile>

2016-01-23_13h14_03

After that you can choose the profile from the profile-dropdown or in the context-menu of the project node.

2016-01-23_13h18_46

This way the configured userdir is used for running/debugging your NetBeans module. It won’t get deleted automatically.

Advanced tips: Of course you can also configure an absolute path or even make the profile default by applying activeByDefault

<profile>
    <id>userdir</id>
    <activation>
        <activeByDefault>true</activeByDefault>
    </activation>
    <properties>
        <netbeans.userdir>/home/user/myuserdir</netbeans.userdir>
    </properties>
</profile>

 

Maven: Force the exclusion of dependencies

In large Maven-based projects consisting of several high-level frameworks sooner or later there will come the time, when there are two versions of the same dependency in the classpath. For example: two versions of the same logging framework.

One approach to solve such ambiguity is to choose one of the versions (which is hopefully compatible) and to use it as an explicit dependency. Nevertheless other dependencies may still introduce other version as transitive dependencies. This may be caused by different groupIds, which will result in two similar named jar.

Once you got a candidate you can start finding all the possible sources of the dependency.

mvn dependency:tree -Dverbose -Dincludes=log4j:log4j

will show you the dependency-tree, but only the relevant excerpt. Using this information you can now add your exclusions to the affected pom.xml files.
Exclusions are configured via the exclusion-tag [1], which excludes specific transitive dependencies. For example:

<dependency>
	<groupId>sample.ProjectB</groupId>
	<artifactId>Project-B</artifactId>
	<version>1.0-SNAPSHOT</version>
	<exclusions>
		<exclusion>
			<groupId>log4j</groupId>
			<artifactId>log4j</artifactId>
		</exclusion>
	</exclusions>
</dependency>

By the way: Java IDEs can help you doing this.

After that you can make sure the faulty dependency versions will never ever be included again. This can be done using the maven-enforcer-plugin [2]

      
<build>
	<plugins>
		<plugin>
			<groupId>org.apache.maven.plugins</groupId>
			<artifactId>maven-enforcer-plugin</artifactId>
			<version>1.3.1</version>
			<executions>
				<execution>
					<id>enforce-version</id>
					<goals>
						<goal>enforce</goal>
					</goals>
					<configuration>
						<rules>
							<bannedDependencies>
								<excludes>
									<!-- exclude all versions lower than 1.2.17-->									
									<exclude>log4j:log4j:[0.0,1.2.17)</exclude>
								</excludes>
							</bannedDependencies>
						</rules>
					</configuration>
				</execution>
			</executions>
		</plugin>
	</plugins>
</build>

[1] http://maven.apache.org/guides/introduction/introduction-to-optional-and-excludes-dependencies.html
[2] http://maven.apache.org/enforcer/maven-enforcer-plugin/

Improved Maven-based NetBeans Platform Application Development using JRebel

Some months ago I already blogged about how to tweak the pom.xml of your Maven-based NetBeans platform application so that you can use JRebel to reload your changes. [1] This process has been simplified in the meantime. Thanks to Peter Hansson for letting me know. Steps:

  • Install the JRebel NetBeans IDE Plugin (from the Plugin Center or from your IDE)
  • Make sure “Compile on Save” is enabled for your project.
  • Make sure the “Enable/Disable JRebel” toolbar button is checked.
  • Generate a rebel.xml file: In the context menu of the project choose “Open JRebel panel” and check the checkbox next to your project in the JRebel Panel.
  • Alter the properties section of the pom.xml like this
        <!-- for JRebel 5.x / JRebel 6 Legacy Client -->
        <properties>
            <!--...-->
            <netbeans.run.params.ide/>
            <netbeans.run.params>-J-javaagent:"${current.jrebel.agent.path}" -J-Drebel.log=true ${netbeans.run.params.ide}</netbeans.run.params>
        </properties>
    
        <!-- for JRebel 6.x (Non-Legacy Client)-->
        <properties>
            <!--...-->
            <netbeans.run.params.ide/>
            <netbeans.run.params>-J-Xbootclasspath/p:C:\temp\rebelboot.jar -J-javaagent:"${current.jrebel.agent.path}" -J-Drebel.log=true ${netbeans.run.params.ide}</netbeans.run.params>
        </properties>
    

    The NEW and COOL thing is that you do not have to bother yourself with the path of the JRebel jar file anymore. The JRebel NetBeans IDE plugin sets the path to the JRebel jar from your IDE into the Maven property “current.jrebel.agent.path” and you can reuse it in your pom.xml. Now there will be no hardcoded paths anymore, when you check-in your pom.xml to SCM – except the JRebel6 bootclasspath edge-case.

  • run the module – the application with your module and JRebel should start up
  • make changes to your classes and JRebel will pick them up

Here a screenshot to illustrate the previous steps: 2014-09-03_23h34_17 Tested with NetBeans 8.0, JRebel NetBeans IDE Plugin 5.6.2 [1] https://benkiew.wordpress.com/2013/10/27/maven-based-netbeans-platform-development-with-jrebel-6-minor-update/