I sure wouldn't mind if a module could say "I provide javax.foo.Bar" and a separate module could say "I require a parent that provides javax.foo.Bar"... As in, interface dependencies instead of name-based dependencies.
Thanks, Aaron On 9/14/06, David Jencks <[EMAIL PROTECTED]> wrote:
I started working on a version of geronimo that uses the jta11 transaction manager in the sandbox. So, I wrote a new transaction configuration using the new gbean and started trying to assemble a server. My new config has gbeans with exactly the same names (except for artifactId) as the old jta 1.0.1B configuration (present in GERONIMO-2398, please vote). Now it turns out that in order to swap these configs I am going to need to change almost all the other configs so they depend on my new one instead of the old one. This highlights a need for more functional-based dependencies. Conceptually we kind of want to say, "this module depends on a module supplying services A, B, C" One idea I had that might be pretty easy to implement would be to expand the explicit-versions resolving code a bit so that you can supply a properties file that says "replace requests for artifactId X with artifactId Y" and plug it in the the artifact resolver, configuration, and kernel so that when you ask for a gbean with artifactId X you get one with the same name map and interfaces but with artifactId Y. I think of this as aliasing X as Y (or maybe its vice-versa). I'm starting to try to implement this since I'm kind of blocked without something like this... but this might not be the best possible solution or even the easiest. Anyone want to comment or suggest better ideas? thanks david jencks