Mmh, not really an idea so far.
The steps you describe look OK.
Try to build and install the Neo4j bundle alone:
cd neo4j-osgi/bundle
mvn clean install
Then try out this project:
https://github.com/jri/neo4j-osgi-test
It provisions a standalone Felix runtime (with the aid of Pax Runner).
There
Hi Peter,
SUCCESS!!!
No index provider 'lucene' found in OSGi is solved for the moment!
Its exactly as you suggest:
When using pax exam's native container no error shows up.
When using pax exam's pax runner container the error shows up (which is correct
OSGi behavoir).
When using
Peter,
no problem, take your time.
I see your super bundle test running OK in pax exam, but with an independant
deployment scenario No index provider 'lucene' found is a persisting error.
Meanwhile I tried the approach you suggested: having the neo-super-bundle and
my activator as separate
I'm seriously trying the superbundle approach and can't get rid of No index
provider 'lucene' found.
The tests at https://github.com/neo4j/neo4j-osgi run successful but I have
serious problems to transfer them to my application (I'm using Felix 3.2.1 on a
Mac).
Just to check my
On Jul 23, 2011, at 1:13, Peter Neubauer wrote:
Will try to check it out tomorrow. Now sleep. Thanks for the test!
Sure.
Just one addition for tomorrow: the only neo-bundles my application need are
kernel and lucene-index. So I did add just these 2 to the super bundle's
dependencies instead
Thanks for replies!
Yes, the super bundle approach (putting *all* neo modules and *all* their
dependencies in one bundle) works in principle. But to be a deployable solution
...
1) it must exist in the Maven repo and be on a par with the Neo4j release
2) A configuration mechanism is required
Hi Peter,
thanks for reply!
Is there any chance to get the old index API back, as an *alternative* to the
new one?
Within an OSGi environment the old index API worked perfectly in Neo4j 1.0,
1.1, and 1.2. In the latter ones the old index API friendly coexists with the
new
Neo4j 1.4 / Lucene 3.1 / OSGi =
java.lang.IllegalArgumentException: No index provider 'lucene' found
I'm running in Felix. All Dependencies are resolved (so version 0.0.0 should
not be the problem here).
1|Active |5|wrap_mvn_org.apache.lucene_lucene-core_3.1.0 (0.0.0)
It works now! Great!
Neo4j 1.1 + meta-model runs together in OSGi environment.
Thank you for quick action!
Cheers,
Jörg
On Aug 4, 2010, at 10:00, Peter Neubauer wrote:
Jörg,
the neo4j-meta-model is not following the core components release
cycle, so it will be released separately when it
Now, with final 1.1 util component, dependencies resolve properly in an OSGi
environment.
Still missing is the meta-model component.
It is at 0.9-SNAPSHOT and declares a dependency of Neo4j 1.1-SNAPSHOT:
Import-Package: org.neo4j.graphdb;version=1.1.0.SNAPSHOT.
So, Neo4j 1.1 can't
Great!
I've tested the 2 new methods.
rename() works as expected.
With remove() there is an issue:
once a class is removed, getMetaClass(name, false) returns a stale
MetaModelClass object if -- and only if -- that class has been renamed before.
It is expected to return null.
If the class has
On Jul 5, 2010, at 8:57, Mattias Persson wrote:
Maybe there's some bug in the removeIndex(Node,String) method. Instead
try to do a:
index.removeIndex(classNode1,MetaModelProperty.KEY_NAME,classNode1.getName());
before you set the new name
I've tested this already. Indexing works OK.
On Jul 5, 2010, at 9:13, Niels Hoogeveen wrote:
MetaModelClasses are cached in a map, so while the property may be renamed
and reindexed, the map still holds the original name value. After a restart
of the application the new value should be applied. To make renaming possible
a method
Thank you!
Highly appreciating that :-)
I'm looking forward ...
Cheers
Jörg
On Jul 5, 2010, at 17:54, Niels Hoogeveen wrote:
If Mattias agrees, I suggest adding the methods:
MetaModelNamespace#rename(String oldName, String newName)
MetaModelNamespace#remove(String name, Boolean forced)
How can a MetaModelClass be renamed?
There seems to be no obvious way.
I tried to change the meta_model_name property of the wrapped node and
re-index the node. This basically works, but namespace.getMetaClass() still
returns a MetaModelClass object when called with the old name. IMO it would
15 matches
Mail list logo
