New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Updates for migrating from standalone Fuseki to fuseki.war. Address F… #50
Conversation
I have nothing against this PR, but Fuseki 1 is getting a bit longer in the tooth and Fuseki 2 is clearly where the Jena folks are putting more attention. See here for an example of how to use Fuseki 2 to support integration tests with the Maven plugin for Cargo. |
@ajs6f this is for moving to Fuseki 2 in fcrepo-exts/fcrepo-vagrant#18. That said, are you saying that we should update the integration tests to account for that? I think that is what you're saying, but I just want to make sure 😄 |
I don't care at all about |
Because |
The current integration test uses fuseki 1.1.1, and I am also in favor of moving that to 2.x, but this PR is completely unrelated to that. That is, this PR is about updating the default properties so that they assume a war-deployed fuseki rather than a standalone fuseki. |
Shall I create a JIRA ticket? |
@ruebot that would be great, thanks |
If they are assuming a war-deployed Fuseki, why is there any use of |
Also, whoever wrote those integration tests, they were extremely helpful for getting this updated. So, thank you very much 😄 |
@ajs6f the EmbeddedFusekiServer class is for doing integration tests. The vagrant project is for actually running the fuseki server. |
Urg, that's my point. If this PR is about relying on a deployed WAR, then using |
@ajs6f The point of the integration test in question is to test how the camel route interacts with an HTTP endpoint backed by some triplestore. In this case it happens to be fuseki. My point is that it shouldn't matter what version or what deployment strategy is used for that HTTP endpoint: the endpoint should be the same. The camel route is completely indifferent about what triplestore is used and what deployment strategy is used for that triplestore. |
Sure. This isn't about the validity of the test. It's about the dependency footprint (which is always an issue) and whether the tests are useful in explaining to people how to set up their own integrations, which is one of the purposes of writing integration tests. As long as it gets fixed, I don't really care where it gets fixed, in this PR or another, but using |
Let me know if this captures what y'all are looking for. |
@ajs6f That's a fair point, and I agree about updating fuseki. Do you have a preference between |
I'm inclined towards Cargo because it generalizes (e.g. you can quickly install profiles to test in other containers, which is a really good habit that we rarely evidence). |
It sounds like we have landed on moving towards a cargo-based, war deployment of Fuseki2 for the integration tests in this project... per the ticket created by @ruebot: Otherwise, this current PR looks good. Are there objections to moving the PR into master? ...pending more testing. |
I'm 👍 on merging this PR with master, provided it works well with the vagrant setup |
From the JIRA ticket: Updated fcrepo-camel-toolbox, built, and deployed artifact on vagrant VM. I added a new object and was successful.
|
Updates for migrating from standalone Fuseki to fuseki.war. Address F…
…CREPO-1467.
https://jira.duraspace.org/browse/FCREPO-1467