apache
Osgify
The goal of this request is to start bundleizing tinkerpop. In this request, I have bundleized the following modules :
- gremlin-core
- gremlin-groovy
- tinkerpop-gremlin They are enough to start playing with TinkerPop in an OSGI environment.
To be the less intrusive as possible, I had to create a new module called gremlin-osgi-deps which aggregate and export packages from tinkerpop dependencies which are not bundles for the moment. As a result, the only impact my request has, is to add entries in the MANIFESTs to make those modules valid bundles.
To illustrate the usage of those bundles, I'm developping a Wisdom-Framework extension (https://github.com/gdelafosse/wisdom-tinkerpop).
I, personally, do not want OSGi support in TinkerPop. Over the years, we never have anyone that maintains such pushes, no one understands its use, there are no test cases, ... Is it possible for this to be maintained by a separate community project (e.g. tinkerpop-osgi-deps) and NOT part of Apache TinkerPop?
I understand.
I propose I remove tinkerpop-osgi-deps from your repository, and I create one repository into my group for it. My plan is to contribute and make those non-bundled dependencies valid OSGI bundles, so that we no longer need tinkerpop-osgi-deps.
But, what about the "bundle" packaging required to make tinkerpop jars OSGI bundles? Do you accept to keep them? If you are afraid with maintaining the maven-bundle-plugin configuration, I propose I check it regularly. I need them for my applications that use wisdom-framework and TinkerPop, so I'll be vigilant...
I removed gremlin-osgi-deps from the pull request and created this project in my repositories : https://github.com/gdelafosse/gremlin-osgi-deps.
Would you accept to package your projects as bundles?
I don't know much about OSGi to properly review/vote on this, so at the moment, I'm +0.
I think I find this situation similar to trying to accept a PR where you don't have a clue as to what the code in the PR is doing (you can't say if it's "right" or "wrong"). I also know from dealing with past pull requests on OSGi (various TinkerPop 2.x projects and Titan) that just altering the pom.xml is only the start of OSGi support - it's never been clear to me what else would need to be done for "full" support, how we would maintain that, how we would keep from breaking that, how it would affect the project as a whole, how it would change design decisions, etc. Answers in this area have been somewhat vague and full of variety going from person to person.
btw, i've known "bundles" to behave weirdly with Grape sometimes (grape not finding dependencies). it would be very bad for the plugin system if introducing a "bundle" packaging type messed up things up there. i think that would have to be tested very carefully if we made this change.
Can other committers who are newer to the TinkerPop game comment on this issue? @pluradj or @twilmes ? do you folks have any experience here?
The maven-bundle-plugin just modifies the MANIFEST file with its own entries. I don't think it impacts any other frameworks or tools.
I worked briefly with OSGi several years ago, but I don't remember too much about it.
The code changes remaining in this PR seem minimal, but like the others have mentioned, there aren't any documentation or tests. If all that this PR does is modify the manifest file, maybe all we need is some committer documentation to verify what to look for and what needs to be updated if packages/dependencies change?
IMO Grapes behaves weirdly in general so if OSGi makes Grapes unstable, that would not be a good story.
IMO Grapes behaves weirdly in general so if OSGi makes Grapes unstable, that would not be a good story.
haha and agreed
Hi all, concerning Grapes, it doesn't seem to use the jar MANIFEST file, so I don't think it will be disturbed by my change.
Concenring the TinkerPop dependencies, I've created a pull request for each of them to turn them into OSGI bundle, so that gremlin-osgi-deps won't be required anymore. See https://github.com/svenkubiak/jBCrypt/pull/4 https://github.com/jcabi/jcabi-log/pull/69 https://github.com/jcabi/jcabi-aspects/pull/201 https://github.com/jcabi/jcabi-manifests/pull/29 https://github.com/carrotsearch/hppc/pull/5 https://github.com/javatuples/javatuples/pull/4
Concerning testing, I'm implementing an it test for each impacted sub module to check that they are valid bundles installable into an OSGI container thanks to PaxExam. I will join those tests to this pull request soon.
Concerning the documentation, where can I document how to install TinkerPop into an OSGI container?
In terms of documentation, perhaps in the "Gremlin Applications" section at the end with a new subsection would be best:
http://tinkerpop.apache.org/docs/3.1.0-incubating/#gremlin-applications
Or is this more of an "Implementations" thing? Again, I'm don't understand OSGi so I don't really what this provides, so its more up to you to decide where in the docs this should go. ??
So before we review this again for PR merge, we are waiting for the aforementioned projects to turn their respective projects in to OSGi bundles?
The reason why I want to osgify your projects is because I'm building graph applications with the wisdom-framework/wisdom which is a web-stack based on OSGI. Anyway, it could be interesting for anybody that wants to integrate TinkerPop artifacts into their OSGI container. You can consider OSGI as a Java application container, where application can be installed and removed dynamically (without restarting the JVM).
So to my mind it's more an "implementation" thing.
Concerning the dependencies, my pull requests are being accepted, but some projects are less reactive than other. So, waiting for all to be accepted, released and published into maven central, I will still maintain gdelafosse/gremlin-osgi-deps. In my documentation I'll explain how to install TinkerPop and the required dependencies into an OSGI container.
To conclude, I think you can review the PR as soon as I implemented the tests.
Concerning testing, I'm implementing an it test for each impacted sub module to check that they are valid bundles installable into an OSGI container thanks to PaxExam. I will join those tests to this pull request soon.
That's interesting - you would be the first person to ever offer to supply tests for OSGi.
Another addition to this PR that I think is important would be some documentation for TinkerPop Committers that serves as some reminder as to how to "maintain" these configuration and their meaning. To me this is more internal developer docs - something that would go in this section somewhere:
https://github.com/apache/incubator-tinkerpop/blob/ef40dce314c1f9ee48661227d992beef8cad64d0/docs/src/dev/developer/contributing.asciidoc#for-committers
From my limited understanding of OSGi, I would say user docs should be updated as part of "Gremlin Applications" section of the user docs. I guess there would be a new sub-section there of some sort.
You should enjoy this update :
- I simplify the gremlin-shaded pom thanks to the solution explained here The idea is to call sequentially the maven-shade-plugin to shade the dependencies, the maven-jar-plugin to unpack the shaded jar, and eventually the maven-bundle-plugin to compute the OSGI MANIFEST entries and repack the jar.
- I implemented an integration test to test that germlin-core is a valid OSGI bundle. Unfortunately I don't manage to implement the same test for tinkerpop-gremlin because when I add my test dependencies it breaks the existing test (hamcrest Matchers classes are not found). I don't understand for the moment how the tinkerpop-gremlin tests work...
Hi, I just have a rapid question. it's this pull request going to be merged at some point? I'm just checking because I already use tinkerpop version 2.6 inside an OSGi application and I would like to upgrade and use latest version
