> 10 other projects also have their implementation and they don't want to > switch :-(((( > > it definitly doesn't make sense to have 10 implemetations for something > like reading an xml config file!!! > is it really impossible to find a solution which can be used by all > projects?? > > let's join forces to find a way to have one configuration package!!!
Hint (if you think it is worth it): 1) Check out the 10 implementations, factor out a common denominator API. 2) Merge all features from all implementations so that your thing will be the most featuresque of them all (so that the potential "customers" won't lose anything in the transition), and thus expanding the API from 1) above. 3) Sell it to them by offering replacement classes that adapts your thing to theirs (a slip-in-replacement). 4) Offer the added functionality on their email lists, pushing the benefits of your thing. Why I don't think that the above will work is that a) the installed base is too big, b) configuration is such a core feature of your product so that you want to retain full release/bugfix/management control over the configuration component and c) The different APIs take different approaches, esp when in the configuration process, and how, the provided String values get converted into real objects. I welcome better config utilities (even though I know that the existing impls are good enough for about any case), but I think that when doing such a thing, considering your answer to point c) is of great importance. I have limited coding possibilities as of now, but I am with you in thinking (feature requests, modelling, opinions etc). I prefer seeing XML config files as a special case of XMLalizing object/bean structures. /O -- To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]> For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>
