You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Merge remote-tracking branch 'upstream/master' into master
* upstream/master:
GitBook: [master] 3 pages and 32 assets modified
Add migration to special field (#7368)
GitBook: [master] 5 pages and 29 assets modified
Copy file name to clipboardExpand all lines: CHANGELOG.md
+1
Original file line number
Diff line number
Diff line change
@@ -20,6 +20,7 @@ Note that this project **does not** adhere to [Semantic Versioning](http://semve
20
20
### Changed
21
21
22
22
- The content of the field `timestamp` is migrated to `creationdate`. In case one configured "udpate timestampe", it is migrated to `modificationdate`. [koppor#130](https://github.com/koppor/jabref/issues/130)
23
+
- The JabRef specific meta-data content in the main field such as priorities (prio1, prio2, ...) are migrated to their respective fields. They are removed from the keywords. [#6840](https://github.com/jabref/jabref/issues/6840)
23
24
- We fixed an issue where groups generated from authors' last names did not include all entries of the authors' [#5833](https://github.com/JabRef/jabref/issues/5833)
24
25
- The export to MS Office XML now uses the month name for the field `MonthAcessed` instead of the two digit number [#7354](https://github.com/JabRef/jabref/issues/7354)
Copy file name to clipboardExpand all lines: docs/advanced-reading/fetchers.md
+21-23
Original file line number
Diff line number
Diff line change
@@ -1,4 +1,4 @@
1
-
# Information about Fetchers
1
+
# Working on fetchers
2
2
3
3
Fetchers are the implementation of the [search using online services](https://docs.jabref.org/collect/import-using-online-bibliographic-database). 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.
4
4
@@ -16,39 +16,37 @@ On Windows, you have to log-off and log-on to let IntelliJ know about the enviro
16
16
17
17
## Fulltext Fetchers
18
18
19
-
- all fulltext fetchers run in parallel
20
-
- the result with the highest priority wins
21
-
-`InterruptedException` | `ExecutionException` | `CancellationException` are ignored
19
+
* all fulltext fetchers run in parallel
20
+
* the result with the highest priority wins
21
+
*`InterruptedException`\|`ExecutionException`\|`CancellationException` are ignored
22
22
23
23
### Trust Levels
24
24
25
-
- SOURCE (highest): definitive URL for a particular paper
26
-
- PUBLISHER: any publisher library
27
-
- PREPRINT: any preprint library that might include non final publications of a paper
28
-
- META_SEARCH: meta search engines
29
-
- UNKNOWN (lowest): anything else not fitting the above categories
25
+
* SOURCE \(highest\): definitive URL for a particular paper
26
+
* PUBLISHER: any publisher library
27
+
* PREPRINT: any preprint library that might include non final publications of a paper
28
+
* META\_SEARCH: meta search engines
29
+
* UNKNOWN \(lowest\): anything else not fitting the above categories
30
30
31
31
### Current trust levels
32
32
33
-
All fetchers are contained in the package `org.jabref.logic.importer.fetcher`.
34
-
Here we list the trust levels of some of them:
33
+
All fetchers are contained in the package `org.jabref.logic.importer.fetcher`. Here we list the trust levels of some of them:
35
34
36
-
- DOI: SOURCE, as the DOI is always forwarded to the correct publisher page for the paper
37
-
- ScienceDirect: Publisher
38
-
- Springer: Publisher
39
-
- ACS: Publisher
40
-
- IEEE: Publisher
41
-
- Google Scholar: META_SEARCH, because it is a search engine
42
-
- Arxiv: PREPRINT, because preprints are published there
43
-
- OpenAccessDOI: META_SEARCH
35
+
* DOI: SOURCE, as the DOI is always forwarded to the correct publisher page for the paper
36
+
* ScienceDirect: Publisher
37
+
* Springer: Publisher
38
+
* ACS: Publisher
39
+
* IEEE: Publisher
40
+
* Google Scholar: META\_SEARCH, because it is a search engine
41
+
* Arxiv: PREPRINT, because preprints are published there
42
+
* OpenAccessDOI: META\_SEARCH
44
43
45
44
Reasoning:
46
45
47
-
- A DOI uniquely identifies a paper. Per definition, a DOI leads to the right paper. Everything else is good guessing.
48
-
- 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
46
+
* A DOI uniquely identifies a paper. Per definition, a DOI leads to the right paper. Everything else is good guessing.
47
+
* 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
49
48
50
-
51
-
Code was first introduced at [PR#3882](https://github.com/JabRef/jabref/pull/3882).
49
+
Code was first introduced at [PR\#3882](https://github.com/JabRef/jabref/pull/3882).
After reading through this guide, check out some good first issues to contribute to by clicking here: [Good First Issues](https://github.com/JabRef/jabref/issues?q=is%3Aissue+is%3Aopen+label%3A%22good+first+issue%22)
4
4
5
5
In case you are aiming to contribute other improvements, please head over to our general [JabRef contribution page](https://docs.jabref.org/faqcontributing).
6
6
7
-
In case you are an instructor and want to use **JabRef as software engineering example**, please head to <https://devdocs.jabref.org/teaching>.
7
+
In case you are an instructor and want to use **JabRef as software engineering example**, please head to [https://devdocs.jabref.org/teaching](https://devdocs.jabref.org/teaching).
8
8
9
9
## Contribute code
10
10
@@ -13,62 +13,53 @@ In case you are an instructor and want to use **JabRef as software engineering e
13
13
We welcome contributions to JabRef and encourage you to follow the GitHub workflow specified below. If you are not familiar with this type of workflow, take a look at GitHub's excellent overview on the [GitHub flow](https://guides.github.com/introduction/flow/index.html) and the explanation of [Feature Branch Workflow](https://atlassian.com/git/tutorials/comparing-workflows#feature-branch-workflow) for the idea behind this kind of development.
14
14
15
15
1. Get the JabRef code on your local machine. Detailed instructions about this step can be found in our [guidelines for setting up a local workspace](https://devdocs.jabref.org/getting-into-the-code/guidelines-for-setting-up-a-local-workspace).
16
-
1. Fork the JabRef into your GitHub account.
17
-
2. Clone your forked repository on your local machine.
18
-
2.**Create a new branch** (such as `fix-for-issue-121`). Be sure to create a **separate branch** for each improvement you implement.
16
+
1. Fork the JabRef into your GitHub account.
17
+
2. Clone your forked repository on your local machine.
18
+
2.**Create a new branch**\(such as `fix-for-issue-121`\). Be sure to create a **separate branch** for each improvement you implement.
19
19
3. Do your work on the **new branch - not the master branch.** Refer to our [code howtos](https://devdocs.jabref.org/getting-into-the-code/code-howtos) if you have questions about your implementation.
20
20
4. Create a pull request. For an overview of pull requests, take a look at GitHub's [pull request help documentation](https://help.github.com/articles/about-pull-requests/).
21
21
5. In case your pull request is not yet complete or not yet ready for review, consider creating a [draft pull request](https://github.blog/2019-02-14-introducing-draft-pull-requests/) instead.
22
22
23
-
In case you have any questions, do not hesitate to write one of our [JabRef developers](https://github.com/orgs/JabRef/teams/developers) an email.
24
-
We should also be online at [gitter](https://gitter.im/JabRef/jabref).
23
+
In case you have any questions, do not hesitate to write one of our [JabRef developers](https://github.com/orgs/JabRef/teams/developers) an email. We should also be online at [gitter](https://gitter.im/JabRef/jabref).
25
24
26
25
### Formal requirements for a pull request
27
26
28
27
The main goal of the formal requirements is to provide credit to you and to be able to understand the patch.
29
28
30
29
#### Add your change to `CHANGELOG.md`
31
30
32
-
You should edit the [`CHANGELOG.md`](https://github.com/JabRef/jabref/blob/master/CHANGELOG.md#changelog) file located in the root directory of the JabRef source.
33
-
Add a line with your changes in the appropriate section.
31
+
You should edit the [`CHANGELOG.md`](https://github.com/JabRef/jabref/blob/master/CHANGELOG.md#changelog) file located in the root directory of the JabRef source. Add a line with your changes in the appropriate section.
34
32
35
-
If you did internal refactorings or improvements not visible to the user (e.g., UI, .bib file), then you don't need to put an entry there.
33
+
If you did internal refactorings or improvements not visible to the user \(e.g., UI, .bib file\), then you don't need to put an entry there.
36
34
37
-
##### Format of keyboard shortcuts
35
+
**Format of keyboard shortcuts**
38
36
39
37
Example: `<kbd>Ctrl</kbd> + <kbd>Enter</kbd>`
40
38
41
39
In case you add keys to the changelog, please follow these rules:
42
40
43
-
-`<kbd>` tag for each key
44
-
- First letter of key capitalized
45
-
- Combined keys separated by `+`
46
-
- Spaces before and after separator `+`
41
+
*`<kbd>` tag for each key
42
+
* First letter of key capitalized
43
+
* Combined keys separated by `+`
44
+
* Spaces before and after separator `+`
47
45
48
46
#### Author credits
49
47
50
-
Please, **do not add yourself at JavaDoc's `@authors`**.
51
-
The contribution information is tracked via the version control system and shown at <https://github.com/JabRef/jabref/graphs/contributors>.
52
-
We also link to the contributors page in our about dialog.
48
+
Please, **do not add yourself at JavaDoc's `@authors`**. The contribution information is tracked via the version control system and shown at [https://github.com/JabRef/jabref/graphs/contributors](https://github.com/JabRef/jabref/graphs/contributors). We also link to the contributors page in our about dialog.
53
49
54
50
Your contribution is considered being made under [MIT license](https://tldrlegal.com/license/mit-license).
55
51
56
52
#### Write a good commit message
57
53
58
-
See [good commit message] or [commit guidelines section of Pro Git].
59
-
The first line of your commit message is automatically taken as the title for the pull-request.
60
-
All other lines make up the body of the pull request. Add the words `fixes #xxx` to your PR to auto-close the corresponding issue.
54
+
See [good commit message](https://github.com/joelparkerhenderson/git_commit_message) or [commit guidelines section of Pro Git](http://git-scm.com/book/en/Distributed-Git-Contributing-to-a-Project#Commit-Guidelines). The first line of your commit message is automatically taken as the title for the pull-request. All other lines make up the body of the pull request. Add the words `fixes #xxx` to your PR to auto-close the corresponding issue.
61
55
62
56
#### Test your code
63
57
64
-
We know that writing test cases takes a lot of time.
65
-
Nevertheless, we rely on our test cases to ensure that a bug fix or a feature implementation doesn't break anything.
66
-
In case you do not have time to add a test case, we nevertheless ask you to at least run `gradlew check` to ensure that your change doesn't break anything else.
58
+
We know that writing test cases takes a lot of time. Nevertheless, we rely on our test cases to ensure that a bug fix or a feature implementation doesn't break anything. In case you do not have time to add a test case, we nevertheless ask you to at least run `gradlew check` to ensure that your change doesn't break anything else.
67
59
68
60
#### When adding a new `Localization.lang` entry
69
61
70
-
Add new `Localization.lang("KEY")` to a Java file.
71
-
The tests will fail. In the test output a snippet is generated, which must be added to the English translation file.
62
+
Add new `Localization.lang("KEY")` to a Java file. The tests will fail. In the test output a snippet is generated, which must be added to the English translation file.
72
63
73
64
Example:
74
65
@@ -82,30 +73,21 @@ Expected :[]
82
73
Actual :[Opens\ JabRef's\ Twitter\ page (src\main\java\org\jabref\gui\JabRefFrame.java LANG)]
83
74
```
84
75
85
-
Add the above snippet to the English translation file located at `src/main/resources/l10n/JabRef_en.properties`.
86
-
[Crowdin](https://crowdin.com/project/jabref) will automatically pick up the new string and add it to the other translations.
76
+
Add the above snippet to the English translation file located at `src/main/resources/l10n/JabRef_en.properties`. [Crowdin](https://crowdin.com/project/jabref) will automatically pick up the new string and add it to the other translations.
87
77
88
-
You can also directly run the specific test in your IDE.
89
-
The test "LocalizationConsistencyTest" is placed under `src/test/java/net.sf.jabref.logic.l10n/LocalizationConsistencyTest.java`
90
-
Find more information in the [JabRef developer docs](https://devdocs.jabref.org/getting-into-the-code/code-howtos#using-localization-correctly).
78
+
You can also directly run the specific test in your IDE. The test "LocalizationConsistencyTest" is placed under `src/test/java/net.sf.jabref.logic.l10n/LocalizationConsistencyTest.java` Find more information in the [JabRef developer docs](https://devdocs.jabref.org/getting-into-the-code/code-howtos#using-localization-correctly).
91
79
92
80
#### When adding a library
93
81
94
-
Please try to use a version available at JCenter and add it to `build.gradle`.
95
-
In any case, describe the library at [`external-libraries.md`](https://github.com/JabRef/jabref/blob/master/external-libraries.md#external-libraries).
96
-
We need that information for our package maintainers (e.g., those of the [debian package](https://tracker.debian.org/pkg/jabref)).
97
-
Also add a txt file stating the license in `libraries/`.
98
-
It is used at `gradlew processResources` to generate the About.html files.
99
-
You can see the result in `build\resources\main\help\en\About.html` or when clicking Help -> About.
82
+
Please try to use a version available at JCenter and add it to `build.gradle`. In any case, describe the library at [`external-libraries.md`](https://github.com/JabRef/jabref/blob/master/external-libraries.md#external-libraries). We need that information for our package maintainers \(e.g., those of the [debian package](https://tracker.debian.org/pkg/jabref)\). Also add a txt file stating the license in `libraries/`. It is used at `gradlew processResources` to generate the About.html files. You can see the result in `build\resources\main\help\en\About.html` or when clicking Help -> About.
100
83
101
84
#### When making an architectural decision
102
85
103
-
In case you add a library or do major code rewrites, we ask you to document your decision.
104
-
Recommended reading: <https://adr.github.io/>.
86
+
In case you add a library or do major code rewrites, we ask you to document your decision. Recommended reading: [https://adr.github.io/](https://adr.github.io/).
105
87
106
-
We simply ask to create a new markdown file in `docs/adr` following the template presented at <https://adr.github.io/madr/>.
88
+
We simply ask to create a new markdown file in `docs/adr` following the template presented at [https://adr.github.io/madr/](https://adr.github.io/madr/).
107
89
108
-
In case you want to directly add a comment to a class, simply use following template (based on [sustainable architectural decisions](https://www.infoq.com/articles/sustainable-architectural-design-decisions)):
90
+
In case you want to directly add a comment to a class, simply use following template \(based on [sustainable architectural decisions](https://www.infoq.com/articles/sustainable-architectural-design-decisions)\):
109
91
110
92
```text
111
93
In the context of <use case/user story u>,
@@ -119,14 +101,9 @@ because <additional rationale>.
119
101
120
102
### Create a pull request
121
103
122
-
Create a pull request on GitHub following GitHub's guide "[Creating a pull request from a fork](https://help.github.com/en/github/collaborating-with-issues-and-pull-requests/creating-a-pull-request-from-a-fork)".
123
-
For text inspirations, consider [How to write the perfect pull request](https://github.com/blog/1943-how-to-write-the-perfect-pull-request).
104
+
Create a pull request on GitHub following GitHub's guide "[Creating a pull request from a fork](https://help.github.com/en/github/collaborating-with-issues-and-pull-requests/creating-a-pull-request-from-a-fork)". For text inspirations, consider [How to write the perfect pull request](https://github.com/blog/1943-how-to-write-the-perfect-pull-request).
124
105
125
-
If you want to indicate that a pull request is not yet complete **before** creating the pull request, you may consider creating a [draft pull request](https://github.blog/2019-02-14-introducing-draft-pull-requests/).
126
-
Alternatively, once the PR has been created, you can add the prefix `[WIP]` (which stands for "Work in Progress") to indicate that the pull request is not yet complete, but you want to discuss something or inform about the current state of affairs.
127
-
128
-
[commit guidelines section of Pro Git]: http://git-scm.com/book/en/Distributed-Git-Contributing-to-a-Project#Commit-Guidelines
If you want to indicate that a pull request is not yet complete **before** creating the pull request, you may consider creating a [draft pull request](https://github.blog/2019-02-14-introducing-draft-pull-requests/). Alternatively, once the PR has been created, you can add the prefix `[WIP]`\(which stands for "Work in Progress"\) to indicate that the pull request is not yet complete, but you want to discuss something or inform about the current state of affairs.
130
107
131
108
## How to improve the developer's documentation
132
109
@@ -139,3 +116,4 @@ In case you use some gitbook special features and you want to test them, checkou
139
116
3.`gitbook serve`
140
117
141
118
Then, you can see a near-to-reality rendering of the development documentation at [http://localhost:4000](http://localhost:4000).
0 commit comments