Skip to content
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

Migrate to Jena 3.1.0 #1075

Closed
wants to merge 4 commits into from
Closed

Migrate to Jena 3.1.0 #1075

wants to merge 4 commits into from

Conversation

acoburn
Copy link
Contributor

@acoburn acoburn commented Jul 25, 2016

Resolves: https://jira.duraspace.org/browse/FCREPO-1672

This PR is divided into three commits as follows (mostly to make review easier):

  1. Change the package names to org.apache.jena and increment version in pom.xml
  2. Update implementation and test code to support the new version
  3. Rework the ldp testsuite (which depends on Jena 2.x) so that we can avoid dependency convergences.

@ajs6f
Copy link
Contributor

ajs6f commented Jul 25, 2016

Okay, obviously the vast majority of line changes are going to be com.hp.hpl => org.apache. Do you have any suggestions for substantive review? Are there places you remember making particular choices that should be reviewed? I don't think Jena's API actually changed all that much across the period in question, so nothing comes to my mind.

@acoburn
Copy link
Contributor Author

acoburn commented Jul 25, 2016

@ajs6f this is why I have three commits here. I'd look particularly at the second one f99a317 -- that's where all of the impl code changes are.

@acoburn
Copy link
Contributor Author

acoburn commented Jul 25, 2016

@ajs6f also, in the first commit, there is this change: 890c31f#diff-f8c7031221097a6120fd8c87ded12841L20

GraphStoreWrapper -> GraphStoreBasic (GraphStoreWrapper doesn't seem to exist any longer)

Otherwise, the first commit is just about renaming the packages.

@ajs6f
Copy link
Contributor

ajs6f commented Jul 25, 2016

GraphStore is now deprecated. I'm inclined to take this opportunity to replace it with either Dataset or DatasetGraph (preferably the former).

@ajs6f
Copy link
Contributor

ajs6f commented Jul 25, 2016

So after the third commit, the LDP suite runs against the actual fcrepo-webapp?

@@ -46,6 +46,8 @@

public static final String VERSIONABLE = "mix:versionable";

public static final String FIELD_DELIMITER = "\30^^\30";
Copy link
Contributor

@ajs6f ajs6f Jul 25, 2016

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Is this @cbeer 's unspeakable insignium?

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Yes.

@acoburn
Copy link
Contributor Author

acoburn commented Jul 25, 2016

@ajs6f yes, the LDP suite runs against fcrepo-webapp

@@ -246,7 +248,7 @@ public URI getContentDigest() {
public String getMimeType() {
try {
if (hasProperty(HAS_MIME_TYPE)) {
return getProperty(HAS_MIME_TYPE).getString();
return getProperty(HAS_MIME_TYPE).getString().replace(FIELD_DELIMITER + XSDstring.getURI(), "");
Copy link

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Instead of hardcoding the clean-up of the FIELD_DELIMITER suffixes throughout the codebase, it seems cleaner to simply create a small utility in https://github.com/fcrepo4-exts/fcrepo4-upgrade-utils to be executed as part of the 4.6.0 to 4.7.0 upgrade process.

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

So you are suggesting removing that construct altogether? What would you propose to replace that with?

To me, that seems like a separate issue.

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

@awoods to be clear, with RDF 1.1, all Literals have a datatype, so the string literals that previously had no datatype now will have a datatype, meaning that when they are persisted to Modeshape, they will always have the FIELD_DELIMITER + xsd:string suffix. Any pre Jena 3.x data will not have that suffix. For RDF output, that's not a problem, but for certain methods (such as getMimeType) you clearly don't want that value (in fact, Jersey will blow up if the mimetype contains that suffix). An alternative would be to use the ValueConverter class here, which is probably a good idea. But again, I think that refactoring goes beyond the simple migration to Jena 3.x of this PR.

Copy link

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I appreciate the explanation, @acoburn. It first pass, it looked like you were just cleaning out the FIELD_DELIMITER cruft from the past.
I would like to give this PR a closer look, but have limited time today. If someone in addition to @ajs6f gives it the thumbs-up, feel free to move it forward. Otherwise, I will aim to give it a closer look tonight.

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

@awoods I would like to address @ajs6f's comment about the use of GraphStore before this is merged. That will likely happen today.

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Thank you for doing that, @acoburn . That GraphStore thing has been bugging me forever.

@acoburn
Copy link
Contributor Author

acoburn commented Jul 27, 2016

@ajs6f: I added another commit (e9292b0) replacing GraphStore with Dataset/DatasetGraph. I also replaced the (deprecated) use of createAnon with createBlankNode. I reordered the commits so that the LDP integration suite changes are still the final commit.

@ajs6f
Copy link
Contributor

ajs6f commented Jul 27, 2016

Looks good to me.

@acoburn
Copy link
Contributor Author

acoburn commented Jul 27, 2016

@awoods ok, this PR is in your court now. I suspect that it will require additional PRs for the various downstream applications

@@ -752,6 +755,8 @@ public void testReplacePropertiesHashURIs() throws RepositoryException {
final Model updatedModel3 = object.getTriples(subjects, PROPERTIES).collect(toModel());

updatedModel3.remove(subject, dcCreator, hashResource);
updatedModel3.removeAll(hashResource, (Property)null, (RDFNode)null);
Copy link

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This line seemed peculiar, so I tested with it commented out.. with all tests passing.
It appears that the update in this line can be removed/reverted.

Copy link

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I am happy to remove it as a part of this PR, unless there is some reason for this update that I am missing.

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Yes, go ahead and remove it

@awoods
Copy link

awoods commented Aug 25, 2016

Resolved with:
46497f5
a9dd847
336424a
4bfdd25

@awoods awoods closed this Aug 25, 2016
@acoburn acoburn deleted the fcrepo-1672 branch August 25, 2016 14:54
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

None yet

3 participants