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#4227217
Reply to the post :
http://www.jboss.org/index.html?module=bb&op=posting&mode=reply&p=4227217
_______________________________________________
jboss-user mailing list
[email protected]
https://lists.jboss.org/mailman/listinfo/jboss-user
