Ola Berg wrote:
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.
i think it would be better to invite the 'customers' to work together ...
Why I don't think that the above will work is thatthat's definitly the main problem .. but we should be able to find a common way ...
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.
first of all we need a list of existing implementations and features to see what's needed, what's common and where are the differences ...
martin
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]>
-- To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]> For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>
