Custom header definition does not allow empty strings
matusfaro opened this issue · comments
Validation for a custom header definition is stricter than definitions inside HeaderType
. Particularly, all tags cannot be empty.
For example, trying to replicate SINGLE_LINE_DOUBLESLASH_STYLE, I receive the following exception:
Caused by: java.lang.IllegalArgumentException: The value cannot be empty for XML tag skipLinePattern for type custom_double_dash
at com.mycila.maven.plugin.license.header.HeaderDefinition.setPropertyFromString (HeaderDefinition.java:172)
at com.mycila.maven.plugin.license.header.AdditionalHeaderDefinition$FeedProperty.execute (AdditionalHeaderDefinition.java:115)
at com.mycila.xmltool.XMLDoc.forEachChild (XMLDoc.java:86)
at com.mycila.maven.plugin.license.header.AdditionalHeaderDefinition$1.execute (AdditionalHeaderDefinition.java:85)
at com.mycila.xmltool.XMLDoc.forEachChild (XMLDoc.java:86)
at com.mycila.maven.plugin.license.header.AdditionalHeaderDefinition.<init> (AdditionalHeaderDefinition.java:76)
...
Fix is to remove the following lines from HeaderDefinition.java
:setPropertyFromString
:
if (isEmpty(value)) {
throw new IllegalArgumentException("The value cannot be empty for XML tag " + property + " for type " + type);
}
And just let the validate
method perform the same validation on both built-in and external header definitions.
Forgot to mention: leaving the tag out completely causes a NPE:
Caused by: java.lang.NullPointerException
at com.mycila.maven.plugin.license.header.HeaderDefinition.check (HeaderDefinition.java:228)
at com.mycila.maven.plugin.license.header.HeaderDefinition.validate (HeaderDefinition.java:209)
at com.mycila.maven.plugin.license.header.AdditionalHeaderDefinition$1.execute (AdditionalHeaderDefinition.java:86)
at com.mycila.xmltool.XMLDoc.forEachChild (XMLDoc.java:86)
at com.mycila.maven.plugin.license.header.AdditionalHeaderDefinition.<init> (AdditionalHeaderDefinition.java:76)
...
Ah never mind, I blinndly copied this comment:
which includes the non-existent property
endLineDetectionPattern
as oppose to the correct lastLineDetectionPattern