Skip to content

Conversation

Code42Cate
Copy link
Contributor

No description provided.

@Code42Cate Code42Cate requested a review from Pfeil December 13, 2022 14:40
@coveralls

This comment was marked as outdated.

@Pfeil
Copy link
Member

Pfeil commented Dec 13, 2022

This is a workaround around issue #56 for the usage with a service offering ro-crate-java as a REST API.

@ThomasJejkal ThomasJejkal changed the base branch from main to development January 11, 2024 08:47
@Pfeil Pfeil changed the base branch from development to main September 12, 2024 13:23
@Pfeil
Copy link
Member

Pfeil commented Sep 12, 2024

TODO (copied from #56 and extended)

  • should be unpacked in subfolder so different imported crates do not interfere
    • Subfolders (e.g. .tmp-ro-crate-java-extracted_cratefile.zip) beside the zip files would be easy to associate etc, but we would mess around in possibly synchronized or otherwise managed directories.
    • The current state uses the folder of where ro-crate-java is running from and stores it in ./temp/$UUID and works. This basically fulfills this task.
    • Suggestion: Use ./.tmp/ro-crate-java/zip-extraction/$UUID-filename.zip or something similar? Optional, take a parameter for the strategy to set up another directory.
  • the content should be removed at some point, currently it is "on JVM exit". This is not really a nice solution, because the library may be included into a server application which may run for longer terms.
    • The question is who is responsible for deletion.
    • The folder needs to live as long as any crate instance which is created by it.
    • The readers will usually live shorter, so they can not manage the folder.
    • The crate may be cloned (creating a builder, then create a new crate, or any other java magic), so it also cannot do it.
    • Suggestion: we manage it by restarts, but the user may choose to manage this situation manually be retrieving information about the location.
    • In the future, we could provide a helper class to make this easier somehow. But I do not see how we can make this being fully managed automatically in the background.

@coveralls
Copy link

coveralls commented Sep 12, 2024

Pull Request Test Coverage Report for Build #258

Details

  • 24 of 25 (96.0%) changed or added relevant lines in 1 file are covered.
  • 1 unchanged line in 1 file lost coverage.
  • Overall coverage increased (+0.001%) to 90.688%

Changes Missing Coverage Covered Lines Changed/Added Lines %
src/main/java/edu/kit/datamanager/ro_crate/reader/ZipReader.java 24 25 96.0%
Files with Coverage Reduction New Missed Lines %
src/main/java/edu/kit/datamanager/ro_crate/reader/ZipReader.java 1 80.56%
Totals Coverage Status
Change from base Build #253: 0.001%
Covered Lines: 1607
Relevant Lines: 1772

💛 - Coveralls

@Pfeil Pfeil changed the title unpack crates into temp/:uuid Unpack zipped crates into unique temporary folder Sep 13, 2024
@Pfeil Pfeil marked this pull request as ready for review September 13, 2024 13:27
Copy link
Member

@Pfeil Pfeil left a comment

Choose a reason for hiding this comment

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

I kept the idea but added some customization possibility and changed the path. Thanks, @Code42Cate !

@Pfeil Pfeil merged commit 1e48267 into main Sep 13, 2024
9 checks passed
@Pfeil Pfeil deleted the unpack-uuid branch September 13, 2024 13:33
@Pfeil Pfeil linked an issue Sep 13, 2024 that may be closed by this pull request
2 tasks
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.

ZipReader unpacks in ./temp

3 participants