I've located the code in service-builder that loads gbeans defined in embedded plans named geronimo-service.xml in dependencies referred to from gbean config plans.
That's exactly the feature which prevented me from including geronimo-service.xml in the tomcat module! You found it! I didn't forget about it and want to enable it to simplify the deployment (and leverage the concept of Jeremy where people could download their configuration and inject it into a running Geronimo instance).
I would like to remove this capability. My experience with its former use to configure parts of jetty was that it successfully concealed from me, for weeks, how many of the gbeans were getting configured. Since I prefer to be able to find configurations through an explicit path, I would prefer to prevent any other such use of this feature.
Are there any objections to my removing this capability?
Isn't it similar in concept to the way Maven should be working, but it isn't at the moment. Every time you include project X jars as dependencies you'll have to figure out what projects the project X jars rely upon. It simply leads to a nightmare to configure a project's dependencies, which is a PITA. I'm not convinced if removing the feature will bring any simplicity. Yeah, your use case suggests it will, but mine shows end users will face more complexity. We'll shift it from the developers (us) to end users (also us, but I think about the less familiar with the internals).
Moreover, I think it will also break what I have aforementioned above - the ability to configure Geronimo on-the-fly (well, I'm not sure if it's a right term for it). What I mean is to create a plan and don't think about the rest dependencies the services (gbeans) rely upon. They'll be downloaded - user won't have to figure it out yourself.
david jencks
Jacek
