[infinispan-dev] Uber Jars

[Galder Zamarreño]

Sounds good to me. I do like the fact that the artifacts have a -all ending, it kinda signals that it’s an Uber jar. This might be handy for users who just look at the list of artifacts in the repository. Alternatively, we could have a group id that signals it, e.g. org.infinispan.all or org.infinispan.uber or something different ?

In terms of the actual uber jars, I’m happy with the separation of embedded/query/remote.

Cheers,

On 03 Jun 2014, at 11:30, Tristan Tarrant <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> 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
> _______________________________________________
> infinispan-dev mailing list
> infinispan-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/infinispan-dev


--
Galder Zamarreño
galder at redhat.com
twitter.com/galderz