-
1. Re: package archiover and dependency
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 -
2. Re: package archiover and dependency
Rob, aren't you saing that if you used the resource api you would actually get the notifications ?
And since these are two different archivers/builders why don't they see each other changes ? -
4. Re: package archiover and dependency
Max:
The builder only gets called once when a file is changed, not twice. That one time, I find out fileX changed. I adjust x.jar to include the newly modified fileX. However, at no point in this call do I (the archives builder) check if the OUTPUT file is further included in other archives.
Additionally, it seems when a refresh is called on changed resources after a build, a new builder does *not* get called. I haven't found the documentation on this, but I believe any files changed DURING the build operation BY a builder are *not* considered changed on the next build (whether you use resource API or file API, doesn't matter).
Using the resource API actually wouldn't fix anything. Even if you change a raw java.io.File, but *REFRESH* the resource, the behaviour should be exactly the same.
A quick test has just proved to me that at no point does the first Jar ever get passed in to any builder as a changed item.
For a while a long time ago marshall and I had come up with a way to make references between one output jar and another. This way if jarX changes as a result of fileX changing, and jarY *should* change as a result of jarX changing, we can accurately model this in the xml configuration.
This happened, though, as he was passing the product off to me and I was making substantial changes to its underlying infrastructure. I'd say that feature was never complete and so never made it into a successful build. In the end it was removed out of concerns over stack overflows and the lack of a proper cycle-finder.
There are huge amounts of problems in getting this to work. Basically if I wanted to try to do this, I'd need to keep a list of files changed during my portion of the build. The current API doesn't really support returning which files were changed (I'm already using the return types to return success / failure so a full out API change would be required). If it were only able to do zipped deployment it'd be a lot easier but the nature of using truezip to abstract away folder vs archive makes it even MORE difficult for me to get a list of what files change.
To remind you, the reason I'd need this list is to then see if any of these changed / updated output files are in fact included in any OTHER archive's filesets.
In short, it was decided long ago that this would not be a supported use-case as-is. To do it via references would require changes to the xml descriptor (to allow for references), the UI (to create these reference types) and the builder (to check for these references). To do it solely in the builder without any additional UI or "reference" concept would require changes to the truezip / archives bridge layer and on a coding level would be much more prone to errors and breakages.
The proper way to use archives for this usecase (for now) is simply to nest the archives together in one configuration. What the user is asking for is not and has not been a supported usecase throughout the entire life of the plugin. -
5. Re: package archiover and dependency
Hi Rob and Max,
from my point of view this is not a much desired feature though. I do not need the EAR to be up to date all the time. Clicking the "Build Archive" before the redeploy is not much bothering. -
6. Re: package archiover and dependency
I'm surprised changed resources by builders are not processed as resource changes and also surprised builders arent called on refresh.
Especially since the Java builder relies on that to work. i.e. if I change a jar outside Eclipse and press refresh then the Java builder seem to rebuild.