On Tue, Jun 3, 2014 at 1:30 PM, Tristan Tarrant <ttarr...@redhat.com> wrote:
> On 03/06/2014 11:35, Sanne Grinovero wrote: > > On 3 June 2014 09:57, Mircea Markus <mmar...@redhat.com> wrote: > >> On Jun 3, 2014, at 8:53, Tristan Tarrant <ttarr...@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. > Interesting, I thought the uber jars would only be relevant for non-Maven users. So we'd also have a POM in the Maven repo that Maven users can reference, for each uber jar? > > > 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@lists.jboss.org > https://lists.jboss.org/mailman/listinfo/infinispan-dev >
_______________________________________________ infinispan-dev mailing list infinispan-dev@lists.jboss.org https://lists.jboss.org/mailman/listinfo/infinispan-dev