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 enviornment 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 |
​IEEEXplore​ | ​IEEE Xplore API portal​ |
| 200 calls/day |
​MathSciNet​ | (none) | (none) | Depending on the current network |
​ADS UI​ |
| 5000 calls/day | |
​Springer Nature​ |
| 5000 calls/day | |
​Zentralblatt Math​ | (none) | (none) | Depending on the current network |
"Depending on the current network" means that it depends 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.
The keys are placed into the build.properties file.
springerNatureAPIKey=${springerNatureAPIKey}
In build.gradle, these variables are filled:
"springerNatureAPIKey": System.getenv('SpringerNatureAPIKey')
The BuildInfo class reads from that file.
new BuildInfo().springerNatureAPIKey
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.
