Currently the configstore.resolve method is not sufficient to allow projects to be run directly from an IDE. By the time this method is called, only the resources found by building up the config are passed into this method to be resolved. Some pluggable method resolving needs to also take place when the configuration is being built up in each of the builders. - EARConfigBuilder cannot assume that each of its modules are located directly inside the root location of the ear so it can support a flattened projects, this goes for utility modules as well. - When searching for libraries such as inside web-inf/lib, since in an IDE these lib entries could be virtual with the actual library residing as another project or an external jar in the filesystem, currently these cannot be found since on the filesystem this folder is empty. This goes for jar entries in a manifest, a relative location cannot be assumed. - A j2ee project in an IDE usually has 2 "binary" locations, a classes folder, and another for the module root. (metadata). The configstore.resolve method handles this, but each of the builders when processing a module cannot be aware of just one root location of the module, because I think there are builders that need to know both where the classes are for a module as well as the metadata. So it would be good to have for for any module whether its a utility module or a j2ee module the notion of a "resources location" and a "binaries" location". I think this covers 90% of the cases and would be a good start. I think if we come up with some common interface that all builders would use to locate resources, it would be easy to plug in different resolvers, that could be set by the deployment manager for each deploy??? Thoughts? -sachin On Jul 12, 2006, at 10:07 PM, Dain Sundstrom wrote:
-sachin |
