: If the changes I proposed are still viewed as having too many downstream : impacts, my fallback position will be to patch the jars. This involves : using the gradle import system to get the jars from Maven, then using a : patch script to manually unzip the jars, move the offending classes into : other jars which share the same package name and rezip. So far, I've been
I'm no expert here, but i trust that Uwe is, and i feel like your followup questions/suggests have still avoided his primary point about *why* Lucene/Solr hasn't attempted jigsaw modulariation... : >>> There is currently some preparatory things to move forward with modules, : >>> so although you might be able to actually compile Lucene with module system : >>> (by limiting to a subset of JAR files), it currently won’t work : >>> cross-module due to the way how it handles ServiceLoader interfaces : >>> (codecs, postings formats, analyzers, see : >>> https://issues.apache.org/jira/browse/LUCENE-9281). The only way to : >>> make it work at runtime is to put all of Lucene into one module. ...so, IIUC, even if you patch the *current* jars, any Lucene code you use that depends on SPI (like analysis chains, codecs, etc...) isn't going to work unless follow Uwe's primary suggestion for folks who care about modules... : >>> Th general recommendation is to combine all required Lucene libraries : >>> into a separate JAR file during the maven / gradle build (e.g. using the : >>> Maven Shade plugin). Keep in mind that Lucene is also not suitable for use -Hoss http://www.lucidworks.com/
--------------------------------------------------------------------- To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
