PackageServerSpecificContent
Creating an archive is known as packaging. All NetBeans projects have the ability to filter content out of the archive that will be created. Currently, none of them have the ability to inject content conditionally. While this is okay for most projects, there are instances where this functionality is useful. One situation is the inclusion of server specific data from somewhere outside the standard sources of content (the source and build directories). One specific instance of this is the request to include a sun-resources.xml file in the archive file produced by a project targeted at GlassFish.
The basic requirement is very simple:
produce a jar that includes some additional content
<target name="-do-dist-without-manifest" depends="init,compile,-pre-dist,library-inclusion-in-archive" unless="has.custom.manifest">
<dirname property="dist.jar.dir" file="${dist.jar}"/>
<mkdir dir="${dist.jar.dir}"/>
<jar jarfile="${dist.jar}" compress="${jar.compress}">
<fileset dir="${build.classes.dir}"/>
<zipfileset dir="${resource.dir}" prefix="META-INF" includes="sun-resources.xml"/>
</jar>
</target>
is the most straight-forward expression of the current use-case.
This is expression is not clean enough, though. It embeds vendor specific content in the build-impl.xml for a project.
A second expression is a bit better:
content of build-impl.xml
<target name="-do-dist-without-manifest" depends="init,compile,-pre-dist,library-inclusion-in-archive" unless="has.custom.manifest">
<dirname property="dist.jar.dir" file="${dist.jar}"/>
<mkdir dir="${dist.jar.dir}"/>
<jar jarfile="${dist.jar}" compress="${jar.compress}">
<fileset dir="${build.classes.dir}"/>
<zipfileset refid="server.dependent.extras"/>
</jar>
</target>
content of ant-deploy.xml
<zipfileset id="server.dependent.extras" dir="setup" prefix="META-INF" includes="sun-resources.xml"/>
This second expression embeds "generic" content in the build-impl.xml. The server specific content gets moved into a file which is written by the server plugin. The hard reference to the setup directory would be created when the plugin writes the file to disk... It would not be present in the source template for the ant-deploy.xml file.
A simple, empty zipfileset would be present in the default ant-deploy.xml file. This would prevent dereference errors.
This solution isn't much better than the first. This is due to the fact that we are reusing an existing project artifact to a new purpose.
