Skip to content

Conversation

dcarpentiero
Copy link
Contributor

@dcarpentiero dcarpentiero commented Sep 1, 2025

Closes #13794

Steps to test

Mandatory checks

  • I own the copyright of the code submitted and I license it under the MIT license
  • I manually tested my changes in running JabRef (always required)
  • I added JUnit tests for changes (if applicable)
  • [/] I added screenshots in the PR description (if change is visible to the user)
  • [/] I described the change in CHANGELOG.md in a way that is understandable for the average user (if change is visible to the user)
  • I checked the user 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 updating file(s) in https://github.com/JabRef/user-documentation/tree/main/en.

@dcarpentiero dcarpentiero changed the title Customized entry types 13794 Customized entry types Sep 1, 2025
@calixtus calixtus changed the title Customized entry types Suppoer customized entry types in BibliographyConsistencyCheck Sep 1, 2025
@calixtus calixtus changed the title Suppoer customized entry types in BibliographyConsistencyCheck Support customized entry types in BibliographyConsistencyCheck Sep 1, 2025
Comment on lines +126 to +129
List<BibEntryType> entryTypeDefinitions = bibEntryTypesManager
.getAllTypes(bibContext.getMode())
.stream()
.toList();
Copy link
Member

Choose a reason for hiding this comment

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

No need to convert to a list - Collection should directly work?

Copy link
Contributor Author

Choose a reason for hiding this comment

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

Collection is a interface though–i need some class to implement it right? For example HashSet class implement the Set interface.

Copy link
Contributor Author

Choose a reason for hiding this comment

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

Screenshot 2025-09-04 alle 11 07 41

Also (correct me if I'm wrong, I'm here to learn) the expected type is a list, so I can't provide something else.

@dcarpentiero
Copy link
Contributor Author

dcarpentiero commented Sep 4, 2025

I've modified the BibliographyConsistencyCheck constructor to accept a CliPreferences parameter. Problem is, to make everything work I should change existing tests as the BibliographyConsistencyCheck constructor needs a param to work.
The assignment said I should't be changing existing tests, how should I proceed?

@koppor
Copy link
Member

koppor commented Sep 5, 2025

I've modified the BibliographyConsistencyCheck constructor to accept a CliPreferences parameter.

Nice

. Problem is, to make everything work I should change existing tests as the BibliographyConsistencyCheck constructor needs a param to work.
The assignment said I should't be changing existing tests, how should I proceed?

Oh, let's think if the intention of that... The intention was that test inputs and outputs should not change. If the test setup changes (e.g., new parameter required), it is perfectly fine!

