spatial
spatial copied to clipboard
Upload neo4j-spatial on Maven central
In order to use the neo4j-spatial artifacts, the Neo4j Snapshot Maven Repository must be used, because neo4j-spatial is not on Maven central. That introduces additional moving parts, and may not be possible in all environments.
It would make sense to upload the neo4j-spatial to Maven central, along with the other neo4j artifacts. The fact that it's a 0.x version already communicates the fact that it's not a stable/production ready release, so stability should not be a concern here.
Also, I'm guessing this has to be done at some point anyways, so the earlier the better.
Any plans to do this, perhaps in the not too distant future?
WDYT @nawroth? I think the biggest bite there is to clean up graph-collections first ...
On Mon, Feb 13, 2012 at 5:27 PM, Eugen [email protected] wrote:
In order to use the neo4j-spatial artifacts, the Neo4j Snapshot Maven Repository must be used, because neo4j-spatial is not on Maven central. That introduces additional moving parts, and may not be possible in all environments.
It would make sense to upload the neo4j-spatial to Maven central, along with the other neo4j artifacts. The fact that it's a 0.x version already communicates the fact that it's not a stable/production ready release, so stability should not be a concern here.
Any plans to do this, perhaps in the not too distant future?
Reply to this email directly or view it on GitHub: https://github.com/neo4j/spatial/issues/37
It's strongly discouraged to upload artifacts to Maven central unless their dependencies are already there. It wouldn't make a lot of sense to do so either: you would still have to add other repositories to use neo4j-spatial.
For the Neo4j part, neo4j-server is the only artifact not on central as far as I can see (note: graph-collections are already on central), and I plan to investigate if all dependencies are now on central. In case they are, we'll start deploying it to central.
Other than that, there are Osgeo and Tinkerpop artifacts missing on central as well. So that should be fixed first as well. And any transitive dependencies of those.
With all that in place, it's time to deploy neo4j-spatial to central! I'd really like that.
I don't know the internal structure of the neo4j-spatial source code vs the dependencies. If it could be devided into multiple projects/modules we could start deploying some modules to central when their dependencies have been cleared.
Note that to make life easier until all dependencies hit Maven central, we have a single repository mirroring everything needed to build neo4j-spatial (or any other Neo4j build): http://m2.neo4j.org/content/groups/everything/ The same thing, but without any snapshot artifacts is found here: http://m2.neo4j.org/content/groups/release-deps/
Well, yes, deploying neo4j-spatial with it's dependencies was implied - it would make little sense otherwise. Since neo4j-spatial developers know best which dependencies are not yet on central, it would make sense to make progress on that front, in order to actually get neo4j-spatial itself on central. If that means modularizing the project, or changing some dependency, or perhaps some other solution - that is something every project need to figure out before being on central. And as I was saying earlier, it is something that needs to be figured out eventually anyways, so it may as well be sooner rather than later, when the dependencies are more entrenched and harder to take out, or when the product is harder to modularize. Thanks for the feedback on this.
If I understood all of the previous discussion it sounded like the only dependency of neo4j-spatial that might prevent it being deployed to maven central was the neo4j-server. If I remember correctly this dependency is only to support a very small wrapper API supporting the REST interface in neo4j-server. It is not deeply integrated in neo4j-spatial. So perhaps the REST API wrapper is the only part to split into a separate project, and it would be a relatively easy I think.
Yes, we could break out the REST API part, I don't think it is widely used anyway. Will check with the community.
/peter
On Tue, Feb 14, 2012 at 10:53 AM, Eugen [email protected] wrote:
Well, yes, deploying neo4j-spatial with it's dependencies was implied - it would make little sense otherwise. Since neo4j-spatial developers know best which dependencies are not yet on central, it would make sense to make progress on that front, in order to actually get neo4j-spatial itself on central. If that means modularizing the project, or changing some dependency, or perhaps some other solution - that is something every project need to figure out before being on central. And as I was saying earlier, it is something that needs to be figured out eventually anyways, so it may as well be sooner rather than later, when the dependencies are more entrenched and harder to take out, or when the product is harder to modularize. Thanks for the feedback on this.
Reply to this email directly or view it on GitHub: https://github.com/neo4j/spatial/issues/37#issuecomment-3957892
Guys, since Neo4j 1.8.M02 all the Neo4j artifacts are deployed to central. Due to Gremlin being on central and some upgrades to versions found on central in other places, we finally arrived at our goal! So now it's time to look at the rest of the dependencies here in spatial and make sure they are all on central ... and fix if they are not.
That is great! I can look into it asap.
Send from mobile. On May 28, 2012 7:24 AM, "Anders Nawroth" < [email protected]> wrote:
Guys, since Neo4j 1.8.M02 all the Neo4j artifacts are deployed to central. Due to Gremlin being on central and some upgrades to versions found on central in other places, we finally arrived at our goal! So now it's time to look at the rest of the dependencies here in spatial and make sure they are all on central ... and fix if they are not.
Reply to this email directly or view it on GitHub: https://github.com/neo4j/spatial/issues/37#issuecomment-5959356
If there are changes required to the geotools dependencies, perhaps Davide or I could help out. Let us know how it goes.
Well, that would be appreciated! Basically, we need non-snapshot versions of everything to be able to lock down things.
On Tue, May 29, 2012 at 11:04 AM, Craig Taverner [email protected] wrote:
If there are changes required to the geotools dependencies, perhaps Davide or I could help out. Let us know how it goes.
Reply to this email directly or view it on GitHub: https://github.com/neo4j/spatial/issues/37#issuecomment-5978652
Right, non-snapshot versions deployed to mvn central.
To find out what versions of a lib exist on mvn central, use this: http://search.maven.org/
/anders
Should this be closed? Sounds like it is completed for non-snapshot versions, right?
I don't know if all non-neo4j dependencies are on central now, that has to be verified. If they are, releases should go to central and this issue should be closed. Any upcoming release planned?
Well, we are planning to let this be a full community project, and the community decide. More details on that later.
On Sun, Jan 13, 2013 at 1:25 AM, Anders Nawroth [email protected]:
I don't know if all non-neo4j dependencies are on central now, that has to be verified. If they are, releases should go to central and this issue should be closed. Any upcoming release planned?
— Reply to this email directly or view it on GitHubhttps://github.com/neo4j/spatial/issues/37#issuecomment-12187428.
Jonathan and Axel have made some important contributions that could warrant a new release. I also want to upgrade neo4-spatial.rb ruby gem and get it working on rails apps, so perhaps synchronized release?
Fine for me. Would like to hear Michaels feedback regarding Spring Data Neo4j. @jexp?
/peter
On Sun, Jan 13, 2013 at 2:34 PM, Craig Taverner [email protected]:
Jonathan and Axel have made some important contributions that could warrant a new release. I also want to upgrade neo4-spatial.rb ruby gem and get it working on rails apps, so perhaps synchronized release?
— Reply to this email directly or view it on GitHubhttps://github.com/neo4j/spatial/issues/37#issuecomment-12193707.