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
Migrate to Jena 3.1.0 #1075
Conversation
Okay, obviously the vast majority of line changes are going to be |
@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. |
|
So after the third commit, the LDP suite runs against the actual |
@@ -46,6 +46,8 @@ | |||
|
|||
public static final String VERSIONABLE = "mix:versionable"; | |||
|
|||
public static final String FIELD_DELIMITER = "\30^^\30"; |
There was a problem hiding this comment.
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?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Yes.
@ajs6f yes, the LDP suite runs against |
@@ -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(), ""); |
There was a problem hiding this comment.
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.
There was a problem hiding this comment.
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.
There was a problem hiding this comment.
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.
There was a problem hiding this comment.
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.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
There was a problem hiding this comment.
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.
* GraphStore to Dataset * createAnon to createBlankNode
Looks good to me. |
@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); |
There was a problem hiding this comment.
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.
There was a problem hiding this comment.
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.
There was a problem hiding this comment.
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
Resolves: https://jira.duraspace.org/browse/FCREPO-1672
This PR is divided into three commits as follows (mostly to make review easier):
org.apache.jena
and increment version in pom.xml