8:31 a.m.
Hey!
Uber jars have been around for quite a while but some old problems are
still biting our ankles. The biggest problem is JBoss Logging... But before
diving into the technical discussion, I would like to clarify how do we
treat Uber Jars and how other (let's call them "extra") modules should
integrate with them...
How Uber Jars look like:
- All Uber Jar dependencies are declared as:
- provided - those are APIs which should be available on your
container
- optional - all other dependencies
- compile - JTA (I'm not sure why, but probably because this is a
required API). I think it should be changed to provided at some point.
- Uber Jars have (almost) no dependencies (apart from JTA)
- Uber Jars contain everything to get a standard application running
with ISPN in a single jar
Now the biggest question is how to integrate other extra modules with them
- for example Spring or Cache Stores? Here are the options:
- Not integrate at all... users should use standard (small) jars in such
use cases
- This one has a big impact on our users, so I would assume no
- All extra modules should shade everything they need and provide their
own Uber Jars (like Spring Uber Jar = ISPN Core + Spring)
- This one might be really hard to maintain, so I would also vote for
no.
- All extra modules should integrate with small jars and Uber Jars (but
not both at the same time). An example application might want to add
Spring-embedded and Infinispan-embedded to it's classpath and it's ready to
go. Alternatively it could add Spring-embedded + infinispan-core + whatever
is needed. Adding both infinispan-embedded and infinispan-core is
prohibited.
- Easy for the users, a bit harder for us. My vote goes here.
Could you please share some thoughts whether this makes sense or not? Once
we achieve common understanding - I'll propose some technical solutions.
Thanks
Sebastian
2:42 a.m.
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
5:21 a.m.
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:
1. Stop relocating dependencies
- Pro: everything should work without problems
- Con: our dependencies will clash with client's dependencies
2. 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
3. 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?
4. 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 <ttarrant(a)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(a)lists.jboss.org
https://lists.jboss.org/mailman/listinfo/infinispan-dev
5:50 a.m.
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 <slaskawi(a)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 <ttarrant(a)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(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
5:57 a.m.
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 <sanne(a)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 <slaskawi(a)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 <ttarrant(a)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(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
7:03 a.m.
On Mon, Mar 14, 2016 at 12:21 PM, Sebastian Laskawiec
<slaskawi(a)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?
+1 for option 4. The embedded uber-jar doesn't expose any class in
org.jboss.logging, so it doesn't provide jboss-logging. The Spring
module should depend on jboss-logging itself, not assume that it's
going to be provided by another module.
One complication we have now is that we've made jboss-logging a part
of our API: one module's i18n Log interface can extend another
module's Log, and that means it extends the BasicLogger from
jboss-logging. I believe the Log interfaces should be private, and
each module should extend BasicLogger directly.
Cheers
Dan
9:02 a.m.
On Mon 2016-03-14 11:21, Sebastian Laskawiec 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).
It's actually the opposite, the way nexus stats work, the stats you see
from our nexus are actually the maven central stats minus direct hits
from our nexus instance.
Don't ask.
5:47 a.m.
--
Galder Zamarreño
Infinispan, Red Hat
On 14 Mar 2016, at 08:42, Tristan Tarrant <ttarrant(a)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.
Good point, so the uber jars are mostly for those use cases then?
That could be the recommendation:
- Using dependency management? Use normal jars, otherwise use uber jars
Cheers,
Tristan
--
Tristan Tarrant
Infinispan Lead
JBoss, a division of Red Hat
_______________________________________________
infinispan-dev mailing list
infinispan-dev(a)lists.jboss.org
https://lists.jboss.org/mailman/listinfo/infinispan-dev
2984
days inactive
2991
days old
infinispan-dev@lists.jboss.org
8 comments
6 participants
participants (6)
-
Dan Berindei -
Emmanuel Bernard -
Galder Zamarreño -
Sanne Grinovero -
Sebastian Laskawiec -
Tristan Tarrant