J
J
JabRef Development Documentation
Search…
J
J
JabRef Development Documentation
main
Overview on Developing
Contributing
Architectural Decisions
Getting into the code
Advanced reading
Code Quality
Recommendations for UI design
Custom SVG icons
Working on fetchers
Creating a binary and debug it
JabRef and Software Engineering Training
Readings on Coding
Powered By GitBook
Working on fetchers
Fetchers are the implementation of the search using online services. Some fetchers require API keys to get them working. To get the fetchers running in a JabRef development setup, the keys need to be placed in the respective environment variable. The following table lists the respective fetchers, where to get the key from and the environment variable where the key has to be placed.
Service
Key Source
Environment Variable
Rate Limit
IEEEAPIKey
200 calls/day
(none)
(none)
Depending on the current network
​ADS UI​
AstrophysicsDataSystemAPIKey
5000 calls/day
​
ScienceDirectApiKey
​
SpringerNatureAPIKey
5000 calls/day
(none)
(none)
Depending on the current network
"Depending on the current network" means that it depends on whether your request is routed through a network having paid access. For instance, some universities have subscriptions to MathSciNet.
On Windows, you have to log off and log on to let IntelliJ know about the environment variable change. Execute the gradle task processResources in the group "others" within IntelliJ to ensure the values have been correctly written. Now, the fetcher tests should run without issues.
JabRef supports different kinds of fetchers:
  • EntryBasedFetcher: Completes an existing bibliographic entry with information retrieved by the fetcher
  • FulltextFetcher: Searches for a PDF for an exiting bibliography entry
  • SearchBasedFetcher: Searches providers using a given query and returns a set of (new) bibliography entry. The user-facing side is implemented in the UI described at https://docs.jabref.org/collect/import-using-online-bibliographic-database.
There are more fetchers supported by JabRef. Investigate the package org.jabref.logic.importer. Another possibility is to investigate the inheritance relation of WebFetcher (Ctrl+H in IntelliJ).

Fulltext Fetchers

  • all fulltext fetchers run in parallel
  • the result with the highest priority wins
  • InterruptedException | ExecutionException | CancellationException are ignored

Trust Levels

  • SOURCE (highest): definitive URL for a particular paper
  • PUBLISHER: any publisher library
  • PREPRINT: any preprint library that might include non final publications of a paper
  • META_SEARCH: meta search engines
  • UNKNOWN (lowest): anything else not fitting the above categories

Current trust levels

All fetchers are contained in the package org.jabref.logic.importer.fetcher. Here we list the trust levels of some of them:
  • DOI: SOURCE, as the DOI is always forwarded to the correct publisher page for the paper
  • ScienceDirect: Publisher
  • Springer: Publisher
  • ACS: Publisher
  • IEEE: Publisher
  • Google Scholar: META_SEARCH, because it is a search engine
  • Arxiv: PREPRINT, because preprints are published there
  • OpenAccessDOI: META_SEARCH
Reasoning:
  • A DOI uniquely identifies a paper. Per definition, a DOI leads to the right paper. Everything else is good guessing.
  • We assume the DOI resolution surely points to the correct paper and that publisher fetches may have errors: For instance, a title of a paper may lead to different publications of it. One the conference version, the other the journal version. --> the PDF could be chosen randomly
Code was first introduced at PR#3882.

Background on embedding the keys in JabRef

The keys are placed into the build.properties file.
1
springerNatureAPIKey=${springerNatureAPIKey}
Copied!
In build.gradle, these variables are filled:
1
"springerNatureAPIKey": System.getenv('SpringerNatureAPIKey')
Copied!
The BuildInfo class reads from that file.
1
new BuildInfo().springerNatureAPIKey
Copied!
When executing ./gradlew run, gradle executes processResources and populates build/build.properties accordingly. However, when working directly in the IDE, Eclipse keeps reading build.properties from src/main/resources. In IntelliJ, the task JabRef Main is executing ./gradlew processResources before running JabRef from the IDE to ensure the build.properties is properly populated.
Previous
Custom SVG icons
Next
Creating a binary and debug it
Last modified 1mo ago
Export as PDF
Copy link
Contents
Fulltext Fetchers
Trust Levels
Current trust levels
Background on embedding the keys in JabRef