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
