I'll proceed on this with lazy consensus.  I suspect most of us don't care,
unsurprisingly since I doubt anyone has any fondness for the "dist" folder.

~ David Smiley
Apache Lucene/Solr Search Developer
http://www.linkedin.com/in/davidwsmiley


On Sun, Nov 15, 2020 at 7:31 AM Erick Erickson <[email protected]>
wrote:

> Well, Solr has grown “organically” so some things just _are_, like
> sunrises and plagues ;)
>
> On a serious note, AFAIC rearrange as you see fit. I wonder how much of
> this is left over from the war days? Anything that’s lasted through all the
> transformations Solr has is bound to need cleaning up betimes.
>
> How would it relate to splitting Solr off into its own TLP? On the
> surface, I’d guess the two efforts would be orthogonal, I mention it just
> in case rearranging the layout would make that task easier or harder...
>
> > On Nov 15, 2020, at 12:18 AM, David Smiley <[email protected]> wrote:
> >
> > 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
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: [email protected]
> For additional commands, e-mail: [email protected]
>
>

Reply via email to