Hi Deepak, I would like to correct myself, as we are using embedded solr plugin on our uat instance. And the client we are working with is thoroughly using all the features solr provides through it. We were planning to get it into production soon, and were thinking of proceeding with the embedded version itself.
Now that you mentioned it, it would be better to use the best possible method for the production environment, that turns out to be the standalone Solr/Solr Cloud, as embedded one will be more tightly coupled with the ofbiz, which can led to server failure in case any issue arise in the solr plugin. I would like to continue with the best approach, and agree with whatever the community decides to do with the embedded solr plugin. Your comment helped me further reinvestigate into the way things were proceeding on my end. Thank you. Warm Regards Anshul Goyal On Mon, 10 Mar 2025 at 13:25, Deepak Dixit <dee...@apache.org> wrote: > Hi Anshul Goyal, > > Thanks for the details! > If users are using Solr in embedded mode in production, that’s great. > > It would be helpful if you could share additional details on the advantages > of using embedded Solr over external Solr/Solr Cloud. > Understanding the benefits would provide better insight into its use case. > > -- > Deepak Dixit > ofbiz.apache.org > > > On Mon, Mar 10, 2025 at 1:12 PM Anshul Goyal <anshe...@gmail.com> wrote: > > > Hi Deepak, > > We are actually using solr in embedded mode on production. We are using > the > > same gradle task to run solr as we are using for running OFBiz. We are > > running both on the same port. > > > > We cannot rule out the possibility of more users making use of the solr > > plugin in a similar way. > > > > Best regards > > Anshul Goyal > > > > On Mon, 10 Mar 2025, 12:21 Deepak Dixit, <dee...@apache.org> wrote: > > > > > We can update the Solr plugin to connect with an external Solr instance > > > instead of running it embedded. I believe no one uses Solr in embedded > > mode > > > in production, > > > so it's best to treat Solr as an external system. > > > With the Solr plugin update, we can configure it to communicate with an > > > external Solr instance. > > > To make it developer-friendly, we can also provide a Gradle task to > > > download and run Solr in the development environment. > > > > > > -- > > > Deepak Dixit > > > ofbiz.apache.org > > > > > > > > > On Mon, Feb 3, 2025 at 2:09 PM gaetan.chaboussie < > > > gaetan.chabous...@nereide.fr> wrote: > > > > > > > Hi all. Thanks for the answer. I'll wait for the Solr update to > > continue > > > > the migration work. > > > > > > > > Gaetan > > > > > > > > On 1/30/25 10:02, Jacques Le Roux wrote: > > > > > Hi, > > > > > > > > > > We are speaking about the trunk, only. So nobody should using it in > > > > > production. But we know it's not the case. > > > > > > > > > > So I agree, we can wait. > > > > > > > > > > Again, thank you for the good work Gaetan. I hope we will able to > > > > > complete in coming months, sounds possible after your research :) > > > > > > > > > > Jacques > > > > > > > > > > Le 30/01/2025 à 03:22, Anshul Goyal a écrit : > > > > >> Hi Gaetan, > > > > >> > > > > >> I agree with Michael that we should wait until the solr migration > > > comes > > > > >> out, as removing it may cause issues to existing users using solr > > > along > > > > >> with OFBiz. > > > > >> > > > > >> Best Regards > > > > >> Anshul Goyal > > > > >> > > > > >> On Thu, 30 Jan 2025, 03:55 Michael Brohl, < > michael.br...@ecomify.de > > > > > > > >> wrote: > > > > >> > > > > >>> Hi Gaetan, > > > > >>> > > > > >>> thanks for your continuing work on this migration task. > > > > >>> > > > > >>> Since there is no urgent need to finish the migration in short > > time, > > > we > > > > >>> should wait until we can do it without regressions or cutting > > > existing > > > > >>> functionality. > > > > >>> > > > > >>> So I vote for option 3 to wait until Solr is ready for this > change. > > > > >>> > > > > >>> Thanks and regards, > > > > >>> > > > > >>> Michael Brohl > > > > >>> > > > > >>> ecomify GmbH - www.ecomify.de > > > > >>> > > > > >>> > > > > >>> Am 29.01.25 um 17:24 schrieb gaetan.chaboussie: > > > > >>>> Hello community, > > > > >>>> In the process of from migrating javax to jakarta in framework, > > then > > > > >>>> in plugins , I came across a compilation issue. > > > > >>>> Links to MR : [1] [2] > > > > >>>> This issue comes from the solr plugin. After some research, it > > seems > > > > >>>> that the plugin doesn't handle jakarta yet and still uses javax > > [3] > > > > >>>> Lucene is up to date at this point and already at version 10.1 > > while > > > > >>>> Solr is in the process of releasing the 10.0 [4] > > > > >>>> If in understand correctly, both libraries should be sync in > their > > > > >>>> version number. > > > > >>>> Jacques already tried to upgrade Solr in the past, and despite > all > > > > >>>> efforts, it seems it didn't work [5] > > > > >>>> > > > > >>>> I see several options : > > > > >>>> - Temporarily disabling the Solr plugin, but carry on with the > > > > >>>> migration and migrate Solr plugin once the 10.0 version is out > > > > >>>> - Move the Solr plugin to the Attic, and update it when the need > > > comes > > > > >>>> - Wait until the Solr migration is out to continue the migration > > > work > > > > >>>> > > > > >>>> FWIW, with both framework and plugins on branch OFBIZ-12989, and > > the > > > > >>>> Solr plugin removed, OFBiz compiles and the integration tests > are > > > OK. > > > > >>>> > > > > >>>> So i'd like to open the discussion ! > > > > >>>> Thanks > > > > >>>> Best Regards, > > > > >>>> Gaetan > > > > >>>> > > > > >>>> [1] https://github.com/apache/ofbiz-plugins/pull/133 > > > > >>>> [2] https://github.com/apache/ofbiz-framework/pull/875 > > > > >>>> [3] https://issues.apache.org/jira/browse/SOLR-17503 > > > > >>>> [4] https://issues.apache.org/jira/browse/SOLR-17631 > > > > >>>> [5] https://issues.apache.org/jira/browse/OFBIZ-12645 > > > > >>>> > > > > >>>> Base OFBiz ticket : > > > https://issues.apache.org/jira/browse/OFBIZ-12989 > > > > >>>> > > > > > > > > > >
