To make a more practical proposal:
give me a way to start a local, non transactional Cache which doesn't
require any of:
- JGroups
- JBoss Marshalling
- JTA API
- Infinispan Commons
If I don't have - for example - JGroups and am starting a clustered
cache, I will see an exception "Enabling Clustering on Cache {1}
requires a Transport Module such as
org.infinispan:transport-jgroups:9.0.0.Final. No transport module
found on classpath."
On 14 March 2016 at 10:50, Sanne Grinovero <sa...@infinispan.org> wrote:
> Hi,
> uber jars were introduced as an answer to complaints such as "there
> are too many jars" but I still think this was the wrong answer.. too
> many issues so please stop this: it's not helping usability to
> understand which jars are needed, and it makes things worse with
> runtime errors not matching source code.
>
> It was my impression that uber jars were a temporary solution to
> improve things, while the real improvements - to actually need less at
> runtime, or provide better errors pointing out what's needed - would
> take more time.
>
> So rather than stubbornly spend time maintaining this approach which
> is so obviously broken, I'd rather see time spent in pursuing the
> better improvements so that we can finally drop this.
>
> Sebastian: I din't understand the idea behind proposal 2#: what does
> it meant to provide our own facade to JBoss Logging? One will still
> need to have JBoss Logging at runtime, right?
>
> Thanks,
> Sanne
>
> On 14 March 2016 at 10:21, Sebastian Laskawiec <slask...@redhat.com> wrote:
>> I took a look at Nexus download statistics and Infinispan Uberjars are about
>> 7% of our downloads (of course this calculation has been based on our JBoss
>> Nexus instance and we have no data from other mirrors).
>>
>> So, once we are clear how Uber Jars should work... let's take a look at one
>> of the problems:
>>
>> Many of our modules use JBoss Logging
>> Uber jars relocate dependencies (like the one above) into infinispan
>> package. The result for JBoss Logging would be:
>> infinispan.org.jboss.logging*
>> Most of our modules are compiled with small jars (like Spring integration),
>> so the compile dependency for Spring integration is org.jboss.logging (not
>> infinispan.org.jboss.logging)
>> If someone wants to use Spring with Uber Jars (which should be absolutely
>> fine), he gets a clash... Spring module can't find JBoss Logging
>>
>> There are several options to solve that:
>>
>> Stop relocating dependencies
>>
>> Pro: everything should work without problems
>> Con: our dependencies will clash with client's dependencies
>>
>> Wrap 3rd party dependency with our own wrappers. In case of JBoss Logging -
>> develop our own facade and put it in common.
>>
>> Pro: 3rd party dependencies will not leak between our modules
>> Con: A lot of effort and rather small gain
>>
>> Develop 3rd party dependencies as Uber Jars. In case of Spring - we will
>> have a Spring Uber Jar. I think Dan put this idea on the table.
>>
>> Pro: Lots of Uber Jars for everyone
>> Con: How to use small jars in this scenario?
>>
>> Mark all module dependencies as provided and let users add small/uber jars
>> themselves.
>>
>> Pro: It should give us the best results with the smallest amount of time
>> Cons: Not all scenarios will be solved. We will also need to stop relocating
>> some dependencies (like logging facades which are used almost everywhere)
>>
>> Having in mind our download statistics I would go for #4 (even though it
>> doesn't solve the problem entirely). However #2 seems like a better fit for
>> long term maintenance and we should proceed with this direction if number of
>> Uber Jars users will grow (I can set a reminder in a 3-4 months time).
>>
>> Does it sound reasonable?
>>
>> Thanks
>> Sebastian
>>
>> On Mon, Mar 14, 2016 at 8:42 AM, Tristan Tarrant <ttarr...@redhat.com>
>> wrote:
>>>
>>>
>>>
>>> On 11/03/2016 18:20, Galder Zamarreño wrote:
>>> > Are uber jars really that useful? From my own experience they often get
>>>
>>> The number of users who don't use a dependency management system (Maven,
>>> Ivy, Gradle) is quite a lot higher than you'd expect.
>>>
>>> Tristan
>>> --
>>> Tristan Tarrant
>>> Infinispan Lead
>>> JBoss, a division of Red Hat
>>> _______________________________________________
>>> infinispan-dev mailing list
>>> infinispan-dev@lists.jboss.org
>>> https://lists.jboss.org/mailman/listinfo/infinispan-dev
>>
>>
>>
>> _______________________________________________
>> infinispan-dev mailing list
>> infinispan-dev@lists.jboss.org
>> https://lists.jboss.org/mailman/listinfo/infinispan-dev
_______________________________________________
infinispan-dev mailing list
infinispan-dev@lists.jboss.org
https://lists.jboss.org/mailman/listinfo/infinispan-dev
