NetBeans, GlassFish & Maven — Clean and Build Fail

Recently I began creating all my new Java EE projects from the Maven templates in NetBeans. So far, great! It really does help with project build consistency and seems to be a silver bullet for “jar hell” as the all jars/libs are handled cleanly as dependencies.

However, I have run into one drawback. After I run/deploy a Maven Enterprise Application (EAR) on my locally installed GlassFish 4.1 for the first time I am unable to execute a clean and/or a clean and build (Shift-F11).

Windows via GlassFish doesn’t seem to release the locks on the ${}\gfdeploy directory.

I get an error similar to:

Failed to execute goal org.apache.maven.plugins:maven-clean-plugin:2.5:clean (default-clean) on project BubbleGum-ear: Failed to clean project: Failed to delete ${}\gfdeploy...

This only happens on my Windows workstation! The same project will clean and build just fine in Ubuntu Linux 14.04. But, for organizational reasons my primary development workstation is Windows so I needed a work around. And, while this isn’t the best workaround it does work without my having to manually click around to stop the GlassFish server in order to clean and build my project.

Basically, I utilize the maven-antrun-plugin to execute the asadmin stop-domain command on my local machine. I hate to have to stop the GlassFish server but it does free the locks to allow my maven clean and build to proceed. It isn’t terrible as GlassFish is pretty darn quick when I run (F6) the project after the clean and build (Shift-F11)

I’ve added the following to the the <plugins> section of the pom.xml of my Enterprise Archive (EAR):


<target name=”shutDownLocalGlasfishDomain”>
<exec executable=”CMD” dir=”C:\java\glassfish-4.1\glassfish\bin” osfamily=”windows”>
<arg value=”/C”/>
<arg value=”asadmin.bat”/>
<arg value=”stop-domain”/>
<arg value=”domain1″/>


Because I do also work on this project on a Linux workstation I don’t need this wasteful stop-domain execution to happen so as you see I’ve set the osfamily attribute of the exec tag to windows so this will only happen on my Windows workstation.

If you use this workaround you will also have to update the dir attribute of the exec tag to point to the proper GLASSFISH_INSTALL_HOME\glassfish\bin directory on your workstation.

Again, this is cludgey but it works. And, I don’t have to use a third party file “unlocker” utility. Overall it does same time from having to manually stop my GlassFish server.