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