New version of JRebel for NetBeans Plugin 6.1.0

I am sure you already noticed that there was an update to the JRebel for NetBeans plugin.

Regarding to http://plugins.netbeans.org/plugin/22254/jrebel-netbeans-plugin version 6.1.0 contains the following changes:

  • Added support for launching Grails applications with JRebel.
  • Added JRebel startup tab to JRebel Configuration. Added setup instructions for three startup scenarios (IDE, CLI and remoting).
  • Added support for enabling/disabling JRebel agent per server and standalone project via the JRebel Configuration. Removed the global on/off JRebel toolbar button.
  • Fixed an issue with setting VPN IPs for remoting/cloud.

One highly visible and very useful new feature is the configuration wizard in the options. This way you can configure your app server/application to use JRebel without any external documenation. Good Job ZT!

2015-03-03_08h43_37

NB platform: Catching missing resources at compile-time using @StaticResource

When you develop a NetBeans platform application sometimes you like to refer to existing resource files like images.

Therefor you have to hard-code the path into your sources in a string literal. Normally you would notice a wrong path at runtime because of a FileNotFoundException – not very professional.

But wait! Use the org.netbeans.api.annotations.common.StaticResource-annotation from the Common Annotations module (/org.netbeans.api:org-netbeans-api-annotations-common) instead. Backed by an annotation processor NetBeans will check whether the path is correct at compile-time. This is pretty cool.

What do you get? NetBeans shows missing resources in the editor, in the “Action Items”-view and even the build will fail.

2015-02-21_18h33_57

[1] http://bits.netbeans.org/8.0/javadoc/org-netbeans-api-annotations-common/org/netbeans/api/annotations/common/StaticResource.html

New version of Open File At Cursor plugin – 1.3.1

Today I released the version 1.3.1 of the “Open File At Cursor” plugin. There are some new minor features, which proofed to be useful for myself and may be also useful for other Java developers.

1395696437_2014-03-24_22h26_10

Updates in 1.3.1:

  • [Issue 18]: NPE when pressing CTRL in the diff dialog

Updates in 1.3.0:

  • [Feature 12]: Support fully qualified classnames
  • [Feature 14]: Search for classname in dependencies too (only works for dependencies with sources)
  • [Feature 10]: Find files in same package but different source root
  • [Issue 16]: Make the hyperlinking faster / use less IO

You can download it from http://plugins.netbeans.org/plugin/52349/open-file-at-cursor. The plugin is currently scheduled for verification for NB 8.0 and NB 7.4 and will be available from the plugin dialog within your NetBeans IDE within the next days (after verification).

As always please file issues and enhancements at https://github.com/markiewb/nb-resource-hyperlink-at-cursor/issues . Pull request are also appreciated. Thank you

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/

New version of “Eclipse Code Formatter for Java” plugin – 1.8.0.4

Breakpoints will now be preserved – that is the major change. Unfortunately linebreakpoints are not supported, but better than nothing and better than the previous state. I also updated the embedded eclipse formatter engine to 4.4.

2014-10-11_10h14_18

Here the full list of changes.

  • [Feature 47]: Preserve Class/Method/Field breakpoints (experimental, can be disabled in options)
  • [Bugfix 53]: Fixed: Do not remove linebreakpoint, if line is not included in selection
  • [Bugfix 52]: Fixed: Cannot assign shortcut for “Format with Eclipse Formatter” action
  • [Task 46]: Update to use eclipse formatter libs from eclipse 4.4
  • [Task 48]: Support only NetBeans 7.4 and above
  • [Task 49]: Add donation button
  • [Task 50]: Add link to github/homepage

Downlad it from the plugin center http://plugins.netbeans.org/plugin/50877/ or install it directly from your IDE (Tools/Plugins).
You can file issues at https://github.com/markiewb/eclipsecodeformatter_for_netbeans/issues

I am looking forward for your feedback.

How to build TuxGuitar with NetBeans

Recently a guitar-playing developer asked me if I can help him to build his favorite guitar tab program TuxGuitar from the sources. So here is a small step-by-step guide using NetBeans.

Steps:

  1. Checkout the sources via the NetBeans SVN Client (Team->Subversion->Checkout…) from
    svn://svn.code.sf.net/p/tuxguitar/code/trunk
    (At http://sourceforge.net/p/tuxguitar/code/HEAD/tree/trunk/ you will find the SCM URL)2014-09-23_21h48_10
    2014-09-23_21h46_58 2014-09-23_21h47_09
  2. Open the maven project at trunk\build-scripts\tuxguitar-windows-x86
  3. Right click on the project, choose “Clean and Build” and wait for the assembly to finish.2014-09-23_17h45_25
  4. After that in trunk\build-scripts\tuxguitar-windows-x86\target\tuxguitar-1.3-SNAPSHOT-windows-x86 there is a executable version of TuxGuitar2014-09-23_21h26_40
  5. Start TuxGuitar *g*
    2014-09-23_21h44_50

The setup was easy because NetBeans provides a SVN Client and a Maven installation out-of-the-box. Tested with NetBeans 8.0.1 (running using JDK8) and Windows 7 64bit.

Troubleshooting:

If you use a x64-Windows and a x64-JDK TuxGuitar won’t run because of native 32bit-SWT libraries. You will see the following exception.

Exception in thread "main" java.lang.UnsatisfiedLinkError: Cannot load 32-bit SWT libraries on 64-bit JVM

Solution: In the tuxguitar.bat set the path to the java executable of a 32 bit JDK.

 SET JAVA="C:/Program Files (x86)/Java/jre7/bin/java"

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/