I've been doing a bit of dependency work in one of our contribs, and
observing more closely than usual exactly what we produce in the
distribution layout (result of gradlew assemble). There are some tricks
Dawid did in gradle/solr/packaging.gradle to pull off this stunt to keep
things as they have been for many years. The distribution layout is
awkward, I think. We produce this "dist" folder at the top level that has
every JAR this project produces, *even contribs*. But why? I think
contribs should keep to themselves. It's ridiculous that /contribs/ltr/ is
empty except for a README.txt... IMO it ought to have the JAR in a "lib"
subdirectory there mixed with its dependencies (LTR has none but others
sure do). Today, each contrib's JAR is in "/dist". And what about SolrJ?
I think SolrJ is important enough that it deserves its very own top-level
directory "solrj", and like the contribs, with a "lib" alongside it. Maybe
Solrj's optional dependencies could be in a lib-optional dir next to it or
lib/opt/ (beneath it). Then... we don't need "dist" at all. It contains
the solr-core JAR but this is redundant. Furthermore, the server webapp
could be configured to add the SolrJ libs so that we don't need to
redundantly put any of them in the distribution. There might be some
duplicated jars overall, but not many. Logging libs might be explicitly
excluded so that they are only in one spot. (Logging in Java is a mess)
WDYT?
~ David Smiley
Apache Lucene/Solr Search Developer
http://www.linkedin.com/in/davidwsmiley
observing more closely than usual exactly what we produce in the
distribution layout (result of gradlew assemble). There are some tricks
Dawid did in gradle/solr/packaging.gradle to pull off this stunt to keep
things as they have been for many years. The distribution layout is
awkward, I think. We produce this "dist" folder at the top level that has
every JAR this project produces, *even contribs*. But why? I think
contribs should keep to themselves. It's ridiculous that /contribs/ltr/ is
empty except for a README.txt... IMO it ought to have the JAR in a "lib"
subdirectory there mixed with its dependencies (LTR has none but others
sure do). Today, each contrib's JAR is in "/dist". And what about SolrJ?
I think SolrJ is important enough that it deserves its very own top-level
directory "solrj", and like the contribs, with a "lib" alongside it. Maybe
Solrj's optional dependencies could be in a lib-optional dir next to it or
lib/opt/ (beneath it). Then... we don't need "dist" at all. It contains
the solr-core JAR but this is redundant. Furthermore, the server webapp
could be configured to add the SolrJ libs so that we don't need to
redundantly put any of them in the distribution. There might be some
duplicated jars overall, but not many. Logging libs might be explicitly
excluded so that they are only in one spot. (Logging in Java is a mess)
WDYT?
~ David Smiley
Apache Lucene/Solr Search Developer
http://www.linkedin.com/in/davidwsmiley