Created JENA-1305 <https://issues.apache.org/jira/browse/JENA-1305> to track Jena ElasticSearch Implementation. Can some one please add the required features that need to be supported. I have added what I can think of.
Thanks, Anuj Kumar On Sat, Mar 4, 2017 at 3:41 PM, anuj kumar <[email protected]> wrote: > Hi Osma, > I just subscribed to the Dev mailing list. > I think you are right. If we know that there's no one using Solr it would > actually be wise to drop it in favour of ElasticSearch. > > Thanks, > Anuj Kumar > > > On Fri, Mar 3, 2017 at 4:51 PM, Osma Suominen <[email protected]> > wrote: > >> Hi Anuj, >> >> Did you see my earlier message to the dev list? Are you subscribed to >> that list? I will Cc: you this time just to be sure. See >> http://jena.markmail.org/thread/uhs6cuhotzj4tjrj for the actual message >> in case you missed it (including some replies). >> >> I see what you mean by deprecating Solr first before removing it, but I >> can't figure out how that would work in practice. If you're right about >> Solr 4.9.1 requiring Lucene 4.9.1, then we can't have Solr and ES support >> in Jena at the same time - unless we upgrade the Solr side as well, which >> seems a bit of a waste of time if you're going to remove it anyway. >> >> Like I explained in JENA-1301 there are many problems with the Solr >> implementation and I doubt there are many users, quite possibly nobody at >> all. >> >> In any case switching indexing technologies for jena-text should be >> rather easy, as the text index itself doesn't need to be migrated - it can >> simply be rebuilt from the RDF data. So if someone runs, say, Fuseki 2.5.0 >> with a Solr index, then upgrading to (as yet hypothetical) Fuseki 2.6.0 >> with an ES index instead is just a matter of setting up ES, changing the >> text index configuration slightly and running jena.textindexer (or >> reloading the data, whichever is easier). There is no technical benefit >> from having support for both Solr and ES in the same Jena release as it >> doesn't make migration any easier, but of course, advance warning might >> help with planning the move to ES. >> >> -Osma >> >> >> >> 03.03.2017, 16:43, anuj kumar kirjoitti: >> >>> Hey, >>> I just saw https://issues.apache.org/jira/browse/JENA-1301 >>> Should we not first officially deprecate it and gives any users of Solr a >>> chance to move to different Indexing technology? >>> >>> BTW, I dont know yet how to login to apache JIRA. >>> >>> Thanks, >>> Anuj Kumar >>> >>> On Fri, Mar 3, 2017 at 1:23 PM, anuj kumar <[email protected]> >>> wrote: >>> >>> I Osma, >>>> I briefly looked at the pull request. I beieve we need to upgrade >>>> Lucene >>>> and Solr in one go, isnt it. The reason being Solr 4.9.1 depends on >>>> Lucene >>>> 4.9.1 >>>> >>>> Also how do i log into issues.apache.org and where to file this bug? >>>> >>>> Thanks, >>>> Anuj Kumar >>>> >>>> On Fri, Mar 3, 2017 at 11:22 AM, Osma Suominen < >>>> [email protected]> >>>> wrote: >>>> >>>> Hi Anuj, >>>>> >>>>> It's great that we found agreement over this! >>>>> >>>>> I've restarted the Lucene upgrade effort (JENA-1250) that had stalled >>>>> and >>>>> made a PR [1] that implements the upgrade up to version 6.4.1 (with >>>>> 5.5.4 >>>>> as an intermediate step). I'll wait for comments on the PR and if >>>>> people >>>>> think it's OK I will merge it soon to Jena master. Meanwhile, you can >>>>> already base your ES implementation on that branch [2] if you like. >>>>> >>>>> Could you please open a JIRA issue on issues.apache.org explaining the >>>>> Elasticsearch support feature, so that we have a place for tracking >>>>> this >>>>> work, request comments etc. >>>>> >>>>> Also I suggest we move the discussion around this to the developers' >>>>> list >>>>> ([email protected]) where it's more appropriate. >>>>> >>>>> -Osma >>>>> >>>>> [1] https://github.com/apache/jena/pull/219 >>>>> >>>>> [2] https://github.com/osma/jena/tree/jena-1250-lucene6 >>>>> >>>>> >>>>> 03.03.2017, 02:45, anuj kumar kirjoitti: >>>>> >>>>> I second that. I am now finalising the integration of ES and should >>>>>> have >>>>>> a >>>>>> good production quality implementation ready in a week's time. At >>>>>> that >>>>>> time I would want you guys to have a look at the implementation and >>>>>> provide >>>>>> feedback. Once you guys have upgraded Lucene to 6.4.1 , I can merge >>>>>> the >>>>>> code in jena-text module and do a round of testing. >>>>>> >>>>>> Thanks, >>>>>> Anuj Kumar >>>>>> >>>>>> On 2 Mar 2017 22:28, "A. Soroka" <[email protected]> wrote: >>>>>> >>>>>> I do agree that trying to juggle different versions of Lucene >>>>>> libraries >>>>>> >>>>>>> is >>>>>>> probably not a realistic option right now. Luckily (if I understand >>>>>>> the >>>>>>> conversation thus far correctly) we have a solid alternative; getting >>>>>>> our >>>>>>> current Lucene dependency upgraded should allow us to (eventually) >>>>>>> merge >>>>>>> Anuj's work into the mainstream of development. Someone please tell >>>>>>> me >>>>>>> if I >>>>>>> have that wrong! :grin: >>>>>>> >>>>>>> Let me reiterate that this seems like very good work and speaking for >>>>>>> myself, I certainly want to get it included into Jena. It's just a >>>>>>> question >>>>>>> of fitting it in correctly, which might take a bit of time. >>>>>>> >>>>>>> --- >>>>>>> A. Soroka >>>>>>> The University of Virginia Library >>>>>>> >>>>>>> On Mar 1, 2017, at 1:27 PM, Osma Suominen <[email protected] >>>>>>> > >>>>>>> >>>>>>>> >>>>>>>> wrote: >>>>>>> >>>>>>> >>>>>>>> Hi Anuj! >>>>>>>> >>>>>>>> I have nothing against modularity in general. However, I cannot see >>>>>>>> how >>>>>>>> >>>>>>>> your proposal could work in practice for the Fuseki build, due to >>>>>>> the >>>>>>> reasons I mentioned in my previous message (and Adam seemed to >>>>>>> concur). >>>>>>> >>>>>>> >>>>>>>> In any case, I'll see what I can do to get the Lucene upgrade moving >>>>>>>> >>>>>>>> again. If all current Jena modules (ie jena-text and jena-spatial) >>>>>>> were >>>>>>> upgraded to Lucene 6.4.1, then you could just add your ES classes to >>>>>>> jena-text, right? I think that would be better for everyone than >>>>>>> having >>>>>>> to >>>>>>> maintain your own separate module. >>>>>>> >>>>>>> >>>>>>>> -Osma >>>>>>>> >>>>>>>> 01.03.2017, 16:59, anuj kumar kirjoitti: >>>>>>>> >>>>>>>> I personally have no preference as to how the code in Jena should be >>>>>>>>> structured, as long as I am able to use it :). >>>>>>>>> I have personal preference of doing it in a specific way because >>>>>>>>> IMO, >>>>>>>>> >>>>>>>>> it is >>>>>>>> >>>>>>> >>>>>>> modular which makes it much easier to maintain in the long run. But >>>>>>>> >>>>>>>>> >>>>>>>>> again >>>>>>>> >>>>>>> >>>>>>> it may not be the quickest one. >>>>>>>> >>>>>>>>> >>>>>>>>> I already have been given a deadline, by the company to have ES >>>>>>>>> >>>>>>>>> extension >>>>>>>> >>>>>>> >>>>>>> implemented in the next 15 days :). What this means is that I will be >>>>>>>> >>>>>>>>> maintaining the ES code extension to Jena Text at-least locally >>>>>>>>> for a >>>>>>>>> coming period of time. I would be more than happy to contribute to >>>>>>>>> Jena >>>>>>>>> community whatever is required to have a proper ElasticSearch >>>>>>>>> Implementation in place, whether within jena-text module or as a >>>>>>>>> >>>>>>>>> separate >>>>>>>> >>>>>>> >>>>>>> module. Till the time Lucene and Solr is not upgraded to the latest >>>>>>>> >>>>>>>>> version, I will have to maintain a separate module for >>>>>>>>> jena-text-es. >>>>>>>>> >>>>>>>>> Cheers! >>>>>>>>> Anuj Kumar >>>>>>>>> >>>>>>>>> >>>>>>>>> On Wed, Mar 1, 2017 at 3:36 PM, A. Soroka <[email protected]> >>>>>>>>> wrote: >>>>>>>>> >>>>>>>>> Osma-- >>>>>>>>> >>>>>>>>>> >>>>>>>>>> The short answer is that yes, given the right tools you _can_ have >>>>>>>>>> different versions of code accessible in different ways. The >>>>>>>>>> longer >>>>>>>>>> >>>>>>>>>> answer >>>>>>>>> >>>>>>>> >>>>>>> is that it's probably not a viable alternative for Jena for this >>>>>>>> >>>>>>>>> >>>>>>>>>> problem, >>>>>>>>> >>>>>>>> >>>>>>> at least not without a lot of other change. >>>>>>>> >>>>>>>>> >>>>>>>>>> You are right to point to the classloader mechanism as being at >>>>>>>>>> the >>>>>>>>>> >>>>>>>>>> heart >>>>>>>>> >>>>>>>> >>>>>>> of this question, but I must alter your remark just slightly. From >>>>>>>> "the >>>>>>>> >>>>>>>>> Java classloader only sees a single, flat package/class namespace >>>>>>>>>> and >>>>>>>>>> >>>>>>>>>> a set >>>>>>>>> >>>>>>>> >>>>>>> of compiled classes" to "ANY GIVEN Java classloader only sees a >>>>>>>> single, >>>>>>>> >>>>>>>>> flat package/class namespace and a set of compiled classes". >>>>>>>>>> >>>>>>>>>> This is the fact that OSGi uses to make it possible to maintain >>>>>>>>>> strict >>>>>>>>>> module boundaries (and even dynamic module relationships at >>>>>>>>>> run-time). >>>>>>>>>> >>>>>>>>>> Each >>>>>>>>> >>>>>>>> >>>>>>> OSGi bundle sees its own classloader, and the framework is >>>>>>>> responsible >>>>>>>> >>>>>>>>> >>>>>>>>>> for >>>>>>>>> >>>>>>>> >>>>>>> connecting bundles up to ensure that every bundle has what it needs >>>>>>>> in >>>>>>>> >>>>>>>>> >>>>>>>>>> the >>>>>>>>> >>>>>>>> >>>>>>> way of types to function, based on metadata that the bundles provide >>>>>>>> >>>>>>>>> >>>>>>>>>> to the >>>>>>>>> >>>>>>>> >>>>>>> framework. It's an incredibly powerful system (I use it every day and >>>>>>>> >>>>>>>>> >>>>>>>>>> enjoy >>>>>>>>> >>>>>>>> >>>>>>> it enormously) but it's also very "heavy" and requires a good deal of >>>>>>>> >>>>>>>>> investment to use. In particular, it's probably too large to put >>>>>>>>>> >>>>>>>>>> _inside_ >>>>>>>>> >>>>>>>> >>>>>>> Jena. (I frequently put Jena inside an OSGi instance, on the other >>>>>>>> >>>>>>>>> >>>>>>>>>> hand.) >>>>>>>>> >>>>>>>> >>>>>>> >>>>>>>> Java 9 Jigsaw [1] offers some possibility for strong modularization >>>>>>>>>> of >>>>>>>>>> this kind, but it's really meant for the JDK itself, not >>>>>>>>>> application >>>>>>>>>> libraries. In theory, we could "roll our own" classloader >>>>>>>>>> management >>>>>>>>>> >>>>>>>>>> for >>>>>>>>> >>>>>>>> >>>>>>> this problem. That sounds like more than a bit of a rabbit hole to >>>>>>>> me. >>>>>>>> >>>>>>>>> There might be another, more lightweight, toolkit out there to this >>>>>>>>>> purpose, but I'm not aware of any myself. >>>>>>>>>> >>>>>>>>>> Otherwise, yes, you get into shading and the like. We have to do >>>>>>>>>> that >>>>>>>>>> >>>>>>>>>> for >>>>>>>>> >>>>>>>> >>>>>>> Guava for now because of HADOOP-10101 (grumble grumble) but it's >>>>>>>> >>>>>>>>> >>>>>>>>>> hardly a >>>>>>>>> >>>>>>>> >>>>>>> thing we want to do any more of than needed, I don't think. >>>>>>>> >>>>>>>>> >>>>>>>>>> --- >>>>>>>>>> A. Soroka >>>>>>>>>> The University of Virginia Library >>>>>>>>>> >>>>>>>>>> [1] http://openjdk.java.net/projects/jigsaw/ >>>>>>>>>> >>>>>>>>>> On Mar 1, 2017, at 9:03 AM, Osma Suominen < >>>>>>>>>> [email protected] >>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>> wrote: >>>>>>>>>> >>>>>>>>>> >>>>>>>>>>> Hi Anuj! >>>>>>>>>>> >>>>>>>>>>> Thanks for the clarification. >>>>>>>>>>> >>>>>>>>>>> However, I'm still not sure I understand the situation >>>>>>>>>>> completely. I >>>>>>>>>>> >>>>>>>>>>> know Maven can perform a lot of tricks, but Maven modules are >>>>>>>>>> just >>>>>>>>>> convenient ways to structure a Java project. Maven cannot change >>>>>>>>>> the >>>>>>>>>> >>>>>>>>>> fact >>>>>>>>> >>>>>>>> >>>>>>> that at runtime, module divisions don't really matter (except that >>>>>>>> they >>>>>>>> >>>>>>>>> usually correspond to package sub-namespaces) and the Java >>>>>>>>>> classloader >>>>>>>>>> >>>>>>>>>> only >>>>>>>>> >>>>>>>> >>>>>>> sees a single, flat package/class namespace and a set of compiled >>>>>>>> >>>>>>>>> >>>>>>>>>> classes >>>>>>>>> >>>>>>>> >>>>>>> (usually within JARs) in the classpath that it needs to check to find >>>>>>>> >>>>>>>>> >>>>>>>>>> the >>>>>>>>> >>>>>>>> >>>>>>> right classes, and if there are two versions of the same library (eg >>>>>>>> >>>>>>>>> Lucene) with overlapping class names, that's going to cause >>>>>>>>>> trouble. >>>>>>>>>> >>>>>>>>>> The >>>>>>>>> >>>>>>>> >>>>>>> only way around that is to shade some of the libraries, i.e. rename >>>>>>>> >>>>>>>>> >>>>>>>>>> them so >>>>>>>>> >>>>>>>> >>>>>>> that they end up in another, non-conflicting namespace. Apparently >>>>>>>> >>>>>>>>> Elasticsearch also did some of that in the past [1] but nowadays >>>>>>>>>> tries >>>>>>>>>> >>>>>>>>>> to >>>>>>>>> >>>>>>>> >>>>>>> avoid it. >>>>>>>> >>>>>>>>> >>>>>>>>>> >>>>>>>>>>> Does your assumption 1 ("At a given point in time, only a single >>>>>>>>>>> >>>>>>>>>>> Indexing Technology is used") imply that in the assembler >>>>>>>>>> >>>>>>>>>> configuration, >>>>>>>>> >>>>>>>> >>>>>>> you cannot have ja:loadClass declarations for both Lucene and ES >>>>>>>> >>>>>>>>> >>>>>>>>>> backends? >>>>>>>>> >>>>>>>> >>>>>>> Or how do you run something like Fuseki that contains (in a single >>>>>>>> big >>>>>>>> >>>>>>>>> >>>>>>>>>> JAR) >>>>>>>>> >>>>>>>> >>>>>>> both the jena-text and jena-text-es modules with all their >>>>>>>> >>>>>>>>> >>>>>>>>>> dependencies, >>>>>>>>> >>>>>>>> >>>>>>> one of which requires the Lucene 4.x classes and the other one the >>>>>>>> >>>>>>>>> >>>>>>>>>> Lucene >>>>>>>>> >>>>>>>> >>>>>>> 6.4.1 classes? How do you ensure that only one of them is used at a >>>>>>>> >>>>>>>>> >>>>>>>>>> time, >>>>>>>>> >>>>>>>> >>>>>>> and that the Java classloader, even though it has access to both >>>>>>>> >>>>>>>>> >>>>>>>>>> versions >>>>>>>>> >>>>>>>> >>>>>>> of Lucene, only loads classes from the single, correct one and not >>>>>>>> the >>>>>>>> >>>>>>>>> other? Or do you need to have separate "Fuseki-Lucene" and >>>>>>>>>> "Fuseki-ES" >>>>>>>>>> packages, so that you don't end up with two Lucene versions within >>>>>>>>>> the >>>>>>>>>> >>>>>>>>>> same >>>>>>>>> >>>>>>>> >>>>>>> Fuseki JAR? >>>>>>>> >>>>>>>>> >>>>>>>>>> >>>>>>>>>>> -Osma >>>>>>>>>>> >>>>>>>>>>> [1] https://www.elastic.co/blog/to-shade-or-not-to-shade >>>>>>>>>>> >>>>>>>>>>> 01.03.2017, 11:03, anuj kumar kirjoitti: >>>>>>>>>>> >>>>>>>>>>> Hi Osma, >>>>>>>>>>>> >>>>>>>>>>>> I understand what you are saying. There are ways to mitigate >>>>>>>>>>>> risks >>>>>>>>>>>> >>>>>>>>>>>> and >>>>>>>>>>> >>>>>>>>>> >>>>>>> balance the refactoring without affecting the existing modules. But I >>>>>>>> >>>>>>>>> >>>>>>>>>>>> will >>>>>>>>>>> >>>>>>>>>> >>>>>>>>>> not delve into those now. I am not an expert in Jena to >>>>>>>>>>> convincingly >>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> say >>>>>>>>>>> >>>>>>>>>> >>>>>>> that it is possible, without any hiccups. But I can take a guess and >>>>>>>> >>>>>>>>> >>>>>>>>>>>> say >>>>>>>>>>> >>>>>>>>>> >>>>>>> that it is indeed possible :) >>>>>>>> >>>>>>>>> >>>>>>>>>>>> For the question: "is it even possible to mix modules that >>>>>>>>>>>> depend >>>>>>>>>>>> on >>>>>>>>>>>> different versions of the Lucene libraries within the same >>>>>>>>>>>> project?" >>>>>>>>>>>> >>>>>>>>>>>> I actually do not understand what you mean by mixing modules. I >>>>>>>>>>>> >>>>>>>>>>>> assume >>>>>>>>>>> >>>>>>>>>> >>>>>>> you >>>>>>>> >>>>>>>>> >>>>>>>>>> mean having jena-text and jena-text-es as dependencies in a build >>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> without >>>>>>>>>>> >>>>>>>>>> >>>>>>>>>> causing the build to conflict. If that is what you mean than the >>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> answer >>>>>>>>>>> >>>>>>>>>> >>>>>>> is >>>>>>>> >>>>>>>>> >>>>>>>>>> yes it is possible and quite simple as well. Let me explain how it >>>>>>>>>>> >>>>>>>>>>>> is >>>>>>>>>>>> possible. But before that some assumption which I want to call >>>>>>>>>>>> out >>>>>>>>>>>> explicitly. >>>>>>>>>>>> >>>>>>>>>>>> *Assumption:* >>>>>>>>>>>> 1. At a given point in time, only a single Indexing Technology >>>>>>>>>>>> is >>>>>>>>>>>> >>>>>>>>>>>> used >>>>>>>>>>> >>>>>>>>>> >>>>>>> for >>>>>>>> >>>>>>>>> >>>>>>>>>> text based indexing and searching via Jean. What this means is >>>>>>>>>>> that >>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> we >>>>>>>>>>> >>>>>>>>>> >>>>>>> will >>>>>>>> >>>>>>>>> >>>>>>>>>> either use Lucene Implementation OR Solr Implementation OR ES >>>>>>>>>>> >>>>>>>>>>>> Implementation at any given point in time. >>>>>>>>>>>> 2. Fuseki build does not depend on any Lucene 4.9.1 specific >>>>>>>>>>>> classes >>>>>>>>>>>> >>>>>>>>>>>> but >>>>>>>>>>> >>>>>>>>>> >>>>>>> only on jena-text classes, if at all. >>>>>>>> >>>>>>>>> >>>>>>>>>>>> Based on these assumptions it is possible to create a build that >>>>>>>>>>>> >>>>>>>>>>>> contains >>>>>>>>>>> >>>>>>>>>> >>>>>>>>>> jena-text based common classes + ES specific classes without any >>>>>>>>>>> >>>>>>>>>>>> compatibility issues. And it is infact quite simple. I did it in >>>>>>>>>>>> the >>>>>>>>>>>> current jena-text-es module and ran the entire build which >>>>>>>>>>>> succeeded. >>>>>>>>>>>> The key is to include the latest Lucene dependencies at the very >>>>>>>>>>>> >>>>>>>>>>>> beginning >>>>>>>>>>> >>>>>>>>>> >>>>>>>>>> in the pom and then include jena-text dependency. Maven will then >>>>>>>>>>> >>>>>>>>>>>> automatically resolve the dependency issues by including the >>>>>>>>>>>> Lucene >>>>>>>>>>>> librarires that we included in our es specific pom. Have a look >>>>>>>>>>>> the >>>>>>>>>>>> >>>>>>>>>>>> pom >>>>>>>>>>> >>>>>>>>>> >>>>>>> of >>>>>>>> >>>>>>>>> >>>>>>>>>> jena-text-es module here to see how it can be done : >>>>>>>>>>> >>>>>>>>>>>> https://github.com/EaseTech/jena/blob/master/jena-text-es/po >>>>>>>>>>>> m.xml >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> Thanks, >>>>>>>>>>>> Anuj Kumar >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> On Wed, Mar 1, 2017 at 7:27 AM, Osma Suominen < >>>>>>>>>>>> >>>>>>>>>>>> [email protected]> >>>>>>>>>>> >>>>>>>>>> >>>>>>>>>> wrote: >>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> Hi Anuj, >>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>>>> I understand your concerns. However, we also need to balance >>>>>>>>>>>>> between >>>>>>>>>>>>> >>>>>>>>>>>>> the >>>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>> needs of individual modules/features and the whole codebase. I'm >>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>>> willing to >>>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>> put in the effort to keep the other modules up to date with newer >>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>>> Lucene >>>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>> versions. Lucene upgrade requirements are well documented, the >>>>>>>>>>> only >>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>>> hitches >>>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>> seen in JENA-1250 were related to how jena-text (ab)used some >>>>>>>>>>> Lucene >>>>>>>>>>> >>>>>>>>>>>> features that were dropped from newer versions. >>>>>>>>>>>>> >>>>>>>>>>>>> A perhaps stupid question to more experienced Java developers: >>>>>>>>>>>>> is >>>>>>>>>>>>> it >>>>>>>>>>>>> >>>>>>>>>>>>> even >>>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>> possible to mix modules that depend on different versions of the >>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>>> Lucene >>>>>>>>>>>> >>>>>>>>>>> >>>>>>> libraries within the same project? In my (quite limited) >>>>>>>> >>>>>>>>> >>>>>>>>>>>>> understanding >>>>>>>>>>>> >>>>>>>>>>> >>>>>>> of >>>>>>>> >>>>>>>>> >>>>>>>>>> Java projects and libraries, this requires special arrangements >>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>>> (e.g. >>>>>>>>>>>> >>>>>>>>>>> >>>>>>> shading) as the Java package/class namespace is shared by all the >>>>>>>> >>>>>>>>> >>>>>>>>>>>>> code >>>>>>>>>>>> >>>>>>>>>>> >>>>>>> running within the same JVM. >>>>>>>> >>>>>>>>> >>>>>>>>>>>>> So can you create, say, a Fuseki build that contains the >>>>>>>>>>>>> current >>>>>>>>>>>>> >>>>>>>>>>>>> jena-text >>>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>> module (depending on Lucene 4.x) and the new jena-text-es module >>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>>> (depending >>>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>> on Lucene 6.4.1) without any compatibility issues? >>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>>> -Osma >>>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>>>> 01.03.2017, 00:47, anuj kumar kirjoitti: >>>>>>>>>>>>> >>>>>>>>>>>>> Hi, >>>>>>>>>>>>> >>>>>>>>>>>>>> >>>>>>>>>>>>>> My 2 Cents : >>>>>>>>>>>>>> >>>>>>>>>>>>>> The reason I proposed to have separate modules for Lucene, >>>>>>>>>>>>>> Solr >>>>>>>>>>>>>> and >>>>>>>>>>>>>> >>>>>>>>>>>>>> ES is >>>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>> exactly for avoiding the "All or Nothing" approach we need to take >>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>>>> if >>>>>>>>>>>>> >>>>>>>>>>>> >>>>>>> we >>>>>>>> >>>>>>>>> >>>>>>>>>> club them all together. If they stay together and if in the near >>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>>>> future I >>>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>> want to upgrade ES to another version, I also need to again >>>>>>>>>>> upgrade >>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>>>> Lucene >>>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>> and Solr and possibly another implementation that may have been >>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>>>> added >>>>>>>>>>>>> >>>>>>>>>>>> >>>>>>> during the time. As we all know, this means weeks of work if not >>>>>>>> >>>>>>>>> >>>>>>>>>>>>>> months to >>>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>> get the changes released. This will personally de-motivate me to >>>>>>>>>>> do >>>>>>>>>>> >>>>>>>>>>>> anything and I will probably start maintaining my version of >>>>>>>>>>>>>> >>>>>>>>>>>>>> Jena-Text as >>>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>> that would be much simpler to do than to upgrade and test and in >>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>>>> the >>>>>>>>>>>>> >>>>>>>>>>>> >>>>>>> process own(read fix bugs) the upgrade for each and every >>>>>>>> >>>>>>>>> >>>>>>>>>>>>>> technology. >>>>>>>>>>>>> >>>>>>>>>>>> >>>>>>> >>>>>>>> If they are developed as separate modules, they can evolve >>>>>>>>>>>>>> >>>>>>>>>>>>>> independently >>>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>> of >>>>>>>>>>> >>>>>>>>>>>> each other and we can avoid situations where we cant upgrade to >>>>>>>>>>>>>> >>>>>>>>>>>>>> latest >>>>>>>>>>>>> >>>>>>>>>>>> >>>>>>> version of Lucene because we do not know what effect it will have >>>>>>>> >>>>>>>>> >>>>>>>>>>>>>> on >>>>>>>>>>>>> >>>>>>>>>>>> >>>>>>> Solr >>>>>>>> >>>>>>>>> >>>>>>>>>> Implementation. >>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>>>> We can start with having a separate Module for Jena Text ES >>>>>>>>>>>>>> and >>>>>>>>>>>>>> see >>>>>>>>>>>>>> >>>>>>>>>>>>>> how >>>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>> things go. If they go well, we could extract out Solr and Lucene >>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>>>> out >>>>>>>>>>>>> >>>>>>>>>>>> >>>>>>> of >>>>>>>> >>>>>>>>> >>>>>>>>>> Jena Text. >>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>>>> Again this is just a suggestion based on my limited industry >>>>>>>>>>>>>> >>>>>>>>>>>>>> experience. >>>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>> >>>>>>>>>>> Thanks, >>>>>>>>>>>>>> Anuj Kumar >>>>>>>>>>>>>> >>>>>>>>>>>>>> >>>>>>>>>>>>>> >>>>>>>>>>>>>> On Tue, Feb 28, 2017 at 5:23 PM, Osma Suominen < >>>>>>>>>>>>>> >>>>>>>>>>>>>> [email protected] >>>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>> >>>>>>>>>>> wrote: >>>>>>>>>>>>>>> >>>>>>>>>>>>>> >>>>>>>>>>>>>> 28.02.2017, 17:12, A. Soroka kirjoitti: >>>>>>>>>>>>>> >>>>>>>>>>>>>> >>>>>>>>>>>>>>> https://lists.apache.org/thread.html/dce0d502b11891c28e57bbc >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> bb0cdef27d8374d58d9634076b8ef4cd7@1431107516@%3Cdev.jena. >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> apache.org >>>>>>>>>>>>>>> >>>>>>>>>>>>>> >>>>>>> %3E >>>>>>>> >>>>>>>>> >>>>>>>>>> ? In other words, might it be better to factor out between -text >>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>>>>>> and >>>>>>>>>>>>>>> >>>>>>>>>>>>>> >>>>>>> -spatial and _then_ try to upgrade the Lucene version? >>>>>>>> >>>>>>>>> >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> I certainly wouldn't object to that, but somebody has to >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>> volunteer >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> to do >>>>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>> the actual work! >>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>>>>> I don't use the Solr component now, but I could easily see so >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> doing... >>>>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>> >>>>>>>>>>> that's pretty vague, I know, and I'm not in a position to do any >>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> work to >>>>>>>>>>>>>>> >>>>>>>>>>>>>> >>>>>>>>>> maintain it, so consider that just a very small and blurry data >>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>>>>>> point. >>>>>>>>>>>>>>> >>>>>>>>>>>>>> >>>>>>>>>> :) >>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> Last time I tried it (it was a while ago) I couldn't figure >>>>>>>>>>>>>>>> out >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> how >>>>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>> to >>>>>>>> >>>>>>>>> >>>>>>>>>> get >>>>>>>>>>> >>>>>>>>>>>> it running... If you could just try that with some toy data, >>>>>>>>>>>>>>> then >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> your >>>>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>> data >>>>>>>>>>> >>>>>>>>>>>> point would be a lot less blurry :) I haven't used Solr for >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> anything, so >>>>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>> I'm not very familiar with how to set it up, and the jena-text >>>>>>>>>>> >>>>>>>>>>>> instructions >>>>>>>>>>>>>>> are pretty vague unfortunately. >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> -Osma >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> -- >>>>>>>>>>>>>>> Osma Suominen >>>>>>>>>>>>>>> D.Sc. (Tech), Information Systems Specialist >>>>>>>>>>>>>>> National Library of Finland >>>>>>>>>>>>>>> P.O. Box 26 (Kaikukatu 4) >>>>>>>>>>>>>>> 00014 HELSINGIN YLIOPISTO >>>>>>>>>>>>>>> Tel. +358 50 3199529 >>>>>>>>>>>>>>> [email protected] >>>>>>>>>>>>>>> http://www.nationallibrary.fi >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> >>>>>>>>>>>>>> >>>>>>>>>>>>>> >>>>>>>>>>>>>> -- >>>>>>>>>>>>> Osma Suominen >>>>>>>>>>>>> D.Sc. (Tech), Information Systems Specialist >>>>>>>>>>>>> National Library of Finland >>>>>>>>>>>>> P.O. Box 26 (Kaikukatu 4) >>>>>>>>>>>>> 00014 HELSINGIN YLIOPISTO >>>>>>>>>>>>> Tel. +358 50 3199529 >>>>>>>>>>>>> [email protected] >>>>>>>>>>>>> http://www.nationallibrary.fi >>>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>> -- >>>>>>>>>>> Osma Suominen >>>>>>>>>>> D.Sc. (Tech), Information Systems Specialist >>>>>>>>>>> National Library of Finland >>>>>>>>>>> P.O. Box 26 (Kaikukatu 4) >>>>>>>>>>> 00014 HELSINGIN YLIOPISTO >>>>>>>>>>> Tel. +358 50 3199529 >>>>>>>>>>> [email protected] >>>>>>>>>>> http://www.nationallibrary.fi >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>> -- >>>>>>>> Osma Suominen >>>>>>>> D.Sc. (Tech), Information Systems Specialist >>>>>>>> National Library of Finland >>>>>>>> P.O. Box 26 (Kaikukatu 4) >>>>>>>> 00014 HELSINGIN YLIOPISTO >>>>>>>> Tel. +358 50 3199529 >>>>>>>> [email protected] >>>>>>>> http://www.nationallibrary.fi >>>>>>>> >>>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>> >>>>> -- >>>>> Osma Suominen >>>>> D.Sc. (Tech), Information Systems Specialist >>>>> National Library of Finland >>>>> P.O. Box 26 (Kaikukatu 4) >>>>> 00014 HELSINGIN YLIOPISTO >>>>> Tel. +358 50 3199529 >>>>> [email protected] >>>>> http://www.nationallibrary.fi >>>>> >>>>> >>>> >>>> >>>> -- >>>> *Anuj Kumar* >>>> >>>> >>> >>> >>> >> >> -- >> Osma Suominen >> D.Sc. (Tech), Information Systems Specialist >> National Library of Finland >> P.O. Box 26 (Kaikukatu 4) >> 00014 HELSINGIN YLIOPISTO >> Tel. +358 50 3199529 >> [email protected] >> http://www.nationallibrary.fi >> > > > > -- > *Anuj Kumar* > -- *Anuj Kumar*
