Re: Lucene 9.0 Java module system support

While the module system sounds nice in theory, my experience is unfortunately that it is quite difficult to use for any application with many existing dependencies, 90% or more of projects don't use it and therefore wind up in the default module. I've wasted many hours trying to get it to work in

Re: Solr Admin UI Refresh 2020

I disagree that "package management frameworks are for loading non-essential features or features not enabled by default". I don't think the proposal of the UI being a "package" (in the new package system) implies that the UI (or _any_ package) is not a highly valuable package that is so highly

Re: [VOTE] Release Lucene/Solr 8.5.1 RC1

+1 SUCCESS! [2:05:03.473933] On Fri, 10 Apr 2020 at 12:24, Adrien Grand wrote: > +1 SUCCESS! [2:38:04.620259] > > On Thu, Apr 9, 2020 at 1:28 PM jim ferenczi > wrote: > >> +1 >> >> SUCCESS! [2:10:08.094546] >> >> Le jeu. 9 avr. 2020 à 10:19, Alan Woodward a >> écrit : >> >>> +1 >>> >>>

Re: Lucene 9.0 Java module system support

Hi Uwe, As I mentioned in the original post, the main issue I've come across with being able to support Java 11 modules is that Lucene doesn't cleanly separate the use of package names across jar libraries which results in errors like: "The package org.apache.lucene.analysis.standard is

Re: [VOTE] Release Lucene/Solr 8.5.1 RC1

+1 SUCCESS! [2:38:04.620259] On Thu, Apr 9, 2020 at 1:28 PM jim ferenczi wrote: > +1 > > SUCCESS! [2:10:08.094546] > > Le jeu. 9 avr. 2020 à 10:19, Alan Woodward a > écrit : > >> +1 >> >> SUCCESS! [1:18:54.574272] >> >> On 8 Apr 2020, at 21:21, Nhat Nguyen >> wrote: >> >> +1 >> >> SUCCESS!

OpenJDK 15 EA build 18 is now available

Hi Uwe & Dawid, OpenJDK 15 EA build 18 is now available at http://jdk.java.net/15 * * * These early access, open source builds are provided under the GNU General Public License, version 2, with the Classpath Exception . * Schedule for JDK 15

Re: Solr Admin UI Refresh 2020

I agree with you.  On Fri, Apr 10, 2020 at 06:22 David Smiley wrote: > I disagree that "package management frameworks are for loading > non-essential features or features not enabled by default". > > I don't think the proposal of the UI being a "package" (in the new package > system) implies

Re: Solr Admin UI Refresh 2020

I don't see admin UI as non-core. I think that an application UI for end-users of an application consumes Solr non-core. I have to resign from arguing, though. I don't consider myself a UI expert. I can do the work. On Fri, Apr 10, 2020 at 11:42 AM Ishan Chattopadhyaya <

Re: Solr Admin UI Refresh 2020

David, you capture my thoughts well. Having a UI as a package gives users more choice and gives our users more flexibility. 1. Users would be able to use a latter version of the UI with an older version of Solr, or vice versa. 2. Users should be able to install multiple types of UI, from

Re: Solr Admin UI Refresh 2020

+1 to David Smiley On Sat, Apr 11, 2020, 8:12 AM Marcus Eagan wrote: > I don't see admin UI as non-core. I think that an application UI for > end-users of an application consumes Solr non-core. I have to resign from > arguing, though. > > I don't consider myself a UI expert. I can do the work.

Re: Lucene 9.0 Java module system support

Just to be clear, I'm not suggesting that you or the Solr project should use the module system. I agree that it is not for every project, however, more and more projects and libraries are moving slowly to using the module system or making their libraries compatible. I'm not suggesting you add

Re: Lucene 9.0 Java module system support

: 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