2009/9/22 Mattias Persson <matt...@neotechnology.com>:
> 2009/9/22 Peter Neubauer <neubauer.pe...@gmail.com>:
>> Hi there,
>>
>> On Tue, Sep 22, 2009 at 9:44 AM, Mattias Persson
>> <matt...@neotechnology.com> wrote:
>>> 2009/9/22 Andreas Kollegger <akolleg...@tembopublic.org>:
>>>> <Export-Package>!${bundle.namespace}.internal.*,$
>>>> {bundle.namespace}.*;version="${pom.version}"</Export-Package>
>>>>
>>>> Which for neo-utils means any available class in the org.neo4j.util.*
>>>> packages
>>>> except for org.neo4j.util.internal classes will be included in the jar.
>>>>
>>>> So, we need a local osgi.bnd file to specifically exclude the non neo-
>>>> utils
>>>> package namespaces. This should do it:
>>>>
>>>> Export-Package: !org.neo4j.util.internal.*,!org.neo4j.util.index,!
>>>> org.neo4j.util.map,!org.neo4j.util.timeline,!org.neo4j.util.btree,!
>>>> org.neo4j.util.sortedtree,org.neo4j.util.*;version="${pom.version}"
>>>
>>> This sounds like a good and subtle fix to me!
>> Yeah, this sounds good, although I agree with Andreas in that we
>> should have better naming conventions in the utils and index-utils
>> components so they don't overlap in the hierarchical structure in the
>> long run. Will do that tonight.
> Great, I agree with having better package names/hierarchy, which may
> be the best solution of them all.
Maybe just adding a sub-package for the classes in neo-utils, like
org.neo4j.util.xxx, where xxx could be "common", "asorted", "extras"
or something like that.
>>
>>>
>>>>
>>>> I'm sorry. I remember coming across this early on, and was sure that I'd
>>>> taken care of it when committing the bundle stuff. This is my fault.
>>>>
>>>> As for things like JTA: I don't think we should embed that in core
>>>> unless we also produce a version without it embedded. We should be
>>>> able to do that with an assembly. My own project is atypical, I know,
>>>> but I actually deploy multiple persistence technologies (jpa, db4o,
>>>> neo4j), in a best tool for the job approach. Having multiple JTAs
>>>> in different bundles would be awkward to overcome.
>>>>
>> Yes, then the current bundling is wrong and we need to import the JTA
>> packages instead of embedding the jta.jar into the bundle. will change
>> that too.
>>
>>>> Alternatively, we could start a neo-commons (or neo-deps?) multi-module
>>>> project with modules that wrap any required third party stuff to keep
>>>> it all in the family, while maintaining maximum flexibility when
>>>> provisioning a runtime.
>>>
>>> I believe that's something like what the APOC bundle is, right?
>>>>
>> Yes and no. We could as part of the APOC bundle provide a wrapped JTA
>> library bundle (if there is none already out there), but that would be
>> purely used in the OSGi scenarios, not otherwise, so I am not sure it
>> should be in there, maybe it's best to have it in the examples
>> instead, as part of the runtime provisioning setup?
>>
>> /peter
>> _______________________________________________
>> Neo mailing list
>> User@lists.neo4j.org
>> https://lists.neo4j.org/mailman/listinfo/user
>>
>
>
>
> --
> Mattias Persson, [matt...@neotechnology.com]
> Neo Technology, www.neotechnology.com
>-- Mattias Persson, [matt...@neotechnology.com] Neo Technology, www.neotechnology.com _______________________________________________ Neo mailing list User@lists.neo4j.org https://lists.neo4j.org/mailman/listinfo/user
