Re: [Neo] RFC: Potentially breaking changes in the upcoming 1.0 release
On Fri, Jan 8, 2010 at 11:56 AM, Laurent Laborde wrote: > On Fri, Jan 8, 2010 at 11:52 AM, Johan Svensson > wrote: > > Hi, > > > > After some discussions following the input here we decided to go with > > no explicit ".api" package but an explicit ".impl" package (for > > implementation that is not supposed to be public). The 1.0 release > > will then look like this: > > > > o "neo" component renamed to "kernel" > > - old core API (org.neo4j.api.core) will be moved to org.neo4j.graphdb > > - NeoService renamed to org.neo4j.graphdb.GraphDatabaseService > > - EmbeddedNeo renamed to org.neo4j.kernel.EmbeddedGraphDatabase > > - org.neo4j.impl.* -> org.neo4j.kernel.impl > > > > o "index-util" renamed to "index" > > - IndexService will be moved to org.neo4j.index > > - public LuceneIndexService stuff will be under org.neo4j.index.lucene > > - timeline will be under org.neo4j.index.timeline > > - rest will be moved to org.neo4j.index.impl > > > > We are starting to change things now so if you see something wrong > > with the above please let us know. > > I like this change :) > > And I love your positive attitude! Keep the hugs and smily-faces coming! -- Tobias Ivarsson Hacker, Neo Technology www.neotechnology.com Cellphone: +46 706 534857 ___ Neo mailing list User@lists.neo4j.org https://lists.neo4j.org/mailman/listinfo/user
Re: [Neo] RFC: Potentially breaking changes in the upcoming 1.0 release
On Fri, Jan 8, 2010 at 11:52 AM, Johan Svensson wrote: > Hi, > > After some discussions following the input here we decided to go with > no explicit ".api" package but an explicit ".impl" package (for > implementation that is not supposed to be public). The 1.0 release > will then look like this: > > o "neo" component renamed to "kernel" > - old core API (org.neo4j.api.core) will be moved to org.neo4j.graphdb > - NeoService renamed to org.neo4j.graphdb.GraphDatabaseService > - EmbeddedNeo renamed to org.neo4j.kernel.EmbeddedGraphDatabase > - org.neo4j.impl.* -> org.neo4j.kernel.impl > > o "index-util" renamed to "index" > - IndexService will be moved to org.neo4j.index > - public LuceneIndexService stuff will be under org.neo4j.index.lucene > - timeline will be under org.neo4j.index.timeline > - rest will be moved to org.neo4j.index.impl > > We are starting to change things now so if you see something wrong > with the above please let us know. I like this change :) -- Laurent "ker2x" Laborde Sysadmin & DBA at http://www.over-blog.com/ ___ Neo mailing list User@lists.neo4j.org https://lists.neo4j.org/mailman/listinfo/user
Re: [Neo] RFC: Potentially breaking changes in the upcoming 1.0 release
Hi, After some discussions following the input here we decided to go with no explicit ".api" package but an explicit ".impl" package (for implementation that is not supposed to be public). The 1.0 release will then look like this: o "neo" component renamed to "kernel" - old core API (org.neo4j.api.core) will be moved to org.neo4j.graphdb - NeoService renamed to org.neo4j.graphdb.GraphDatabaseService - EmbeddedNeo renamed to org.neo4j.kernel.EmbeddedGraphDatabase - org.neo4j.impl.* -> org.neo4j.kernel.impl o "index-util" renamed to "index" - IndexService will be moved to org.neo4j.index - public LuceneIndexService stuff will be under org.neo4j.index.lucene - timeline will be under org.neo4j.index.timeline - rest will be moved to org.neo4j.index.impl We are starting to change things now so if you see something wrong with the above please let us know. Regards, -Johan ___ Neo mailing list User@lists.neo4j.org https://lists.neo4j.org/mailman/listinfo/user
Re: [Neo] RFC: Potentially breaking changes in the upcoming 1.0 release
Thanks Andreas for the input, I guess if Stuart McCulloch is doing it in PaxConstruct, we can stop arguing :) So, no problems from the OSGi side for root-package-APIs :) Cheers, /peter neubauer COO and Sales, Neo Technology GTalk: neubauer.peter Skype peter.neubauer Phone +46 704 106975 LinkedIn http://www.linkedin.com/in/neubauer Twitter http://twitter.com/peterneubauer http://www.neo4j.org- Relationships count. http://gremlin.tinkerpop.com- PageRank in 2 lines of code. http://www.linkedprocess.org - Computing at LinkedData scale. On Wed, Jan 6, 2010 at 11:12 PM, Andreas Kollegger wrote: > Honestly, I've handled package naming both ways and have yet to settle > on a preferred scheme. I like the explicitness of a *.api making it > obvious where to find the public interface for bundle services. But, > if a bundle is more of a library, then I expect the top-level package > to have what I want. Also, when I don't see a *.api, I assume the > top-level has the public interfaces for services. > > So, for services: *.api and !*.impl !*.internal > For libraries: !*.internal > > But, I haven't got strong feelings about it. Just export !*.internal > and OSGi is happy. > > -Andreas > > ps. For reference, the excellent pax-construct example code uses the > top-level package for the public interfaces and *.internal for the > implementation classes, making it a pseudo-standard in my mind. > > On Jan 6, 2010, at 4:26 PM, Peter Neubauer wrote: > >> Hi there, >> from an OSGi perspective, everything between bundles is handled on >> package level. From that perspective, separation of api and impl (and >> others) is better separated via org.neo4j.api and org.neo4j.impl etc. >> Otherwise, e.g. the org.neo4j.* would be exported from the bundle >> containing the api, and any other bundle exporting e.g. some >> implementation would be hard to separate from that since it exports >> "child" package names to the first one. So, in the OSGi world of >> things this is handled by parallel naming schemes like *.api and >> *.impl.simple, *.internal etc etc. >> >> Just my 2c, WDYT Andreas Kolleger? >> >> Cheers, >> >> /peter neubauer >> >> COO and Sales, Neo Technology >> >> GTalk: neubauer.peter >> Skype peter.neubauer >> Phone +46 704 106975 >> LinkedIn http://www.linkedin.com/in/neubauer >> Twitter http://twitter.com/peterneubauer >> >> http://www.neo4j.org - Relationships count. >> http://gremlin.tinkerpop.com - PageRank in 2 lines of code. >> http://www.linkedprocess.org - Computing at LinkedData scale. >> >> >> >> On Wed, Jan 6, 2010 at 9:55 PM, Emil Eifrem wrote: >>> On Wed, Jan 6, 2010 at 21:48, Craig Taverner wrote: 1. Will a restructuring like this cause problems for your projects? Yes, but minor. Should be a simple search and replace to upgrade. >>> >>> And if you need backwards compatibility then you can just go through >>> the 'retro' component. >>> 2. Do you think this change will result in a positive overall effect for Neo4j? Perhaps. You're pushing for more use of the terms 'graph' and 'graph database', and I can see the marketing value in that. >>> >>> That's not the biggest deal although I like that. The biggest deal is >>> that it's a consistent naming scheme with -- hopefully -- proper api / >>> impl separation. >>> 3. Do these positive effects outweigh any potential problems the change causes? Hard to say. Can swing either way. Reading the wiki page, I noticed a question regarding the rdf package names, and a suggestion to add .api and .impl packages. I can answer this with my opinion, which I doubt you will agree with, but I'll add it here so at least it is said. If you had the freedom to make the change, I think that the API packages should have simple package names without the .api extension, and implementations should live in the impl packages. I think this goes even for the core api, which would be at org.neo4j.graphdb with the default implementations at org.neo4j.graphdb.impl (alternatively org.neo4j.graphdb.internal, since you explicitly state it is not of interest to users). If you had such a scheme, the location of implementations is much more flexible. You do not need to make the decision about the RDF package names now, and when you do split them, they still conform to the global naming strategy. >>> >>> I'd love to get some input from the OSGi experienced crowd on this. >>> >>> Cheers, >>> >>> -- >>> Emil Eifrém, CEO [e...@neotechnology.com] >>> Neo Technology, www.neotechnology.com >>> Cell: +46 733 462 271 | US: 206 403 8808 >>> http://blogs.neotechnology.com/emil >>> http://twitter.com/emileifrem >>> ___ >>> Neo mailing list >>> User@lists.neo4j.org >>> https://lists.neo4j.org/mailman/listinfo/user
Re: [Neo] RFC: Potentially breaking changes in the upcoming 1.0 release
Honestly, I've handled package naming both ways and have yet to settle on a preferred scheme. I like the explicitness of a *.api making it obvious where to find the public interface for bundle services. But, if a bundle is more of a library, then I expect the top-level package to have what I want. Also, when I don't see a *.api, I assume the top-level has the public interfaces for services. So, for services: *.api and !*.impl !*.internal For libraries: !*.internal But, I haven't got strong feelings about it. Just export !*.internal and OSGi is happy. -Andreas ps. For reference, the excellent pax-construct example code uses the top-level package for the public interfaces and *.internal for the implementation classes, making it a pseudo-standard in my mind. On Jan 6, 2010, at 4:26 PM, Peter Neubauer wrote: > Hi there, > from an OSGi perspective, everything between bundles is handled on > package level. From that perspective, separation of api and impl (and > others) is better separated via org.neo4j.api and org.neo4j.impl etc. > Otherwise, e.g. the org.neo4j.* would be exported from the bundle > containing the api, and any other bundle exporting e.g. some > implementation would be hard to separate from that since it exports > "child" package names to the first one. So, in the OSGi world of > things this is handled by parallel naming schemes like *.api and > *.impl.simple, *.internal etc etc. > > Just my 2c, WDYT Andreas Kolleger? > > Cheers, > > /peter neubauer > > COO and Sales, Neo Technology > > GTalk: neubauer.peter > Skype peter.neubauer > Phone +46 704 106975 > LinkedIn http://www.linkedin.com/in/neubauer > Twitter http://twitter.com/peterneubauer > > http://www.neo4j.org- Relationships count. > http://gremlin.tinkerpop.com- PageRank in 2 lines of code. > http://www.linkedprocess.org - Computing at LinkedData scale. > > > > On Wed, Jan 6, 2010 at 9:55 PM, Emil Eifrem wrote: >> On Wed, Jan 6, 2010 at 21:48, Craig Taverner wrote: >>> 1. Will a restructuring like this cause problems for your projects? >>> Yes, but minor. Should be a simple search and replace to upgrade. >> >> And if you need backwards compatibility then you can just go through >> the 'retro' component. >> >>> >>> 2. Do you think this change will result in a positive overall effect for >>> Neo4j? >>> Perhaps. You're pushing for more use of the terms 'graph' and 'graph >>> database', and I can see the marketing value in that. >> >> That's not the biggest deal although I like that. The biggest deal is >> that it's a consistent naming scheme with -- hopefully -- proper api / >> impl separation. >> >>> >>> 3. Do these positive effects outweigh any potential problems the change >>> causes? >>> Hard to say. Can swing either way. >>> >>> Reading the wiki page, I noticed a question regarding the rdf package names, >>> and a suggestion to add .api and .impl packages. I can answer this with my >>> opinion, which I doubt you will agree with, but I'll add it here so at least >>> it is said. >>> >>> If you had the freedom to make the change, I think that the API packages >>> should have simple package names without the .api extension, and >>> implementations should live in the impl packages. I think this goes even for >>> the core api, which would be at org.neo4j.graphdb with the default >>> implementations at org.neo4j.graphdb.impl (alternatively >>> org.neo4j.graphdb.internal, since you explicitly state it is not of interest >>> to users). If you had such a scheme, the location of implementations is much >>> more flexible. You do not need to make the decision about the RDF package >>> names now, and when you do split them, they still conform to the global >>> naming strategy. >> >> I'd love to get some input from the OSGi experienced crowd on this. >> >> Cheers, >> >> -- >> Emil Eifrém, CEO [e...@neotechnology.com] >> Neo Technology, www.neotechnology.com >> Cell: +46 733 462 271 | US: 206 403 8808 >> http://blogs.neotechnology.com/emil >> http://twitter.com/emileifrem >> ___ >> Neo mailing list >> User@lists.neo4j.org >> https://lists.neo4j.org/mailman/listinfo/user >> > ___ > Neo mailing list > User@lists.neo4j.org > https://lists.neo4j.org/mailman/listinfo/user ___ Neo mailing list User@lists.neo4j.org https://lists.neo4j.org/mailman/listinfo/user
Re: [Neo] RFC: Potentially breaking changes in the upcoming 1.0 release
+1 On Jan 6, 2010, at 4:52 PM, Tobias Ivarsson wrote: > On Wed, Jan 6, 2010 at 10:36 PM, Mattias Persson > wrote: > >> 2010/1/6 Rick Bullotta : >>> It's a relatively minor thing to fix in our code. I would suggest >>> reconsidering the "retro" façade, however - it really doesn't buy you >> much >>> and requires resources to keep it up-to-date, fattens up the JAR a bit, >> and >>> so on. If we're going to all move to the new version, it's best to use >> the >>> new package and class names and not lean on a "crutch" of the retro >> package. >> It'd perhaps require some extra resources, but it wouldn't fatten up >> the JAR since it would be a separate component (if I got this right)! > > > Right. The retro package would be a separate component, it would also only > be maintained until the release of 1.1. All classes and interfaces in the > retro package would obviously be marked as deprecated, giving you heaps of > horrible warnings from javac. > > That said, I do agree, if we can avoid creating it at all, it would free up > some resources. > > -- > Tobias Ivarsson > Hacker, Neo Technology > www.neotechnology.com > Cellphone: +46 706 534857 > ___ > Neo mailing list > User@lists.neo4j.org > https://lists.neo4j.org/mailman/listinfo/user ___ Neo mailing list User@lists.neo4j.org https://lists.neo4j.org/mailman/listinfo/user
Re: [Neo] RFC: Potentially breaking changes in the upcoming 1.0 release
On Wed, Jan 6, 2010 at 10:36 PM, Mattias Persson wrote: > 2010/1/6 Rick Bullotta : > > It's a relatively minor thing to fix in our code. I would suggest > > reconsidering the "retro" façade, however - it really doesn't buy you > much > > and requires resources to keep it up-to-date, fattens up the JAR a bit, > and > > so on. If we're going to all move to the new version, it's best to use > the > > new package and class names and not lean on a "crutch" of the retro > package. > It'd perhaps require some extra resources, but it wouldn't fatten up > the JAR since it would be a separate component (if I got this right)! Right. The retro package would be a separate component, it would also only be maintained until the release of 1.1. All classes and interfaces in the retro package would obviously be marked as deprecated, giving you heaps of horrible warnings from javac. That said, I do agree, if we can avoid creating it at all, it would free up some resources. -- Tobias Ivarsson Hacker, Neo Technology www.neotechnology.com Cellphone: +46 706 534857 ___ Neo mailing list User@lists.neo4j.org https://lists.neo4j.org/mailman/listinfo/user
Re: [Neo] RFC: Potentially breaking changes in the upcoming 1.0 release
2010/1/6 Rick Bullotta : > It's a relatively minor thing to fix in our code. I would suggest > reconsidering the "retro" façade, however - it really doesn't buy you much > and requires resources to keep it up-to-date, fattens up the JAR a bit, and > so on. If we're going to all move to the new version, it's best to use the > new package and class names and not lean on a "crutch" of the retro package. It'd perhaps require some extra resources, but it wouldn't fatten up the JAR since it would be a separate component (if I got this right)! > > > > -Original Message- > From: user-boun...@lists.neo4j.org [mailto:user-boun...@lists.neo4j.org] On > Behalf Of Tobias Ivarsson > Sent: Wednesday, January 06, 2010 3:28 PM > To: Neo user discussions > Subject: [Neo] RFC: Potentially breaking changes in the upcoming 1.0 release > > Hi all! > > For our upcoming final 1.0 release we are thinking about restructuring the > components and package names to make them at least closer to something we > would want to live with for a considerable future. The main affected > component at this point is the Neo4j kernel, even if other components would > follow later on as well. > > What we would like to achieve with such a refactoring is a more consistent > naming scheme, and a more descriptive naming scheme. This means that we > would change the current core api (org.neo4j.api.core). Most of the > interfaces would remain the same, but the package name would change to > org.neo4j.graphdb.api. We would also change the name of the NeoService > interface to the more descriptive name GraphDatabaseService. > > Since we have multiple components that implement the Neo4j Graph Database > API (the Neo4j kernel, the remote implementation, and the upcoming HA > system), we might at some point in the future extract the API to a separate > component that we would call graphdb-api. The current neo component would > thus be divided into two, graphdb-api and kernel. The class EmbeddedNeo > would be part of the kernel component and would (even before the division of > the components) be renamed to org.neo4j.kernel.api.EmbeddedGraphDatabase. > > In order to mitigate the transition to the new api we would provide a > transitional component, lets call it retro to have a name to refer to it by. > This component would contain the org.neo4j.api.core package and an > implementation thereof as a facade for the new org.neo4j.graphdb.api package > with the org.neo4j.kernel.api.EmbeddedGraphDatabase implementation. > > We have created a wiki page at > http://wiki.neo4j.org/content/Component_Naming where we outline the strategy > behind the naming structure, and list the renaming actions that would take > place if we go through with this. > > Since this is a rather substantial change, we want to get your input first. > There are a few things we would like to know from you: > > 1. Will a restructuring like this cause problems for your projects? > 2. Do you think this change will result in a positive overall effect for > Neo4j? > 3. Do these positive effects outweigh any potential problems the change > causes? > > If this goes well we plan to make similar refactorings to the index-util > component shortly after. > > Cheers, > The Neo4j team through > -- > Tobias Ivarsson > Hacker, Neo Technology > www.neotechnology.com > Cellphone: +46 706 534857 > ___ > Neo mailing list > User@lists.neo4j.org > https://lists.neo4j.org/mailman/listinfo/user > > ___ > Neo mailing list > User@lists.neo4j.org > https://lists.neo4j.org/mailman/listinfo/user > -- Mattias Persson, [matt...@neotechnology.com] Neo Technology, www.neotechnology.com ___ Neo mailing list User@lists.neo4j.org https://lists.neo4j.org/mailman/listinfo/user
Re: [Neo] RFC: Potentially breaking changes in the upcoming 1.0 release
Hi there, from an OSGi perspective, everything between bundles is handled on package level. From that perspective, separation of api and impl (and others) is better separated via org.neo4j.api and org.neo4j.impl etc. Otherwise, e.g. the org.neo4j.* would be exported from the bundle containing the api, and any other bundle exporting e.g. some implementation would be hard to separate from that since it exports "child" package names to the first one. So, in the OSGi world of things this is handled by parallel naming schemes like *.api and *.impl.simple, *.internal etc etc. Just my 2c, WDYT Andreas Kolleger? Cheers, /peter neubauer COO and Sales, Neo Technology GTalk: neubauer.peter Skype peter.neubauer Phone +46 704 106975 LinkedIn http://www.linkedin.com/in/neubauer Twitter http://twitter.com/peterneubauer http://www.neo4j.org- Relationships count. http://gremlin.tinkerpop.com- PageRank in 2 lines of code. http://www.linkedprocess.org - Computing at LinkedData scale. On Wed, Jan 6, 2010 at 9:55 PM, Emil Eifrem wrote: > On Wed, Jan 6, 2010 at 21:48, Craig Taverner wrote: >> 1. Will a restructuring like this cause problems for your projects? >> Yes, but minor. Should be a simple search and replace to upgrade. > > And if you need backwards compatibility then you can just go through > the 'retro' component. > >> >> 2. Do you think this change will result in a positive overall effect for >> Neo4j? >> Perhaps. You're pushing for more use of the terms 'graph' and 'graph >> database', and I can see the marketing value in that. > > That's not the biggest deal although I like that. The biggest deal is > that it's a consistent naming scheme with -- hopefully -- proper api / > impl separation. > >> >> 3. Do these positive effects outweigh any potential problems the change >> causes? >> Hard to say. Can swing either way. >> >> Reading the wiki page, I noticed a question regarding the rdf package names, >> and a suggestion to add .api and .impl packages. I can answer this with my >> opinion, which I doubt you will agree with, but I'll add it here so at least >> it is said. >> >> If you had the freedom to make the change, I think that the API packages >> should have simple package names without the .api extension, and >> implementations should live in the impl packages. I think this goes even for >> the core api, which would be at org.neo4j.graphdb with the default >> implementations at org.neo4j.graphdb.impl (alternatively >> org.neo4j.graphdb.internal, since you explicitly state it is not of interest >> to users). If you had such a scheme, the location of implementations is much >> more flexible. You do not need to make the decision about the RDF package >> names now, and when you do split them, they still conform to the global >> naming strategy. > > I'd love to get some input from the OSGi experienced crowd on this. > > Cheers, > > -- > Emil Eifrém, CEO [e...@neotechnology.com] > Neo Technology, www.neotechnology.com > Cell: +46 733 462 271 | US: 206 403 8808 > http://blogs.neotechnology.com/emil > http://twitter.com/emileifrem > ___ > Neo mailing list > User@lists.neo4j.org > https://lists.neo4j.org/mailman/listinfo/user > ___ Neo mailing list User@lists.neo4j.org https://lists.neo4j.org/mailman/listinfo/user
Re: [Neo] RFC: Potentially breaking changes in the upcoming 1.0 release
Sounds good, minor changes for us, I'd probably think twice about the retro facade to, pre 1.0 you shouldn't be expected to worry about backward compatability should you? D On 6 Jan 2010, at 20:59, Craig Taverner wrote: > +1 > > On Wed, Jan 6, 2010 at 9:57 PM, Rick Bullotta < > rick.bullo...@burningskysoftware.com> wrote: > >> It's a relatively minor thing to fix in our code. I would suggest >> reconsidering the "retro" façade, however - it really doesn't buy >> you much >> and requires resources to keep it up-to-date, fattens up the JAR a >> bit, and >> so on. If we're going to all move to the new version, it's best to >> use the >> new package and class names and not lean on a "crutch" of the retro >> package. >> >> >> >> -Original Message- >> From: user-boun...@lists.neo4j.org [mailto:user- >> boun...@lists.neo4j.org] >> On >> Behalf Of Tobias Ivarsson >> Sent: Wednesday, January 06, 2010 3:28 PM >> To: Neo user discussions >> Subject: [Neo] RFC: Potentially breaking changes in the upcoming 1.0 >> release >> >> Hi all! >> >> For our upcoming final 1.0 release we are thinking about >> restructuring the >> components and package names to make them at least closer to >> something we >> would want to live with for a considerable future. The main affected >> component at this point is the Neo4j kernel, even if other >> components would >> follow later on as well. >> >> What we would like to achieve with such a refactoring is a more >> consistent >> naming scheme, and a more descriptive naming scheme. This means >> that we >> would change the current core api (org.neo4j.api.core). Most of the >> interfaces would remain the same, but the package name would change >> to >> org.neo4j.graphdb.api. We would also change the name of the >> NeoService >> interface to the more descriptive name GraphDatabaseService. >> >> Since we have multiple components that implement the Neo4j Graph >> Database >> API (the Neo4j kernel, the remote implementation, and the upcoming HA >> system), we might at some point in the future extract the API to a >> separate >> component that we would call graphdb-api. The current neo component >> would >> thus be divided into two, graphdb-api and kernel. The class >> EmbeddedNeo >> would be part of the kernel component and would (even before the >> division >> of >> the components) be renamed to >> org.neo4j.kernel.api.EmbeddedGraphDatabase. >> >> In order to mitigate the transition to the new api we would provide a >> transitional component, lets call it retro to have a name to refer >> to it >> by. >> This component would contain the org.neo4j.api.core package and an >> implementation thereof as a facade for the new org.neo4j.graphdb.api >> package >> with the org.neo4j.kernel.api.EmbeddedGraphDatabase implementation. >> >> We have created a wiki page at >> http://wiki.neo4j.org/content/Component_Naming where we outline the >> strategy >> behind the naming structure, and list the renaming actions that >> would take >> place if we go through with this. >> >> Since this is a rather substantial change, we want to get your >> input first. >> There are a few things we would like to know from you: >> >> 1. Will a restructuring like this cause problems for your projects? >> 2. Do you think this change will result in a positive overall >> effect for >> Neo4j? >> 3. Do these positive effects outweigh any potential problems the >> change >> causes? >> >> If this goes well we plan to make similar refactorings to the index- >> util >> component shortly after. >> >> Cheers, >> The Neo4j team through >> -- >> Tobias Ivarsson >> Hacker, Neo Technology >> www.neotechnology.com >> Cellphone: +46 706 534857 >> ___ >> Neo mailing list >> User@lists.neo4j.org >> https://lists.neo4j.org/mailman/listinfo/user >> >> ___ >> Neo mailing list >> User@lists.neo4j.org >> https://lists.neo4j.org/mailman/listinfo/user >> > ___ > Neo mailing list > User@lists.neo4j.org > https://lists.neo4j.org/mailman/listinfo/user ___ Neo mailing list User@lists.neo4j.org https://lists.neo4j.org/mailman/listinfo/user
Re: [Neo] RFC: Potentially breaking changes in the upcoming 1.0 release
+1 On Wed, Jan 6, 2010 at 9:57 PM, Rick Bullotta < rick.bullo...@burningskysoftware.com> wrote: > It's a relatively minor thing to fix in our code. I would suggest > reconsidering the "retro" façade, however - it really doesn't buy you much > and requires resources to keep it up-to-date, fattens up the JAR a bit, and > so on. If we're going to all move to the new version, it's best to use the > new package and class names and not lean on a "crutch" of the retro > package. > > > > -Original Message- > From: user-boun...@lists.neo4j.org [mailto:user-boun...@lists.neo4j.org] > On > Behalf Of Tobias Ivarsson > Sent: Wednesday, January 06, 2010 3:28 PM > To: Neo user discussions > Subject: [Neo] RFC: Potentially breaking changes in the upcoming 1.0 > release > > Hi all! > > For our upcoming final 1.0 release we are thinking about restructuring the > components and package names to make them at least closer to something we > would want to live with for a considerable future. The main affected > component at this point is the Neo4j kernel, even if other components would > follow later on as well. > > What we would like to achieve with such a refactoring is a more consistent > naming scheme, and a more descriptive naming scheme. This means that we > would change the current core api (org.neo4j.api.core). Most of the > interfaces would remain the same, but the package name would change to > org.neo4j.graphdb.api. We would also change the name of the NeoService > interface to the more descriptive name GraphDatabaseService. > > Since we have multiple components that implement the Neo4j Graph Database > API (the Neo4j kernel, the remote implementation, and the upcoming HA > system), we might at some point in the future extract the API to a separate > component that we would call graphdb-api. The current neo component would > thus be divided into two, graphdb-api and kernel. The class EmbeddedNeo > would be part of the kernel component and would (even before the division > of > the components) be renamed to org.neo4j.kernel.api.EmbeddedGraphDatabase. > > In order to mitigate the transition to the new api we would provide a > transitional component, lets call it retro to have a name to refer to it > by. > This component would contain the org.neo4j.api.core package and an > implementation thereof as a facade for the new org.neo4j.graphdb.api > package > with the org.neo4j.kernel.api.EmbeddedGraphDatabase implementation. > > We have created a wiki page at > http://wiki.neo4j.org/content/Component_Naming where we outline the > strategy > behind the naming structure, and list the renaming actions that would take > place if we go through with this. > > Since this is a rather substantial change, we want to get your input first. > There are a few things we would like to know from you: > > 1. Will a restructuring like this cause problems for your projects? > 2. Do you think this change will result in a positive overall effect for > Neo4j? > 3. Do these positive effects outweigh any potential problems the change > causes? > > If this goes well we plan to make similar refactorings to the index-util > component shortly after. > > Cheers, > The Neo4j team through > -- > Tobias Ivarsson > Hacker, Neo Technology > www.neotechnology.com > Cellphone: +46 706 534857 > ___ > Neo mailing list > User@lists.neo4j.org > https://lists.neo4j.org/mailman/listinfo/user > > ___ > Neo mailing list > User@lists.neo4j.org > https://lists.neo4j.org/mailman/listinfo/user > ___ Neo mailing list User@lists.neo4j.org https://lists.neo4j.org/mailman/listinfo/user
Re: [Neo] RFC: Potentially breaking changes in the upcoming 1.0 release
It's a relatively minor thing to fix in our code. I would suggest reconsidering the "retro" façade, however - it really doesn't buy you much and requires resources to keep it up-to-date, fattens up the JAR a bit, and so on. If we're going to all move to the new version, it's best to use the new package and class names and not lean on a "crutch" of the retro package. -Original Message- From: user-boun...@lists.neo4j.org [mailto:user-boun...@lists.neo4j.org] On Behalf Of Tobias Ivarsson Sent: Wednesday, January 06, 2010 3:28 PM To: Neo user discussions Subject: [Neo] RFC: Potentially breaking changes in the upcoming 1.0 release Hi all! For our upcoming final 1.0 release we are thinking about restructuring the components and package names to make them at least closer to something we would want to live with for a considerable future. The main affected component at this point is the Neo4j kernel, even if other components would follow later on as well. What we would like to achieve with such a refactoring is a more consistent naming scheme, and a more descriptive naming scheme. This means that we would change the current core api (org.neo4j.api.core). Most of the interfaces would remain the same, but the package name would change to org.neo4j.graphdb.api. We would also change the name of the NeoService interface to the more descriptive name GraphDatabaseService. Since we have multiple components that implement the Neo4j Graph Database API (the Neo4j kernel, the remote implementation, and the upcoming HA system), we might at some point in the future extract the API to a separate component that we would call graphdb-api. The current neo component would thus be divided into two, graphdb-api and kernel. The class EmbeddedNeo would be part of the kernel component and would (even before the division of the components) be renamed to org.neo4j.kernel.api.EmbeddedGraphDatabase. In order to mitigate the transition to the new api we would provide a transitional component, lets call it retro to have a name to refer to it by. This component would contain the org.neo4j.api.core package and an implementation thereof as a facade for the new org.neo4j.graphdb.api package with the org.neo4j.kernel.api.EmbeddedGraphDatabase implementation. We have created a wiki page at http://wiki.neo4j.org/content/Component_Naming where we outline the strategy behind the naming structure, and list the renaming actions that would take place if we go through with this. Since this is a rather substantial change, we want to get your input first. There are a few things we would like to know from you: 1. Will a restructuring like this cause problems for your projects? 2. Do you think this change will result in a positive overall effect for Neo4j? 3. Do these positive effects outweigh any potential problems the change causes? If this goes well we plan to make similar refactorings to the index-util component shortly after. Cheers, The Neo4j team through -- Tobias Ivarsson Hacker, Neo Technology www.neotechnology.com Cellphone: +46 706 534857 ___ Neo mailing list User@lists.neo4j.org https://lists.neo4j.org/mailman/listinfo/user ___ Neo mailing list User@lists.neo4j.org https://lists.neo4j.org/mailman/listinfo/user
Re: [Neo] RFC: Potentially breaking changes in the upcoming 1.0 release
On Wed, Jan 6, 2010 at 21:48, Craig Taverner wrote: > 1. Will a restructuring like this cause problems for your projects? > Yes, but minor. Should be a simple search and replace to upgrade. And if you need backwards compatibility then you can just go through the 'retro' component. > > 2. Do you think this change will result in a positive overall effect for > Neo4j? > Perhaps. You're pushing for more use of the terms 'graph' and 'graph > database', and I can see the marketing value in that. That's not the biggest deal although I like that. The biggest deal is that it's a consistent naming scheme with -- hopefully -- proper api / impl separation. > > 3. Do these positive effects outweigh any potential problems the change > causes? > Hard to say. Can swing either way. > > Reading the wiki page, I noticed a question regarding the rdf package names, > and a suggestion to add .api and .impl packages. I can answer this with my > opinion, which I doubt you will agree with, but I'll add it here so at least > it is said. > > If you had the freedom to make the change, I think that the API packages > should have simple package names without the .api extension, and > implementations should live in the impl packages. I think this goes even for > the core api, which would be at org.neo4j.graphdb with the default > implementations at org.neo4j.graphdb.impl (alternatively > org.neo4j.graphdb.internal, since you explicitly state it is not of interest > to users). If you had such a scheme, the location of implementations is much > more flexible. You do not need to make the decision about the RDF package > names now, and when you do split them, they still conform to the global > naming strategy. I'd love to get some input from the OSGi experienced crowd on this. Cheers, -- Emil Eifrém, CEO [e...@neotechnology.com] Neo Technology, www.neotechnology.com Cell: +46 733 462 271 | US: 206 403 8808 http://blogs.neotechnology.com/emil http://twitter.com/emileifrem ___ Neo mailing list User@lists.neo4j.org https://lists.neo4j.org/mailman/listinfo/user
Re: [Neo] RFC: Potentially breaking changes in the upcoming 1.0 release
1. Will a restructuring like this cause problems for your projects? Yes, but minor. Should be a simple search and replace to upgrade. 2. Do you think this change will result in a positive overall effect for Neo4j? Perhaps. You're pushing for more use of the terms 'graph' and 'graph database', and I can see the marketing value in that. 3. Do these positive effects outweigh any potential problems the change causes? Hard to say. Can swing either way. Reading the wiki page, I noticed a question regarding the rdf package names, and a suggestion to add .api and .impl packages. I can answer this with my opinion, which I doubt you will agree with, but I'll add it here so at least it is said. If you had the freedom to make the change, I think that the API packages should have simple package names without the .api extension, and implementations should live in the impl packages. I think this goes even for the core api, which would be at org.neo4j.graphdb with the default implementations at org.neo4j.graphdb.impl (alternatively org.neo4j.graphdb.internal, since you explicitly state it is not of interest to users). If you had such a scheme, the location of implementations is much more flexible. You do not need to make the decision about the RDF package names now, and when you do split them, they still conform to the global naming strategy. That was my 2 cents. You are welcome to ignore it :-) On Wed, Jan 6, 2010 at 9:28 PM, Tobias Ivarsson < tobias.ivars...@neotechnology.com> wrote: > Hi all! > > For our upcoming final 1.0 release we are thinking about restructuring the > components and package names to make them at least closer to something we > would want to live with for a considerable future. The main affected > component at this point is the Neo4j kernel, even if other components would > follow later on as well. > > What we would like to achieve with such a refactoring is a more consistent > naming scheme, and a more descriptive naming scheme. This means that we > would change the current core api (org.neo4j.api.core). Most of the > interfaces would remain the same, but the package name would change to > org.neo4j.graphdb.api. We would also change the name of the NeoService > interface to the more descriptive name GraphDatabaseService. > > Since we have multiple components that implement the Neo4j Graph Database > API (the Neo4j kernel, the remote implementation, and the upcoming HA > system), we might at some point in the future extract the API to a separate > component that we would call graphdb-api. The current neo component would > thus be divided into two, graphdb-api and kernel. The class EmbeddedNeo > would be part of the kernel component and would (even before the division > of > the components) be renamed to org.neo4j.kernel.api.EmbeddedGraphDatabase. > > In order to mitigate the transition to the new api we would provide a > transitional component, lets call it retro to have a name to refer to it > by. > This component would contain the org.neo4j.api.core package and an > implementation thereof as a facade for the new org.neo4j.graphdb.api > package > with the org.neo4j.kernel.api.EmbeddedGraphDatabase implementation. > > We have created a wiki page at > http://wiki.neo4j.org/content/Component_Naming where we outline the > strategy > behind the naming structure, and list the renaming actions that would take > place if we go through with this. > > Since this is a rather substantial change, we want to get your input first. > There are a few things we would like to know from you: > > 1. Will a restructuring like this cause problems for your projects? > 2. Do you think this change will result in a positive overall effect for > Neo4j? > 3. Do these positive effects outweigh any potential problems the change > causes? > > If this goes well we plan to make similar refactorings to the index-util > component shortly after. > > Cheers, > The Neo4j team through > -- > Tobias Ivarsson > Hacker, Neo Technology > www.neotechnology.com > Cellphone: +46 706 534857 > ___ > Neo mailing list > User@lists.neo4j.org > https://lists.neo4j.org/mailman/listinfo/user > ___ Neo mailing list User@lists.neo4j.org https://lists.neo4j.org/mailman/listinfo/user
