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

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) - 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) - 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). Discuss :)

Tristan [1] https://github.com/infinispan/infinispan/pull/2589 _______________________________________________ infinispan-dev mailing list infinispan-dev(a)lists.jboss.org https://lists.jboss.org/mailman/listinfo/infinispan-dev

On 3 June 2014 09:57, Mircea Markus <mmarkus(a)redhat.com&gt; wrote: > On Jun 3, 2014, at 8:53, Tristan Tarrant <ttarrant(a)redhat.com&gt; 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.

Much simpler this way, so why not making this the default packaging?

On Tue, Jun 3, 2014 at 1:30 PM, Tristan Tarrant <ttarrant(a)redhat.com <mailto:ttarrant@redhat.com>> wrote: On 03/06/2014 11:35, Sanne Grinovero wrote: > On 3 June 2014 09:57, Mircea Markus <mmarkus(a)redhat.com <mailto:mmarkus@redhat.com>> wrote: >> On Jun 3, 2014, at 8:53, Tristan Tarrant <ttarrant(a)redhat.com <mailto:ttarrant@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?

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.