[
https://issues.apache.org/jira/browse/SOLR-16157?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17524590#comment-17524590
]
Houston Putman commented on SOLR-16157:
---------------------------------------
No, {{/server/lib}} is meant to host the libraries just needed for the server
(but also all of the jetty libraries, because of jetty limitations).
{{/server/lib/ext}} is supposed to house all of the libraries used by both the
server and web-app, but in reality it's not because it doesn't include the
jetty libraries. {{/server/solr-webapp/webapp/WEB-INF/lib/}} holds the
libraries that JUST the webapp uses, not the server as well, but with the
jetty-client libraries included. These jetty client libraries are duplicated
across {{/server/lib}} and {{/server/solr-webapp/webapp/WEB-INF/lib/}}, those
are the only duplicated Jars.
But note, not all jetty jars are duplicated. Just the ones marked
{{jettyClientImplementation}} in {{core/build.gradle}} in the PR.
> Improve jar de-duplication between server/lib(/ext) and WEB-INF/lib
> -------------------------------------------------------------------
>
> Key: SOLR-16157
> URL: https://issues.apache.org/jira/browse/SOLR-16157
> Project: Solr
> Issue Type: Improvement
> Security Level: Public(Default Security Level. Issues are Public)
> Components: Build, Gradle, Server
> Affects Versions: 9.0
> Reporter: Houston Putman
> Assignee: Houston Putman
> Priority: Blocker
> Fix For: 9.0
>
> Time Spent: 10m
> Remaining Estimate: 0h
>
> Currently the jars in the binary release's {{server/lib}}, {{server/lib/ext}}
> and {{WEB-INF/lib}} directories are manually de-duplicated, and it's very
> fragile and only works because of transitive dependencies in SolrJ.
> One example of this is done in SOLR-16072.
> Since we have the full-power of Gradle, we should be able to automate this.
> I tried to do a first-pass where all shared-libs between the server and
> web-app are put into {{server/lib/ext}}, and removed from {{server/lib}} and
> {{WEB-INF/lib}}. The problem with this approach is that Jetty does not allow
> webapps to access the Jetty libraries. Therefore this approach didn't buy
> much since we would have to write exceptions for most of the shared
> libraries, since they are jetty server libraries.
> I settled on something closer to the current approach. Two configurations in
> {{server/build.gradle}}, {{serverLib}} and {{libExt}}. in
> {{core/build.gradle}} there is an additional configuration
> {{jettyClientImplementation}}, which {{implementation}} inherits from. Both
> sets libraries are removed from {{WEB-INF/lib}} when it is built, but
> because of the jetty library limitation, {{jettyClientImplementation}}
> libraries are added back in. This is why they are specified separately in
> {{core/build.gradle}}.
> Therefore the only time a developer has to think about shared dependencies is
> when adding a client-jetty-library to Solr Core.
> Note: This is somewhat complicated by the fact that solr-core has Jetty
> Server libraries though it is never used during runtime. They are there just
> because the embedded Solr Server lives in solr-core. We should split this out
> into another package, solr-embedded so that the dependencies make more sense.
> Will create a separate issue for this.
--
This message was sent by Atlassian Jira
(v8.20.7#820007)
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]
