Date: 2004-04-30T15:03:00
Editor: 80.121.39.185 <>
Wiki: Jakarta HiveMind Wiki
Page: ConditionalContributionsProposal
URL: http://wiki.apache.org/jakarta-hivemind/ConditionalContributionsProposal
no comment
Change Log:
------------------------------------------------------------------------------
@@ -100,3 +100,8 @@
I was thinking more like '"${interface.module.!ServiceName}" ==
"implementation.module.!ImplementationName"'. Then you just arrange your
symbol sources to look in standard places for these definitions, and you have
maximum configurability.
+ChristianEssl:
+
+I think the solution is insufficient and cluttered: To a module a service
defined by the module is either a service with module provided
implementation(s) or a service demanded by the module (implementation is
provided by another module). This combined with overriding/default-impl gives
four (abstract) types of services: A provided service implementations(s) may
either be overwriten (Type I) or final (Type II), a demanded service may either
have a default implemantation(s) (Type III) or none (Type IV). Type I and Type
III are actually the same, both provide different default implementations which
can be overwritten. Current Hivemind (without this proposal) supports only Type
II and IV with one implementation. The current proposal also supports a Type I
and Type III but with the restriction to have only one default implementation.
Ie it would be impossible to provide your own regex-impl if the regex-module
already defines for JDK1.4 and JDK1.3 and you use JDK1.4.
+
+A little change could solve that: The implementation tag should be used for
overriding only and should be unconditional. The service however should be
allowed to provide differend conditional implementations which are only taken
if there is no implementation. (So implementation are allowed even when the
service-definiton provides an implementation). If TYPE II (final) is seen as
important - I don't think so - also an extra attribute should be added to the
service tag. (An alternative - of course my favorite - would be to replace the
invoke-factory with a script :-))
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
