DOI determining now uses "DOI.findInText" (and not "DOI.parse")

[koppor]

This addresses #8127 by using the findInText functionality of the DOI parsing functionaltiy. Thereby, my copy&paste issue is gone.

• Change in CHANGELOG.md described in a way that is understandable for the average user (if applicable)
• Tests created for changes (if applicable)
• Manually tested changed features in running JabRef (always required)
• Screenshots added in PR description (for UI changes)
• Checked documentation: Is the information available and up to date? If not, I created an issue at https://github.com/JabRef/user-documentation/issues or, even better, I submitted a pull request to the documentation repository.

[koppor]

Waiting for @jiezheng5 to include their test cases from #8215 to here. findInText should be used instead of parse

[mrcstan]

@koppor, @Siedlerchr, I found a case where this method failed in Line 120 in DOITest.java. For the DOI, https : / / doi.org / 10 / gf4gqc , what I got with @koppor's proposed change is the following:

1. After copy and pasting the DOI,
   

2. After pressing enter,
   

In contrast, the proposed change in the PR #8228 did not have the issue

[jiezheng5]

Waiting for @jiezheng5 to include their test cases from #8215 to here. findInText should be used instead of parse

I would like to add the Parameterized Test Cases here. However, since that this PR(#8127) is not merged nor sent by me, I don't know how I can modify it locally.
I tried

thanks very much for your time.

[Siedlerchr]

@jiezheng5 If jabRef/jabref is configured as upstream then: (git remote -v)

git fetch upstream --prune
git checkout fix-8127

[tobiasdiez]

Semantically, you would want to parse the identifier here and not find it in some bigger text. Thus, if you think "findInText" is better, then please change the implementation of "parse". This makes it also more coherent with the other id fetchers below that use "parse" as well (and the idea was to extract this to a common interface at some point).

[mrcstan]

I am working on the parser in the PR #8228

[mrcstan]

I use single regexp to parse the DOI in and added several test cases in DOITest PR #8228. Also address the request by @koppor for informing the user that "no DOI data exists" rather than "invalid DOI" when the fetcher fails to download from a valid DOI (#8217).

[tobiasdiez]

I prefer the approach by @mrcstan in #8228.

[ThiloteE]

@mrcstan

I use single regexp to parse the DOI in and added several test cases in DOITest PR #8228. Also address the request by @koppor for informing the user that "no DOI data exists" rather than "invalid DOI" when the fetcher fails to download from a valid DOI (#8217).

i think you meant to reference #8127, not 8217. I just got confused when i followed the link in 8217 to this thread. This one here deals with an entirely different topic.

[jiezheng5]

@jiezheng5 If jabRef/jabref is configured as upstream then: (git remote -v)

git fetch upstream --prune
git checkout fix-8127

Thanks very much for the response. I encountered the following error following the instructions.

sincerely,

[koppor]

Fully agree with @tobiasdiez - following up at #8228.

[koppor]

@jiezheng5 Regarding your git issue, it seems that your configuration of upstream is wrong:

You should execute

git remote set-url upstream https://github.com/jabref/jabref.git

However, check before

git remote -v

to check which repositories you have configured

[jiezheng5]

@jiezheng5 Regarding your git issue, it seems that your configuration of upstream is wrong:

You should execute

git remote set-url upstream https://github.com/jabref/jabref.git

However, check before

git remote -v

to check which repositories you have configured

thanks very much, it worked now.