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 <e...@neotechnology.com> wrote: >> On Wed, Jan 6, 2010 at 21:48, Craig Taverner <cr...@amanzi.com> 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
