aries-dev mailing list archives

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 <david.bosschaert@gmail.com> wrote:
> On 1 February 2012 15:29, Felix Meschberger <fmeschbe@adobe.com> 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.