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
Since 0.9.10 ResourcesScanner no longer works and will return all .class resources along. Filtering in acceptsInput in there has become useless since it's OR-ed with acceptResult, whose resultFilter is Predicates.alwaysTrue() by default.
Culprit commit is the following: 2f3294c FilterBuilder check for matches for each resource on both file relative path (with /) and fqn (with .)
I never knew what was the motivation to replace slashes with dots in the first place (producing fqns over paths); I agree we should definitely be able to filter on paths. Just not sure it was the rightest way to introduce that (especially with respect to the evaluation overhead which others reported).
If time allows I'd gladly contribute something, but I think a first step would be to revert what has happened there anyway. Any opinion or rationale?
Cheers,
Mika
The text was updated successfully, but these errors were encountered:
Just found the same bug today, exactly as mkgl said:
Since 0.9.10 ResourcesScanner no longer works and will return all .class resources along. Filtering in acceptsInput in there has become useless since it's OR-ed with acceptResult, whose resultFilter is Predicates.alwaysTrue() by default.
Since 0.9.10
ResourcesScannerno longer works and will return all.classresources along. Filtering inacceptsInputin there has become useless since it's OR-ed withacceptResult, whoseresultFilterisPredicates.alwaysTrue()by default.Culprit commit is the following:
2f3294c FilterBuilder check for matches for each resource on both file relative path (with /) and fqn (with .)I never knew what was the motivation to replace slashes with dots in the first place (producing fqns over paths); I agree we should definitely be able to filter on paths. Just not sure it was the rightest way to introduce that (especially with respect to the evaluation overhead which others reported).
If time allows I'd gladly contribute something, but I think a first step would be to revert what has happened there anyway. Any opinion or rationale?
Cheers,
Mika
The text was updated successfully, but these errors were encountered: