Thanks dantran for the feedback. How did you envision the filter definition? I imagined a the capability to define exact-string / regular-expressions filters for each of the following attribute: groupId, artifactId, version (e.g. "0.5-SNAPSHOT"), classifier, type.

I had in mind to not propose for the first version filters on: expanded version (e.g. "0.5-20180218.180717-50"), extension (because we can filter on the type).

Regarding the classifier, note that for the moment, we just list the "generated artifact" of the maven module and NOT the attached artifacts (e.g. sources, javadocs...).

As you mentionned that you build OVAs and RPM, I found that the rpm-maven-plugin can generate rpm as "primary artifacts (see http://www.mojohaus.org/rpm-maven-plugin/usage.html#RPM_as_Primary_Artifact)

My final user's facing artifacts  consists of 2 files ( a .ova and .pkg) both using maven attach mechanism with build-helper-maven plugin to deploy secondary or classify artifacts.  So using regular expression should work

Note: currently we only see primary artifacts ( .jar .war  .rpm ( via rpm-maven-plugin) show up in the deployed list

To rephrase your RFE.

You ask to filter the listed artifacts to only show the artifacts that matter to the users who browse this page (eg. Don't show pom files and intermediate artifacts).
Your goal is not related to the number of generated artifacts that would be too big and that would impact the rendering of the page.

For this reason, a pagination mechanism would not solve your problem.

Correct?

out of 400+ artifacts showing up in the list,  my users only care about 2.  Paging does not help and the selected artifacts are burried in list, very hard to look up

You are combining the 2 problems to solve in 1 single use case

Understood, the filtering seem to be the way forward for your problems.