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
[DS-1443] Export structure with structure-builder #1257
Conversation
this would be very practical |
I tested this PR and it works. Just some minor notes here:
|
All of these points are good ones. I'm addressing each. I took the cheap way out on (3) and just issue a warning when 'identifier' attributes are present. I wonder why we have two different root element names at all. |
Rebased on current master. |
Rebased again on current master. |
…ommand function a separate method for clarity.
…able; warn when importing containers with 'identifier' attributes
Rebased again on current master. |
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.
👍 Code looks good, but I haven't had a chance to test it. This seems like a logical feature to add in though, as we already have a corresponding import.
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.
By code inspection it looks good +1
I have made only a small suggestion/comment inline in the code to be (eventually) addressed.
It will be nice to provide IT for this feature, import a structure and check that the output match with the import file will be great
@@ -142,13 +171,52 @@ public static void main(String[] argv) | |||
// set the context | |||
context.setCurrentUser(ePersonService.findByEmail(context, eperson)); | |||
|
|||
// Export? Import? | |||
if (line.hasOption('x')) { | |||
exportStructure(context, output); |
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.
as you don't have a logged-in user I guess that you can hit auth issue with communities or collections without Anonymous READ
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.
The user is logged in by line 172. But it is possible that 'String eperson' contains a name that matches no EPerson, and in that case the context will be logged out. We could find the EPerson during command analysis, and exit with an error if -e was given but its value is not a known account. Probably that should be a separate issue. The code doesn't do anything wrong, but the resulting error message is less helpful than it might be. We ought to check for this problem throughout the CLI.
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.
Oh, I see: you perhaps mean that export should require -e as import does. That also can be pushed up to command analysis, so that execution can assume that it has a valid identity to set into the Context.
However, it is still possible to give an identity which is not authorized to access some of the repository structure.
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.
Looks fine by code review. Will give it a test run asap.
I think this can be merged as it is. I would like to see one further improvement, which could be done in a separate pull request. We can create Communities with new identifiers by using |
BufferedWriter out = new BufferedWriter(new FileWriter(output)); | ||
out.write(new XMLOutputter().outputString(xmlOutput)); | ||
out.close(); | ||
new XMLOutputter().output(xmlOutput, output); |
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.
In the export method we use Format.getPrettyFormat()
to indent the XML. Why don't we use this for the xml output of the import method?
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.
That sounds like a good idea, but it seems out-of-scope for the present patch and issue which are focused on the new export feature. I think that a new issue and a small patch would be welcome.
@mwoodiupui : Just to clarify, are you working on Integration tests for this feature? I recall you asking about how to do so on Slack. If you are working on ITs, then I'd suggest we wait to merge for ITs, and then merge immediately after ITs are added. |
@mwoodiupui I just send you a PR realizing my idea to import Communities and Collections reusing their old handles if the import file contains those: mwoodiupui#13. Can we include it in this PR or shall I create a separate ticket and PR? |
While extending the Code, I tested it. It works great. :-) |
@tdonohue I am working (slowly) on ITs for the feature. |
@mwoodiupui Could you please take a look on my additions (mwoodiupui#13)? Would you like to integrate them here or shall I create a separate PR? |
This PR was built before DSpace 7 became master, and is rather out-of-sync with the current master. I'm closing it and will submit a new one, rebuilt for v7. |
@pnbecker I think that your patch really should be a separate Jira issue. |
https://jira.duraspace.org/browse/DS-1443
Export the current Community/Collection structure in a form suitable for re-importation with the command-line structure-builder.