I'd say it's more "undefined" ;) The approved method for nesting jars is making one archive configuration where the jar is nested inside the ear straight from the beginning. For example, your view would look like: project1 |- ear.ear |- filesets |- my.jar |- jar filesets Doing it the way you're doing it has not been tested as it was not a primary use case. The reason is because it basically requires a second pass of sorts. Basically, when you change a file, the builder runs and generates the classes. These classes are then recognoized as changed resources and are passed to the next builder, (mine), which updates the jar. The jar *should* be being also updated in the workspace (refreshed) and recognized as a changed resource and then another build should be called with the output jar as a changed file... and when the ear archive configuration sees that hte jar changed, the ear should update also. The problem here is trying to figure out the several passes. I believe my builder only gets called once, even if a resource changes. I've never extensively tested this part of builders in eclipse, but my assumption is that the results of one builder are only passed to the next builder. For example, if you change a java file, the java builder gets called, and then the next builder in line receives the changed java file AND the changed class files. So when my builder is called I only get access to everything that's been changed thus far... not things that *I* change. The way I *try* to get around this is to change files only using the File API and not the Resource API, this way the project requires a refresh (which I force provide) which then initiates another build. But this specific use case hasn't been tested. If you want you can open a JIRA and I'll try to make a test case for it. - Rob View the original post : http://www.jboss.org/index.html?module=bb&op=viewtopic&p=4227217#... Reply to the post : http://www.jboss.org/index.html?module=bb&op=posting&mode=reply&a...