Are uber jars really that useful? From my own experience they often get more in the way, e.g. clash of dependencies. We can fix our own clashes but once you have other modules creating uber jars users might get more of those clashes.
Regardless of that, if we're continue with uber jars, it'd make sense to provide individual jars too, particularly when you want more finer grained dependency resolution.
Cheers,
--
Galder Zamarreño
Infinispan, Red Hat
On 7 Mar 2016, at 16:31, Sebastian Laskawiec <slask...@redhat.com> wrote:
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
_______________________________________________
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
