[infinispan-dev] Uber Jars

[Sanne Grinovero]

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.

> Just for my own understanding, what is the rationale behind this?
>
>>
>> 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)

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.

Very glad to see progress in this area :-)

Cheers,
Sanne

>>
>> Discuss :)
>
> Much simpler this way, so why not making this the default packaging?
>
>>
>>
>> Tristan
>>
>>
>>
>> [1] https://github.com/infinispan/infinispan/pull/2589
>> _______________________________________________
>> infinispan-dev mailing list
>> infinispan-dev at lists.jboss.org
>> https://lists.jboss.org/mailman/listinfo/infinispan-dev
>
> Cheers,
> --
> Mircea Markus
> Infinispan lead (www.infinispan.org)
>
>
>
>
> _______________________________________________
> infinispan-dev mailing list
> infinispan-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/infinispan-dev