My worry is that this YALA approach is a solution set in the context of our current module structure. The aries util module risks becoming the one module that binds them all and so may become to focus of refactoring. A consequence would likely be the separation of the different utility concerns and I think you'd then end up in the same place. An alternative way to look at this is you could achieve the same number of modules and capabilities by creating a utility uber bundle from aries util and slf4j.
Graham. On 1 February 2012 15:43, David Bosschaert <[email protected]> wrote: > On 1 February 2012 15:29, Felix Meschberger <[email protected]> wrote: >> Hi, >> >> Am 01.02.2012 um 14:53 schrieb David Bosschaert: >> >>> My issue with it is that it brings in 2 dependencies: the SLF4J api >>> and an SLF4J implementation bundle. >>> In the context where I want to use the JNDI component there is already >>> a log subsystem in place, which can be reached through the OSGi >>> LogService, so adding those 2 SLF4J bundles brings in dependencies >>> that appear like noise. >> >> Got it. >> >> In my setup I already use SLF4J (and LogService and Log4J and Commons >> Logging). Adding yet another logging API just adds another dependency to my >> setup and adds CPU consumption and learning curve experiences and makes my >> users wonder. > > Well, if Aries has a small log API in its util component that wouldn't > add any dependencies, because most things in Aries already depend on > util. > That component could then delegate to SLF4J, the OSGi LogService or > whatever bringing only those dependencies in that are actually used. > So for your use-case you should still be able to use it with SLF4J, > but for my usecase I don't need to.
