We (all?) agree to do away with "contrib" :-). I think a folder grouping the modules (that which can plug inside Solr) is useful as there are a number of them -- as such this is a nice organization IMO. There's a bunch of other stuff at the top level and I'd rather not intermix all our modules at this layer.
~ David Smiley Apache Lucene/Solr Search Developer http://www.linkedin.com/in/davidwsmiley On Fri, Jun 11, 2021 at 4:41 PM Mike Drob <[email protected]> wrote: > We can have modules, but why do they need to be in an additional folder > deep? Why not just have langid next to solrj and core? Contrib to me > connotes experimental or unsupported, which these things are decidedly not. > > On Fri, Jun 11, 2021 at 2:59 PM David Smiley <[email protected]> wrote: > >> 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] >>> >>>
