8:25 p.m.
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
8:48 p.m.
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(a)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(a)lists.jboss.org
https://lists.jboss.org/mailman/listinfo/infinispan-dev
9:22 p.m.
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.
Tristan
--
Tristan Tarrant
Infinispan Lead
JBoss, a division of Red Hat
10:32 p.m.
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
2981
days inactive
2981
days old
infinispan-dev@lists.jboss.org
3 comments
3 participants
participants (3)
-
Sanne Grinovero -
Sebastian Laskawiec -
Tristan Tarrant