I think related to this, I would like to see some "contibs" moved out from the contrib folder and into proper modules. Right now the definition of contrib seems to be anything that isn't core or solrj, but maybe there is room for a backup module that has gcs and s3 and hdfs all under it. LangId is already mentioned in our ref guide but we pretend like it is always present and don't think of it as a contrib. We kind of think of contrib as optional extra stuff, so maybe we call the things what they are - plugins and extensions? Then we don't have to think as hard about why certain things are showing up in which lib folders.
Also, minor benefit, I would then be able to type c<tab> instead of having to type cor<tab> to disambiguate from con<tab> in my terminal. On Fri, Jun 11, 2021 at 8:09 AM David Smiley <[email protected]> wrote: > > I believe we can do a fair amount of re-organization pertaining to Jetty > without losing the Jetty configuration that I think is valuable to users who > want to tweak something. > > ~ David Smiley > Apache Lucene/Solr Search Developer > http://www.linkedin.com/in/davidwsmiley > > > On Fri, Jun 11, 2021 at 8:01 AM Jan Høydahl <[email protected]> wrote: >> >> +1 to a cleanup here for 9.0. As clean and neat organization as possible. >> Perhaps rename "dist" -> "lib"? >> >> I wish we could get rid of the server (jetty) folder altogether, and move >> everything from server/solr-webapp/webapp/WEB-INF/lib to "lib/deps/". But >> that ties into custom boot-class, getting rid of web.xml and building Jetty >> context in Java code.. I'm willing to help here if others also want to go >> this direction. This would further hide Jetty as an impl detail and let us >> organize stuff more freely. >> >> Jan >> >> 11. jun. 2021 kl. 13:29 skrev David Smiley <[email protected]>: >> >> Bumping this conversation up, based on recent communication. I have yet to >> take action but really any of us can. >> >> ~ David Smiley >> Apache Lucene/Solr Search Developer >> http://www.linkedin.com/in/davidwsmiley >> >> >> On Mon, Nov 23, 2020 at 8:48 AM David Smiley <[email protected]> wrote: >>> >>> 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] >>>> >> --------------------------------------------------------------------- To unsubscribe, e-mail: [email protected] For additional commands, e-mail: [email protected]
