Paul:
I don't quite understand your example. While configId has the same
xml structure as a dependency, it is the name of the current
configuration, not a reference to something outside the current
configuration.
In my example I just (lazily) copy/pasted the configId from higher up in the DD which I suppose would have created a circular reference :-) My intent was actually just to show the suggested element structure, which would look like:
<dependency>
<configId>
<groupId/>
<type/>
<artifactId/>
<version/>
</configId>
<load/>
</dependency>
The rationale behind making <configId> a child of <dependency> (as well as <environment>) would be to make a clear separation between identifying the target of the dependency vs. describing the way that Geronimo should enable it (start its gbeans, load its classes, import it, etc). It would also allow the dependency element to automatically inherit any future changes in the schema for the configId element.
All that being said, I could certainly understand a counter argument for mirroring maven's dependency element. When it comes to tight integration with maven I'm starting to "stop worrying and love the bomb" ;-)
Do the load/include elements in this example work for
you in place of the ambiguous scope in the previous example?
Yes -- makes sense, thanks.
Best wishes,
Paul
