Re: [Neo] RFC: Potentially breaking changes in the upcoming 1.0 release

2010-01-08 Thread Tobias Ivarsson
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

2010-01-08 Thread Laurent Laborde
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

2010-01-08 Thread Johan Svensson
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

2010-01-06 Thread Peter Neubauer
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

2010-01-06 Thread Andreas Kollegger
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

2010-01-06 Thread Andreas Kollegger
+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

2010-01-06 Thread Tobias Ivarsson
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-01-06 Thread Mattias Persson
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

2010-01-06 Thread Peter Neubauer
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

2010-01-06 Thread Dan Heaver
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

2010-01-06 Thread Craig Taverner
+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

2010-01-06 Thread 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.



-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

2010-01-06 Thread Emil Eifrem
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

2010-01-06 Thread Craig Taverner
 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