In the new year I can add a few use cases to the testsuite that expose
the issue.
Let's revisit what to do when we can talk about specifics.
Have a good holiday - all
-thomas
On 12/21/2010 06:09 PM, Jason T. Greene wrote:
On 12/21/10 2:54 AM, Thomas Diesler wrote:
> For this to work it'd be necessary for a module to define its
> capabilities/requirements. At runtime, there should be a "gate keeper"
> to the modules dependency API - the Resolver. Deployments would also
> define their respective set of capabilities/requirements. The resolver
> could reject a deployment if the runtime does not provide the required
> set of capabilities. This could happen with very detailed error
> response. Currently we have various DUPs that use the modules dependency
> API. IMHO these DUPs cannot be expected to produce consistent wiring
> graphs for the non-trivial setups that we expect in future. Instead a
> single authority should be tasked to validate that a set of modules can
> be installed in an existing setup. This must happen without modifying
> the existing setup.
No matter where you move the dependency information, there is still
going to be some kind of human factor here.
To reiterate, we must resist the urge to do fancy things that make our
(and not our users') life easier, as it costs us performance. The only
way we are going to remain as fast as we are, is if we continue to push
ourselves.
That said, I think we can do all kinds of error checking during build,
which to me makes way more sense then any kind of runtime analysis (why
continually verify what is known to be good?).
--
xxxxxxxxxxxxxxxxxxxxxxxxxxxx
Thomas Diesler
JBoss OSGi Lead
JBoss, a division of Red Hat
xxxxxxxxxxxxxxxxxxxxxxxxxxxx