Not all Service Loader files in "/META-INF/services" are in form of multi-line text file

[hmozaffari]

ServiceLoaderFileScannerPlugin assumes files in "META-INF/services" folder are in form of text files holding class names in earch line:
https://github.com/jQAssistant/jqassistant/blob/master/plugin/java/src/main/java/com/buschmais/jqassistant/plugin/java/impl/scanner/ServiceLoaderFileScannerPlugin.java#L56

But there are cases where XML files are placed in "META-INF/services" folder and ServiceLoaderFileScannerPlugin scans it incorrectly.
For example Websphere libraries have XML files placed in "META-INF/services" of Jar files:
https://www.ibm.com/docs/en/was/9.0.5?topic=clients-custom-binding-providers-jax-rpc-applications

Ideally those xml files can be ignored if parsing them is not feasible.

[DirkMahler]

Interesting to see that this folder is (mis)used to placing other files into it. I hope this happened accidentally, not by intention…

I wouldn’t like to hard-code an exclusion for XML files, there could by any file in that folder as well. On the other hand it doesn’t seem trivial to identify service loader files. The criteria is that the file name represents the name of a Java interface and the content only consists of Java class names (each on a new line) as well.

Any idea?

[hmozaffari]

I agree with your term of (mis)use :). But seems it is used intentionally and other vendors may also put extra files in that folder.
I found schema of that xml file:
https://www.ibm.com/docs/en/was/9.0.5?topic=clients-custom-binding-providers-jax-rpc-applications

      ...
      <xsd:sequence>
          <xsd:element name="description" type="xsd:string" minOccurs="0"/>
          <xsd:element name="xmlQName" type="xsd:QName"/>
          <xsd:element name="javaName" type="xsd:string"/>
          <xsd:element name="qnameScope" type="customdatabinding:qnameScopeType"/>
          <xsd:element name="binder" type="xsd:string"/>
      </xsd:sequence>
      ...

As you see in addition to java class name they put extra information in that xml file.

I agree it is not feasible to identify all those custom formats. But may be the line reader can validate lines against a regular expression and if it is not presenting Package+JavaFile ignores it with a warning?