2011/12/31 Eric Charles <e...@apache.org>: > Hi, > > As said, I am more in favor of uniformisation across projects, but I'm also > fine with an adapter.
(I'm not trying to push my idea, but instead trying to explain you my thinking, as we talked about this a bunch of times in the past years) Logging is a very peculiar "aspect" and while in the past 10 years everything moved to dependency injection and separation of concerns, logging did not. You can't bring this uniformisation to every user's projects. Most of our users use only one of our products. Most jspf users only use jspf from Apache James. Most mime4j users only use mime4j from Apache James and so on. So uniformisation doesn't give anything to them and instead they would have the same issue that you now try to solve with our use case (as James Server instead uses all of them). Correct me if I'm wrong, but let's say someone wants to take james 2.3 branch and make a 2.x release just adding an updated smtp component based on our new protocols libraries: the slf4j dependency would add pain for them as there is no way to bridge slf4j to avalon (while the opposite is really easy). > I'm seeing the current 'server' projects more like components/librairies > like the other libraries, thus tend to apply the same rules to them. I'm not aware of downstream users for the single modules of server product and I don't see a clear use case for that, so maybe it doesn't worth using the same adapter approach there. Furthermore most of the server components already have many dependencies on other components, so they are not really usable without inheriting many other stuff. This is not the same thing as jspf, mime4j, protocols so I don't think we should treat them as the same thing. If/when we'll identify some james server component that can be promoted to a generic library then we'll have to deal with the removal of many dependencies and in that case we will also deal with the logging aspect. Stefano --------------------------------------------------------------------- To unsubscribe, e-mail: server-dev-unsubscr...@james.apache.org For additional commands, e-mail: server-dev-h...@james.apache.org
