Propose changing the "dist" layout

classic Classic list List threaded Threaded
3 messages Options
Reply | Threaded
Open this post in threaded view
|

Propose changing the "dist" layout

David Smiley
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
Reply | Threaded
Open this post in threaded view
|

Re: Propose changing the "dist" layout

Erick Erickson
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 <[hidden email]> 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: [hidden email]
For additional commands, e-mail: [hidden email]

Reply | Threaded
Open this post in threaded view
|

Re: Propose changing the "dist" layout

David Smiley
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


On Sun, Nov 15, 2020 at 7:31 AM Erick Erickson <[hidden email]> 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 <[hidden email]> 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: [hidden email]
For additional commands, e-mail: [hidden email]