Stephen McConnell wrote: > > Carsten Ziegeler wrote: > > And make sure that the components run out-of the box in the most > > recent containers including at least Fortress (ECM would be good as > > well, but perhaps we can forget that one) > > Carsten: > > Thanks for the email - there are several points I would like > to expand on but that's for another thread. Concerning the > above - I would like to figure out a way in which we move you > from a implementation dependency to a service dependency. > I.e. I don't want you to be dependent on Fortress. Yes, I understand.
> I want > you to be dependent on an API. If you can define that API, > I'm ready to take a shot a delivering an implementation > solution. Even better - if you can provide some test cases, > I'm ready to spend some time making sure we provide a > sustainable solution. > The most problematic area I currently see is Configuration. For example in Cocoon we are using the ECM with three configuration files: a roles configuration containg all roles, the component configuration, containg the configuration for some components in addition with some new components that are not in the roles file and the logkit configuration. Now Fortress is using a different approach, I uses for some aspects Meta-Information and for some other aspects configuration files that are not compatible with ECM. But you can use ECM configuration files with Fortress but can't additionally use the new configuration things from Fortress. So it's currently an all or nothing approach (old or new, but not both) which makes a smooth upgrade strategy impossible. And if I peek at Merlin I fear that this is even worse - don't get me wrong, I don't say Merlin is worse or Merlin is bad or something like that. It's just that migration with regards to Configuration is very hard. So, this area lacks currently I think. In addition, what I meant with my above statement is that you should make sure that components in a component library not only use all the latest available features of the latest container version. They should also be runnable in older containers. For example, if a component uses meta-info then it's not usable with ECM. If a component uses meta-info that only Merlin supports, than it's not useable with Fortress and so on. The more I think about it, the more I come to the conclusion that the current situation is bad. People, currently using ECM can choose between Fortress and Merlin, but if they choose Fortress they already know that they have to migrate sooner or later to Merlin anyway. People writing components have to choose for which container they write components - obviously the container they are using. So, perhaps it would really be better to forget Fortress and move everything into Merlin but of course maintain the simplicity of Fortress. Embedding Fortress into an own application is four or five lines of Java code and some simple configuration file. That's it. Carsten --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
