[infinispan-dev] Uber Jars

[Tristan Tarrant]

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 [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.

> 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.

Tristan