[infinispan-dev] Spring module - change dependencies to Uber Jars

[Sebastian Laskawiec]

During our talk on IRC Tristan proposed to mark Spring dependencies as
provided. Another similar approach would be to make them optional.

I think both approaches are even better than making Spring module depend on
Uber Jars. However there is a price to pay - each user will probably have
to declare in his pom what dependencies he'd like to use (uber or small
jars).

On Tue, Feb 2, 2016 at 7:53 AM, Sebastian Laskawiec <slaskawi at redhat.com>
wrote:

> I think the plan is to cover more integration tests (if not all) with Uber
> Jars - right Martin?
>
> WRT the logger - yes you are absolutely correct and that's why logger
> implementations are excluded from Uber Jars (Ubers contain only APIs - like
> SLF4J-API or LOG4J-API).
>
> I think the uber jar vs small jar is more about what configurations are
> preferred. Note that you can always (even now) exclude all dependencies
> from Spring Remote and add Remote Uber Jar manually. Switching Spring
> Remote module to Uber Jars will only change the default behavior (we will
> still be able to exclude dependencies and add small jars if you prefer
> them).
> If we proceed with this change - of course I will document this excluding
> part in the docs (currently it is not written anywhere and it is
> not-so-obvious solution).
>
> On Mon, Feb 1, 2016 at 3:12 PM, Sanne Grinovero <sanne at infinispan.org>
> wrote:
>
>> The Uber Jars will always be more problematic than the "small ones" -
>> as the testsuite doesn't cover them at the same level, if at all - so
>> I don't think it would be wise to start having components to depend on
>> them, especially as this looks like it might become viral: what about
>> other component X that people will want to use with Spring?
>>
>> Also when you're deploying on WildFly you probably want to use the
>> Logger from the application server as it's the one being managed. So
>> the solution would be wither never use Uber Jars when deploying on the
>> container, or remove JBoss Logger from the Uber Jars.
>>
>> Shall I state once more that the whole Uber Jars affair seems a really
>> bad idea to me?
>>
>> Thanks,
>> Sanne
>>
>>
>>
>> On 1 February 2016 at 11:31, Sebastian Laskawiec <slaskawi at redhat.com>
>> wrote:
>> > Hey!
>> >
>> > I'm currently trying to solve a tricky class loading issue connected to
>> > Spring, CDI and Uber Jars. Here's the scenario:
>> >
>> > Remote Uber Jar contains CDI module
>> > Our Hot Rod client use newer version of JBoss Logging which is present
>> in
>> > Wildfly/EAP modules
>> > However EAP and Wildfly will load (and make available for deployment)
>> their
>> > own version of JBoss Logging [1]
>> >
>> > The easiest fix for this is to relocate JBoss Logging package in Uber
>> Jar
>> >
>> > Spring module requires some classes from Infinispan Common and they in
>> turn
>> > need BasicLogger from JBoss Logging
>> >
>> > If we relocate JBoss Logging and will try to use Uber Jar with Spring -
>> we
>> > will end up with classloading issue [2]
>> >
>> > So it seems the best approach is to make Spring depend on Uber Jars
>> instead
>> > of "small ones". Of course, users who use small jars will probably be
>> > affected by this change (they would have to either accept using Uber
>> Jars or
>> > exclude them in their poms and add dependencies manually).
>> >
>> > Is anyone against this solution? JIRA tracking ticket: [3].
>> >
>> > Thanks
>> > Sebastian
>> >
>> > [1] Scenario with Weld enabled WAR
>> >
>> https://docs.jboss.org/author/display/AS7/Implicit+module+dependencies+for+deployments
>> > [2] https://bugzilla.redhat.com/show_bug.cgi?id=1266831#c7
>> > [3] https://issues.jboss.org/browse/ISPN-6132
>> >
>> > _______________________________________________
>> > infinispan-dev mailing list
>> > infinispan-dev at lists.jboss.org
>> > https://lists.jboss.org/mailman/listinfo/infinispan-dev
>> _______________________________________________
>> infinispan-dev mailing list
>> infinispan-dev at lists.jboss.org
>> https://lists.jboss.org/mailman/listinfo/infinispan-dev
>>
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.jboss.org/pipermail/infinispan-dev/attachments/20160203/5d41a222/attachment-0001.html