Currently it's only possible to use Resources for the Suffix creation:
As soon as you want to build a suffix for two page-resources, this fails as the resources are no descendents.
java.lang.IllegalArgumentException: the resource JcrNodeResource, type=/apps/foo/components/page/bar, superType=null, path=/content/foo/bar/ipsum/jcr:content is not a descendent of the base resource JcrNodeResource, type=/apps/foo/components/page/bar, superType=null, path=/content/foo/bar/jcr:content
The naming of the Test-Methods is a little bit strange (e.g. testGetLongIntBooleanStringResourceFilterOfResourceString). Not sure if this is intentional, I just reused them to ensure a consistent naming.
To avoid bloating up the SuffixParser, I didn't overload all getPages(...) methods, only the getPage(...) ones.
i think it would make more sense to use Filter<Page> instead of Filter<Resource> for the SuffixParser.getPage/getPages methods with filtering?
But then it would not be possible to reuse the "getResourcesWithBaseResource" method. I thought about this too, but as there are not many (if any?) filter options for pages that do not exist for resources, I decided against it.
it is more consistent to use Filter<Page> instead of Filter<Resource>, and it's easy to still reuse getResourcesWithBaseResource.
i've enhanced your patch to reflect this and added some more signature missing compared to the signature variants for resources.
merged in rev. 441dfb1592cb1f35ad153634b91b35483ec3c475 and now available in the current snapshot.