[infinispan-dev] Uber Jars

[Tristan Tarrant]

On 03/06/2014 16:40, Dan Berindei wrote:
>
>
>
> On Tue, Jun 3, 2014 at 1:30 PM, Tristan Tarrant <ttarrant at redhat.com 
> <mailto:ttarrant at redhat.com>> wrote:
>
>     On 03/06/2014 11:35, Sanne Grinovero wrote:
>     > On 3 June 2014 09:57, Mircea Markus <mmarkus at redhat.com
>     <mailto:mmarkus at redhat.com>> wrote:
>     >> On Jun 3, 2014, at 8:53, Tristan Tarrant <ttarrant at redhat.com
>     <mailto:ttarrant at redhat.com>> wrote:
>     >>
>     >>> Dear all,
>     >>>
>     >>> on Thursday I issued a PR [1] to introduce Uber Jars, i.e.
>     single jars
>     >>> which wrap our multitude of jars and some of the transitive
>     >>> dependencies, but it was (rightly) pointed out that we should
>     have a
>     >>> little discussion here first.
>     > thanks!
>     >
>     >>> Firstly, I'm using the maven shade plugin which repackages
>     multiple jars
>     >>> into one with:
>     >>> - automatic transitive resolution
>     >>> - the ability to include/exclude certain jars
>     >>> - move classes if necessary to other packages to avoid conflicts
>     >>> - rewrite the POM with the new dependencies.
>     >>>
>     >>> Here is my global strategy:
>     >>> - define a set of uber-jars (see below)
>     >>> - include all non-optional dependencies in each uber-jar
>     except for the
>     >>> specification Jars (e.g. javax.transaction and javax.persistence)
>     >>> - rename some internal-only dependencies to avoid conflicts
>     >>> - uber jars MUST NOT inherit from infinispan-parent (too much
>     cruft in
>     >>> there) but only from infinispan-bom.
>     > What is the definition of an "internal-only" dependency?
>     > I really like the intention but renaming seems quite dangerous.
>     >
>     > For example, JGroups is quite internal but doing so it means the
>     user
>     > could not create a custom Protocol and define it in his
>     configuration
>     > file.
>     > Also I suspect several frameworks rely on reflection to "wire-up" at
>     > boot time (like JGroups does with Protocol class names), so if we're
>     > in the business of relocating classes, this should be followed by
>     > integration tests.
>     The only dependency which currently "fits" my definitions is
>     jboss-logging. It is only used internally and its APIs are not
>     "re-exported".
>     My PR also includes a simple integration test for the "embedded"
>     case. I
>     will obviously integrate it with tests with the others once we
>     agree on
>     the structure.
>     >> Just for my own understanding, what is the rationale behind this?
>     Users who don't use a dependency management system (i.e. Maven, Ivy,
>     etc) can write an application just by adding a "single" jar.
>     >>
>     >>> The Uber Jars
>     >>> - infinispan-embedded-all (infinispan-commons,
>     infinispan-core, jgroups,
>     >>> jboss-marshalling-osgi, jboss-logging, infinispan-cachestore-jdbc,
>     >>> infinispan-cachestore-jpa, infinispan-cachestore-leveldb)
>     > I wouldn't call a package "-all" if it's missing some things. For
>     > example, without Query functionality this "All" is actually a very
>     > limited subset ;-)
>     >
>     > WDYT "infinispan-embedded"
>     Ok.
>     >>> - infinispan-remote-all (infinispan-commons,
>     infinispan-client-hotrod,
>     >>> commons-pool, jboss-marshalling-osgi, jboss-logging,
>     >>> infinispan-remote-query-client, infinispan-query-dsl,
>     >>> infinispan-protostream, protobuf-java)
>     > Same objection on the "-all" naming.
>     > I'd suggest "infinispan-client".
>     Ok
>     >>> - infinispan-query-all (infinispan-query, infinispan-query-dsl,
>     >>> hibernate-hql-parser, antlr, stringtemplate, hibernate-hql-lucene,
>     >>> hibernate-search-engine, infinispan-lucene-v4,
>     >>> hibernate-search-analyzers, lucene*, solr*, avro, jackson-core,
>     >>> jackson-mapper, paranamer, apache-compress,
>     infinispan-lucene-directory,
>     >>> hibernate-search-infinispan, hibernate-commons-annotations). This
>     >>> package will depend on infinispan-embedded-all and we should
>     only make a
>     >>> Lucene v4 version).
>     > If you make only a Lucene V4 version that's not going to work with
>     > master as it's today, my patches to upgade the Query engine to use
>     > Lucene V4 are not integrated yet. (And if it's meant for a Lucene4
>     > target, then you don't need Solr)
>     I added solr since that is what my aging neuron remembered. Shade
>     actually pulls in the dependency tree automatically so I don't have to
>     think about these things (and the Infinispan Query dependency
>     hierarchy
>     is hairier than a sea otter).
>     > More importantly: is the user meant to use these as Either/OR or as
>     > additive packages? From the dependencies you listed it looks like
>     > additive packages, but I think the name suggests that using
>     > "infinispan-query-all" you have all what's needed.
>
>     infinispan-embedded-query would still depend on
>     infinispan-embedded, so
>     the user would require both jars. For the maven user, just
>     depending on
>     infinispan-embedded-query will do the trick, since infinispan-embedded
>     would be a transitive.
>
>
> Interesting, I thought the uber jars would only be relevant for 
> non-Maven users.
> So we'd also have a POM in the Maven repo that Maven users can 
> reference, for each uber jar?
Why not. A side of effect of Maven Shade is that it generates a 
"dependency-reduced-pom.xml" which is then "installed" or "deployed" to 
the repo in place of the original "pom.xml"

Tristan