Re: [infinispan-dev] Practical example of difficulties with dependencies
On 17 March 2016 at 12:22, Tristan Tarrant <ttarrant(a)redhat.com> wrote:
On 17/03/2016 12:25, Sanne Grinovero 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..
While you are right that we could be clearer, and providing a printout
of mvn dependency:dependency-[list|tree] would help some users, managing
dependencies manually always comes loaded with a number of issues:
duplicate jars, multiple versions, incompatible versions, useless jars,
etc. So, to me, this is an NP complete problem.
Sure, I don't expect neither yourself or the Infinispan team as a
whole to have a magic solution.
Just wondering what could be "good enough" without being too hard to maintain,
maybe environment/goal driven? For example: to run on Websphere, you
will need this list.
The Wildfly modules are a great way to package; maybe we should
provide (and test) packages for other containers?
BTW Maven helps a bit but it's not providing the magic solution
either, especially
not when deploying on containers and it's not clear what is already
going to be provided,
but also for example it doesn't help with the different versions of
JEE API specifications which we,
i.e. geronimo and Narayana publish different artifact identifiers, and
even within the same project
they will publish a different API version as a different artifact.
N.B. Uber Jars didn't help at all here, and they potentially add even
more confusion or duplication.
Sanne
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