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 <akolleg...@tembopublic.org> 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 <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 > _______________________________________________ Neo mailing list User@lists.neo4j.org https://lists.neo4j.org/mailman/listinfo/user