…ckResultTxtWriterTest` and `BibliographyConsistencyCsvWriterTest` testing with `CliPreference` parameter
}

Injector.setModelOrService(BibEntryTypesManager.class, preferences.getCustomEntryTypesRepository());
Injector.setModelOrService(BibEntryTypesManager.class, preferences.getCustomEntryTypesRepository(bibEntryTypesManager));
Copy link

Choose a reason for hiding this comment

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

Direct dependency injection manipulation in GUI code violates layered architecture principle. This logic should be moved to a service layer in org.jabref.logic.

@dcarpentiero
Copy link
Contributor Author

@subhramit hello I might need some help to resolve the conflicts. I tried to solve them but they still appear. What's still happening? Thank you

@subhramit
Copy link
Member

subhramit commented Sep 9, 2025

@subhramit hello I might need some help to resolve the conflicts. I tried to solve them but they still appear. What's still happening? Thank you

Go to Resolve conflicts in the GitHub editor.
image

Here, there will be two pieces of code separated by =======
The upper section will contain your changes (in this branch)
The lower changes will contain what main has

These sections of code are basically conflicting, that is, trying to take the same lines. In most cases, only one of them should be there after your changes, but sometimes a combination can also be there, depending on your branch's logic.

After resolution, pull your changes to your local.

Please ask again if something is unclear.

Alternative:
If you pull upstream/main from IntelliJ, it will open a merge conflict resolution window where you can pick changes from your branch and main (wherever conflicting) and create the net file without conflicts.
After resolution, push your changes to remote.

@dcarpentiero
Copy link
Contributor Author

@subhramit hello I might need some help to resolve the conflicts. I tried to solve them but they still appear. What's still happening? Thank you

Go to Resolve conflicts in the GitHub editor. image

Here, there will be two pieces of code separated by ======= The upper section will contain your changes (in this branch) The lower changes will contain what main has

These sections of code are basically conflicting, that is, trying to take the same lines. In most cases, only one of them should be there after your changes, but sometimes a combination can also be there, depending on your branch's logic.

After resolution, pull your changes to your local.

Please ask again if something is unclear.

Alternative: If you pull upstream/main from IntelliJ, it will open a merge conflict resolution window where you can pick changes from your branch and main (wherever conflicting) and create the net file without conflicts. After resolution, push your changes to remote.

Thank you I've resolved by following this, will surely ask again if necessity arises.

Copy link
Member

@koppor koppor left a comment

Choose a reason for hiding this comment

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

Too many changes regarding BibEntryTypesManager. Most of them can be undone.

Start with reverting all changes in CliPreferences

Injector.setModelOrService(BuildInfo.class, new BuildInfo());

final JabRefGuiPreferences preferences = JabRefGuiPreferences.getInstance();
final BibEntryTypesManager bibEntryTypesManager = new BibEntryTypesManager();
Copy link
Member

Choose a reason for hiding this comment

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

Please do not store it as variable - you only need it once below.

Copy link
Contributor Author

Choose a reason for hiding this comment

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

fixed.

}

PreferencesMigrations.runMigrations(preferences);
PreferencesMigrations.runMigrations(preferences, bibEntryTypesManager);
Copy link
Member

Choose a reason for hiding this comment

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

Remove the parameter.

Later, use preferences.getCustomEntryTypesRepository() to get the bibEntryTypesManager

Copy link
Contributor Author

Choose a reason for hiding this comment

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

What is the advantage of declaring BibEntryTypesManager bibEntryTypesManager = preferences.getCustomEntryTypesRepository(); and then upgradeStoredBibEntryTypes(preferences, mainPrefsNode, bibEntryTypesManager); instead of just upgradeStoredBibEntryTypes(preferences, mainPrefsNode, preferences.getCustomEntryTypesRepository());? Am i missing something here?

dialogService,
fileUpdateMonitor,
preferences,
cliPreferences,
Copy link
Member

Choose a reason for hiding this comment

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

Please remove this.

See that GuiPreferences extends CliPreferences.

Thus, the GuiPreferences have all the CliPreferences

Copy link
Contributor Author

Choose a reason for hiding this comment

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

fixed.

@Override
public BibEntryTypesManager getCustomEntryTypesRepository() {
BibEntryTypesManager bibEntryTypesManager = new BibEntryTypesManager();
public BibEntryTypesManager getCustomEntryTypesRepository(BibEntryTypesManager bibEntryTypesManager) {
Copy link
Member

Choose a reason for hiding this comment

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

Please undo this - the point here is that a new repository is generated.

Copy link
Contributor Author

Choose a reason for hiding this comment

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

Ohhh I should implement both, the one without the parameter and then override with the parameter did I get it right?

@jabref-machine
Copy link
Collaborator

Your code currently does not meet JabRef's code guidelines. We use Checkstyle to identify issues. You can see which checks are failing by locating the box "Some checks were not successful" on the pull request page. To see the test output, locate "Source Code Tests / Checkstyle (pull_request)" and click on it.

In case of issues with the import order, double check that you activated Auto Import. You can trigger fixing imports by pressing Ctrl+Alt+O to trigger Optimize Imports.

Please carefully follow the setup guide for the codestyle. Afterwards, please run checkstyle locally and fix the issues, commit, and push.

@dcarpentiero
Copy link
Contributor Author

@subhramit Hi, I'm running into a design issue with the filtering logic in filterAndSortEntriesWithFieldDifferences.

I have two types of inconsistencies to handle:

  1. Missing required fields (e.g., BIBLATEX with Online type): all entries in the group should be included
  2. Only inconsistencies between optional fields (e.g., BIBTEX with unknown type): only entries that have those fields should be included

The problem is that the method only receives differingFields and requiredFields, but cannot distinguish whether there are actually entries with missing required fields in the specific group.

The failing tests show that:

  • checkComplexLibrary expects the sixth entry (which has none of the inconsistent fields)
  • unsetFieldsReportedInBibtexMode does NOT want the withoutDate entry (which lacks the date field)

The current logic cannot satisfy both cases. I need a refactoring to pass more context or change the filtering approach.

I'd like some help on how to proceed?

@jabref-machine
Copy link
Collaborator

Your code currently does not meet JabRef's code guidelines. IntelliJ auto format covers some cases. There seem to be issues with your code style and autoformat configuration. Please reformat your code (Ctrl+Alt+L) and commit, then push.

In special cases, consider using // formatter:off and // formatter:on annotations to allow deviation from the code style.

BibDatabaseContext bibContext = databaseContext.get();

BibliographyConsistencyCheck consistencyCheck = new BibliographyConsistencyCheck();
BibliographyConsistencyCheck consistencyCheck = new BibliographyConsistencyCheck(preferences, entryTypesManager);
Copy link

Choose a reason for hiding this comment

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

The patch introduces a constructor call with parameters, but it does not ensure that null is never passed to the method, which violates the guideline that null should never be passed to a method.

@subhramit
Copy link
Member

@subhramit Hi, I'm running into a design issue with the filtering logic in filterAndSortEntriesWithFieldDifferences.

I have two types of inconsistencies to handle:

  1. Missing required fields (e.g., BIBLATEX with Online type): all entries in the group should be included
  2. Only inconsistencies between optional fields (e.g., BIBTEX with unknown type): only entries that have those fields should be included

The problem is that the method only receives differingFields and requiredFields, but cannot distinguish whether there are actually entries with missing required fields in the specific group.

The failing tests show that:

  • checkComplexLibrary expects the sixth entry (which has none of the inconsistent fields)
  • unsetFieldsReportedInBibtexMode does NOT want the withoutDate entry (which lacks the date field)

The current logic cannot satisfy both cases. I need a refactoring to pass more context or change the filtering approach.

I'd like some help on how to proceed?

Passing more context is fine, also, when you say change the filtering approach, what do you propose?
I also think I am not the best person to answer this, tagging @koppor

@Siedlerchr Siedlerchr added the status: changes-required Pull requests that are not yet complete label Sep 23, 2025
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
status: changes-required Pull requests that are not yet complete
Projects
None yet
Development

Successfully merging this pull request may close these issues.

Support customized entry types in BibliographyConsistencyCheck
6 participants