The contrib folder is just a folder of modules -- optional plugins for solr-core. IMO we should simply rename "contrib" to "modules". I think the only non-module in there is the prometheus exporter which could move out. Mike, I'm not sure if you have a different notion of what "module" is? I believe most of us would be happy to move away from "contrib" wording, anyway.
~ David Smiley Apache Lucene/Solr Search Developer http://www.linkedin.com/in/davidwsmiley On Fri, Jun 11, 2021 at 3:03 PM Mike Drob <[email protected]> wrote: > 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] > >
