One of the reasons I created oakpal was that I recognized a real need for a standard filevault validation framework, because the AEM community is littered with package validation attempts that quietly nibble around the edges of the filevault API. And while maven is the default build tool that most AEM developers use to create a zip file archive, it's not the only tool, and the zip file format is not the only kind of filevault archive that needs validation (potentially). My own inspiration came when I was trying to solve too many possible edge cases in the Jenkins CRX Content Package Deployer Plugin, which doesn't require that packages are built from maven.
Here are some tools that I know are completely unaddressed by maven-based validation solutions: 1. vlt 2. Cognifide's gradle-aem-plugin : https://github.com/Cognifide/gradle-aem-plugin 3. aemsync (node.js tool used by aemfed) : https://www.npmjs.com/package/aemsync My hunch is that while it is great to add the specific validations included in the PR to the maven plugin execution, the interfaces for Validator et al should not be published as an SPI under the "org.apache.jackrabbit.filevault.maven.packaging" namespace, and an SPI, as such, should be published as a unique artifact, if not included in vault-core itself. Mark Adamcin On 2019/09/18 17:27:34, Konrad Windszus <[email protected]> wrote: > Hi, > in the context of https://issues.apache.org/jira/browse/JCRVLT-345 > <https://issues.apache.org/jira/browse/JCRVLT-345> I have been working on a > generic validator SPI as well as some validator implementations. Currently > they are part of a PR > (https://github.com/apache/jackrabbit-filevault-package-maven-plugin/pull/28 > <https://github.com/apache/jackrabbit-filevault-package-maven-plugin/pull/28>) > belonging to the filevault-package-maven-plugin (the classes in package > o.a.j.f.maven.packaging.validator) and to some extent tightly coupled to > Maven (i.e. they use JSR330 annotation and Sisu metainformation, > https://maven.apache.org/maven-jsr330.html > <https://maven.apache.org/maven-jsr330.html>). > Mark proposed in > https://github.com/apache/jackrabbit-filevault-package-maven-plugin/pull/28#issuecomment-532738071 > > <https://github.com/apache/jackrabbit-filevault-package-maven-plugin/pull/28#issuecomment-532738071> > to move the SPI to a dedicated filevault module instead to make it possible > to leverage the same validators also from vlt or some 3rd party gradle > plugin. That would require some additional effort and also one has to come up > with technology agnostic way for registering services (e.g. > https://docs.oracle.com/javase/8/docs/api/java/util/ServiceLoader.html > <https://docs.oracle.com/javase/8/docs/api/java/util/ServiceLoader.html>). > > I can see some usage for Maven agnostic FileVault validators but this is > different from the original proposal. Therefore I would like to know if there > is a real need for leveraging those validators outside of Maven? > > TIA for your input, > Konrad > > >
