resulting jar contains neo4j classes

[boggle]

Hi, I'd like to use pacer-neo4j with a different version of neo4j (1.7.2) but the resulting jar contains some old (1.5.) neo4j kernel classes. Is it possible to build pacer against a different version, preferably in a way that does not include any neo4j classes in the result jar?

This issue is not such a big deal when using bundler and rackup as the load order of gems can be controled there. However when using warbler and deploying to a servlet container the load order of jars cannot be controled and thus the old neo4j classes included with pacer-neo4j caused problems by shadowing the newer ones.

[pangloss]

It should be possible to do that by editing pacer-neo4j's pom.xml. It normally points to blueprints-neo4j-graph for blueprints 1.0. You'd probably need to replicate that file tweaked with the newer version of neo4j but otherwise use the same versions of blueprints

I haven't tried that but you can run Pacer's test suite which fully exercises pacer-neo4j as well, hopefully it will just work.

You can't just simply upgrade blueprints unfortunately because there loads of breaking changes in their API. I'll be working through that in the near future though.

Cheers, Darrick

On Fri, Jul 13, 2012 at 12:09 PM, Stefan Plantikow < reply@reply.github.com

wrote:

Hi, I'd like to use pacer-neo4j with a different version of neo4j (1.7.2) but the resulting jar contains some old (1.5.) neo4j kernel classes. Is it possible to build pacer against a different version, preferably in a way that does not include any neo4j classes in the result jar?

This issue is not such a big deal when using bundler and rackup as the load order of gems can be controled there. However when using warbler and deploying to a servlet container the load order of jars cannot be controled and thus the old neo4j classes included with pacer-neo4j caused problems by shadowing the newer ones.

---

Reply to this email directly or view it on GitHub: https://github.com/pangloss/pacer-neo4j/issues/3

[boggle]

Hi,

Am 13.07.2012 um 19:34 schrieb Darrick Wiebe:

It should be possible to do that by editing pacer-neo4j's pom.xml. It normally points to blueprints-neo4j-graph for blueprints 1.0. You'd probably need to replicate that file tweaked with the newer version of neo4j but otherwise use the same versions of blueprints

Trouble is, there is no 1.x release of blueprints for neo4j 1.7.

I haven't tried that but you can run Pacer's test suite which fully exercises pacer-neo4j as well, hopefully it will just work.

You can't just simply upgrade blueprints unfortunately because there loads of breaking changes in their API. I'll be working through that in the near future though.

That will be awesome.

I will try to just remove the neo4j classes from the jar and see if this works.

Please make sure that you do not include again any Neo4j core classes in new jars. This kind of mistake is not easily found.

Regars,

Stefan.

[pangloss]

Is it a mistake? It was certainly an intentional decision to include the required jars in the gem and that is why I split Pacer into a core gem and this gem.

What is the alternative to including the jars you need in a gem package? I'd be interested to know how you recommend I package the gem while still making it very simple to install for new users.

Let me know how it goes with removing the Neo4j classes from the jar. If you build a rake task to do that (and it is effective), I'll include it in the project.

Cheers, Darrick

On Mon, Jul 16, 2012 at 4:58 AM, Stefan Plantikow < reply@reply.github.com

wrote:

Hi,

Am 13.07.2012 um 19:34 schrieb Darrick Wiebe:

It should be possible to do that by editing pacer-neo4j's pom.xml. It normally points to blueprints-neo4j-graph for blueprints 1.0. You'd probably need to replicate that file tweaked with the newer version of neo4j but otherwise use the same versions of blueprints

Trouble is, there is no 1.x release of blueprints for neo4j 1.7.

I haven't tried that but you can run Pacer's test suite which fully exercises pacer-neo4j as well, hopefully it will just work.

You can't just simply upgrade blueprints unfortunately because there loads of breaking changes in their API. I'll be working through that in the near future though.

That will be awesome.

I will try to just remove the neo4j classes from the jar and see if this works.

Please make sure that you do not include again any Neo4j core classes in new jars. This kind of mistake is not easily found.

Regars,

Stefan.

---

Reply to this email directly or view it on GitHub: https://github.com/pangloss/pacer-neo4j/issues/3#issuecomment-7001310

[boggle]

Hi again,

Am 16.07.2012 um 17:36 schrieb Darrick Wiebe reply@reply.github.com:

Is it a mistake? It was certainly an intentional decision to include the required jars in the gem and that is why I split Pacer into a core gem and this gem.

I think yes. At least please provide a version that does not include neo4j classes and its dependencies.

Rationale (for jruby):

neo4j.rb 2 has factored out the neo4j dependencies into separate gems that come with a bit of glue code, so it is not sufficient to just have the classes. In the end switching the neo4j version required making custom versions of these gems. Now when that stuff gets deployed together with pacer into a servlet container, it becomes pure happenstance which version of the neo4j classes ends up first in the class path. This in turn leads to nasty bugs that are very tricky to debug (you get messages like "store upgrade failed" and "wrong log version" from neo4j. On the other hand it is very important to be able to switch the neo4j version in use to fix bugs etc.

What is the alternative to including the jars you need in a gem package? I'd be interested to know how you recommend I package the gem while still making it very simple to install for new users.

Can't you just exclude all neo4j classes and add a dependency to the neo4j-community gem instead ?

In general, the more gem dependencies you use instead of including some version of some maven dependency directly in the jar, the less likely someone will be hit by these kind of problems. For example, there is a jrjackson gem which we use which might also be shadowed accidentally by pacer.

Also from the java side of things, I'd rather used maven dependencies that get required classes as part of a contains-all.jar

Let me know how it goes with removing the Neo4j classes from the jar. If you build a rake task to do that (and it is effective), I'll include it in the project.

In the end I build a custom pacer vendor gem that adds

/ true runtime org.neo4j:_ org.scala-lang:_ org.apache_:_ org.codehaus.jackson_:_ javax.transaction:jta javax.xml.stream:stax-api

to pom/standalone.xml. Surely not the best way to fix this but works for me :)

Cheers,

Stefan Plantikow

PS: That is my real name actually, that boggle account is just for fun but tied to github ;)