[infinispan-dev] Uber Jars
ttarrant at redhat.com
Tue Jun 3 06:30:40 EDT 2014
On 03/06/2014 11:35, Sanne Grinovero wrote:
> On 3 June 2014 09:57, Mircea Markus <mmarkus at redhat.com> wrote:
>> On Jun 3, 2014, at 8:53, Tristan Tarrant <ttarrant at redhat.com> wrote:
>>> Dear all,
>>> on Thursday I issued a PR  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.
>>> 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
> 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
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
>> 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"
>>> - 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".
>>> - 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.
> Much simpler this way, so why not making this the default packaging?
The "uber" jars are what we should advertise in our quickstarts, docs,
etc. Obviously the single underlying jars would still be deployed to maven.
More information about the infinispan-dev