Skip to content
This repository has been archived by the owner on Jun 30, 2022. It is now read-only.

2.x #91

Closed
wants to merge 3 commits into from
Closed

2.x #91

wants to merge 3 commits into from

Conversation

M3ssman
Copy link

@M3ssman M3ssman commented Oct 25, 2019

  • fix changeMetadata
  • ignore local bin-Folder

@@ -1,2 +1,3 @@
/build
/dist
/bin
Copy link
Collaborator

Choose a reason for hiding this comment

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

Ant and ant tools are not creating directory called bin. Maybe your build environment must be adjusted or add /bin to your global git ignore list. IMHO: There is no need to add more directories to the ignore list

Copy link
Author

Choose a reason for hiding this comment

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

Well, you're right, it has nothing to do with Ant. Eclipse IDE did this, according to the Eclipse-configuration that is already included in the Repository Branch 2.x at ugh/.project

@@ -1742,8 +1742,8 @@ public boolean changeMetadata(Metadata theOldMd, Metadata theNewMd) {
oldName = oldMdt.getName();
newName = newMdt.getName();

if (oldName.equals(newName)) {
// Different metadata types.
if (! oldName.equals(newName)) {
Copy link
Collaborator

Choose a reason for hiding this comment

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

What are you try to fix? If the meta data are the same (according to the name of the meta data) there is no change needed. Ignoring comments is sometimes a good choice as they are in most cases not updated if the code is changed.

Copy link
Author

Choose a reason for hiding this comment

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

Use Case: Exchange metadata values, i.e. put a different value for Metadatatype "4000 (Hauptitel)" (PICA-Data).

The Variables state, IMHO, that if the names of the Metadatatypes (not the values) are equal, there is nothing to exchange. The Method returns immediately, therefore it is not possible Update the Value.

Copy link
Collaborator

Choose a reason for hiding this comment

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

This change seems right to me. Also, considering the method description in Javadoc above: The method must be used to swap the same type of metadata, so returning in case of the same type has been a mistake.

Copy link
Collaborator

Choose a reason for hiding this comment

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

In which context are you using this method? So far as I could discover this method is not used direct or indirect by Kitodo.Production so I assume that you write your own application which is using Kitodo.UGH?

Copy link
Author

Choose a reason for hiding this comment

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

@henning-gerhardt
No, you can't yet, you're right.

It is an enhancement to existing Metadaten-Backing-Bean in Kitodo.Production 2.x to handle possible Updates of Metadata and alike. It's required by our staff when they need to do metadata corrections afterwards, i.e. at structure or segmentation stages.

I'm not sure if this is of interest to the community, since it was obviously not used in other scopes until now and it is only for users that spent a lot of resources for very precise structures. Furthermore, the old Metadaten-class is already some complex piece of code, but it's got even more complicated by now.

Meanwhile, it is possible to achieve this if you iterate all Metadata of a given DocStruct, pic the one to replace (in case there is only one, of course), remove it and finally add the updated one.

Copy link
Collaborator

Choose a reason for hiding this comment

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

Do not understand me wrong. I would to see an update feature in Kitodo.Production for existing meta and structure data as this can solve a lot of issues of the daily work. But I think on the other side that this kind of improvement should be done in Kitodo.Production 3.x as this version has the current and future focus in development. I don't think that Kitodo.Production 2.x receive a lot of updates so additional work should be decided by how important is this feature and can it be done in 3.x on an easier way or can it be re-implemented in 3.x in a same or cleaner way.

Copy link
Author

Choose a reason for hiding this comment

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

@henning-gerhardt
I totally agree, Version 3 has to have focus. Personally, I do not like to resurrect legacy ghosts of version 2. I'm in to provide a proper platform for our library staff, based on what already has been done.

To provide some explanations: Back in time, when ULB Sachsen-Anhalt decided to move to Kitodo.Production, there was no Version 3. Therefore, many parts of the digitalization-workflow-in-spe came to life since 2017 are centered around Version 2.x. For the next 1-2 years I have to support this old stuff. There's no green field left on our side.

Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

4 participants