Re: FileVault: Validator SPI and implementations

[Konrad Windszus]

Ok, I am convinced. I created 
https://github.com/apache/jackrabbit-filevault/pull/58 
 for the addition of 
the validation framework to FileVault itself.
Actually it was not too much work.
This includes both SPI and API (Maven agnostic).
Review would be highly appreciated.

Only a very thin layer is now necessary to leverage validation e.g. in Maven (I 
am working on that as well), as well as in other toolings (any volunteers?).

Thanks for the input,
Konrad

> On 19. Sep 2019, at 10:58, Robert Munteanu  wrote:
> 
> On Thu, 2019-09-19 at 10:45 +0200, Konrad Windszus wrote:
>> Hi Robert,
>> Eclipse would be covered with the Maven Plugin which has m2e support.
>> I have it already running locally with my proposed PR with nice error
>> markers in the IDE.
>> That would not cover IntelliJ though, unfortunately...
> 
> Out-of-the-box Eclipse support is nice, indeed. I think other IDEs
> would be useful, but I'm not able to quantify the return on effort.
> 
> Thanks,
> Robert
> 

Re: FileVault: Validator SPI and implementations

[Robert Munteanu]

On Thu, 2019-09-19 at 10:45 +0200, Konrad Windszus wrote:
> Hi Robert,
> Eclipse would be covered with the Maven Plugin which has m2e support.
> I have it already running locally with my proposed PR with nice error
> markers in the IDE.
> That would not cover IntelliJ though, unfortunately...

Out-of-the-box Eclipse support is nice, indeed. I think other IDEs
would be useful, but I'm not able to quantify the return on effort.

Thanks,
Robert

Re: FileVault: Validator SPI and implementations

[Konrad Windszus]

Hi Robert,
Eclipse would be covered with the Maven Plugin which has m2e support.
I have it already running locally with my proposed PR with nice error markers 
in the IDE.
That would not cover IntelliJ though, unfortunately...

Konrad

> On 19. Sep 2019, at 10:42, Robert Munteanu  wrote:
> 
> Hi Konrad,
> 
> On Wed, 2019-09-18 at 19:27 +0200, Konrad Windszus wrote:
>> 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?
> 
> IDE tooling is another case, although I have no plans to work on that
> on the short term.
> 
> Robert
> 

Re: FileVault: Validator SPI and implementations

[Robert Munteanu]

Hi Konrad,

On Wed, 2019-09-18 at 19:27 +0200, Konrad Windszus wrote:
> 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?

IDE tooling is another case, although I have no plans to work on that
on the short term.

Robert

Re: FileVault: Validator SPI and implementations

[Mark Adamcin]

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  wrote: 
> Hi,
> in the context of 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 
> )
>  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 
> ).
> Mark proposed in 
> 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 
> ).
> 
> 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
> 
> 
>