-
-
Notifications
You must be signed in to change notification settings - Fork 2.6k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Localization tests #2582
Localization tests #2582
Conversation
@JabRef/developers Hm, our org.jabref move obviously lost all information on who did author the files :( |
@@ -75,6 +75,14 @@ | |||
} | |||
} | |||
|
|||
public static Set<LocalizationEntry> findLocalizationParametersStringsInJavaFiles(LocalizationBundleForTest type) | |||
throws IOException { | |||
return Files.walk(Paths.get("src/main")) |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
You could directly use the Files.find method and pass the filter predicate as argument. maxDepth would then be Integer.MaxValue
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Just looked at it. Doesn't seem like a real change to me except that its a parameter then?!
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
A bit different. Instead of collecting all files and then filtering on the list(the stream), the Files.find directly invokes the predicate on each file and the file is only included in the stream if it matches:
This method walks the file tree in exactly the manner specified by the walk method. For each file encountered, the given BiPredicate is invoked with its Path and BasicFileAttributes. The Path object is obtained as if by resolving the relative path against start and is only included in the returned Stream if the BiPredicate returns true. Compare to calling filter on the Stream returned by walk method, this method may be more efficient by avoiding redundant retrieval of the BasicFileAttributes.
look in FileUtil.findFiles
int index = matcher.end(); | ||
int brackets = 1; | ||
StringBuilder buffer = new StringBuilder(); | ||
while (brackets != 0) { |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Look in our StringUtil class, there is already a method for finding braces
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Thanks for the hints, but this is old code which I didnt write and don't wanna change if not really necessary.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
But you created a test for it right? So you could check it....
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
"basst scho"
* upstream/master: Revert "Update gradle from 3.3 to 3.4" Localization tests (#2582) Update IEEEJournalList (#2579) Keyword - Special field synchronization (#2583) Update gradle from 3.3 to 3.4 Check similarity of entry when using DOI retrieval with ArXiV (#2575) Add logic for new Sciencedirect pages (#2576) [WIP] Refactored around the FileAnnotationCache. (#2557)
Test for #1985