2:18 p.m.
There are some benefits to it, but it gets extremely tricky and nasty
for end users if they happen to get duplicates of any of our
libraries, or dependencies.
I think the worst problem being that they "sneak in" unexpectedly as
Maven doesn't deal nicely with such situations, and the error messages
one gets are both scary and counter-intuitive.
Maybe we could alleviate for this problem by e.g. testing that some
resources are unique on the classpath? For example, add a marker file
in the infinispan-core.jar and a different marker in the uber jar,
then verify there's a strict either/or of each dependency instance.
FWI I'm confident that the current "benefits" far outweigh all the
problems these introduce, unless you can all spend some time on polish
those errors, and make sure the examples and docs are very clear about
either/or situations, I'd rather drop them.
Thanks,
Sanne
On 28 November 2016 at 12:31, Sebastian Laskawiec <slaskawi(a)redhat.com> wrote:
I'm actually on the other side of the table. I really like them!
They are super easy to use - one dependency and off you go. It doesn't
matter whether you use CDI, Query or any other feature - everything is
there.
Of course, there is a price to pay - we need to pull additional dependencies
and relocate packages. But as Tristan once mentioned - it's only a matter of
hammering all the errors out.
On Thu, Nov 3, 2016 at 10:23 AM, Gustavo Fernandes <gustavo(a)infinispan.org>
wrote:
>
> On Wed, Nov 2, 2016 at 11:12 PM, Sanne Grinovero <sanne(a)infinispan.org>
> wrote:
>>
>> On 1 February 2016 at 14:12, Sanne Grinovero <sanne(a)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?
>>
>> +1 to myself here :) as we're witnessing again reports of issues with
>> them.
>>
>> Unless someone has a solid explanation about why they are needed,
>> could we start making plans for their deprecation?
>>
>> As far as I remember they were introduced to "reduce the number of
>> dependencies" but this isn't the right way.
>
>
>
> +1
>
> Having an uber jar is mostly a convenience for those not using a proper
> dependency management
> system or doing quick prototypes, but as soon as we start having several
> uber jars, putting them
> inside osgi bundles and creating jboss modules with them, they become
> really alternate jars and
> a maintenance burden for very little benefit.
>
> Gustavo
>
>
>>
>>
>> Thanks,
>> Sanne
>> _______________________________________________
>> infinispan-dev mailing list
>> infinispan-dev(a)lists.jboss.org
>> https://lists.jboss.org/mailman/listinfo/infinispan-dev
>
>
>
> _______________________________________________
> infinispan-dev mailing list
> infinispan-dev(a)lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/infinispan-dev
_______________________________________________
infinispan-dev mailing list
infinispan-dev(a)lists.jboss.org
https://lists.jboss.org/mailman/listinfo/infinispan-dev