Hey!

If Hibernate had an Uber jar - one could add it to the classpath and fix the problem :) Of course I'm not serious here...

So what are you proposing? One of the proposed solutions (in "Uber jars - how do we want to use them" email thread) was to limit number of dependencies and throw errors in the runtime if something is missing. I'm slightly positive to the first part but really negative to the second (it only delays the problem until you run the application).

Another idea (a bit similar) is to squash most of the ISPN modules into infinispan-core and move all "extras" (like Spring support) in separate repository (infinispan-extras organization?). Such projects would have a dependency to core. But with this approach we get all the bad things from coarse grained layout.

The question I'm asking here is - if not Uber Jars, than what? Ideas are more than welcome!

Thanks
Sebastian 

On Thu, Mar 17, 2016 at 12:25 PM, Sanne Grinovero <sanne@infinispan.org> wrote:
Since we recently discussed the purpose of the "UberJar"s , I think it
would be a great exercise to look at this discussion:
 - https://developer.jboss.org/message/953081

and ask ourselves what we could have done to make the first steps of
this new user less miserable.

Personally I think we could go a long way with some clear
documentation about our dependencies;
it's not hard to inject version properties from the pom files into the
docs, so we could have a little reminder about - for example - which
version of Hibernate is expected to have the JPACacheStore working.

Also, I think it's clear that uber jars - at least in this case - are
not even close to the solution, unless you intend to include all of
Hibernate ORM and transitive dependencies..

Thanks,
Sanne
_______________________________________________
infinispan-dev mailing list
infinispan-dev@lists.jboss.org
https://lists.jboss.org/mailman/listinfo/infinispan-dev