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] >>> >>> >
