Karoshi Ethos

(See the original post)

I messed around with this quite a bit but was never able to get things to work exactly as I'd hoped. I even got as far as using the XmlTask Ant extensions to modify the launch file on the fly. Unfortunately, I couldn't figure out how to get Eclipse to reload the modified configuration without completely restarting, so that path resulted more or less in a dead end.

What I did figure out is how to make your launch configurations shareable via SVN, so that only one team member (yours truly) has to deal with builds and launch configurations. Everyone else can update from SVN and run ANT tasks without being familiar with all these grisly details.

The last post mentioned (with no small amount of grumbling) that you have to change the JRE setting to "Same JRE as Workspace" on every single build target you create (or rename). This is incredibly annoying. If you go to the same dialog: Run >> External Tools >> External Tools Configurations...

Check out the Common Tab. Here you can pull the launch file configuration into the project and out of the workspace by selecting "Shared file" instead of "Local file". This lets you share launch configurations with the rest of the team.

If you wish, you can create a template for new build targets. If you get the file naming convention right, you should be able to get away with defining new build targets without ever needing to visit the External Tools Configurations dialog. I've got a mixed OS X / Windows Team, so I made some modifications to Eclipse's default launch file output. In short, I removed explicit references to my OS X default JVM.

<?xml version="1.0" encoding="UTF-8" standalone="no"?>
<launchConfiguration type="org.eclipse.ant.AntLaunchConfigurationType">
<booleanAttribute key="org.eclipse.ant.ui.DEFAULT_VM_INSTALL" value="false"/>
<listAttribute key="org.eclipse.debug.core.MAPPED_RESOURCE_PATHS">
<listEntry value="/PROJECT_NAME/build.xml"/>
</listAttribute>
<listAttribute key="org.eclipse.debug.core.MAPPED_RESOURCE_TYPES">
<listEntry value="1"/>
</listAttribute>
<stringAttribute key="org.eclipse.jdt.launching.CLASSPATH_PROVIDER" value="org.eclipse.ant.ui.AntClasspathProvider"/>
<stringAttribute key="org.eclipse.jdt.launching.PROJECT_ATTR" value="PROJECT_NAME"/>
<stringAttribute key="org.eclipse.jdt.launching.SOURCE_PATH_PROVIDER" value="org.eclipse.ant.ui.AntClasspathProvider"/>
<stringAttribute key="org.eclipse.ui.externaltools.ATTR_ANT_TARGETS" value="BUILD_TARGET_NAME"/>
<stringAttribute key="org.eclipse.ui.externaltools.ATTR_LOCATION" value="${workspace_loc:/PROJECT_NAME/build.xml}"/>
<stringAttribute key="process_factory_id" value="org.eclipse.ant.ui.remoteAntProcessFactory"/>
</launchConfiguration>

Note the spots where you should substitute your own PROJECT_NAME and BUILD_TARGET_NAME.

I tried setting the DEFAULT_VM_INSTALL to true, and it worked, but Eclipse insisted on mucking with it as soon as I visited the External Tools Configurations dialog again.

I'm storing my launch files in .settings and setting the filename to:
PROJECT_NAME BUILD_FILE_NAME.xml [BUILD_TARGET_NAME].launch

Your mileage will almost certainly vary.

Add your comment

My latest FDT project has a lot of sub-projects. We've got a small team of mixed Mac and Windows users, so we don't want to assume any particular project directory structure if we can help it. The original thinking was to export SWC files for each sub-project, copy them to the appropriate projects for which they are dependencies, wash-rinse-repeat. I'd assumed I'd be able to use FDTs pre/post-build ANT tasks for this, but unfortunately you only get that tab when building to SWF, not for SWCs.

This brought about the idea of putting the entire build routine in ANT, but I hit another roadblock: I want the team members to be able to define folder path variables using the FDT Eclipse Linked Libraries mechanism. To access these:

• Right-click the FDT project folder >> Properties
• Choose FDT Build Path
• Click "Add Linked Libraries..."
• Click "Add..."

This window lets you manage folder and SWC paths in an abstract way so that build files and classpaths can use the variable instead of a hardcoded path. As long as each team member uses the same variable name, you can share build scripts and complicated classpath settings. All you have to do is tell SVN to ignore the .project file, and everything should be golden.

Ok, so how do you get access to those variables within your ANT scripts? Like this:

<project name="SampleProject" default="compileAll" basedir=".">
    <!-- Import FDT path variables for use as ANT properties -->
    <property file="${basedir}/../.metadata/.plugins/org.eclipse.core.runtime/.settings/org.eclipse.core.resources.prefs"/>

    <!-- etc -->
</project>

(I know the wordpress template makes that impossible to read. Cut paste it.) There are some fairly radical assumptions at work here, and I'm not enough of an Eclipse expert to know if it will work in all environments (plus, there are a LOT of variations in environments out there). The idea, however, is that all projects are direct children of the workspace. Therefore, backing up one level from the basedir should put you in the root of the workspace. From there, the path to the aforementioned FDT path variable property file should be as listed. That, of course, assumes that your Eclipse projects are using the default path. If they aren't, you're on your own. I wasn't able to find a workspace variable that gets passed to ANT automatically, but you should be able to set one yourself by going to the menu Run >> External Tools >> External Tools Configurations... In the Arguments textbox, put:

-Dworkspace_loc=${workspace_loc}

That would let you use the workspace location directly:

    <!-- Import FDT path variables for use as ANT properties -->
    <property file="${workspace_loc}/.metadata/.plugins/org.eclipse.core.runtime/.settings/org.eclipse.core.resources.prefs"/>

You'll need to become at least passingly familiar with the External Tools dialog because you'll be visiting it more often than you'd like in order to bypass a minor oversight by the FDT team (IMHO). Go to the JRE tab and switch your Runtime JRE to "Run in the same JRE as the workspace". If I recall correctly, you'll have to do this every time you create a new build target (sigh). If you know a better way, by all means leave a comment.

This configuration also assumes that the build.xml file is a direct child of the project folder, ie basedir="." If this isn't the case you should now have enough info to pass the project folder as well. (Hint: try project_loc or project_path)

Once you've done this, your FDT path variables can be accessed by prefixing with "pathvariable". For example:

<echo message="${pathvariable.AS3SWF_SRC}" />

It took a little Googling on my part to find how to properly export a SWC under ANT without resorting to a complete re-configuration of the classpath. FDT includes an ANT task specifically meant for this purpose. An example looks like:

<target name="generateSwc2">
  <fdt.launch.library
    projectname="${ant.project.name}"
    debug="false"
    target="${swcdir}/${swcfilename}"
  />
</target>

Getting all the variables set up is left as an exercise for the reader. For some help, try Boostworthy's seminal article.

You should now have all the pieces required to compile and copy SWCs without having paths to specific projects or tools littering your ANT build files. Good luck!

2 comments