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

Change method scope to support extending module classes #465

Closed

Conversation

karenhanson
Copy link
Contributor

Portico is working to upgrade to 1.23 - we currently use a modified older version of JHOVE. There are several method/property scope changes would that allow us to continue to use some local module extensions without having to maintain a customized version of JHOVE. If they are benign (or even useful) for other users, it would be great if we could merge these.

Question for reviewer(s): one of the changes is in the xml-hul module. Should I increment the version? and if so to a SNAPSHOT version?

Thanks!

@codecov
Copy link

codecov bot commented Jul 17, 2019

Codecov Report

Merging #465 into integration will not change coverage.
The diff coverage is n/a.

Impacted file tree graph

@@              Coverage Diff               @@
##             integration     #465   +/-   ##
==============================================
  Coverage          49.36%   49.36%           
  Complexity           969      969           
==============================================
  Files                 55       55           
  Lines               7666     7666           
  Branches            1392     1392           
==============================================
  Hits                3784     3784           
  Misses              3422     3422           
  Partials             460      460
Impacted Files Coverage Δ Complexity Δ
...in/java/edu/harvard/hul/ois/jhove/HandlerBase.java 67.35% <ø> (ø) 46 <0> (ø) ⬇️
.../edu/harvard/hul/ois/jhove/handler/XmlHandler.java 62.93% <ø> (ø) 270 <0> (ø) ⬇️
...ain/java/edu/harvard/hul/ois/jhove/ModuleBase.java 50.69% <ø> (ø) 70 <0> (ø) ⬇️

Continue to review full report at Codecov.

Legend - Click here to learn more
Δ = absolute <relative> (impact), ø = not affected, ? = missing data
Powered by Codecov. Last update dd25d0f...bd2d38d. Read the comment docs.

@carlwilson carlwilson added this to the v1.24-m4 Release milestone Oct 18, 2019
@carlwilson carlwilson added feature New functionality to be developed P2 Medium priority issues to be scheduled in a future release labels Oct 18, 2019
Copy link
Contributor

@tledoux tledoux left a comment

Choose a reason for hiding this comment

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

My feeling is that the 4 methods (encodeContent, encodeValue, isPropertyEmpty, cleanURIString) are really utility functions. It would be easier for maintenance to put them all in a Utility class, so we know others may use them and we don't mess with them.

*/
private boolean isPropertyEmpty (Property property, PropertyArity arity) {
public boolean isPropertyEmpty (Property property, PropertyArity arity) {
Copy link
Contributor

Choose a reason for hiding this comment

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

Shouldn't this method be static also ?

* @param uri
* @return
*/
public String cleanURIString (String uri) {
Copy link
Contributor

Choose a reason for hiding this comment

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

Shouldn't this method be static ?

@carlwilson
Copy link
Member

I'd not thought that clearly about it before @tledoux but I think you're right. Will pr a refactor.

@carlwilson
Copy link
Member

Included in #538

@carlwilson carlwilson closed this Dec 10, 2019
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
feature New functionality to be developed P2 Medium priority issues to be scheduled in a future release
Projects
None yet
Development

Successfully merging this pull request may close these issues.

None yet

3 participants