In general, I like the idea because there are numerous projects out there that use specific jars from tomcat and this would greatly ease access. There is some discussion going on elsewhere in the community for distributing jars with this kind of model. The idea is that an application's expressed dependencies on 3rd party packages can include a URL to the specific jar (including version specification). Thus deployment host platforms can automatically retrieve and resolve dependencies without the application developer having to be responsible for unpacking, repackaging a subset of tomcat (or whatever) and then possibly having to provide the subset on his/her own server.
The caveats are that I don't know if there is consensus yet on versioning format, there definitely are too many competing package dependency schemes and I'm not sure what the impact of jar refactoring will be.
Overall, though, I like the idea.
If it's just to be used for build tools, then it's ok (and no need for a proposal, it just needs to get done). The trouble starts if users start thinking they can use that to upgrade to a newer release, just by upgrading one or two JARs (or ever worse, mixing components). Then there's trouble.
Remy
--------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
