Hi,
Remember jackrabbit depends on Lucene as well so upgrading Lucene can be a
problem here.
Regarding maven-indexer yes we can depend on a snapshot until the release.
I can release it ;-)
On 13 June 2017 at 06:06, Martin wrote:
> Hi,
>
> the lucene version depends on the maven indexer. But I'm
forget it but we need to ensure we can read maven index files
On 13 June 2017 at 17:06, Olivier Lamy wrote:
> Hi,
> Remember jackrabbit depends on Lucene as well so upgrading Lucene can be a
> problem here.
> Regarding maven-indexer yes we can depend on a snapshot until the release.
> I can
Hi,
upgrading the maven indexer leads to some major changes.
Lucene is used by maven-indexer and also by jackrabbit. Jackrabbit sticks to
the old 3.x version and, as I see it, they will not move to a newer version.
There is Jackrabbit Oak as alternative.
I tried a proof of concept and could repla
Hi
Maven Indexer 6.0-SNAPSHOT doesn't need anymore plexus bridge.
I'm working on it in the branch ( feature/jcr_oak )
Not sure why but I have intermittent failure with store-jcr module.
I definitely agree on the upgrade.
Well we can simply detect it's not oak compatible and schedule a full
reindex
well the issue is non compatible version of Lucene for Maven Indexer and
Oak (well I can try push a patch to Oak for upgrading...)
On 24 June 2017 at 08:41, Olivier Lamy wrote:
> Hi
> Maven Indexer 6.0-SNAPSHOT doesn't need anymore plexus bridge.
> I'm working on it in the branch ( feature/jcr_o
well this gonna be a pain.
IMHO we need to find a new alternative to jcr oak.
And something not using Lucene as it's a real pain to have different
librairies using lucene as they do not update in the same time (and Lucene
break backward compat so quickly...)
Any ideas? I'd like to have something em
Yes, you are right. The lucene dependency causes a lot of trouble and will
cause headaches with each version change of one of the dependencies.
What are the requirements for a replacement?
- We want to store hierarchical data?
- We want to store metadata for nodes ?
- Fulltext search (only metadat
I think we merge the branch to the master, when it's decided what way to go.
Do you refer to the intermittent failures of store-jcr module with your answer
or do you refer to other issues?
I had the intermittent failures too and thought about some race condition,
because JCR Oak is very asynchro
Hi
graph/document storage could be convenient (but not possible with neo4j as
it's GPL license [1])
well we can add solr as an additional webapp with our jetty distribution
but this will be a pain for users who want to use tomcat or any other
servlet container...
we still need to investigate a new
maybe an option is to use some shading?
I'm thinking of shading lucene packages used by maven indexer. I can easily
provide a build for that.
WDYT?
On 26 June 2017 at 11:49, Olivier Lamy wrote:
> Hi
> graph/document storage could be convenient (but not possible with neo4j as
> it's GPL license
What do you mean exactly by shading? Moving to another package name?
Am Mittwoch, 5. Juli 2017, 01:19:17 CEST schrieb Olivier Lamy:
> maybe an option is to use some shading?
> I'm thinking of shading lucene packages used by maven indexer. I can easily
> provide a build for that.
> WDYT?
>
> On 26
Yup.
The idea is to have an extra jar produced by the maven-indexer with shaded
lucene version.
So the lucene classes (version used by Maven indexer) will be relocated in
a package called org.apache.maven.index.shaded.lucene (such
org.apache.maven.index.shaded.lucene.search.BooleanClause )
Then you
Can I please an obvious/stupid question?
What is driving this need for change?
From a quick read of the thread above, all of the options appear to introduce a
lot of breaking changes, and a whole lot more uncertainty.
So, what is so broken that it is driving these changes?
Sent from my iPhone
We have different lucene (incompatible) dependencies that prevents us to update
the maven indexer and/or jackrabbit. And this will happen again with each
upgrade from one of these two packages in the future.
So would be really good if we can find a solution that removes one of the
lucene depend
I will try to share the work I did tomorrow in a branch
On Thu, 6 Jul 2017 at 7:48 pm, Martin Stockhammer
wrote:
> We have different lucene (incompatible) dependencies that prevents us to
> update the maven indexer and/or jackrabbit. And this will happen again with
> each upgrade from one of the
So the repo contains a branch feature/jar_shaded_lucene here
https://git1-us-west.apache.org/repos/asf?p=maven-indexer.git;a=summary
and I pushed what I started for Archiva in the branch called feature/jcr_oak
So in order to test it you need to build first maven-indexer from the
branch feature/jar_
Hi Olivier,
great!
For my understanding: The dependency to lucene in the pom of indexer-core is
still there, but the lucene packages are moved to the ...maven.index.shaded...
package? You develop indexer-core with the standard lucene packages and the
shading is executed during the build of the
Hi
Took a bit of time but I finally get the branch working :-)
branch: feature/jcr_oak
Let me know what do you think of?
Well I guess there are still some optimisations to do for jcr oak
I can see some logs:
21:02:39.559 [1071] [main] WARN oak.query.QueryImpl - Traversal query
(query without index
Hi Olivier,
great! I will look at it. I will give you feedback the next days.
And yes I have to optimize the jcr oak part and stabilize it. I will work on it.
Greetings
Martin
Am 15. August 2017 11:30:04 MESZ schrieb Olivier Lamy :
>Hi
>Took a bit of time but I finally get the branch working
Hi
So I have merged to master :-)
On 18 August 2017 at 01:22, Martin Stockhammer wrote:
> Hi Olivier,
>
> great! I will look at it. I will give you feedback the next days.
> And yes I have to optimize the jcr oak part and stabilize it. I will work
> on it.
>
> Greetings
>
> Martin
>
>
>
>
> Am 1
Hi,
I got it now running on my local machine (had to fight some issues with old
packages in my
local mvn repository).
So the shaded lucene is now in the maven-indexer master, if I see it correctly.
We have a dependency problem with the guava version. The selenium tests need
guava 22.0
and jcr o
21 matches
Mail list logo