[jira] [Created] (RAT-129) Add support for CDDL 1.0

[JIRA]

Francesco Chicchiriccò created RAT-129:
--

 Summary: Add support for CDDL 1.0
 Key: RAT-129
 URL: https://issues.apache.org/jira/browse/RAT-129
 Project: Apache Rat
  Issue Type: Improvement
Reporter: Francesco Chicchiriccò
 Fix For: 0.9
 Attachments: RAT-129.patch

The CDDL 1.0 is not currently supported.
The attached patch adds this feature.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

[jira] [Updated] (RAT-129) Add support for CDDL 1.0

[JIRA]

 [ 
https://issues.apache.org/jira/browse/RAT-129?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Francesco Chicchiriccò updated RAT-129:
---

Attachment: RAT-129.patch

 Add support for CDDL 1.0
 

 Key: RAT-129
 URL: https://issues.apache.org/jira/browse/RAT-129
 Project: Apache Rat
  Issue Type: Improvement
Reporter: Francesco Chicchiriccò
 Fix For: 0.9

 Attachments: RAT-129.patch


 The CDDL 1.0 is not currently supported.
 The attached patch adds this feature.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

[jira] [Comment Edited] (RAT-131) GSOC Refactor Apache Rat Core to a Classic Object Oriented Design

[JIRA]

[ 
https://issues.apache.org/jira/browse/RAT-131?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13628805#comment-13628805
 ] 

Manuel Súarez Sánchez edited comment on RAT-131 at 4/15/13 2:21 PM:


Hello, 

Is this project still available to take up at Google summer of code 2013?? I'm 
interested in this project because I have experience in Agile, skill in Java 
with Testing(I like Q.A), now I´m studying OCPJP(Oracle Certified Professional 
Java Programmer) and in the future I would like to be architect java(For me 
this project it´s great to improve my skill besides I contribute to the open 
source and Google summer of code).

I wait news about it.

  was (Author: elnuma):
Hello, 

Is this project still available to take up at Google summer of code 2013?? I'm 
interested in this project because I have experience in Agile, skill in Java 
with Testing(I like Q.A), now I´m studying OCPJP(Oracle Certified Professional 
Java Programmer) and in the future I would like to be architect java(For me 
this project it´s great to improve my skill besides I contribute to the open 
soure and Google summer of code).

I wait news about it.
  
 GSOC Refactor Apache Rat Core to a Classic Object Oriented Design
 -

 Key: RAT-131
 URL: https://issues.apache.org/jira/browse/RAT-131
 Project: Apache Rat
  Issue Type: Wish
Reporter: Robert Burrell Donkin
  Labels: agile, ddd, gsoc2013, java, test-driven

 The core code for Apache Rat has difficulties which lead to a high bar for 
 contributions:
 * based on an experimental streaming architecture
 * hard to understand
 * poorly covered by edge-to-edge tests
 Replace this by a conventional object-oriented design with clear model based 
 on the domain.
 A good opportunity for a student interested in Agile, test-first approaches 
 and domain-driven design with a good sense of object-oriented design to 
 showcase their skills and learn about open source development. The emphasis 
 would be on high quality, test-driven code driving a clear, well documented 
 design,  

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

[jira] [Updated] (RAT-194) upgrade Doxia (from 1.2) to 1.6

[JIRA]

 [ 
https://issues.apache.org/jira/browse/RAT-194?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Hervé Boutemy updated RAT-194:
--
Attachment: RAT-194.patch

here is patch for Doxia upgrade (along with a little bit of code cleanup)

 upgrade Doxia (from 1.2) to 1.6
 ---

 Key: RAT-194
 URL: https://issues.apache.org/jira/browse/RAT-194
 Project: Apache Rat
  Issue Type: Improvement
  Components: maven
Affects Versions: 0.11
Reporter: Hervé Boutemy
 Fix For: 0.12

 Attachments: RAT-194.patch


 this only will affect Doxia report run as direct mojo invocation, since Doxia 
 is provided by maven-site-plugin when run as a report during site rendering



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Created] (RAT-194) upgrade Doxia (from 1.2) to 1.6

[JIRA]

Hervé Boutemy created RAT-194:
-

 Summary: upgrade Doxia (from 1.2) to 1.6
 Key: RAT-194
 URL: https://issues.apache.org/jira/browse/RAT-194
 Project: Apache Rat
  Issue Type: Improvement
  Components: maven
Affects Versions: 0.11
Reporter: Hervé Boutemy
 Fix For: 0.12


this only will affect Doxia report run as direct mojo invocation, since Doxia 
is provided by maven-site-plugin when run as a report during site rendering



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Commented] (RAT-158) SAXParser warnings

[JIRA]

[ 
https://issues.apache.org/jira/browse/RAT-158?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14321129#comment-14321129
 ] 

Hervé Boutemy commented on RAT-158:
---

Thank you Christopher: you found the cause and immediate workaround!

I opened a Jira issue at Doxia to remove this nasty dependency in Doxia: 
http://jira.codehaus.org/browse/DOXIA-526

It would be nice if next Rat version could implement the workaround, even if 
Doxia is not yet released with the fix at root cause

 SAXParser warnings
 --

 Key: RAT-158
 URL: https://issues.apache.org/jira/browse/RAT-158
 Project: Apache Rat
  Issue Type: Bug
Affects Versions: 0.10
 Environment: Apache Maven 3.0.4
 Maven home: /usr/share/maven
 Java version: 1.6.0_30, vendor: Sun Microsystems Inc.
 Java home: /usr/lib/jvm/java-6-openjdk-amd64/jre
 Default locale: en_US, platform encoding: UTF-8
 OS name: linux, version: 3.11.0-17-generic, arch: amd64, family: unix
Reporter: John Vines
Priority: Minor

 I have rat configured as such
 {code} plugin
  groupIdorg.apache.rat/groupId
  artifactIdapache-rat-plugin/artifactId
  inheritedfalse/inherited
  executions
execution
  phaseverify/phase
  goals
goalcheck/goal
  /goals
/execution
  /executions
  configuration
excludes
  exclude**/conf/**/exclude
/excludes
  /configuration
/plugin
 {code}
 And with every build where it triggers, I see 
 {code}
 Warning:  org.apache.xerces.jaxp.SAXParserImpl$JAXPSAXParser: Property 
 'http://www.oracle.com/xml/jaxp/properties/entityExpansionLimit' is not 
 recognized.
 Warning:  org.apache.xerces.parsers.SAXParser: Feature 
 'http://javax.xml.XMLConstants/feature/secure-processing' is not recognized.
 Warning:  org.apache.xerces.parsers.SAXParser: Property 
 'http://www.oracle.com/xml/jaxp/properties/entityExpansionLimit' is not 
 recognized.
 {code}



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Commented] (RAT-158) SAXParser warnings

[JIRA]

[ 
https://issues.apache.org/jira/browse/RAT-158?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14321141#comment-14321141
 ] 

Hervé Boutemy commented on RAT-158:
---

notice the workaround is now part of the future asf parent pom version 17: see 
MPOM-69

 SAXParser warnings
 --

 Key: RAT-158
 URL: https://issues.apache.org/jira/browse/RAT-158
 Project: Apache Rat
  Issue Type: Bug
Affects Versions: 0.10
 Environment: Apache Maven 3.0.4
 Maven home: /usr/share/maven
 Java version: 1.6.0_30, vendor: Sun Microsystems Inc.
 Java home: /usr/lib/jvm/java-6-openjdk-amd64/jre
 Default locale: en_US, platform encoding: UTF-8
 OS name: linux, version: 3.11.0-17-generic, arch: amd64, family: unix
Reporter: John Vines
Priority: Minor

 I have rat configured as such
 {code} plugin
  groupIdorg.apache.rat/groupId
  artifactIdapache-rat-plugin/artifactId
  inheritedfalse/inherited
  executions
execution
  phaseverify/phase
  goals
goalcheck/goal
  /goals
/execution
  /executions
  configuration
excludes
  exclude**/conf/**/exclude
/excludes
  /configuration
/plugin
 {code}
 And with every build where it triggers, I see 
 {code}
 Warning:  org.apache.xerces.jaxp.SAXParserImpl$JAXPSAXParser: Property 
 'http://www.oracle.com/xml/jaxp/properties/entityExpansionLimit' is not 
 recognized.
 Warning:  org.apache.xerces.parsers.SAXParser: Feature 
 'http://javax.xml.XMLConstants/feature/secure-processing' is not recognized.
 Warning:  org.apache.xerces.parsers.SAXParser: Property 
 'http://www.oracle.com/xml/jaxp/properties/entityExpansionLimit' is not 
 recognized.
 {code}



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Commented] (RAT-158) SAXParser warnings

[JIRA]

[ 
https://issues.apache.org/jira/browse/RAT-158?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14322057#comment-14322057
 ] 

Hervé Boutemy commented on RAT-158:
---

Doxia doesn't have much activity these time
and looking at Rat and Doxia roadmaps in respective Jira, I hope for Rat that 
there will be a Rat release before Doxia release :)

 SAXParser warnings
 --

 Key: RAT-158
 URL: https://issues.apache.org/jira/browse/RAT-158
 Project: Apache Rat
  Issue Type: Bug
Affects Versions: 0.10
 Environment: Apache Maven 3.0.4
 Maven home: /usr/share/maven
 Java version: 1.6.0_30, vendor: Sun Microsystems Inc.
 Java home: /usr/lib/jvm/java-6-openjdk-amd64/jre
 Default locale: en_US, platform encoding: UTF-8
 OS name: linux, version: 3.11.0-17-generic, arch: amd64, family: unix
Reporter: John Vines
Assignee: Philipp Ottlinger
Priority: Minor
 Attachments: RAT-158.patch


 I have rat configured as such
 {code} plugin
  groupIdorg.apache.rat/groupId
  artifactIdapache-rat-plugin/artifactId
  inheritedfalse/inherited
  executions
execution
  phaseverify/phase
  goals
goalcheck/goal
  /goals
/execution
  /executions
  configuration
excludes
  exclude**/conf/**/exclude
/excludes
  /configuration
/plugin
 {code}
 And with every build where it triggers, I see 
 {code}
 Warning:  org.apache.xerces.jaxp.SAXParserImpl$JAXPSAXParser: Property 
 'http://www.oracle.com/xml/jaxp/properties/entityExpansionLimit' is not 
 recognized.
 Warning:  org.apache.xerces.parsers.SAXParser: Feature 
 'http://javax.xml.XMLConstants/feature/secure-processing' is not recognized.
 Warning:  org.apache.xerces.parsers.SAXParser: Property 
 'http://www.oracle.com/xml/jaxp/properties/entityExpansionLimit' is not 
 recognized.
 {code}



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Commented] (RAT-242) Encoding of XML report

[JIRA]

[ 
https://issues.apache.org/jira/browse/RAT-242?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16314689#comment-16314689
 ] 

Matthias Bläsing commented on RAT-242:
--

Further information: you asked for an apache ICLA. I can confirm, that an ICLA 
is filed.

> Encoding of XML report
> --
>
> Key: RAT-242
> URL: https://issues.apache.org/jira/browse/RAT-242
> Project: Apache Rat
>  Issue Type: Bug
>  Components: reports
>Affects Versions: 0.12
> Environment: ubuntu
>Reporter: Eric Barboni
> Attachments: rat-242.patch
>
>
> Hi, we encounter an issue with encoding of a xml rat report. 
> We try to parse an xml rat report generated on an iso-8859-1 file system. The 
> xml has no encoding element in the prolog. If you open it with fileinpustream 
> it may fail.
> last comment in this pull request 
> (https://github.com/apache/incubator-netbeans/pull/70)  by Matthias Bläsing  
> suggest forcing to UTF-8.
> encoding  may also be an option in the report task
> Regards



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

[jira] [Commented] (RAT-242) Encoding of XML report

[JIRA]

[ 
https://issues.apache.org/jira/browse/RAT-242?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16325667#comment-16325667
 ] 

Matthias Bläsing commented on RAT-242:
--

I tried to reproduce the test failure and totally failed. I switched JDKs, 
Maven versions and system locales and nothing changed. The build runs cleanly. 
I checked the test files and both contain the the right ISO-8859-1 encoding 
umlauts. I suggest to modify the test to output the header-sample content like 
this:

{noformat}
matthias@athena:~/src/creadur-rat-svn$ svn diff
Index: apache-rat-plugin/src/test/java/org/apache/rat/mp/RatCheckMojoTest.java
===
--- apache-rat-plugin/src/test/java/org/apache/rat/mp/RatCheckMojoTest.java 
(Revision 182)
+++ apache-rat-plugin/src/test/java/org/apache/rat/mp/RatCheckMojoTest.java 
(Arbeitskopie)
@@ -238,11 +238,12 @@
 boolean documentParsed = false;
 try {
 Document doc = db.parse(fis);
-boolean byteSequencePresent = 
doc.getElementsByTagName("header-sample")
+String headerSample = doc.getElementsByTagName("header-sample")
 .item(0)
-.getTextContent()
+.getTextContent();
+boolean byteSequencePresent = headerSample
 .contains("\u00E4\u00F6\u00FC\u00C4\u00D6\u00DC\u00DF");
-assertTrue("Report should contain test umlauts", 
byteSequencePresent);
+assertTrue("header-sample should contain test umlauts: " + 
headerSample, byteSequencePresent);
 documentParsed = true;
 } catch (Exception ex) {
 documentParsed = false;
matthias@athena:~/src/creadur-rat-svn$ 
{noformat}

Maybe that reveals something.

> Encoding of XML report
> --
>
> Key: RAT-242
> URL: https://issues.apache.org/jira/browse/RAT-242
> Project: Apache Rat
>  Issue Type: Bug
>  Components: reports
>Affects Versions: 0.12
> Environment: ubuntu
>Reporter: Eric Barboni
> Attachments: rat-242.patch
>
>
> Hi, we encounter an issue with encoding of a xml rat report. 
> We try to parse an xml rat report generated on an iso-8859-1 file system. The 
> xml has no encoding element in the prolog. If you open it with fileinpustream 
> it may fail.
> last comment in this pull request 
> (https://github.com/apache/incubator-netbeans/pull/70)  by Matthias Bläsing  
> suggest forcing to UTF-8.
> encoding  may also be an option in the report task
> Regards



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

[jira] [Commented] (RAT-242) Encoding of XML report

[JIRA]

[ 
https://issues.apache.org/jira/browse/RAT-242?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16325182#comment-16325182
 ] 

Matthias Bläsing commented on RAT-242:
--

Philipp thank you for merging the patch. I checked the current state in the 
subversion and found the new unittests failing. I tracked it down to a followup 
commit in revision 1821058, that modifies

apache-rat-tasks/src/test/resources/org/example/iso-8859-1.html

and adds a license header to this file. The license header must not be there, 
as the whole point of this file is to cause the rat test in the unittests to 
fail and report the encoded header.

Your commit message mentions failing jenkis build. Could it be, that there is a 
rat check in place, that now fails, because there are two files in the 
repository that don't hold a valid license:

./apache-rat-plugin/src/test/resources/unit/it4/iso-8859-1.html
./apache-rat-tasks/src/test/resources/org/example/iso-8859-1.html

Could you point me to the jenkins build report, I'd like to have a look at it, 
to finally fix this.

> Encoding of XML report
> --
>
> Key: RAT-242
> URL: https://issues.apache.org/jira/browse/RAT-242
> Project: Apache Rat
>  Issue Type: Bug
>  Components: reports
>Affects Versions: 0.12
> Environment: ubuntu
>Reporter: Eric Barboni
> Attachments: rat-242.patch
>
>
> Hi, we encounter an issue with encoding of a xml rat report. 
> We try to parse an xml rat report generated on an iso-8859-1 file system. The 
> xml has no encoding element in the prolog. If you open it with fileinpustream 
> it may fail.
> last comment in this pull request 
> (https://github.com/apache/incubator-netbeans/pull/70)  by Matthias Bläsing  
> suggest forcing to UTF-8.
> encoding  may also be an option in the report task
> Regards



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

[jira] [Commented] (RAT-242) Encoding of XML report

[JIRA]

[ 
https://issues.apache.org/jira/browse/RAT-242?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16340241#comment-16340241
 ] 

Matthias Bläsing commented on RAT-242:
--

I had another look at it and the unittests currently run correctly. I suggest 
to close this for now and reopen/contact me if it surfaces again. For the 
record things that could go wrong:
 * the JVM could deny access to the system properties and thus the needed 
latin1 encoding can't be set for the invocation of the test (should raise an 
exception)
 * parallel test runs (threaded in the same VM) would also expose the unittests 
to race conditions (the default encoding is set VM wide)
 * different VM implementations could use different fields/caching strategies 
for the default file encoding (I'd expect an exception then)
 * JVM might not make the field accessible (relevant for JDK 9), should also 
raise an exception

I hoped to get some more insight, but from the look all should be good.

> Encoding of XML report
> --
>
> Key: RAT-242
> URL: https://issues.apache.org/jira/browse/RAT-242
> Project: Apache Rat
>  Issue Type: Bug
>  Components: reports
>Affects Versions: 0.12
> Environment: ubuntu
>Reporter: Eric Barboni
>Priority: Major
> Attachments: rat-242.patch
>
>
> Hi, we encounter an issue with encoding of a xml rat report. 
> We try to parse an xml rat report generated on an iso-8859-1 file system. The 
> xml has no encoding element in the prolog. If you open it with fileinpustream 
> it may fail.
> last comment in this pull request 
> (https://github.com/apache/incubator-netbeans/pull/70)  by Matthias Bläsing  
> suggest forcing to UTF-8.
> encoding  may also be an option in the report task
> Regards



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

[jira] [Commented] (RAT-265) Wildcard file filter do not work anymore

[Jira]

[ 
https://issues.apache.org/jira/browse/RAT-265?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16980874#comment-16980874
 ] 

Raphael von der Grün commented on RAT-265:
--

No, we cannot. We use it as a part of the release process of Apache Cordova 
which is all Node.js. So Maven makes no sense in our case.

> Wildcard file filter do not work anymore
> 
>
> Key: RAT-265
> URL: https://issues.apache.org/jira/browse/RAT-265
> Project: Apache Rat
>  Issue Type: Bug
>  Components: cli
>Affects Versions: 0.13, 0.14
>Reporter: Raphael von der Grün
>Priority: Major
>
> Run the following command in the root of the `rat` repo:
> {noformat}
> java -jar apache-rat-0.14-20191120.132901-66.jar -e "*.txt" -d 
> apache-rat-core/src/test/resources/violations/bad.txt{noformat}
> This will give the following output on `stderr`: 
> {noformat}
> Will skip given exclusion '*.txt' due to 
> java.util.regex.PatternSyntaxException: Dangling meta character '*' near 
> index 0
> *.txt
> ^
> {noformat}
> Furthermore, `bad.txt` will NOT be excluded from the license check.
> The error that causes this is thrown in [line 132 of 
> `org.apache.rat.Report.java`|#L132]]. The reason is simple: any glob pattern 
> that starts with `*` or `?` is not a valid regex. When Line 132 throws, the 
> next two lines will also be skipped, so the pattern will not be added at all.
> Unfortunately, a solution to this problem is not so simple. In `v0.12` the 
> `-e` option always added wildcard filters while `-E` always added regex 
> filters. The documentation still states the same in the latest `v0.14` 
> snapshot. Beginning with `v0.13` the code tries to add any exclude rule as 
> three different filters. I believe this approach is inherently flawed.
> Firstly, the `new NameFileFilter(exclusion)` is redundant if we also add `new 
> WildcardFileFilter(exclusion)`. The files matched by the `NameFileFilter` are 
> a subset of those matched by the `WildcardFileFilter` since any magic 
> character (i.e. `?` or `*`) in `exclusion` also matches itself when used in a 
> `WildcardFileFilter`.
> So let's assume we only register the `WildcardFileFilter` and the 
> `RegexFileFilter`. Even if we properly add patterns as wildcard filters that 
> are not a valid RegEx, there are still patterns where we cannot decide what 
> the user's intention was. Consider the pattern `bi.ini`. Should it be 
> interpreted as a wildcard pattern and match only itself or should it be 
> interpreted as a regex and also match `bikini` for example?
> My recommendation for a quick patch solution would be to go back to the 
> behavior of `v0.12`.
> Beyond that, the nicest solution IMHO would be support for ignore files with 
> the same semantics as `.gitignore` (via `-E`) and support for giving extended 
> shell globs via `-e`.



--
This message was sent by Atlassian Jira
(v8.3.4#803005)

[jira] [Comment Edited] (RAT-265) Wildcard file filter do not work anymore

[Jira]

[ 
https://issues.apache.org/jira/browse/RAT-265?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16980874#comment-16980874
 ] 

Raphael von der Grün edited comment on RAT-265 at 11/23/19 8:43 PM:


Unfortunately we cannot. We use it as a part of the release process of Apache 
Cordova which is all Node.js. So Maven makes no sense in our case.


was (Author: raphinesse):
No, we cannot. We use it as a part of the release process of Apache Cordova 
which is all Node.js. So Maven makes no sense in our case.

> Wildcard file filter do not work anymore
> 
>
> Key: RAT-265
> URL: https://issues.apache.org/jira/browse/RAT-265
> Project: Apache Rat
>  Issue Type: Bug
>  Components: cli
>Affects Versions: 0.13, 0.14
>Reporter: Raphael von der Grün
>Priority: Major
>
> Run the following command in the root of the `rat` repo:
> {noformat}
> java -jar apache-rat-0.14-20191120.132901-66.jar -e "*.txt" -d 
> apache-rat-core/src/test/resources/violations/bad.txt{noformat}
> This will give the following output on `stderr`: 
> {noformat}
> Will skip given exclusion '*.txt' due to 
> java.util.regex.PatternSyntaxException: Dangling meta character '*' near 
> index 0
> *.txt
> ^
> {noformat}
> Furthermore, `bad.txt` will NOT be excluded from the license check.
> The error that causes this is thrown in [line 132 of 
> `org.apache.rat.Report.java`|#L132]]. The reason is simple: any glob pattern 
> that starts with `*` or `?` is not a valid regex. When Line 132 throws, the 
> next two lines will also be skipped, so the pattern will not be added at all.
> Unfortunately, a solution to this problem is not so simple. In `v0.12` the 
> `-e` option always added wildcard filters while `-E` always added regex 
> filters. The documentation still states the same in the latest `v0.14` 
> snapshot. Beginning with `v0.13` the code tries to add any exclude rule as 
> three different filters. I believe this approach is inherently flawed.
> Firstly, the `new NameFileFilter(exclusion)` is redundant if we also add `new 
> WildcardFileFilter(exclusion)`. The files matched by the `NameFileFilter` are 
> a subset of those matched by the `WildcardFileFilter` since any magic 
> character (i.e. `?` or `*`) in `exclusion` also matches itself when used in a 
> `WildcardFileFilter`.
> So let's assume we only register the `WildcardFileFilter` and the 
> `RegexFileFilter`. Even if we properly add patterns as wildcard filters that 
> are not a valid RegEx, there are still patterns where we cannot decide what 
> the user's intention was. Consider the pattern `bi.ini`. Should it be 
> interpreted as a wildcard pattern and match only itself or should it be 
> interpreted as a regex and also match `bikini` for example?
> My recommendation for a quick patch solution would be to go back to the 
> behavior of `v0.12`.
> Beyond that, the nicest solution IMHO would be support for ignore files with 
> the same semantics as `.gitignore` (via `-E`) and support for giving extended 
> shell globs via `-e`.



--
This message was sent by Atlassian Jira
(v8.3.4#803005)

[jira] [Comment Edited] (RAT-265) Wildcard file filter do not work anymore

[Jira]

[ 
https://issues.apache.org/jira/browse/RAT-265?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16980874#comment-16980874
 ] 

Raphael von der Grün edited comment on RAT-265 at 11/23/19 8:45 PM:


Unfortunately we cannot. We use it as a part of the release process of Apache 
Cordova which is all Node.js. So Maven makes no sense in our case.

I will downgrade our process to use v0.12 again, for the time being.


was (Author: raphinesse):
Unfortunately we cannot. We use it as a part of the release process of Apache 
Cordova which is all Node.js. So Maven makes no sense in our case.

I will downgrade our process to use 0.12 for the time being.

> Wildcard file filter do not work anymore
> 
>
> Key: RAT-265
> URL: https://issues.apache.org/jira/browse/RAT-265
> Project: Apache Rat
>  Issue Type: Bug
>  Components: cli
>Affects Versions: 0.13, 0.14
>Reporter: Raphael von der Grün
>Priority: Major
>
> Run the following command in the root of the `rat` repo:
> {noformat}
> java -jar apache-rat-0.14-20191120.132901-66.jar -e "*.txt" -d 
> apache-rat-core/src/test/resources/violations/bad.txt{noformat}
> This will give the following output on `stderr`: 
> {noformat}
> Will skip given exclusion '*.txt' due to 
> java.util.regex.PatternSyntaxException: Dangling meta character '*' near 
> index 0
> *.txt
> ^
> {noformat}
> Furthermore, `bad.txt` will NOT be excluded from the license check.
> The error that causes this is thrown in [line 132 of 
> `org.apache.rat.Report.java`|#L132]]. The reason is simple: any glob pattern 
> that starts with `*` or `?` is not a valid regex. When Line 132 throws, the 
> next two lines will also be skipped, so the pattern will not be added at all.
> Unfortunately, a solution to this problem is not so simple. In `v0.12` the 
> `-e` option always added wildcard filters while `-E` always added regex 
> filters. The documentation still states the same in the latest `v0.14` 
> snapshot. Beginning with `v0.13` the code tries to add any exclude rule as 
> three different filters. I believe this approach is inherently flawed.
> Firstly, the `new NameFileFilter(exclusion)` is redundant if we also add `new 
> WildcardFileFilter(exclusion)`. The files matched by the `NameFileFilter` are 
> a subset of those matched by the `WildcardFileFilter` since any magic 
> character (i.e. `?` or `*`) in `exclusion` also matches itself when used in a 
> `WildcardFileFilter`.
> So let's assume we only register the `WildcardFileFilter` and the 
> `RegexFileFilter`. Even if we properly add patterns as wildcard filters that 
> are not a valid RegEx, there are still patterns where we cannot decide what 
> the user's intention was. Consider the pattern `bi.ini`. Should it be 
> interpreted as a wildcard pattern and match only itself or should it be 
> interpreted as a regex and also match `bikini` for example?
> My recommendation for a quick patch solution would be to go back to the 
> behavior of `v0.12`.
> Beyond that, the nicest solution IMHO would be support for ignore files with 
> the same semantics as `.gitignore` (via `-E`) and support for giving extended 
> shell globs via `-e`.



--
This message was sent by Atlassian Jira
(v8.3.4#803005)

[jira] [Comment Edited] (RAT-265) Wildcard file filter do not work anymore

[Jira]

[ 
https://issues.apache.org/jira/browse/RAT-265?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16980874#comment-16980874
 ] 

Raphael von der Grün edited comment on RAT-265 at 11/23/19 8:45 PM:


Unfortunately we cannot. We use it as a part of the release process of Apache 
Cordova which is all Node.js. So Maven makes no sense in our case.

I will downgrade our process to use 0.12 for the time being.


was (Author: raphinesse):
Unfortunately we cannot. We use it as a part of the release process of Apache 
Cordova which is all Node.js. So Maven makes no sense in our case.

> Wildcard file filter do not work anymore
> 
>
> Key: RAT-265
> URL: https://issues.apache.org/jira/browse/RAT-265
> Project: Apache Rat
>  Issue Type: Bug
>  Components: cli
>Affects Versions: 0.13, 0.14
>Reporter: Raphael von der Grün
>Priority: Major
>
> Run the following command in the root of the `rat` repo:
> {noformat}
> java -jar apache-rat-0.14-20191120.132901-66.jar -e "*.txt" -d 
> apache-rat-core/src/test/resources/violations/bad.txt{noformat}
> This will give the following output on `stderr`: 
> {noformat}
> Will skip given exclusion '*.txt' due to 
> java.util.regex.PatternSyntaxException: Dangling meta character '*' near 
> index 0
> *.txt
> ^
> {noformat}
> Furthermore, `bad.txt` will NOT be excluded from the license check.
> The error that causes this is thrown in [line 132 of 
> `org.apache.rat.Report.java`|#L132]]. The reason is simple: any glob pattern 
> that starts with `*` or `?` is not a valid regex. When Line 132 throws, the 
> next two lines will also be skipped, so the pattern will not be added at all.
> Unfortunately, a solution to this problem is not so simple. In `v0.12` the 
> `-e` option always added wildcard filters while `-E` always added regex 
> filters. The documentation still states the same in the latest `v0.14` 
> snapshot. Beginning with `v0.13` the code tries to add any exclude rule as 
> three different filters. I believe this approach is inherently flawed.
> Firstly, the `new NameFileFilter(exclusion)` is redundant if we also add `new 
> WildcardFileFilter(exclusion)`. The files matched by the `NameFileFilter` are 
> a subset of those matched by the `WildcardFileFilter` since any magic 
> character (i.e. `?` or `*`) in `exclusion` also matches itself when used in a 
> `WildcardFileFilter`.
> So let's assume we only register the `WildcardFileFilter` and the 
> `RegexFileFilter`. Even if we properly add patterns as wildcard filters that 
> are not a valid RegEx, there are still patterns where we cannot decide what 
> the user's intention was. Consider the pattern `bi.ini`. Should it be 
> interpreted as a wildcard pattern and match only itself or should it be 
> interpreted as a regex and also match `bikini` for example?
> My recommendation for a quick patch solution would be to go back to the 
> behavior of `v0.12`.
> Beyond that, the nicest solution IMHO would be support for ignore files with 
> the same semantics as `.gitignore` (via `-E`) and support for giving extended 
> shell globs via `-e`.



--
This message was sent by Atlassian Jira
(v8.3.4#803005)

[jira] [Updated] (RAT-265) Wildcard file filter do not work anymore

[Jira]

 [ 
https://issues.apache.org/jira/browse/RAT-265?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Raphael von der Grün updated RAT-265:
-
Description: 
Run the following command in the root of the `rat` repo:
{noformat}
java -jar apache-rat-0.14-20191120.132901-66.jar -e "*.txt" -d 
apache-rat-core/src/test/resources/violations/bad.txt{noformat}
This will give the following output on `stderr`: 
{noformat}
Will skip given exclusion '*.txt' due to 
java.util.regex.PatternSyntaxException: Dangling meta character '*' near index 0
*.txt
^
{noformat}
Furthermore, `bad.txt` will NOT be excluded from the license check.

The error that causes this is thrown in [line 132 of 
`org.apache.rat.Report.java`|#L132]]. The reason is simple: any glob pattern 
that starts with `*` or `?` is not a valid regex. When Line 132 throws, the 
next two lines will also be skipped, so the pattern will not be added at all.

Unfortunately, a solution to this problem is not so simple. In `v0.12` the `-e` 
option always added wildcard filters while `-E` always added regex filters. The 
documentation still states the same in the latest `v0.14` snapshot. Beginning 
with `v0.13` the code tries to add any exclude rule as three different filters. 
I believe this approach is inherently flawed.

Firstly, the `new NameFileFilter(exclusion)` is redundant if we also add `new 
WildcardFileFilter(exclusion)`. The files matched by the `NameFileFilter` are a 
subset of those matched by the `WildcardFileFilter` since any magic character 
(i.e. `?` or `*`) in `exclusion` also matches itself when used in a 
`WildcardFileFilter`.

So let's assume we only register the `WildcardFileFilter` and the 
`RegexFileFilter`. Even if we properly add patterns as wildcard filters that 
are not a valid RegEx, there are still patterns where we cannot decide what the 
user's intention was. Consider the pattern `bi.ini`. Should it be interpreted 
as a wildcard pattern and match only itself or should it be interpreted as a 
regex and also match `bikini` for example?

My recommendation for a quick patch solution would be to go back to the 
behavior of `v0.12`.

Beyond that, the nicest solution IMHO would be support for ignore files with 
the same semantics as `.gitignore` (via `-E`) and support for giving extended 
shell globs via `-e`.

  was:
Run the following command in the root of the `rat` repo:

 
{noformat}
java -jar apache-rat-0.14-20191120.132901-66.jar -e "*.txt" -d 
apache-rat-core/src/test/resources/violations/bad.txt{noformat}
This will give the following output on `stderr`:

 

 
{noformat}
Will skip given exclusion '*.txt' due to 
java.util.regex.PatternSyntaxException: Dangling meta character '*' near index 0
*.txt
^
{noformat}
Furthermore, `bad.txt` will NOT be excluded from the license check.

 

The error that causes this is thrown in [line 132 of 
`org.apache.rat.Report.java`|[https://github.com/apache/creadur-rat/blob/b271d7ff1bfa1b919fe0ed1e89d8831b30c42750/apache-rat-core/src/main/java/org/apache/rat/Report.java#L132]].
 The reason is simple: any glob pattern that starts with `*` or `?` is not a 
valid regex. When Line 132 throws, the next two lines will also be skipped, so 
the pattern will not be added at all.

Unfortunately, a solution to this problem is not so simple. In `v0.12` the `-e` 
option always added wildcard filters while `-E` always added regex filters. The 
documentation still states the same in the latest `v0.14` snapshot. Beginning 
with `v0.13` the code tries to add any exclude rule as three different filters. 
I believe this approach is inherently flawed.

Firstly, the `new NameFileFilter(exclusion)` is redundant if we also add `new 
WildcardFileFilter(exclusion)`. The files matched by the `NameFileFilter` are a 
subset of those matched by the `WildcardFileFilter` since any magic character 
(i.e. `?` or `*`) in `exclusion` also matches itself when used in a 
`WildcardFileFilter`.

So let's assume we only register the `WildcardFileFilter` and the 
`RegexFileFilter`. Even if we properly add patterns as wildcard filters that 
are not a valid RegEx, there are still patterns where we cannot decide what the 
user's intention was. Consider the pattern `bi.ini`. Should it be interpreted 
as a wildcard pattern and match only itself or should it be interpreted as a 
regex and also match `bikini` for example?

My recommendation for a quick patch solution would be to go back to the 
behavior of `v0.12`.

Beyond that, the nicest solution IMHO would be support for ignore files with 
the same semantics as `.gitignore` (via `-E`) and support for giving extended 
shell globs via `-e`.


> Wildcard file filter do not work anymore
> 
>
> Key: RAT-265
> URL: https://issues.apache.org/jira/browse/RAT-265
> Project: Apache Rat
>  Issue Type: Bug
>   

[jira] [Created] (RAT-265) Wildcard file filter do not work anymore

[Jira]

Raphael von der Grün created RAT-265:


 Summary: Wildcard file filter do not work anymore
 Key: RAT-265
 URL: https://issues.apache.org/jira/browse/RAT-265
 Project: Apache Rat
  Issue Type: Bug
  Components: cli
Affects Versions: 0.13, 0.14
Reporter: Raphael von der Grün


Run the following command in the root of the `rat` repo:

 
{noformat}
java -jar apache-rat-0.14-20191120.132901-66.jar -e "*.txt" -d 
apache-rat-core/src/test/resources/violations/bad.txt{noformat}
This will give the following output on `stderr`:

 

 
{noformat}
Will skip given exclusion '*.txt' due to 
java.util.regex.PatternSyntaxException: Dangling meta character '*' near index 0
*.txt
^
{noformat}
Furthermore, `bad.txt` will NOT be excluded from the license check.

 

The error that causes this is thrown in [line 132 of 
`org.apache.rat.Report.java`|[https://github.com/apache/creadur-rat/blob/b271d7ff1bfa1b919fe0ed1e89d8831b30c42750/apache-rat-core/src/main/java/org/apache/rat/Report.java#L132]].
 The reason is simple: any glob pattern that starts with `*` or `?` is not a 
valid regex. When Line 132 throws, the next two lines will also be skipped, so 
the pattern will not be added at all.

Unfortunately, a solution to this problem is not so simple. In `v0.12` the `-e` 
option always added wildcard filters while `-E` always added regex filters. The 
documentation still states the same in the latest `v0.14` snapshot. Beginning 
with `v0.13` the code tries to add any exclude rule as three different filters. 
I believe this approach is inherently flawed.

Firstly, the `new NameFileFilter(exclusion)` is redundant if we also add `new 
WildcardFileFilter(exclusion)`. The files matched by the `NameFileFilter` are a 
subset of those matched by the `WildcardFileFilter` since any magic character 
(i.e. `?` or `*`) in `exclusion` also matches itself when used in a 
`WildcardFileFilter`.

So let's assume we only register the `WildcardFileFilter` and the 
`RegexFileFilter`. Even if we properly add patterns as wildcard filters that 
are not a valid RegEx, there are still patterns where we cannot decide what the 
user's intention was. Consider the pattern `bi.ini`. Should it be interpreted 
as a wildcard pattern and match only itself or should it be interpreted as a 
regex and also match `bikini` for example?

My recommendation for a quick patch solution would be to go back to the 
behavior of `v0.12`.

Beyond that, the nicest solution IMHO would be support for ignore files with 
the same semantics as `.gitignore` (via `-E`) and support for giving extended 
shell globs via `-e`.



--
This message was sent by Atlassian Jira
(v8.3.4#803005)

[jira] [Updated] (RAT-265) Certain wildcard file filters do not work anymore

[Jira]

 [ 
https://issues.apache.org/jira/browse/RAT-265?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Raphael von der Grün updated RAT-265:
-
Description: 
Run the following command in the root of the `rat` repo:
{noformat}
java -jar apache-rat-0.14-20191120.132901-66.jar -e "*.txt" -d 
apache-rat-core/src/test/resources/violations/bad.txt{noformat}
This will give the following output on `stderr`: 
{noformat}
Will skip given exclusion '*.txt' due to 
java.util.regex.PatternSyntaxException: Dangling meta character '*' near index 0
*.txt
^
{noformat}
Furthermore, `bad.txt` will NOT be excluded from the license check.

The error that causes this is thrown in [line 132 of 
`org.apache.rat.Report.java`|#L132]]. The reason is simple: any glob pattern 
that starts with `*` or `?` is not a valid regex. When Line 132 throws, the 
next two lines will also be skipped, so the pattern will not be added at all.

Unfortunately, a solution to this problem is not so simple. In `v0.12` the `-e` 
option always added wildcard filters while `-E` always added regex filters. The 
documentation still states the same in the latest `v0.14` snapshot. Beginning 
with `v0.13` the code tries to add any exclude rule as three different filters. 
I believe this approach is inherently flawed.

Firstly, the `new NameFileFilter(exclusion)` is redundant if we also add `new 
WildcardFileFilter(exclusion)`. The files matched by the `NameFileFilter` are a 
subset of those matched by the `WildcardFileFilter` since any magic character 
(i.e. `?` or `*`) in `exclusion` also matches itself when used in a 
`WildcardFileFilter`.

So let's assume we only register the `WildcardFileFilter` and the 
`RegexFileFilter`. Even if we properly add patterns as wildcard filters that 
are not a valid RegEx, there are still patterns where we cannot decide what the 
user's intention was. Consider the pattern `bi.ini`. Should it be interpreted 
as a wildcard pattern and match only itself or should it be interpreted as a 
regex and also match `bikini` for example?

My recommendation for a quick patch solution would be to go back to the 
exclusion behavior of `v0.12`.

Beyond that, the nicest solution IMHO would be support for ignore files with 
the same semantics as `.gitignore` (via `-E`) and support for giving extended 
shell globs via `-e`.

  was:
Run the following command in the root of the `rat` repo:
{noformat}
java -jar apache-rat-0.14-20191120.132901-66.jar -e "*.txt" -d 
apache-rat-core/src/test/resources/violations/bad.txt{noformat}
This will give the following output on `stderr`: 
{noformat}
Will skip given exclusion '*.txt' due to 
java.util.regex.PatternSyntaxException: Dangling meta character '*' near index 0
*.txt
^
{noformat}
Furthermore, `bad.txt` will NOT be excluded from the license check.

The error that causes this is thrown in [line 132 of 
`org.apache.rat.Report.java`|#L132]]. The reason is simple: any glob pattern 
that starts with `*` or `?` is not a valid regex. When Line 132 throws, the 
next two lines will also be skipped, so the pattern will not be added at all.

Unfortunately, a solution to this problem is not so simple. In `v0.12` the `-e` 
option always added wildcard filters while `-E` always added regex filters. The 
documentation still states the same in the latest `v0.14` snapshot. Beginning 
with `v0.13` the code tries to add any exclude rule as three different filters. 
I believe this approach is inherently flawed.

Firstly, the `new NameFileFilter(exclusion)` is redundant if we also add `new 
WildcardFileFilter(exclusion)`. The files matched by the `NameFileFilter` are a 
subset of those matched by the `WildcardFileFilter` since any magic character 
(i.e. `?` or `*`) in `exclusion` also matches itself when used in a 
`WildcardFileFilter`.

So let's assume we only register the `WildcardFileFilter` and the 
`RegexFileFilter`. Even if we properly add patterns as wildcard filters that 
are not a valid RegEx, there are still patterns where we cannot decide what the 
user's intention was. Consider the pattern `bi.ini`. Should it be interpreted 
as a wildcard pattern and match only itself or should it be interpreted as a 
regex and also match `bikini` for example?

My recommendation for a quick patch solution would be to go back to the 
behavior of `v0.12`.

Beyond that, the nicest solution IMHO would be support for ignore files with 
the same semantics as `.gitignore` (via `-E`) and support for giving extended 
shell globs via `-e`.


> Certain wildcard file filters do not work anymore
> -
>
> Key: RAT-265
> URL: https://issues.apache.org/jira/browse/RAT-265
> Project: Apache Rat
>  Issue Type: Bug
>  Components: cli
>Affects Versions: 0.13, 0.14
>Reporter: Raphael von der Grün
>Prio

[jira] [Updated] (RAT-265) Certain wildcard file filters do not work anymore

[Jira]

 [ 
https://issues.apache.org/jira/browse/RAT-265?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Raphael von der Grün updated RAT-265:
-
Summary: Certain wildcard file filters do not work anymore  (was: Wildcard 
file filter do not work anymore)

> Certain wildcard file filters do not work anymore
> -
>
> Key: RAT-265
> URL: https://issues.apache.org/jira/browse/RAT-265
> Project: Apache Rat
>  Issue Type: Bug
>  Components: cli
>Affects Versions: 0.13, 0.14
>Reporter: Raphael von der Grün
>Priority: Major
>
> Run the following command in the root of the `rat` repo:
> {noformat}
> java -jar apache-rat-0.14-20191120.132901-66.jar -e "*.txt" -d 
> apache-rat-core/src/test/resources/violations/bad.txt{noformat}
> This will give the following output on `stderr`: 
> {noformat}
> Will skip given exclusion '*.txt' due to 
> java.util.regex.PatternSyntaxException: Dangling meta character '*' near 
> index 0
> *.txt
> ^
> {noformat}
> Furthermore, `bad.txt` will NOT be excluded from the license check.
> The error that causes this is thrown in [line 132 of 
> `org.apache.rat.Report.java`|#L132]]. The reason is simple: any glob pattern 
> that starts with `*` or `?` is not a valid regex. When Line 132 throws, the 
> next two lines will also be skipped, so the pattern will not be added at all.
> Unfortunately, a solution to this problem is not so simple. In `v0.12` the 
> `-e` option always added wildcard filters while `-E` always added regex 
> filters. The documentation still states the same in the latest `v0.14` 
> snapshot. Beginning with `v0.13` the code tries to add any exclude rule as 
> three different filters. I believe this approach is inherently flawed.
> Firstly, the `new NameFileFilter(exclusion)` is redundant if we also add `new 
> WildcardFileFilter(exclusion)`. The files matched by the `NameFileFilter` are 
> a subset of those matched by the `WildcardFileFilter` since any magic 
> character (i.e. `?` or `*`) in `exclusion` also matches itself when used in a 
> `WildcardFileFilter`.
> So let's assume we only register the `WildcardFileFilter` and the 
> `RegexFileFilter`. Even if we properly add patterns as wildcard filters that 
> are not a valid RegEx, there are still patterns where we cannot decide what 
> the user's intention was. Consider the pattern `bi.ini`. Should it be 
> interpreted as a wildcard pattern and match only itself or should it be 
> interpreted as a regex and also match `bikini` for example?
> My recommendation for a quick patch solution would be to go back to the 
> behavior of `v0.12`.
> Beyond that, the nicest solution IMHO would be support for ignore files with 
> the same semantics as `.gitignore` (via `-E`) and support for giving extended 
> shell globs via `-e`.



--
This message was sent by Atlassian Jira
(v8.3.4#803005)

[jira] [Commented] (RAT-265) CLI: Certain wildcard file filters do not work anymore

[Jira]

[ 
https://issues.apache.org/jira/browse/RAT-265?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16980887#comment-16980887
 ] 

Raphael von der Grün commented on RAT-265:
--

Thanks for looking into this. I'm on Ubuntu using bash though. But I'm fairly 
certain that this is not a quoting issue.

However, I just noticed that I had an error in my reproduction command. The 
value of the `-d` option has to be a directory of course. I just updated it in 
the original post. The correct command is the following:
{noformat}
java -jar apache-rat-0.14-20191120.132901-66.jar -e "*.txt" -d 
apache-rat-core/src/test/resources/violations
{noformat}
the quoting of the `-e` option cannot be omitted. The reason why you do not see 
the warning with an unquoted exclude pattern is shell expansion:
{noformat}
$ echo *.txt
BUILD.txt README.txt RELEASE-NOTES.txt RELEASE_NOTES.txt
{noformat}
Since the shell expands the glob before passing it to RAT you don't get the 
warning from before.

> CLI: Certain wildcard file filters do not work anymore
> --
>
> Key: RAT-265
> URL: https://issues.apache.org/jira/browse/RAT-265
> Project: Apache Rat
>  Issue Type: Bug
>  Components: cli
>Affects Versions: 0.13, 0.14
>Reporter: Raphael von der Grün
>Priority: Major
>
> Run the following command in the root of the `rat` repo:
> {noformat}
> java -jar apache-rat-0.14-20191120.132901-66.jar -e "*.txt" -d 
> apache-rat-core/src/test/resources/violations{noformat}
> This will give the following output on `stderr`: 
> {noformat}
> Will skip given exclusion '*.txt' due to 
> java.util.regex.PatternSyntaxException: Dangling meta character '*' near 
> index 0
> *.txt
> ^
> {noformat}
> Furthermore, `bad.txt` will NOT be excluded from the license check.
> The error that causes this is thrown in [line 132 of 
> `org.apache.rat.Report.java`|#L132]]. The reason is simple: any glob pattern 
> that starts with `*` or `?` is not a valid regex. When Line 132 throws, the 
> next two lines will also be skipped, so the pattern will not be added at all.
> Unfortunately, a solution to this problem is not so simple. In `v0.12` the 
> `-e` option always added wildcard filters while `-E` always added regex 
> filters. The documentation still states the same in the latest `v0.14` 
> snapshot. Beginning with `v0.13` the code tries to add any exclude rule as 
> three different filters. I believe this approach is inherently flawed.
> Firstly, the `new NameFileFilter(exclusion)` is redundant if we also add `new 
> WildcardFileFilter(exclusion)`. The files matched by the `NameFileFilter` are 
> a subset of those matched by the `WildcardFileFilter` since any magic 
> character (i.e. `?` or `*`) in `exclusion` also matches itself when used in a 
> `WildcardFileFilter`.
> So let's assume we only register the `WildcardFileFilter` and the 
> `RegexFileFilter`. Even if we properly add patterns as wildcard filters that 
> are not a valid RegEx, there are still patterns where we cannot decide what 
> the user's intention was. Consider the pattern `bi.ini`. Should it be 
> interpreted as a wildcard pattern and match only itself or should it be 
> interpreted as a regex and also match `bikini` for example?
> My recommendation for a quick patch solution would be to go back to the 
> exclusion behavior of `v0.12`.
> Beyond that, the nicest solution IMHO would be support for ignore files with 
> the same semantics as `.gitignore` (via `-E`) and support for giving extended 
> shell globs via `-e`.



--
This message was sent by Atlassian Jira
(v8.3.4#803005)

[jira] [Comment Edited] (RAT-265) CLI: Certain wildcard file filters do not work anymore

[Jira]

[ 
https://issues.apache.org/jira/browse/RAT-265?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16980887#comment-16980887
 ] 

Raphael von der Grün edited comment on RAT-265 at 11/23/19 9:37 PM:


Thanks for looking into this. I'm on Ubuntu using bash. But I'm fairly certain 
that this is not a quoting issue.

However, I just noticed that I had an error in my reproduction command. The 
value of the `-d` option has to be a directory of course. I just updated it in 
the original post. The correct command is the following:
{noformat}
java -jar apache-rat-0.14-20191120.132901-66.jar -e "*.txt" -d 
apache-rat-core/src/test/resources/violations
{noformat}
the quoting of the `-e` option cannot be omitted. The reason why you do not see 
the warning with an unquoted exclude pattern is shell expansion:
{noformat}
$ echo *.txt
BUILD.txt README.txt RELEASE-NOTES.txt RELEASE_NOTES.txt
{noformat}
Since the shell expands the glob before passing it to RAT you don't get the 
warning from before.


was (Author: raphinesse):
Thanks for looking into this. I'm on Ubuntu using bash though. But I'm fairly 
certain that this is not a quoting issue.

However, I just noticed that I had an error in my reproduction command. The 
value of the `-d` option has to be a directory of course. I just updated it in 
the original post. The correct command is the following:
{noformat}
java -jar apache-rat-0.14-20191120.132901-66.jar -e "*.txt" -d 
apache-rat-core/src/test/resources/violations
{noformat}
the quoting of the `-e` option cannot be omitted. The reason why you do not see 
the warning with an unquoted exclude pattern is shell expansion:
{noformat}
$ echo *.txt
BUILD.txt README.txt RELEASE-NOTES.txt RELEASE_NOTES.txt
{noformat}
Since the shell expands the glob before passing it to RAT you don't get the 
warning from before.

> CLI: Certain wildcard file filters do not work anymore
> --
>
> Key: RAT-265
> URL: https://issues.apache.org/jira/browse/RAT-265
> Project: Apache Rat
>  Issue Type: Bug
>  Components: cli
>Affects Versions: 0.13, 0.14
>Reporter: Raphael von der Grün
>Priority: Major
>
> Run the following command in the root of the `rat` repo:
> {noformat}
> java -jar apache-rat-0.14-20191120.132901-66.jar -e "*.txt" -d 
> apache-rat-core/src/test/resources/violations{noformat}
> This will give the following output on `stderr`: 
> {noformat}
> Will skip given exclusion '*.txt' due to 
> java.util.regex.PatternSyntaxException: Dangling meta character '*' near 
> index 0
> *.txt
> ^
> {noformat}
> Furthermore, `bad.txt` will NOT be excluded from the license check.
> The error that causes this is thrown in [line 132 of 
> `org.apache.rat.Report.java`|#L132]]. The reason is simple: any glob pattern 
> that starts with `*` or `?` is not a valid regex. When Line 132 throws, the 
> next two lines will also be skipped, so the pattern will not be added at all.
> Unfortunately, a solution to this problem is not so simple. In `v0.12` the 
> `-e` option always added wildcard filters while `-E` always added regex 
> filters. The documentation still states the same in the latest `v0.14` 
> snapshot. Beginning with `v0.13` the code tries to add any exclude rule as 
> three different filters. I believe this approach is inherently flawed.
> Firstly, the `new NameFileFilter(exclusion)` is redundant if we also add `new 
> WildcardFileFilter(exclusion)`. The files matched by the `NameFileFilter` are 
> a subset of those matched by the `WildcardFileFilter` since any magic 
> character (i.e. `?` or `*`) in `exclusion` also matches itself when used in a 
> `WildcardFileFilter`.
> So let's assume we only register the `WildcardFileFilter` and the 
> `RegexFileFilter`. Even if we properly add patterns as wildcard filters that 
> are not a valid RegEx, there are still patterns where we cannot decide what 
> the user's intention was. Consider the pattern `bi.ini`. Should it be 
> interpreted as a wildcard pattern and match only itself or should it be 
> interpreted as a regex and also match `bikini` for example?
> My recommendation for a quick patch solution would be to go back to the 
> exclusion behavior of `v0.12`.
> Beyond that, the nicest solution IMHO would be support for ignore files with 
> the same semantics as `.gitignore` (via `-E`) and support for giving extended 
> shell globs via `-e`.



--
This message was sent by Atlassian Jira
(v8.3.4#803005)

[jira] [Updated] (RAT-265) CLI: Certain wildcard file filters do not work anymore

[Jira]

 [ 
https://issues.apache.org/jira/browse/RAT-265?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Raphael von der Grün updated RAT-265:
-
Description: 
Run the following command in the root of the `rat` repo:
{noformat}
java -jar apache-rat-0.14-20191120.132901-66.jar -e "*.txt" -d 
apache-rat-core/src/test/resources/violations{noformat}
This will give the following output on `stderr`: 
{noformat}
Will skip given exclusion '*.txt' due to 
java.util.regex.PatternSyntaxException: Dangling meta character '*' near index 0
*.txt
^
{noformat}
Furthermore, `bad.txt` will NOT be excluded from the license check.

The error that causes this is thrown in [line 132 of 
`org.apache.rat.Report.java`|#L132]]. The reason is simple: any glob pattern 
that starts with `*` or `?` is not a valid regex. When Line 132 throws, the 
next two lines will also be skipped, so the pattern will not be added at all.

Unfortunately, a solution to this problem is not so simple. In `v0.12` the `-e` 
option always added wildcard filters while `-E` always added regex filters. The 
documentation still states the same in the latest `v0.14` snapshot. Beginning 
with `v0.13` the code tries to add any exclude rule as three different filters. 
I believe this approach is inherently flawed.

Firstly, the `new NameFileFilter(exclusion)` is redundant if we also add `new 
WildcardFileFilter(exclusion)`. The files matched by the `NameFileFilter` are a 
subset of those matched by the `WildcardFileFilter` since any magic character 
(i.e. `?` or `*`) in `exclusion` also matches itself when used in a 
`WildcardFileFilter`.

So let's assume we only register the `WildcardFileFilter` and the 
`RegexFileFilter`. Even if we properly add patterns as wildcard filters that 
are not a valid RegEx, there are still patterns where we cannot decide what the 
user's intention was. Consider the pattern `bi.ini`. Should it be interpreted 
as a wildcard pattern and match only itself or should it be interpreted as a 
regex and also match `bikini` for example?

My recommendation for a quick patch solution would be to go back to the 
exclusion behavior of `v0.12`.

Beyond that, the nicest solution IMHO would be support for ignore files with 
the same semantics as `.gitignore` (via `-E`) and support for giving extended 
shell globs via `-e`.

  was:
Run the following command in the root of the `rat` repo:
{noformat}
java -jar apache-rat-0.14-20191120.132901-66.jar -e "*.txt" -d 
apache-rat-core/src/test/resources/violations/bad.txt{noformat}
This will give the following output on `stderr`: 
{noformat}
Will skip given exclusion '*.txt' due to 
java.util.regex.PatternSyntaxException: Dangling meta character '*' near index 0
*.txt
^
{noformat}
Furthermore, `bad.txt` will NOT be excluded from the license check.

The error that causes this is thrown in [line 132 of 
`org.apache.rat.Report.java`|#L132]]. The reason is simple: any glob pattern 
that starts with `*` or `?` is not a valid regex. When Line 132 throws, the 
next two lines will also be skipped, so the pattern will not be added at all.

Unfortunately, a solution to this problem is not so simple. In `v0.12` the `-e` 
option always added wildcard filters while `-E` always added regex filters. The 
documentation still states the same in the latest `v0.14` snapshot. Beginning 
with `v0.13` the code tries to add any exclude rule as three different filters. 
I believe this approach is inherently flawed.

Firstly, the `new NameFileFilter(exclusion)` is redundant if we also add `new 
WildcardFileFilter(exclusion)`. The files matched by the `NameFileFilter` are a 
subset of those matched by the `WildcardFileFilter` since any magic character 
(i.e. `?` or `*`) in `exclusion` also matches itself when used in a 
`WildcardFileFilter`.

So let's assume we only register the `WildcardFileFilter` and the 
`RegexFileFilter`. Even if we properly add patterns as wildcard filters that 
are not a valid RegEx, there are still patterns where we cannot decide what the 
user's intention was. Consider the pattern `bi.ini`. Should it be interpreted 
as a wildcard pattern and match only itself or should it be interpreted as a 
regex and also match `bikini` for example?

My recommendation for a quick patch solution would be to go back to the 
exclusion behavior of `v0.12`.

Beyond that, the nicest solution IMHO would be support for ignore files with 
the same semantics as `.gitignore` (via `-E`) and support for giving extended 
shell globs via `-e`.


> CLI: Certain wildcard file filters do not work anymore
> --
>
> Key: RAT-265
> URL: https://issues.apache.org/jira/browse/RAT-265
> Project: Apache Rat
>  Issue Type: Bug
>  Components: cli
>Affects Versions: 0.13, 0.14
>Reporter: Raphael von der Grün
>

[jira] [Commented] (RAT-282) Release 1.0

[Jira]

[ 
https://issues.apache.org/jira/browse/RAT-282?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17390870#comment-17390870
 ] 

吴伟杰 commented on RAT-282:
-

I'm looking forward to the next release of Apache Rat Plugin for Maven.

> Release 1.0
> ---
>
> Key: RAT-282
> URL: https://issues.apache.org/jira/browse/RAT-282
> Project: Apache Rat
>  Issue Type: Task
>Reporter: Elliotte Rusty Harold
>Priority: Major
>
> This has been pre-1.0 for years, despite being included in most Apache 
> projects including the Apache Maven parent pom. It's time to make a 
> commitment and release this.



--
This message was sent by Atlassian Jira
(v8.3.4#803005)

[jira] [Commented] (RAT-212) pom.xml license failure when url is https

[Jira]

[ 
https://issues.apache.org/jira/browse/RAT-212?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17477305#comment-17477305
 ] 

Jorge Solórzano commented on RAT-212:
-

Is there an ETA for the 0.14 release that includes this fix?

> pom.xml license failure when url is https
> -
>
> Key: RAT-212
> URL: https://issues.apache.org/jira/browse/RAT-212
> Project: Apache Rat
>  Issue Type: Bug
>Affects Versions: 0.11
>Reporter: Christopher Tubbs
>Priority: Major
> Fix For: 0.14
>
>  Time Spent: 20m
>  Remaining Estimate: 0h
>
> apache-rat-plugin:check fails when the license information in the POM has a 
> url of "https://www.apache.org/licenses/LICENSE-2.0;, but not when it has a 
> url of "http://www.apache.org/licenses/LICENSE-2.0;
> It should probably not fail in the case of https.



--
This message was sent by Atlassian Jira
(v8.20.1#820001)

[jira] [Commented] (RAT-322) Be able to not restrict hidden directory

[Jira]

[ 
https://issues.apache.org/jira/browse/RAT-322?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17780407#comment-17780407
 ] 

Jean-Baptiste Onofré commented on RAT-322:
--

I have a PR ready :) 

> Be able to not restrict hidden directory
> 
>
> Key: RAT-322
> URL: https://issues.apache.org/jira/browse/RAT-322
> Project: Apache Rat
>  Issue Type: New Feature
>  Components: cli, maven
>Affects Versions: 0.15
>Reporter: Jean-Baptiste Onofré
>Priority: Major
> Fix For: 0.16
>
>
> Currently, the {{DirectoryWalker}} tests if a directory is "restricted":
> [https://github.com/apache/creadur-rat/blob/master/apache-rat-core/src/main/java/org/apache/rat/walker/DirectoryWalker.java#L71]
> Restricted means a directory starting with . e.g. a hidden directory:
> [https://github.com/apache/creadur-rat/blob/master/apache-rat-core/src/main/java/org/apache/rat/walker/Walker.java#L52]
> The problem is that rat doesn't scan files in *ANY* hidden directory.
> We should add a flag to scan hidden directories (the user can decide to 
> bypass the hidden directories or not) and let the user eventually define 
> excludes.



--
This message was sent by Atlassian Jira
(v8.20.10#820010)

[jira] [Created] (RAT-322) Be able to not restrict hidden directory

[Jira]

Jean-Baptiste Onofré created RAT-322:


 Summary: Be able to not restrict hidden directory
 Key: RAT-322
 URL: https://issues.apache.org/jira/browse/RAT-322
 Project: Apache Rat
  Issue Type: New Feature
  Components: cli, maven
Affects Versions: 0.15
Reporter: Jean-Baptiste Onofré
 Fix For: 0.16


Currently, the {{DirectoryWalker}} tests if a directory is "restricted":

[https://github.com/apache/creadur-rat/blob/master/apache-rat-core/src/main/java/org/apache/rat/walker/DirectoryWalker.java#L71]

Restricted means a directory starting with . e.g. a hidden directory:

[https://github.com/apache/creadur-rat/blob/master/apache-rat-core/src/main/java/org/apache/rat/walker/Walker.java#L52]

The problem is that rat doesn't scan files in *ANY* hidden directory.

We should add a flag to scan hidden directories (the user can decide to bypass 
the hidden directories or not) and let the user eventually define excludes.



--
This message was sent by Atlassian Jira
(v8.20.10#820010)

[jira] [Commented] (RAT-322) Add possibility to be able to scan objects in hidden directories

[Jira]

[ 
https://issues.apache.org/jira/browse/RAT-322?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17780590#comment-17780590
 ] 

Jean-Baptiste Onofré commented on RAT-322:
--

[~pottlinger] yes, I'm working on the PR right now. Thanks !

> Add possibility to be able to scan objects in hidden directories
> 
>
> Key: RAT-322
> URL: https://issues.apache.org/jira/browse/RAT-322
> Project: Apache Rat
>  Issue Type: New Feature
>  Components: cli, maven
>Affects Versions: 0.15
>Reporter: Jean-Baptiste Onofré
>Priority: Major
> Fix For: 0.16
>
>
> Currently, the {{DirectoryWalker}} tests if a directory is "restricted":
> [https://github.com/apache/creadur-rat/blob/master/apache-rat-core/src/main/java/org/apache/rat/walker/DirectoryWalker.java#L71]
> Restricted means a directory starting with . e.g. a hidden directory:
> [https://github.com/apache/creadur-rat/blob/master/apache-rat-core/src/main/java/org/apache/rat/walker/Walker.java#L52]
> The problem is that rat doesn't scan files in *ANY* hidden directory.
> We should add a flag to scan hidden directories (the user can decide to 
> bypass the hidden directories or not) and let the user eventually define 
> excludes.



--
This message was sent by Atlassian Jira
(v8.20.10#820010)

[jira] [Commented] (RAT-325) Performance degradation compared to 0.15

[Jira]

[ 
https://issues.apache.org/jira/browse/RAT-325?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17781612#comment-17781612
 ] 

Jean-Baptiste Onofré commented on RAT-325:
--

It seems that commit c457a07f3768e6e2aebb4c326247170727fcaec2 introduced 
regression as well. I continue the investigations.

> Performance degradation compared to 0.15
> 
>
> Key: RAT-325
> URL: https://issues.apache.org/jira/browse/RAT-325
> Project: Apache Rat
>  Issue Type: Bug
>  Components: cli
>Affects Versions: 0.16
>Reporter: Jean-Baptiste Onofré
>Priority: Major
> Fix For: 0.16
>
>
> While testing 0.16-SNAPSHOT, I identified rat is much longer to execute than 
> with 0.15.
> I'm investigating why.



--
This message was sent by Atlassian Jira
(v8.20.10#820010)

[jira] [Commented] (RAT-325) Performance degradation compared to 0.15

[Jira]

[ 
https://issues.apache.org/jira/browse/RAT-325?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17781224#comment-17781224
 ] 

Jean-Baptiste Onofré commented on RAT-325:
--

I'm doing a new pass to be more precise on the change. I will do a test by 
removing the SPDX feature to narrow the issue.

> Performance degradation compared to 0.15
> 
>
> Key: RAT-325
> URL: https://issues.apache.org/jira/browse/RAT-325
> Project: Apache Rat
>  Issue Type: Bug
>  Components: cli
>Affects Versions: 0.16
>Reporter: Jean-Baptiste Onofré
>Priority: Major
> Fix For: 0.16
>
>
> While testing 0.16-SNAPSHOT, I identified rat is much longer to execute than 
> with 0.15.
> I'm investigating why.



--
This message was sent by Atlassian Jira
(v8.20.10#820010)

[jira] [Commented] (RAT-325) Performance degradation compared to 0.15

[Jira]

[ 
https://issues.apache.org/jira/browse/RAT-325?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17781269#comment-17781269
 ] 

Jean-Baptiste Onofré commented on RAT-325:
--

Let me do further tests to square the issue.

> Performance degradation compared to 0.15
> 
>
> Key: RAT-325
> URL: https://issues.apache.org/jira/browse/RAT-325
> Project: Apache Rat
>  Issue Type: Bug
>  Components: cli
>Affects Versions: 0.16
>Reporter: Jean-Baptiste Onofré
>Priority: Major
> Fix For: 0.16
>
>
> While testing 0.16-SNAPSHOT, I identified rat is much longer to execute than 
> with 0.15.
> I'm investigating why.



--
This message was sent by Atlassian Jira
(v8.20.10#820010)

[jira] [Commented] (RAT-325) Performance degradation compared to 0.15

[Jira]

[ 
https://issues.apache.org/jira/browse/RAT-325?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17781273#comment-17781273
 ] 

Jean-Baptiste Onofré commented on RAT-325:
--

Good idea, I will add some regression/bench tests.

> Performance degradation compared to 0.15
> 
>
> Key: RAT-325
> URL: https://issues.apache.org/jira/browse/RAT-325
> Project: Apache Rat
>  Issue Type: Bug
>  Components: cli
>Affects Versions: 0.16
>Reporter: Jean-Baptiste Onofré
>Priority: Major
> Fix For: 0.16
>
>
> While testing 0.16-SNAPSHOT, I identified rat is much longer to execute than 
> with 0.15.
> I'm investigating why.



--
This message was sent by Atlassian Jira
(v8.20.10#820010)

[jira] [Commented] (RAT-320) Add a command line option to output to a file.

[Jira]

[ 
https://issues.apache.org/jira/browse/RAT-320?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17780950#comment-17780950
 ] 

Jean-Baptiste Onofré commented on RAT-320:
--

It would be great to include this in next release (0.16).

> Add a command line option to output to a file.
> --
>
> Key: RAT-320
> URL: https://issues.apache.org/jira/browse/RAT-320
> Project: Apache Rat
>  Issue Type: Improvement
>  Components: cli
>Affects Versions: 0.15
>Reporter: Claude Warren
>Priority: Minor
>
> Currently the only way to capture output is to pipe it to a file.  When 
> working in the codebase it is often necessary to review the output of a run, 
> adding the ability to pipe the output of the command line to a file is simple 
> and assistive.



--
This message was sent by Atlassian Jira
(v8.20.10#820010)

[jira] [Commented] (RAT-322) Add possibility to be able to scan objects in hidden directories

[Jira]

[ 
https://issues.apache.org/jira/browse/RAT-322?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17780953#comment-17780953
 ] 

Jean-Baptiste Onofré commented on RAT-322:
--

[~pottlinger] do you mind to assign this Jira to me ? Thanks !

> Add possibility to be able to scan objects in hidden directories
> 
>
> Key: RAT-322
> URL: https://issues.apache.org/jira/browse/RAT-322
> Project: Apache Rat
>  Issue Type: New Feature
>  Components: cli, maven
>Affects Versions: 0.15
>Reporter: Jean-Baptiste Onofré
>Priority: Major
> Fix For: 0.16
>
>
> Currently, the {{DirectoryWalker}} tests if a directory is "restricted":
> [https://github.com/apache/creadur-rat/blob/master/apache-rat-core/src/main/java/org/apache/rat/walker/DirectoryWalker.java#L71]
> Restricted means a directory starting with . e.g. a hidden directory:
> [https://github.com/apache/creadur-rat/blob/master/apache-rat-core/src/main/java/org/apache/rat/walker/Walker.java#L52]
> The problem is that rat doesn't scan files in *ANY* hidden directory.
> We should add a flag to scan hidden directories (the user can decide to 
> bypass the hidden directories or not) and let the user eventually define 
> excludes.



--
This message was sent by Atlassian Jira
(v8.20.10#820010)

[jira] [Commented] (RAT-320) Add a command line option to output to a file.

[Jira]

[ 
https://issues.apache.org/jira/browse/RAT-320?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17780954#comment-17780954
 ] 

Jean-Baptiste Onofré commented on RAT-320:
--

[~claude] [~pottlinger] do you mind guys to assign this Jira to me (as I'm 
working on this one) ?

> Add a command line option to output to a file.
> --
>
> Key: RAT-320
> URL: https://issues.apache.org/jira/browse/RAT-320
> Project: Apache Rat
>  Issue Type: Improvement
>  Components: cli
>Affects Versions: 0.15
>Reporter: Claude Warren
>Priority: Minor
>
> Currently the only way to capture output is to pipe it to a file.  When 
> working in the codebase it is often necessary to review the output of a run, 
> adding the ability to pipe the output of the command line to a file is simple 
> and assistive.



--
This message was sent by Atlassian Jira
(v8.20.10#820010)

[jira] [Created] (RAT-325) Performance degradation compared to 0.15

[Jira]

Jean-Baptiste Onofré created RAT-325:


 Summary: Performance degradation compared to 0.15
 Key: RAT-325
 URL: https://issues.apache.org/jira/browse/RAT-325
 Project: Apache Rat
  Issue Type: Bug
  Components: cli
Affects Versions: 0.16
Reporter: Jean-Baptiste Onofré
 Fix For: 0.16


While testing 0.16-SNAPSHOT, I identified rat is way longer to execute than 
with 0.15.

I'm investigating why.



--
This message was sent by Atlassian Jira
(v8.20.10#820010)

[jira] [Commented] (RAT-320) Add a command line option to output to a file.

[Jira]

[ 
https://issues.apache.org/jira/browse/RAT-320?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17780948#comment-17780948
 ] 

Jean-Baptiste Onofré commented on RAT-320:
--

I'm on it as it need it :) 

> Add a command line option to output to a file.
> --
>
> Key: RAT-320
> URL: https://issues.apache.org/jira/browse/RAT-320
> Project: Apache Rat
>  Issue Type: Improvement
>  Components: cli
>Affects Versions: 0.15
>Reporter: Claude Warren
>Priority: Minor
>
> Currently the only way to capture output is to pipe it to a file.  When 
> working in the codebase it is often necessary to review the output of a run, 
> adding the ability to pipe the output of the command line to a file is simple 
> and assistive.



--
This message was sent by Atlassian Jira
(v8.20.10#820010)

[jira] [Commented] (RAT-326) Fix javadoc errors

[Jira]

[ 
https://issues.apache.org/jira/browse/RAT-326?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17781057#comment-17781057
 ] 

Jean-Baptiste Onofré commented on RAT-326:
--

I fixed some in my PRs. I'm tackling this one (and also fixing some typos in 
comments).

> Fix javadoc errors
> --
>
> Key: RAT-326
> URL: https://issues.apache.org/jira/browse/RAT-326
> Project: Apache Rat
>  Issue Type: Bug
>  Components: site
>Affects Versions: 0.16
>Reporter: Claude Warren
>Priority: Minor
>
> Build scripts report javadoc errors.  For example:
>  
> Warning:  Javadoc Warnings 
>  
> Warning:  
> /home/runner/work/creadur-rat/creadur-rat/apache-rat-core/src/main/java/org/apache/rat/policy/DefaultPolicy.java:84:
>  warning - @return tag has no arguments. 
>  
> Warning:  
> /home/runner/work/creadur-rat/creadur-rat/apache-rat-core/src/main/java/org/apache/rat/ReportConfiguration.java:339:
>  warning - Tag @see: can't find setAddingLicenses(boolean) in 
> org.apache.rat.ReportConfiguration 
>  
> Warning:  
> /home/runner/work/creadur-rat/creadur-rat/apache-rat-core/src/main/java/org/apache/rat/ReportConfiguration.java:371:
>  warning - Tag @see: can't find setAddingLicensesForced(boolean) in 
> org.apache.rat.ReportConfiguration 
>  
> Warning:  
> /home/runner/work/creadur-rat/creadur-rat/apache-rat-core/src/main/java/org/apache/rat/ReportConfiguration.java:217:
>  warning - @param argument "license" is not a parameter name. 
>  
> Warning:  
> /home/runner/work/creadur-rat/creadur-rat/apache-rat-core/src/main/java/org/apache/rat/ReportConfiguration.java:252:
>  warning - @param argument "license" is not a parameter name. 
>  
> Warning:  
> /home/runner/work/creadur-rat/creadur-rat/apache-rat-core/src/main/java/org/apache/rat/ReportConfiguration.java:431:
>  warning - @param argument "a" is not a parameter name. 
>  
> Warning:  
> /home/runner/work/creadur-rat/creadur-rat/apache-rat-core/src/main/java/org/apache/rat/configuration/Format.java:107:
>  warning - @param argument "name" is not a parameter name. 
>  
> Warning:  
> /home/runner/work/creadur-rat/creadur-rat/apache-rat-core/src/main/java/org/apache/rat/configuration/Format.java:116:
>  warning - @param argument "name" is not a parameter name. 
>  
> Warning:  
> /home/runner/work/creadur-rat/creadur-rat/apache-rat-core/src/main/java/org/apache/rat/configuration/builders/SpdxBuilder.java:38:
>  warning - @return tag has no arguments. 
>  
> Warning:  
> /home/runner/work/creadur-rat/creadur-rat/apache-rat-core/src/main/java/org/apache/rat/license/LicenseFamilySetFactory.java:104:
>  warning - @return tag has no arguments. 
>  
> Warning:  
> /home/runner/work/creadur-rat/creadur-rat/apache-rat-core/src/main/java/org/apache/rat/license/LicenseFamilySetFactory.java:116:
>  warning - @return tag has no arguments. 
>  
> Warning:  
> /home/runner/work/creadur-rat/creadur-rat/apache-rat-core/src/main/java/org/apache/rat/analysis/matchers/SPDXMatcherFactory.java:42:
>  warning - Tag @see:illegal character: "58" in "[https://spdx.dev/ids/]; 
>  
> Warning:  
> /home/runner/work/creadur-rat/creadur-rat/apache-rat-core/src/main/java/org/apache/rat/analysis/matchers/SPDXMatcherFactory.java:42:
>  warning - Tag @see:illegal character: "47" in "[https://spdx.dev/ids/]; 
>  
> Warning:  
> /home/runner/work/creadur-rat/creadur-rat/apache-rat-core/src/main/java/org/apache/rat/analysis/matchers/SPDXMatcherFactory.java:42:
>  warning - Tag @see:illegal character: "47" in "[https://spdx.dev/ids/]; 
>  
> Warning:  
> /home/runner/work/creadur-rat/creadur-rat/apache-rat-core/src/main/java/org/apache/rat/analysis/matchers/SPDXMatcherFactory.java:42:
>  warning - Tag @see:illegal character: "47" in "[https://spdx.dev/ids/]; 
>  
> Warning:  
> /home/runner/work/creadur-rat/creadur-rat/apache-rat-core/src/main/java/org/apache/rat/analysis/matchers/SPDXMatcherFactory.java:42:
>  warning - Tag @see:illegal character: "47" in "[https://spdx.dev/ids/]; 
>  
> Warning:  
> /home/runner/work/creadur-rat/creadur-rat/apache-rat-core/src/main/java/org/apache/rat/analysis/matchers/SPDXMatcherFactory.java:42:
>  warning - Tag @see: reference not found: [https://spdx.dev/ids/] 
>  
> Warning:  
> /home/runner/work/creadur-rat/creadur-rat/apache-rat-tasks/src/main/java/org/apache/rat/anttasks/Report.java:117:
>  warning - Tag @link: can't find addStyleSheet(File) in 
> org.apache.rat.anttasks.Report



--
This message was sent by Atlassian Jira
(v8.20.10#820010)

[jira] [Commented] (RAT-325) Performance degradation compared to 0.15

[Jira]

[ 
https://issues.apache.org/jira/browse/RAT-325?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17781062#comment-17781062
 ] 

Jean-Baptiste Onofré commented on RAT-325:
--

With rat 0.16-SNAPSHOT:
{code:java}
44.53s user 0.51s system 103% cpu 43.501 total {code}
With rat 0.15:
{code:java}
2.25s user 0.33s system 279% cpu 0.923 total {code}
On the same machine, same JVM, same directory scanned.

> Performance degradation compared to 0.15
> 
>
> Key: RAT-325
> URL: https://issues.apache.org/jira/browse/RAT-325
> Project: Apache Rat
>  Issue Type: Bug
>  Components: cli
>Affects Versions: 0.16
>Reporter: Jean-Baptiste Onofré
>Priority: Major
> Fix For: 0.16
>
>
> While testing 0.16-SNAPSHOT, I identified rat is way longer to execute than 
> with 0.15.
> I'm investigating why.



--
This message was sent by Atlassian Jira
(v8.20.10#820010)

[jira] [Updated] (RAT-325) Performance degradation compared to 0.15

[Jira]

 [ 
https://issues.apache.org/jira/browse/RAT-325?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Jean-Baptiste Onofré updated RAT-325:
-
Description: 
While testing 0.16-SNAPSHOT, I identified rat is much longer to execute than 
with 0.15.

I'm investigating why.

  was:
While testing 0.16-SNAPSHOT, I identified rat is way longer to execute than 
with 0.15.

I'm investigating why.


> Performance degradation compared to 0.15
> 
>
> Key: RAT-325
> URL: https://issues.apache.org/jira/browse/RAT-325
> Project: Apache Rat
>  Issue Type: Bug
>  Components: cli
>Affects Versions: 0.16
>Reporter: Jean-Baptiste Onofré
>Priority: Major
> Fix For: 0.16
>
>
> While testing 0.16-SNAPSHOT, I identified rat is much longer to execute than 
> with 0.15.
> I'm investigating why.



--
This message was sent by Atlassian Jira
(v8.20.10#820010)

[jira] [Comment Edited] (RAT-314) .mvn folder default exclude is not respected

[Jira]

[ 
https://issues.apache.org/jira/browse/RAT-314?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17648426#comment-17648426
 ] 

François Guillot edited comment on RAT-314 at 12/16/22 10:42 AM:
-

[~pottlinger], you can reproduce with this very simple reproducer project: 
[https://github.com/facewindu/RAT-314]

Just check out the master branch, and execute "mvn clean apache-rat:check"

The build will fail due to 

[WARNING] Files with unapproved licenses:
  .mvn/extensions.xml

 

Anything that is under ".mvn" should not be checked, as this is an internal 
directory used by Maven, I think.

I guess this was the intent of [this default 
exclusion|https://github.com/apache/creadur-rat/blob/bcaff1efdbb942c1b69e2b930dad489d65fd53e8/apache-rat-plugin/src/main/java/org/apache/rat/mp/util/ExclusionHelper.java#L46]
 but instead of writing it ".mvn", it should be done as for the files within 
the target folder ({{target/\*\*/\*}}), so {{.mvn/\*\*/\*}}


There is even a comment about that in code "// Project configuration since 
Maven 3.3.1 which contains maven.config, jvm.config, extensions.xml" but 
currently, it only avoids checking the ".mvn" dir itself, not recursively 
inside it (which is useless).


was (Author: facewindu):
[~pottlinger], you can reproduce with this very simple reproducer project: 
[https://github.com/facewindu/RAT-314]

Just check out the master branch, and execute "mvn clean apache-rat:check"

The build will fail due to 

[WARNING] Files with unapproved licenses:
  .mvn/extensions.xml

 

Anything that is under ".mvn" should not be checked, as this is an internal 
directory used by Maven, I think.

I guess this was the intent of [this default 
exclusion|https://github.com/apache/creadur-rat/blob/bcaff1efdbb942c1b69e2b930dad489d65fd53e8/apache-rat-plugin/src/main/java/org/apache/rat/mp/util/ExclusionHelper.java#L46]
 but instead of writing it ".mvn", it should be done as for the files within 
the target folder:
{{.mvn/\*\*/\*}}

There is even a comment about that in code "// Project configuration since 
Maven 3.3.1 which contains maven.config, jvm.config, extensions.xml" but 
currently, it only avoids checking the ".mvn" dir itself, not recursively 
inside it (which is useless).

> .mvn folder default exclude is not respected
> ----
>
> Key: RAT-314
> URL: https://issues.apache.org/jira/browse/RAT-314
> Project: Apache Rat
>  Issue Type: Bug
>  Components: maven
>Affects Versions: 0.15
>Reporter: François Guillot
>Priority: Minor
>
> The RAT plugin defines default excludes in `ExclusionHelper.addMavenDefaults` 
> for Maven project. One of them is ".mvn"
>  
> Yet, if you declare an extension in ".mvn/extensions.xml", the file is not 
> excluded.



--
This message was sent by Atlassian Jira
(v8.20.10#820010)

[jira] [Commented] (RAT-314) .mvn folder default exclude is not respected

[Jira]

[ 
https://issues.apache.org/jira/browse/RAT-314?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17648426#comment-17648426
 ] 

François Guillot commented on RAT-314:
--

[~pottlinger], you can reproduce with this very simple reproducer project: 
[https://github.com/facewindu/RAT-314]

Just check out the master branch, and execute "mvn clean apache-rat:check"

The build will fail due to 

[WARNING] Files with unapproved licenses:
  .mvn/extensions.xml

 

Anything that is under ".mvn" should not be checked, as this is an internal 
directory used by Maven, I think.

I guess this was the intent of [this default 
exclusion|https://github.com/apache/creadur-rat/blob/bcaff1efdbb942c1b69e2b930dad489d65fd53e8/apache-rat-plugin/src/main/java/org/apache/rat/mp/util/ExclusionHelper.java#L46]
 but instead of writing it ".mvn", it should be done as for the files within 
the target folder ("target/**/*"), so ".mvn/**/*"

There is even a comment about that in code "// Project configuration since 
Maven 3.3.1 which contains maven.config, jvm.config, extensions.xml" but 
currently, it only avoids checking the ".mvn" dir itself, not recursively 
inside it (which is useless).

> .mvn folder default exclude is not respected
> 
>
> Key: RAT-314
> URL: https://issues.apache.org/jira/browse/RAT-314
> Project: Apache Rat
>  Issue Type: Bug
>  Components: maven
>Affects Versions: 0.15
>Reporter: François Guillot
>Priority: Minor
>
> The RAT plugin defines default excludes in `ExclusionHelper.addMavenDefaults` 
> for Maven project. One of them is ".mvn"
>  
> Yet, if you declare an extension in ".mvn/extensions.xml", the file is not 
> excluded.



--
This message was sent by Atlassian Jira
(v8.20.10#820010)

[jira] [Comment Edited] (RAT-314) .mvn folder default exclude is not respected

[Jira]

[ 
https://issues.apache.org/jira/browse/RAT-314?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17648426#comment-17648426
 ] 

François Guillot edited comment on RAT-314 at 12/16/22 10:39 AM:
-

[~pottlinger], you can reproduce with this very simple reproducer project: 
[https://github.com/facewindu/RAT-314]

Just check out the master branch, and execute "mvn clean apache-rat:check"

The build will fail due to 

[WARNING] Files with unapproved licenses:
  .mvn/extensions.xml

 

Anything that is under ".mvn" should not be checked, as this is an internal 
directory used by Maven, I think.

I guess this was the intent of [this default 
exclusion|https://github.com/apache/creadur-rat/blob/bcaff1efdbb942c1b69e2b930dad489d65fd53e8/apache-rat-plugin/src/main/java/org/apache/rat/mp/util/ExclusionHelper.java#L46]
 but instead of writing it ".mvn", it should be done as for the files within 
the target folder:
{quote}{{.mvn/**{*}/*{*}}}
{quote}
There is even a comment about that in code "// Project configuration since 
Maven 3.3.1 which contains maven.config, jvm.config, extensions.xml" but 
currently, it only avoids checking the ".mvn" dir itself, not recursively 
inside it (which is useless).


was (Author: facewindu):
[~pottlinger], you can reproduce with this very simple reproducer project: 
[https://github.com/facewindu/RAT-314]

Just check out the master branch, and execute "mvn clean apache-rat:check"

The build will fail due to 

[WARNING] Files with unapproved licenses:
  .mvn/extensions.xml

 

Anything that is under ".mvn" should not be checked, as this is an internal 
directory used by Maven, I think.

I guess this was the intent of [this default 
exclusion|https://github.com/apache/creadur-rat/blob/bcaff1efdbb942c1b69e2b930dad489d65fd53e8/apache-rat-plugin/src/main/java/org/apache/rat/mp/util/ExclusionHelper.java#L46]
 but instead of writing it ".mvn", it should be done as for the files within 
the target folder:

{{.mvn/**/*}}

There is even a comment about that in code "// Project configuration since 
Maven 3.3.1 which contains maven.config, jvm.config, extensions.xml" but 
currently, it only avoids checking the ".mvn" dir itself, not recursively 
inside it (which is useless).

> .mvn folder default exclude is not respected
> ----
>
> Key: RAT-314
> URL: https://issues.apache.org/jira/browse/RAT-314
> Project: Apache Rat
>  Issue Type: Bug
>  Components: maven
>Affects Versions: 0.15
>Reporter: François Guillot
>Priority: Minor
>
> The RAT plugin defines default excludes in `ExclusionHelper.addMavenDefaults` 
> for Maven project. One of them is ".mvn"
>  
> Yet, if you declare an extension in ".mvn/extensions.xml", the file is not 
> excluded.



--
This message was sent by Atlassian Jira
(v8.20.10#820010)

[jira] [Comment Edited] (RAT-314) .mvn folder default exclude is not respected

[Jira]

[ 
https://issues.apache.org/jira/browse/RAT-314?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17648426#comment-17648426
 ] 

François Guillot edited comment on RAT-314 at 12/16/22 10:39 AM:
-

[~pottlinger], you can reproduce with this very simple reproducer project: 
[https://github.com/facewindu/RAT-314]

Just check out the master branch, and execute "mvn clean apache-rat:check"

The build will fail due to 

[WARNING] Files with unapproved licenses:
  .mvn/extensions.xml

 

Anything that is under ".mvn" should not be checked, as this is an internal 
directory used by Maven, I think.

I guess this was the intent of [this default 
exclusion|https://github.com/apache/creadur-rat/blob/bcaff1efdbb942c1b69e2b930dad489d65fd53e8/apache-rat-plugin/src/main/java/org/apache/rat/mp/util/ExclusionHelper.java#L46]
 but instead of writing it ".mvn", it should be done as for the files within 
the target folder (`target/**/*`), so "`.mvn/**/*`"

There is even a comment about that in code "// Project configuration since 
Maven 3.3.1 which contains maven.config, jvm.config, extensions.xml" but 
currently, it only avoids checking the ".mvn" dir itself, not recursively 
inside it (which is useless).


was (Author: facewindu):
[~pottlinger], you can reproduce with this very simple reproducer project: 
[https://github.com/facewindu/RAT-314]

Just check out the master branch, and execute "mvn clean apache-rat:check"

The build will fail due to 

[WARNING] Files with unapproved licenses:
  .mvn/extensions.xml

 

Anything that is under ".mvn" should not be checked, as this is an internal 
directory used by Maven, I think.

I guess this was the intent of [this default 
exclusion|https://github.com/apache/creadur-rat/blob/bcaff1efdbb942c1b69e2b930dad489d65fd53e8/apache-rat-plugin/src/main/java/org/apache/rat/mp/util/ExclusionHelper.java#L46]
 but instead of writing it ".mvn", it should be done as for the files within 
the target folder ("target/**/*"), so ".mvn/**/*"

There is even a comment about that in code "// Project configuration since 
Maven 3.3.1 which contains maven.config, jvm.config, extensions.xml" but 
currently, it only avoids checking the ".mvn" dir itself, not recursively 
inside it (which is useless).

> .mvn folder default exclude is not respected
> 
>
> Key: RAT-314
> URL: https://issues.apache.org/jira/browse/RAT-314
> Project: Apache Rat
>  Issue Type: Bug
>  Components: maven
>Affects Versions: 0.15
>Reporter: François Guillot
>Priority: Minor
>
> The RAT plugin defines default excludes in `ExclusionHelper.addMavenDefaults` 
> for Maven project. One of them is ".mvn"
>  
> Yet, if you declare an extension in ".mvn/extensions.xml", the file is not 
> excluded.



--
This message was sent by Atlassian Jira
(v8.20.10#820010)

[jira] [Comment Edited] (RAT-314) .mvn folder default exclude is not respected

[Jira]

[ 
https://issues.apache.org/jira/browse/RAT-314?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17648426#comment-17648426
 ] 

François Guillot edited comment on RAT-314 at 12/16/22 10:40 AM:
-

[~pottlinger], you can reproduce with this very simple reproducer project: 
[https://github.com/facewindu/RAT-314]

Just check out the master branch, and execute "mvn clean apache-rat:check"

The build will fail due to 

[WARNING] Files with unapproved licenses:
  .mvn/extensions.xml

 

Anything that is under ".mvn" should not be checked, as this is an internal 
directory used by Maven, I think.

I guess this was the intent of [this default 
exclusion|https://github.com/apache/creadur-rat/blob/bcaff1efdbb942c1b69e2b930dad489d65fd53e8/apache-rat-plugin/src/main/java/org/apache/rat/mp/util/ExclusionHelper.java#L46]
 but instead of writing it ".mvn", it should be done as for the files within 
the target folder:

{{.mvn/**/*}}

There is even a comment about that in code "// Project configuration since 
Maven 3.3.1 which contains maven.config, jvm.config, extensions.xml" but 
currently, it only avoids checking the ".mvn" dir itself, not recursively 
inside it (which is useless).


was (Author: facewindu):
[~pottlinger], you can reproduce with this very simple reproducer project: 
[https://github.com/facewindu/RAT-314]

Just check out the master branch, and execute "mvn clean apache-rat:check"

The build will fail due to 

[WARNING] Files with unapproved licenses:
  .mvn/extensions.xml

 

Anything that is under ".mvn" should not be checked, as this is an internal 
directory used by Maven, I think.

I guess this was the intent of [this default 
exclusion|https://github.com/apache/creadur-rat/blob/bcaff1efdbb942c1b69e2b930dad489d65fd53e8/apache-rat-plugin/src/main/java/org/apache/rat/mp/util/ExclusionHelper.java#L46]
 but instead of writing it ".mvn", it should be done as for the files within 
the target folder:
{quote}{{.mvn/**{*}/*{*}}}
{quote}
There is even a comment about that in code "// Project configuration since 
Maven 3.3.1 which contains maven.config, jvm.config, extensions.xml" but 
currently, it only avoids checking the ".mvn" dir itself, not recursively 
inside it (which is useless).

> .mvn folder default exclude is not respected
> ----
>
> Key: RAT-314
> URL: https://issues.apache.org/jira/browse/RAT-314
> Project: Apache Rat
>  Issue Type: Bug
>  Components: maven
>Affects Versions: 0.15
>Reporter: François Guillot
>Priority: Minor
>
> The RAT plugin defines default excludes in `ExclusionHelper.addMavenDefaults` 
> for Maven project. One of them is ".mvn"
>  
> Yet, if you declare an extension in ".mvn/extensions.xml", the file is not 
> excluded.



--
This message was sent by Atlassian Jira
(v8.20.10#820010)

[jira] [Comment Edited] (RAT-314) .mvn folder default exclude is not respected

[Jira]

[ 
https://issues.apache.org/jira/browse/RAT-314?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17648426#comment-17648426
 ] 

François Guillot edited comment on RAT-314 at 12/16/22 10:40 AM:
-

[~pottlinger], you can reproduce with this very simple reproducer project: 
[https://github.com/facewindu/RAT-314]

Just check out the master branch, and execute "mvn clean apache-rat:check"

The build will fail due to 

[WARNING] Files with unapproved licenses:
  .mvn/extensions.xml

 

Anything that is under ".mvn" should not be checked, as this is an internal 
directory used by Maven, I think.

I guess this was the intent of [this default 
exclusion|https://github.com/apache/creadur-rat/blob/bcaff1efdbb942c1b69e2b930dad489d65fd53e8/apache-rat-plugin/src/main/java/org/apache/rat/mp/util/ExclusionHelper.java#L46]
 but instead of writing it ".mvn", it should be done as for the files within 
the target folder:
.mvn/**/*

There is even a comment about that in code "// Project configuration since 
Maven 3.3.1 which contains maven.config, jvm.config, extensions.xml" but 
currently, it only avoids checking the ".mvn" dir itself, not recursively 
inside it (which is useless).


was (Author: facewindu):
[~pottlinger], you can reproduce with this very simple reproducer project: 
[https://github.com/facewindu/RAT-314]

Just check out the master branch, and execute "mvn clean apache-rat:check"

The build will fail due to 

[WARNING] Files with unapproved licenses:
  .mvn/extensions.xml

 

Anything that is under ".mvn" should not be checked, as this is an internal 
directory used by Maven, I think.

I guess this was the intent of [this default 
exclusion|https://github.com/apache/creadur-rat/blob/bcaff1efdbb942c1b69e2b930dad489d65fd53e8/apache-rat-plugin/src/main/java/org/apache/rat/mp/util/ExclusionHelper.java#L46]
 but instead of writing it ".mvn", it should be done as for the files within 
the target folder:

{{.mvn/**/*}}

There is even a comment about that in code "// Project configuration since 
Maven 3.3.1 which contains maven.config, jvm.config, extensions.xml" but 
currently, it only avoids checking the ".mvn" dir itself, not recursively 
inside it (which is useless).

> .mvn folder default exclude is not respected
> ----
>
> Key: RAT-314
> URL: https://issues.apache.org/jira/browse/RAT-314
> Project: Apache Rat
>  Issue Type: Bug
>  Components: maven
>Affects Versions: 0.15
>Reporter: François Guillot
>Priority: Minor
>
> The RAT plugin defines default excludes in `ExclusionHelper.addMavenDefaults` 
> for Maven project. One of them is ".mvn"
>  
> Yet, if you declare an extension in ".mvn/extensions.xml", the file is not 
> excluded.



--
This message was sent by Atlassian Jira
(v8.20.10#820010)

[jira] [Comment Edited] (RAT-314) .mvn folder default exclude is not respected

[Jira]

[ 
https://issues.apache.org/jira/browse/RAT-314?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17648426#comment-17648426
 ] 

François Guillot edited comment on RAT-314 at 12/16/22 10:40 AM:
-

[~pottlinger], you can reproduce with this very simple reproducer project: 
[https://github.com/facewindu/RAT-314]

Just check out the master branch, and execute "mvn clean apache-rat:check"

The build will fail due to 

[WARNING] Files with unapproved licenses:
  .mvn/extensions.xml

 

Anything that is under ".mvn" should not be checked, as this is an internal 
directory used by Maven, I think.

I guess this was the intent of [this default 
exclusion|https://github.com/apache/creadur-rat/blob/bcaff1efdbb942c1b69e2b930dad489d65fd53e8/apache-rat-plugin/src/main/java/org/apache/rat/mp/util/ExclusionHelper.java#L46]
 but instead of writing it ".mvn", it should be done as for the files within 
the target folder:

{{.mvn/**/*}}

There is even a comment about that in code "// Project configuration since 
Maven 3.3.1 which contains maven.config, jvm.config, extensions.xml" but 
currently, it only avoids checking the ".mvn" dir itself, not recursively 
inside it (which is useless).


was (Author: facewindu):
[~pottlinger], you can reproduce with this very simple reproducer project: 
[https://github.com/facewindu/RAT-314]

Just check out the master branch, and execute "mvn clean apache-rat:check"

The build will fail due to 

[WARNING] Files with unapproved licenses:
  .mvn/extensions.xml

 

Anything that is under ".mvn" should not be checked, as this is an internal 
directory used by Maven, I think.

I guess this was the intent of [this default 
exclusion|https://github.com/apache/creadur-rat/blob/bcaff1efdbb942c1b69e2b930dad489d65fd53e8/apache-rat-plugin/src/main/java/org/apache/rat/mp/util/ExclusionHelper.java#L46]
 but instead of writing it ".mvn", it should be done as for the files within 
the target folder:

{{.mvn/**/*}}

There is even a comment about that in code "// Project configuration since 
Maven 3.3.1 which contains maven.config, jvm.config, extensions.xml" but 
currently, it only avoids checking the ".mvn" dir itself, not recursively 
inside it (which is useless).

> .mvn folder default exclude is not respected
> ----
>
> Key: RAT-314
> URL: https://issues.apache.org/jira/browse/RAT-314
> Project: Apache Rat
>  Issue Type: Bug
>  Components: maven
>Affects Versions: 0.15
>Reporter: François Guillot
>Priority: Minor
>
> The RAT plugin defines default excludes in `ExclusionHelper.addMavenDefaults` 
> for Maven project. One of them is ".mvn"
>  
> Yet, if you declare an extension in ".mvn/extensions.xml", the file is not 
> excluded.



--
This message was sent by Atlassian Jira
(v8.20.10#820010)

[jira] [Comment Edited] (RAT-314) .mvn folder default exclude is not respected

[Jira]

[ 
https://issues.apache.org/jira/browse/RAT-314?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17648426#comment-17648426
 ] 

François Guillot edited comment on RAT-314 at 12/16/22 10:39 AM:
-

[~pottlinger], you can reproduce with this very simple reproducer project: 
[https://github.com/facewindu/RAT-314]

Just check out the master branch, and execute "mvn clean apache-rat:check"

The build will fail due to 

[WARNING] Files with unapproved licenses:
  .mvn/extensions.xml

 

Anything that is under ".mvn" should not be checked, as this is an internal 
directory used by Maven, I think.

I guess this was the intent of [this default 
exclusion|https://github.com/apache/creadur-rat/blob/bcaff1efdbb942c1b69e2b930dad489d65fd53e8/apache-rat-plugin/src/main/java/org/apache/rat/mp/util/ExclusionHelper.java#L46]
 but instead of writing it ".mvn", it should be done as for the files within 
the target folder:

{{.mvn/**/*}}

There is even a comment about that in code "// Project configuration since 
Maven 3.3.1 which contains maven.config, jvm.config, extensions.xml" but 
currently, it only avoids checking the ".mvn" dir itself, not recursively 
inside it (which is useless).


was (Author: facewindu):
[~pottlinger], you can reproduce with this very simple reproducer project: 
[https://github.com/facewindu/RAT-314]

Just check out the master branch, and execute "mvn clean apache-rat:check"

The build will fail due to 

[WARNING] Files with unapproved licenses:
  .mvn/extensions.xml

 

Anything that is under ".mvn" should not be checked, as this is an internal 
directory used by Maven, I think.

I guess this was the intent of [this default 
exclusion|https://github.com/apache/creadur-rat/blob/bcaff1efdbb942c1b69e2b930dad489d65fd53e8/apache-rat-plugin/src/main/java/org/apache/rat/mp/util/ExclusionHelper.java#L46]
 but instead of writing it ".mvn", it should be done as for the files within 
the target folder (`target/**/*`), so "`.mvn/**/*`"

There is even a comment about that in code "// Project configuration since 
Maven 3.3.1 which contains maven.config, jvm.config, extensions.xml" but 
currently, it only avoids checking the ".mvn" dir itself, not recursively 
inside it (which is useless).

> .mvn folder default exclude is not respected
> ----
>
> Key: RAT-314
> URL: https://issues.apache.org/jira/browse/RAT-314
> Project: Apache Rat
>  Issue Type: Bug
>  Components: maven
>Affects Versions: 0.15
>Reporter: François Guillot
>Priority: Minor
>
> The RAT plugin defines default excludes in `ExclusionHelper.addMavenDefaults` 
> for Maven project. One of them is ".mvn"
>  
> Yet, if you declare an extension in ".mvn/extensions.xml", the file is not 
> excluded.



--
This message was sent by Atlassian Jira
(v8.20.10#820010)

[jira] [Comment Edited] (RAT-314) .mvn folder default exclude is not respected

[Jira]

[ 
https://issues.apache.org/jira/browse/RAT-314?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17648426#comment-17648426
 ] 

François Guillot edited comment on RAT-314 at 12/16/22 10:41 AM:
-

[~pottlinger], you can reproduce with this very simple reproducer project: 
[https://github.com/facewindu/RAT-314]

Just check out the master branch, and execute "mvn clean apache-rat:check"

The build will fail due to 

[WARNING] Files with unapproved licenses:
  .mvn/extensions.xml

 

Anything that is under ".mvn" should not be checked, as this is an internal 
directory used by Maven, I think.

I guess this was the intent of [this default 
exclusion|https://github.com/apache/creadur-rat/blob/bcaff1efdbb942c1b69e2b930dad489d65fd53e8/apache-rat-plugin/src/main/java/org/apache/rat/mp/util/ExclusionHelper.java#L46]
 but instead of writing it ".mvn", it should be done as for the files within 
the target folder:
{{.mvn/\*\*/\*}}

There is even a comment about that in code "// Project configuration since 
Maven 3.3.1 which contains maven.config, jvm.config, extensions.xml" but 
currently, it only avoids checking the ".mvn" dir itself, not recursively 
inside it (which is useless).


was (Author: facewindu):
[~pottlinger], you can reproduce with this very simple reproducer project: 
[https://github.com/facewindu/RAT-314]

Just check out the master branch, and execute "mvn clean apache-rat:check"

The build will fail due to 

[WARNING] Files with unapproved licenses:
  .mvn/extensions.xml

 

Anything that is under ".mvn" should not be checked, as this is an internal 
directory used by Maven, I think.

I guess this was the intent of [this default 
exclusion|https://github.com/apache/creadur-rat/blob/bcaff1efdbb942c1b69e2b930dad489d65fd53e8/apache-rat-plugin/src/main/java/org/apache/rat/mp/util/ExclusionHelper.java#L46]
 but instead of writing it ".mvn", it should be done as for the files within 
the target folder:
.mvn/<*><*>/<*>

There is even a comment about that in code "// Project configuration since 
Maven 3.3.1 which contains maven.config, jvm.config, extensions.xml" but 
currently, it only avoids checking the ".mvn" dir itself, not recursively 
inside it (which is useless).

> .mvn folder default exclude is not respected
> ----
>
> Key: RAT-314
> URL: https://issues.apache.org/jira/browse/RAT-314
> Project: Apache Rat
>  Issue Type: Bug
>  Components: maven
>Affects Versions: 0.15
>Reporter: François Guillot
>Priority: Minor
>
> The RAT plugin defines default excludes in `ExclusionHelper.addMavenDefaults` 
> for Maven project. One of them is ".mvn"
>  
> Yet, if you declare an extension in ".mvn/extensions.xml", the file is not 
> excluded.



--
This message was sent by Atlassian Jira
(v8.20.10#820010)

[jira] [Comment Edited] (RAT-314) .mvn folder default exclude is not respected

[Jira]

[ 
https://issues.apache.org/jira/browse/RAT-314?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17648426#comment-17648426
 ] 

François Guillot edited comment on RAT-314 at 12/16/22 10:41 AM:
-

[~pottlinger], you can reproduce with this very simple reproducer project: 
[https://github.com/facewindu/RAT-314]

Just check out the master branch, and execute "mvn clean apache-rat:check"

The build will fail due to 

[WARNING] Files with unapproved licenses:
  .mvn/extensions.xml

 

Anything that is under ".mvn" should not be checked, as this is an internal 
directory used by Maven, I think.

I guess this was the intent of [this default 
exclusion|https://github.com/apache/creadur-rat/blob/bcaff1efdbb942c1b69e2b930dad489d65fd53e8/apache-rat-plugin/src/main/java/org/apache/rat/mp/util/ExclusionHelper.java#L46]
 but instead of writing it ".mvn", it should be done as for the files within 
the target folder:
.mvn/<*><*>/<*>

There is even a comment about that in code "// Project configuration since 
Maven 3.3.1 which contains maven.config, jvm.config, extensions.xml" but 
currently, it only avoids checking the ".mvn" dir itself, not recursively 
inside it (which is useless).


was (Author: facewindu):
[~pottlinger], you can reproduce with this very simple reproducer project: 
[https://github.com/facewindu/RAT-314]

Just check out the master branch, and execute "mvn clean apache-rat:check"

The build will fail due to 

[WARNING] Files with unapproved licenses:
  .mvn/extensions.xml

 

Anything that is under ".mvn" should not be checked, as this is an internal 
directory used by Maven, I think.

I guess this was the intent of [this default 
exclusion|https://github.com/apache/creadur-rat/blob/bcaff1efdbb942c1b69e2b930dad489d65fd53e8/apache-rat-plugin/src/main/java/org/apache/rat/mp/util/ExclusionHelper.java#L46]
 but instead of writing it ".mvn", it should be done as for the files within 
the target folder:
.mvn/**/*

There is even a comment about that in code "// Project configuration since 
Maven 3.3.1 which contains maven.config, jvm.config, extensions.xml" but 
currently, it only avoids checking the ".mvn" dir itself, not recursively 
inside it (which is useless).

> .mvn folder default exclude is not respected
> ----
>
> Key: RAT-314
> URL: https://issues.apache.org/jira/browse/RAT-314
> Project: Apache Rat
>  Issue Type: Bug
>  Components: maven
>Affects Versions: 0.15
>Reporter: François Guillot
>Priority: Minor
>
> The RAT plugin defines default excludes in `ExclusionHelper.addMavenDefaults` 
> for Maven project. One of them is ".mvn"
>  
> Yet, if you declare an extension in ".mvn/extensions.xml", the file is not 
> excluded.



--
This message was sent by Atlassian Jira
(v8.20.10#820010)

[jira] [Created] (RAT-314) .mvn folder default exclude is not respected

[Jira]

François Guillot created RAT-314:


 Summary: .mvn folder default exclude is not respected
 Key: RAT-314
 URL: https://issues.apache.org/jira/browse/RAT-314
 Project: Apache Rat
  Issue Type: Bug
  Components: maven
Affects Versions: 0.15
Reporter: François Guillot


The RAT plugin defines default excludes in `ExclusionHelper.addMavenDefaults` 
for Maven project. One of them is ".mvn"

 

Yet, if you declare an extension in ".mvn/extensions.xml", the file is not 
excluded.



--
This message was sent by Atlassian Jira
(v8.20.10#820010)

[jira] [Commented] (RAT-314) .mvn folder default exclude is not respected recursively

[Jira]

[ 
https://issues.apache.org/jira/browse/RAT-314?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17681915#comment-17681915
 ] 

François Guillot commented on RAT-314:
--

Hi [~pottlinger]

Fix confirmed from my side. Thank you !

> .mvn folder default exclude is not respected recursively
> 
>
> Key: RAT-314
> URL: https://issues.apache.org/jira/browse/RAT-314
> Project: Apache Rat
>  Issue Type: Bug
>  Components: maven
>Affects Versions: 0.15
>Reporter: François Guillot
>Assignee: Philipp Ottlinger
>Priority: Minor
> Fix For: 0.16
>
>
> The RAT plugin defines default excludes in `ExclusionHelper.addMavenDefaults` 
> for Maven project. One of them is ".mvn"
>  
> Yet, if you declare an extension in ".mvn/extensions.xml", the file is not 
> excluded.



--
This message was sent by Atlassian Jira
(v8.20.10#820010)

[jira] [Assigned] (RAT-362) plugin: .gitignore not correctly applied

[Jira]

 [ 
https://issues.apache.org/jira/browse/RAT-362?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Jean-Baptiste Onofré reassigned RAT-362:


Assignee: Jean-Baptiste Onofré

> plugin: .gitignore not correctly applied
> 
>
> Key: RAT-362
> URL: https://issues.apache.org/jira/browse/RAT-362
> Project: Apache Rat
>  Issue Type: Bug
>Reporter: Arnout Engelen
>Assignee: Jean-Baptiste Onofré
>Priority: Minor
>
> When I have a Maven project checked out in the directory '/foo', and I have a 
> file called 'foo.md' in the root of that project, ignoring it by putting a 
> '/foo.md' entry in the .gitignore file does not work.
> It is unclear whether this is an issue in the plugin or in de codeowners 
> gitignore-reader dependency: the plugin is passing relative filenames (i.e. 
> 'foo.md') to GitIgnoreFileSet#isIgnoredFile , but the API docs on that method 
> don't make it too clear whether that is intended to accept absolute 
> filenames, relative filename, or both.
> In this scenario, it seems to take the relative filename 'foo.md' and remove 
> the project base directory '/foo' from it, leaving '/.md' (which then of 
> course does not match the 'foo.md' from the .gitignore).



--
This message was sent by Atlassian Jira
(v8.20.10#820010)

[jira] [Commented] (RAT-362) plugin: .gitignore not correctly applied

[Jira]

[ 
https://issues.apache.org/jira/browse/RAT-362?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17814345#comment-17814345
 ] 

Jean-Baptiste Onofré commented on RAT-362:
--

Thanks for the report, I will take a look.

> plugin: .gitignore not correctly applied
> 
>
> Key: RAT-362
> URL: https://issues.apache.org/jira/browse/RAT-362
> Project: Apache Rat
>  Issue Type: Bug
>Reporter: Arnout Engelen
>Assignee: Jean-Baptiste Onofré
>Priority: Minor
>
> When I have a Maven project checked out in the directory '/foo', and I have a 
> file called 'foo.md' in the root of that project, ignoring it by putting a 
> '/foo.md' entry in the .gitignore file does not work.
> It is unclear whether this is an issue in the plugin or in de codeowners 
> gitignore-reader dependency: the plugin is passing relative filenames (i.e. 
> 'foo.md') to GitIgnoreFileSet#isIgnoredFile , but the API docs on that method 
> don't make it too clear whether that is intended to accept absolute 
> filenames, relative filename, or both.
> In this scenario, it seems to take the relative filename 'foo.md' and remove 
> the project base directory '/foo' from it, leaving '/.md' (which then of 
> course does not match the 'foo.md' from the .gitignore).



--
This message was sent by Atlassian Jira
(v8.20.10#820010)

[jira] [Updated] (RAT-325) Performance degradation compared to 0.15

[Jira]

 [ 
https://issues.apache.org/jira/browse/RAT-325?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Jean-Baptiste Onofré updated RAT-325:
-
Fix Version/s: 0.17
   (was: 0.16)

> Performance degradation compared to 0.15
> 
>
> Key: RAT-325
> URL: https://issues.apache.org/jira/browse/RAT-325
> Project: Apache Rat
>  Issue Type: Bug
>  Components: cli
>Affects Versions: 0.16
>Reporter: Jean-Baptiste Onofré
>Assignee: Jean-Baptiste Onofré
>Priority: Major
> Fix For: 0.17
>
>
> While testing 0.16-SNAPSHOT, I identified rat is much longer to execute than 
> with 0.15.
> I'm investigating why.



--
This message was sent by Atlassian Jira
(v8.20.10#820010)

[jira] [Updated] (RAT-336) Use assertj in RAT tests

[Jira]

 [ 
https://issues.apache.org/jira/browse/RAT-336?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Jean-Baptiste Onofré updated RAT-336:
-
Fix Version/s: 0.17
   (was: 0.16)

> Use assertj in RAT tests
> 
>
> Key: RAT-336
> URL: https://issues.apache.org/jira/browse/RAT-336
> Project: Apache Rat
>  Issue Type: Improvement
>  Components: build
>Affects Versions: 0.15
>Reporter: Jean-Baptiste Onofré
>Assignee: Jean-Baptiste Onofré
>Priority: Major
> Fix For: 0.17
>
>
> As discussed during RAT-322 fix, I will refactore all tests to use assertj.



--
This message was sent by Atlassian Jira
(v8.20.10#820010)

[jira] [Commented] (RAT-325) Performance degradation compared to 0.15

[Jira]

[ 
https://issues.apache.org/jira/browse/RAT-325?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17794922#comment-17794922
 ] 

Jean-Baptiste Onofré commented on RAT-325:
--

[~pottlinger] I'm back on RAT this week end. I will resume work on this one.

> Performance degradation compared to 0.15
> 
>
> Key: RAT-325
> URL: https://issues.apache.org/jira/browse/RAT-325
> Project: Apache Rat
>  Issue Type: Bug
>  Components: cli
>Affects Versions: 0.16
>Reporter: Jean-Baptiste Onofré
>Assignee: Jean-Baptiste Onofré
>Priority: Major
> Fix For: 0.16
>
>
> While testing 0.16-SNAPSHOT, I identified rat is much longer to execute than 
> with 0.15.
> I'm investigating why.



--
This message was sent by Atlassian Jira
(v8.20.10#820010)

[jira] [Commented] (RAT-325) Performance degradation compared to 0.15

[Jira]

[ 
https://issues.apache.org/jira/browse/RAT-325?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17804985#comment-17804985
 ] 

Jean-Baptiste Onofré commented on RAT-325:
--

[~joc...@apache.org] I did the tests using 0.16-SNAPSHOT at the time of the 
test (build locally), running rat on iceberg repo (main). When I did the 
bisect, the performance regression was due to SPDX scanning. I was busy with 
other Apache projects, but now that 0.16 has been released, I will do the test 
again (adding itests/perf tests in the rat directly).

> Performance degradation compared to 0.15
> 
>
> Key: RAT-325
> URL: https://issues.apache.org/jira/browse/RAT-325
> Project: Apache Rat
>  Issue Type: Bug
>  Components: cli
>Affects Versions: 0.16
>Reporter: Jean-Baptiste Onofré
>Assignee: Jean-Baptiste Onofré
>Priority: Major
> Fix For: 0.17
>
>
> While testing 0.16-SNAPSHOT, I identified rat is much longer to execute than 
> with 0.15.
> I'm investigating why.



--
This message was sent by Atlassian Jira
(v8.20.10#820010)

[jira] [Created] (RAT-336) Use assertj in RAT tests

[Jira]

Jean-Baptiste Onofré created RAT-336:


 Summary: Use assertj in RAT tests
 Key: RAT-336
 URL: https://issues.apache.org/jira/browse/RAT-336
 Project: Apache Rat
  Issue Type: Improvement
  Components: build
Reporter: Jean-Baptiste Onofré
 Fix For: 0.16


As discussed during RAT-322 fix, I will refactore all tests to use assertj.



--
This message was sent by Atlassian Jira
(v8.20.10#820010)

[jira] [Commented] (RAT-326) Fix javadoc errors

[Jira]

[ 
https://issues.apache.org/jira/browse/RAT-326?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17785139#comment-17785139
 ] 

Jean-Baptiste Onofré commented on RAT-326:
--

[~pottlinger] Thanks ! I will check also. FYI, I'm almost full back in the 
business now, so resuming my work on RAT.

> Fix javadoc errors
> --
>
> Key: RAT-326
> URL: https://issues.apache.org/jira/browse/RAT-326
> Project: Apache Rat
>  Issue Type: Bug
>  Components: site
>Affects Versions: 0.16
>Reporter: Claude Warren
>Assignee: Philipp Ottlinger
>Priority: Major
> Fix For: 0.16
>
>
> Build scripts report javadoc errors and warnings.  For example:
> h1. Javadoc errors
>  * broken markup
>  
> h1.  Warnings
> Warning: Javadoc Warnings
>  
> Warning: 
> /home/runner/work/creadur-rat/creadur-rat/apache-rat-core/src/main/java/org/apache/rat/policy/DefaultPolicy.java:84:
>  warning - @return tag has no arguments. 
>  
> Warning: 
> /home/runner/work/creadur-rat/creadur-rat/apache-rat-core/src/main/java/org/apache/rat/ReportConfiguration.java:339:
>  warning - Tag @see: can't find setAddingLicenses(boolean) in 
> org.apache.rat.ReportConfiguration 
>  
> Warning: 
> /home/runner/work/creadur-rat/creadur-rat/apache-rat-core/src/main/java/org/apache/rat/ReportConfiguration.java:371:
>  warning - Tag @see: can't find setAddingLicensesForced(boolean) in 
> org.apache.rat.ReportConfiguration 
>  
> Warning: 
> /home/runner/work/creadur-rat/creadur-rat/apache-rat-core/src/main/java/org/apache/rat/ReportConfiguration.java:217:
>  warning - @param argument "license" is not a parameter name. 
>  
> Warning: 
> /home/runner/work/creadur-rat/creadur-rat/apache-rat-core/src/main/java/org/apache/rat/ReportConfiguration.java:252:
>  warning - @param argument "license" is not a parameter name. 
>  
> Warning: 
> /home/runner/work/creadur-rat/creadur-rat/apache-rat-core/src/main/java/org/apache/rat/ReportConfiguration.java:431:
>  warning - @param argument "a" is not a parameter name. 
>  
> Warning: 
> /home/runner/work/creadur-rat/creadur-rat/apache-rat-core/src/main/java/org/apache/rat/configuration/Format.java:107:
>  warning - @param argument "name" is not a parameter name. 
>  
> Warning: 
> /home/runner/work/creadur-rat/creadur-rat/apache-rat-core/src/main/java/org/apache/rat/configuration/Format.java:116:
>  warning - @param argument "name" is not a parameter name. 
>  
> Warning: 
> /home/runner/work/creadur-rat/creadur-rat/apache-rat-core/src/main/java/org/apache/rat/configuration/builders/SpdxBuilder.java:38:
>  warning - @return tag has no arguments. 
>  
> Warning: 
> /home/runner/work/creadur-rat/creadur-rat/apache-rat-core/src/main/java/org/apache/rat/license/LicenseFamilySetFactory.java:104:
>  warning - @return tag has no arguments. 
>  
> Warning: 
> /home/runner/work/creadur-rat/creadur-rat/apache-rat-core/src/main/java/org/apache/rat/license/LicenseFamilySetFactory.java:116:
>  warning - @return tag has no arguments. 
>  
> Warning: 
> /home/runner/work/creadur-rat/creadur-rat/apache-rat-core/src/main/java/org/apache/rat/analysis/matchers/SPDXMatcherFactory.java:42:
>  warning - Tag @see:illegal character: "58" in "[https://spdx.dev/ids/]; 
>  
> Warning: 
> /home/runner/work/creadur-rat/creadur-rat/apache-rat-core/src/main/java/org/apache/rat/analysis/matchers/SPDXMatcherFactory.java:42:
>  warning - Tag @see:illegal character: "47" in "[https://spdx.dev/ids/]; 
>  
> Warning: 
> /home/runner/work/creadur-rat/creadur-rat/apache-rat-core/src/main/java/org/apache/rat/analysis/matchers/SPDXMatcherFactory.java:42:
>  warning - Tag @see:illegal character: "47" in "[https://spdx.dev/ids/]; 
>  
> Warning: 
> /home/runner/work/creadur-rat/creadur-rat/apache-rat-core/src/main/java/org/apache/rat/analysis/matchers/SPDXMatcherFactory.java:42:
>  warning - Tag @see:illegal character: "47" in "[https://spdx.dev/ids/]; 
>  
> Warning: 
> /home/runner/work/creadur-rat/creadur-rat/apache-rat-core/src/main/java/org/apache/rat/analysis/matchers/SPDXMatcherFactory.java:42:
>  warning - Tag @see:illegal character: "47" in "[https://spdx.dev/ids/]; 
>  
> Warning: 
> /home/runner/work/creadur-rat/creadur-rat/apache-rat-core/src/main/java/org/apache/rat/analysis/matchers/SPDXMatcherFactory.java:42:
>  warning - Tag @see: reference not found: [https://spdx.dev/ids/] 
>  
> Warning: 
> /home/runner/work/creadur-rat/creadur-rat/apache-rat-tasks/src/main/java/org/apache/rat/anttasks/Report.java:117:
>  warning - Tag @link: can't find addStyleSheet(File) in 
> org.apache.rat.anttasks.Report



--
This message was sent by Atlassian Jira
(v8.20.10#820010)

[jira] [Commented] (RAT-98) Maven RAT report does not document skipped files

[Sebb (JIRA)]

[ 
https://issues.apache.org/jira/browse/RAT-98?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13490312#comment-13490312
 ] 

Sebb commented on RAT-98:
-

Yes, the details need to appear in the report so that it contains all the 
necessary information.
Ideally this should show all files that are actually excluded, not the file 
names in the exclude tags - i.e. don't show missing files, but do show files 
that match wildcard entries.

The console log is transitory, so should not be the only place where such 
information is reported.

 Maven RAT report does not document skipped files
 

 Key: RAT-98
 URL: https://issues.apache.org/jira/browse/RAT-98
 Project: Apache Rat
  Issue Type: Bug
Reporter: Sebb

 The Maven RAT report should document which files have been skipped using the 
 exclude option.
 Either by listing the configuration details, or better by listing the file 
 names with a marker, e.g. EX to show they were deliberately skipped.
 Note: this only refers to files listed in exclude entries, not files which 
 are excluded by default.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

[jira] [Created] (RAT-133) Unthrown Exceptions

[Sebb (JIRA)]

Sebb created RAT-133:


 Summary: Unthrown Exceptions
 Key: RAT-133
 URL: https://issues.apache.org/jira/browse/RAT-133
 Project: Apache Rat
  Issue Type: Bug
Reporter: Sebb
Priority: Minor


Eclipse reports several unthrown Exceptions.
Either these should be removed (as per patch to follow), or - if they are 
needed - they should be documented to avoid the warning.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

[jira] [Created] (RAT-134) RAT CLI uses different wildcard syntax for -e and -E; neither matches Ant/Maven wildcards

[Sebb (JIRA)]

Sebb created RAT-134:


 Summary: RAT CLI uses different wildcard syntax for -e and -E; 
neither matches Ant/Maven wildcards
 Key: RAT-134
 URL: https://issues.apache.org/jira/browse/RAT-134
 Project: Apache Rat
  Issue Type: Bug
Affects Versions: 0.8, 0.9
Reporter: Sebb


RAT CLI uses two different wildcard syntaxes, neither of which agree with the 
Ant/Maven syntax.

For the -E option (expressions read from a file), it uses RegexFileFilter which 
uses java.util.regex.Pattern syntax.

For the -e option (expression provided on command-line), it uses 
WildcardFileFilter, whose Javadoc says:
The wildcard matcher uses the characters '?' and '*' to represent a single or 
multiple wildcard characters. This is the same as often found on Dos/Unix 
command lines.

Ant and Maven syntax is similar to the -e syntax, except that they use '**' to 
mean zero or more directories.

RAT CLI should be consistent, and should use Ant/Maven style syntax.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

[jira] [Created] (RAT-138) RAT runs very slowly on some input

[Sebb (JIRA)]

Sebb created RAT-138:


 Summary: RAT runs very slowly on some input
 Key: RAT-138
 URL: https://issues.apache.org/jira/browse/RAT-138
 Project: Apache Rat
  Issue Type: Bug
  Components: engine
Affects Versions: 0.9
Reporter: Sebb


Commons IO discovered that mvn site was spending a lot of time running RAT 0.9. 
Reverting to 0.8 fixes the problem.
Turns out that certain files seem to cause RAT to chew CPU in the 
Pattern.matcher; here is a sample stack trace from a thread dump:

main prio=6 tid=0x003c8c00 nid=0xecc runnable [0x00a5e000]
   java.lang.Thread.State: RUNNABLE
at java.util.regex.Pattern$Slice.match(Pattern.java:3867)
at java.util.regex.Pattern$Curly.match0(Pattern.java:4170)
at java.util.regex.Pattern$Curly.match(Pattern.java:4132)
at java.util.regex.Matcher.match(Matcher.java:1221)
at java.util.regex.Matcher.matches(Matcher.java:559)
at 
org.apache.rat.analysis.generation.GeneratedLicenseNotRequired.match(GeneratedLicenseNotRequired.java:71)
at 
org.apache.rat.analysis.util.HeaderMatcherMultiplexer.match(HeaderMatcherMultiplexer.java:42)
at 
org.apache.rat.analysis.HeaderCheckWorker.readLine(HeaderCheckWorker.java:113)
at 
org.apache.rat.analysis.HeaderCheckWorker.read(HeaderCheckWorker.java:84)
at 
org.apache.rat.analysis.DocumentHeaderAnalyser.analyse(DocumentHeaderAnalyser.java:43)
at 
org.apache.rat.analysis.DefaultAnalyserFactory$DefaultAnalyser.analyse(DefaultAnalyserFactory.java:60)
at 
org.apache.rat.document.impl.util.DocumentAnalyserMultiplexer.analyse(DocumentAnalyserMultiplexer.java:37)
at 
org.apache.rat.report.claim.util.ClaimReporterMultiplexer.report(ClaimReporterMultiplexer.java:42)
at org.apache.rat.mp.FilesReportable.run(FilesReportable.java:68)
at org.apache.rat.Report.report(Report.java:393)
at org.apache.rat.Report.report(Report.java:373)
at 
org.apache.rat.mp.AbstractRatMojo.createReport(AbstractRatMojo.java:462)
at org.apache.rat.mp.RatReportMojo.createReport(RatReportMojo.java:148)
at org.apache.rat.mp.RatReportMojo.generate(RatReportMojo.java:310)
at org.apache.rat.mp.RatReportMojo.execute(RatReportMojo.java:210)

I assume there must be a problem with one of the REs which is triggering lots 
of backtracking when applied to files under site-content/, which is a working 
copy of:

https://svn.apache.org/repos/infra/websites/production/commons/content/proper/commons-io
Last Changed Rev: 861378

This directory should not have been included in the RAT scan, but the files 
don't cause problems for RAT 0.8.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

[jira] [Commented] (RAT-138) RAT runs very slowly on some input

[Sebb (JIRA)]

[ 
https://issues.apache.org/jira/browse/RAT-138?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13657801#comment-13657801
 ] 

Sebb commented on RAT-138:
--

Seems to be just the Javadocs that causes the problem.

The following file (amongst others) causes the spinning to occur:

https://svn.apache.org/repos/infra/websites/production/commons/content/proper/commons-io/apidocs/index-all.html

 RAT runs very slowly on some input
 --

 Key: RAT-138
 URL: https://issues.apache.org/jira/browse/RAT-138
 Project: Apache Rat
  Issue Type: Bug
  Components: engine
Affects Versions: 0.9
Reporter: Sebb

 Commons IO discovered that mvn site was spending a lot of time running RAT 
 0.9. Reverting to 0.8 fixes the problem.
 Turns out that certain files seem to cause RAT to chew CPU in the 
 Pattern.matcher; here is a sample stack trace from a thread dump:
 main prio=6 tid=0x003c8c00 nid=0xecc runnable [0x00a5e000]
java.lang.Thread.State: RUNNABLE
 at java.util.regex.Pattern$Slice.match(Pattern.java:3867)
 at java.util.regex.Pattern$Curly.match0(Pattern.java:4170)
 at java.util.regex.Pattern$Curly.match(Pattern.java:4132)
 at java.util.regex.Matcher.match(Matcher.java:1221)
 at java.util.regex.Matcher.matches(Matcher.java:559)
 at 
 org.apache.rat.analysis.generation.GeneratedLicenseNotRequired.match(GeneratedLicenseNotRequired.java:71)
 at 
 org.apache.rat.analysis.util.HeaderMatcherMultiplexer.match(HeaderMatcherMultiplexer.java:42)
 at 
 org.apache.rat.analysis.HeaderCheckWorker.readLine(HeaderCheckWorker.java:113)
 at 
 org.apache.rat.analysis.HeaderCheckWorker.read(HeaderCheckWorker.java:84)
 at 
 org.apache.rat.analysis.DocumentHeaderAnalyser.analyse(DocumentHeaderAnalyser.java:43)
 at 
 org.apache.rat.analysis.DefaultAnalyserFactory$DefaultAnalyser.analyse(DefaultAnalyserFactory.java:60)
 at 
 org.apache.rat.document.impl.util.DocumentAnalyserMultiplexer.analyse(DocumentAnalyserMultiplexer.java:37)
 at 
 org.apache.rat.report.claim.util.ClaimReporterMultiplexer.report(ClaimReporterMultiplexer.java:42)
 at org.apache.rat.mp.FilesReportable.run(FilesReportable.java:68)
 at org.apache.rat.Report.report(Report.java:393)
 at org.apache.rat.Report.report(Report.java:373)
 at 
 org.apache.rat.mp.AbstractRatMojo.createReport(AbstractRatMojo.java:462)
 at 
 org.apache.rat.mp.RatReportMojo.createReport(RatReportMojo.java:148)
 at org.apache.rat.mp.RatReportMojo.generate(RatReportMojo.java:310)
 at org.apache.rat.mp.RatReportMojo.execute(RatReportMojo.java:210)
 I assume there must be a problem with one of the REs which is triggering lots 
 of backtracking when applied to files under site-content/, which is a working 
 copy of:
 https://svn.apache.org/repos/infra/websites/production/commons/content/proper/commons-io
 Last Changed Rev: 861378
 This directory should not have been included in the RAT scan, but the files 
 don't cause problems for RAT 0.8.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

[jira] [Updated] (RAT-138) RAT runs very slowly on some input

[Sebb (JIRA)]

 [ 
https://issues.apache.org/jira/browse/RAT-138?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Sebb updated RAT-138:
-

Description: 
Commons IO discovered that mvn site was spending a lot of time running RAT 0.9. 
Reverting to 0.8 fixes the problem.
Turns out that certain files seem to cause RAT to chew CPU in the 
Pattern.matcher; here is a sample stack trace from a thread dump:

main prio=6 tid=0x003c8c00 nid=0xa4c runnable [0x00a5e000]
   java.lang.Thread.State: RUNNABLE
at java.util.regex.Pattern$Curly.match0(Pattern.java:4166)
at java.util.regex.Pattern$Curly.match(Pattern.java:4132)
at java.util.regex.Matcher.match(Matcher.java:1221)
at java.util.regex.Matcher.matches(Matcher.java:559)
at 
org.apache.rat.analysis.license.FullTextMatchingLicense.match(FullTextMatchingLicense.java:79)
at 
org.apache.rat.analysis.util.HeaderMatcherMultiplexer.match(HeaderMatcherMultiplexer.java:42)
at 
org.apache.rat.analysis.HeaderCheckWorker.readLine(HeaderCheckWorker.java:113)
at 
org.apache.rat.analysis.HeaderCheckWorker.read(HeaderCheckWorker.java:84)
at 
org.apache.rat.analysis.DocumentHeaderAnalyser.analyse(DocumentHeaderAnalyser.java:43)
at 
org.apache.rat.analysis.DefaultAnalyserFactory$DefaultAnalyser.analyse(DefaultAnalyserFactory.java:60)
at 
org.apache.rat.document.impl.util.DocumentAnalyserMultiplexer.analyse(DocumentAnalyserMultiplexer.java:37)
at 
org.apache.rat.report.claim.util.ClaimReporterMultiplexer.report(ClaimReporterMultiplexer.java:42)
at org.apache.rat.mp.FilesReportable.run(FilesReportable.java:68)
at org.apache.rat.Report.report(Report.java:393)
at org.apache.rat.Report.report(Report.java:373)
at 
org.apache.rat.mp.AbstractRatMojo.createReport(AbstractRatMojo.java:462)
at org.apache.rat.mp.RatReportMojo.createReport(RatReportMojo.java:148)
at org.apache.rat.mp.RatReportMojo.generate(RatReportMojo.java:310)
at org.apache.rat.mp.RatReportMojo.execute(RatReportMojo.java:210)

I assume there must be a problem with one of the REs which is triggering lots 
of backtracking when applied to files under site-content/, which is a working 
copy of:

https://svn.apache.org/repos/infra/websites/production/commons/content/proper/commons-io
Last Changed Rev: 861378

This directory should not have been included in the RAT scan, but the files 
don't cause problems for RAT 0.8.

  was:
Commons IO discovered that mvn site was spending a lot of time running RAT 0.9. 
Reverting to 0.8 fixes the problem.
Turns out that certain files seem to cause RAT to chew CPU in the 
Pattern.matcher; here is a sample stack trace from a thread dump:

main prio=6 tid=0x003c8c00 nid=0xecc runnable [0x00a5e000]
   java.lang.Thread.State: RUNNABLE
at java.util.regex.Pattern$Slice.match(Pattern.java:3867)
at java.util.regex.Pattern$Curly.match0(Pattern.java:4170)
at java.util.regex.Pattern$Curly.match(Pattern.java:4132)
at java.util.regex.Matcher.match(Matcher.java:1221)
at java.util.regex.Matcher.matches(Matcher.java:559)
at 
org.apache.rat.analysis.generation.GeneratedLicenseNotRequired.match(GeneratedLicenseNotRequired.java:71)
at 
org.apache.rat.analysis.util.HeaderMatcherMultiplexer.match(HeaderMatcherMultiplexer.java:42)
at 
org.apache.rat.analysis.HeaderCheckWorker.readLine(HeaderCheckWorker.java:113)
at 
org.apache.rat.analysis.HeaderCheckWorker.read(HeaderCheckWorker.java:84)
at 
org.apache.rat.analysis.DocumentHeaderAnalyser.analyse(DocumentHeaderAnalyser.java:43)
at 
org.apache.rat.analysis.DefaultAnalyserFactory$DefaultAnalyser.analyse(DefaultAnalyserFactory.java:60)
at 
org.apache.rat.document.impl.util.DocumentAnalyserMultiplexer.analyse(DocumentAnalyserMultiplexer.java:37)
at 
org.apache.rat.report.claim.util.ClaimReporterMultiplexer.report(ClaimReporterMultiplexer.java:42)
at org.apache.rat.mp.FilesReportable.run(FilesReportable.java:68)
at org.apache.rat.Report.report(Report.java:393)
at org.apache.rat.Report.report(Report.java:373)
at 
org.apache.rat.mp.AbstractRatMojo.createReport(AbstractRatMojo.java:462)
at org.apache.rat.mp.RatReportMojo.createReport(RatReportMojo.java:148)
at org.apache.rat.mp.RatReportMojo.generate(RatReportMojo.java:310)
at org.apache.rat.mp.RatReportMojo.execute(RatReportMojo.java:210)

I assume there must be a problem with one of the REs which is triggering lots 
of backtracking when applied to files under site-content/, which is a working 
copy of:

https://svn.apache.org/repos/infra/websites/production/commons/content/proper/commons-io
Last Changed Rev: 861378

This directory should not have been included in the RAT scan, but the files 
don't cause problems for RAT 0.8.


 RAT runs very slowly on some input

[jira] [Created] (RAT-139) FullTextMatchingLicense.prune uses inefficient deleteAtChar

[Sebb (JIRA)]

Sebb created RAT-139:


 Summary: FullTextMatchingLicense.prune uses inefficient 
deleteAtChar
 Key: RAT-139
 URL: https://issues.apache.org/jira/browse/RAT-139
 Project: Apache Rat
  Issue Type: Improvement
Reporter: Sebb


FullTextMatchingLicense.prune is quite inefficient.

It first copies the entire string to a StringBuilder, then scans the buffer 
deleting characters that are not letters or digits.

It should be a lot quicker to just copy the letters and digits once, skipping 
the rest.


--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

[jira] [Commented] (RAT-138) RAT runs very slowly on some input

[Sebb (JIRA)]

[ 
https://issues.apache.org/jira/browse/RAT-138?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13657822#comment-13657822
 ] 

Sebb commented on RAT-138:
--

Looks like GeneratedLicenseNotRequired does not need to use regexes either - it 
does not even use case-insensitive matching.


 RAT runs very slowly on some input
 --

 Key: RAT-138
 URL: https://issues.apache.org/jira/browse/RAT-138
 Project: Apache Rat
  Issue Type: Bug
  Components: engine
Affects Versions: 0.9
Reporter: Sebb

 Commons IO discovered that mvn site was spending a lot of time running RAT 
 0.9. Reverting to 0.8 fixes the problem.
 Turns out that certain files seem to cause RAT to chew CPU in the 
 Pattern.matcher; here is a sample stack trace from a thread dump:
 main prio=6 tid=0x003c8c00 nid=0xa4c runnable [0x00a5e000]
java.lang.Thread.State: RUNNABLE
 at java.util.regex.Pattern$Curly.match0(Pattern.java:4166)
 at java.util.regex.Pattern$Curly.match(Pattern.java:4132)
 at java.util.regex.Matcher.match(Matcher.java:1221)
 at java.util.regex.Matcher.matches(Matcher.java:559)
 at 
 org.apache.rat.analysis.license.FullTextMatchingLicense.match(FullTextMatchingLicense.java:79)
 at 
 org.apache.rat.analysis.util.HeaderMatcherMultiplexer.match(HeaderMatcherMultiplexer.java:42)
 at 
 org.apache.rat.analysis.HeaderCheckWorker.readLine(HeaderCheckWorker.java:113)
 at 
 org.apache.rat.analysis.HeaderCheckWorker.read(HeaderCheckWorker.java:84)
 at 
 org.apache.rat.analysis.DocumentHeaderAnalyser.analyse(DocumentHeaderAnalyser.java:43)
 at 
 org.apache.rat.analysis.DefaultAnalyserFactory$DefaultAnalyser.analyse(DefaultAnalyserFactory.java:60)
 at 
 org.apache.rat.document.impl.util.DocumentAnalyserMultiplexer.analyse(DocumentAnalyserMultiplexer.java:37)
 at 
 org.apache.rat.report.claim.util.ClaimReporterMultiplexer.report(ClaimReporterMultiplexer.java:42)
 at org.apache.rat.mp.FilesReportable.run(FilesReportable.java:68)
 at org.apache.rat.Report.report(Report.java:393)
 at org.apache.rat.Report.report(Report.java:373)
 at 
 org.apache.rat.mp.AbstractRatMojo.createReport(AbstractRatMojo.java:462)
 at 
 org.apache.rat.mp.RatReportMojo.createReport(RatReportMojo.java:148)
 at org.apache.rat.mp.RatReportMojo.generate(RatReportMojo.java:310)
 at org.apache.rat.mp.RatReportMojo.execute(RatReportMojo.java:210)
 I assume there must be a problem with one of the REs which is triggering lots 
 of backtracking when applied to files under site-content/, which is a working 
 copy of:
 https://svn.apache.org/repos/infra/websites/production/commons/content/proper/commons-io
 Last Changed Rev: 861378
 This directory should not have been included in the RAT scan, but the files 
 don't cause problems for RAT 0.8.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

[jira] [Updated] (RAT-138) RAT runs very slowly on some input

[Sebb (JIRA)]

 [ 
https://issues.apache.org/jira/browse/RAT-138?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Sebb updated RAT-138:
-

Labels: perfomance regression  (was: )

 RAT runs very slowly on some input
 --

 Key: RAT-138
 URL: https://issues.apache.org/jira/browse/RAT-138
 Project: Apache Rat
  Issue Type: Bug
  Components: engine
Affects Versions: 0.9
Reporter: Sebb
  Labels: perfomance, regression

 Commons IO discovered that mvn site was spending a lot of time running RAT 
 0.9. Reverting to 0.8 fixes the problem.
 Turns out that certain files seem to cause RAT to chew CPU in the 
 Pattern.matcher; here is a sample stack trace from a thread dump:
 main prio=6 tid=0x003c8c00 nid=0xa4c runnable [0x00a5e000]
java.lang.Thread.State: RUNNABLE
 at java.util.regex.Pattern$Curly.match0(Pattern.java:4166)
 at java.util.regex.Pattern$Curly.match(Pattern.java:4132)
 at java.util.regex.Matcher.match(Matcher.java:1221)
 at java.util.regex.Matcher.matches(Matcher.java:559)
 at 
 org.apache.rat.analysis.license.FullTextMatchingLicense.match(FullTextMatchingLicense.java:79)
 at 
 org.apache.rat.analysis.util.HeaderMatcherMultiplexer.match(HeaderMatcherMultiplexer.java:42)
 at 
 org.apache.rat.analysis.HeaderCheckWorker.readLine(HeaderCheckWorker.java:113)
 at 
 org.apache.rat.analysis.HeaderCheckWorker.read(HeaderCheckWorker.java:84)
 at 
 org.apache.rat.analysis.DocumentHeaderAnalyser.analyse(DocumentHeaderAnalyser.java:43)
 at 
 org.apache.rat.analysis.DefaultAnalyserFactory$DefaultAnalyser.analyse(DefaultAnalyserFactory.java:60)
 at 
 org.apache.rat.document.impl.util.DocumentAnalyserMultiplexer.analyse(DocumentAnalyserMultiplexer.java:37)
 at 
 org.apache.rat.report.claim.util.ClaimReporterMultiplexer.report(ClaimReporterMultiplexer.java:42)
 at org.apache.rat.mp.FilesReportable.run(FilesReportable.java:68)
 at org.apache.rat.Report.report(Report.java:393)
 at org.apache.rat.Report.report(Report.java:373)
 at 
 org.apache.rat.mp.AbstractRatMojo.createReport(AbstractRatMojo.java:462)
 at 
 org.apache.rat.mp.RatReportMojo.createReport(RatReportMojo.java:148)
 at org.apache.rat.mp.RatReportMojo.generate(RatReportMojo.java:310)
 at org.apache.rat.mp.RatReportMojo.execute(RatReportMojo.java:210)
 I assume there must be a problem with one of the REs which is triggering lots 
 of backtracking when applied to files under site-content/, which is a working 
 copy of:
 https://svn.apache.org/repos/infra/websites/production/commons/content/proper/commons-io
 Last Changed Rev: 861378
 This directory should not have been included in the RAT scan, but the files 
 don't cause problems for RAT 0.8.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

[jira] [Commented] (RAT-138) RAT runs very slowly on some input

[Sebb (JIRA)]

[ 
https://issues.apache.org/jira/browse/RAT-138?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13661069#comment-13661069
 ] 

Sebb commented on RAT-138:
--

Seems it is mainly the extra matchers that are being run; 0.9 additionally runs:

GPL1License
GPL2License
GPL3License
MITLicense

These are all FullTextMatchers which currently use regexes unnecessarily.

 RAT runs very slowly on some input
 --

 Key: RAT-138
 URL: https://issues.apache.org/jira/browse/RAT-138
 Project: Apache Rat
  Issue Type: Bug
  Components: engine
Affects Versions: 0.9
Reporter: Sebb
  Labels: perfomance, regression

 Commons IO discovered that mvn site was spending a lot of time running RAT 
 0.9. Reverting to 0.8 fixes the problem.
 Turns out that certain files seem to cause RAT to chew CPU in the 
 Pattern.matcher; here is a sample stack trace from a thread dump:
 main prio=6 tid=0x003c8c00 nid=0xa4c runnable [0x00a5e000]
java.lang.Thread.State: RUNNABLE
 at java.util.regex.Pattern$Curly.match0(Pattern.java:4166)
 at java.util.regex.Pattern$Curly.match(Pattern.java:4132)
 at java.util.regex.Matcher.match(Matcher.java:1221)
 at java.util.regex.Matcher.matches(Matcher.java:559)
 at 
 org.apache.rat.analysis.license.FullTextMatchingLicense.match(FullTextMatchingLicense.java:79)
 at 
 org.apache.rat.analysis.util.HeaderMatcherMultiplexer.match(HeaderMatcherMultiplexer.java:42)
 at 
 org.apache.rat.analysis.HeaderCheckWorker.readLine(HeaderCheckWorker.java:113)
 at 
 org.apache.rat.analysis.HeaderCheckWorker.read(HeaderCheckWorker.java:84)
 at 
 org.apache.rat.analysis.DocumentHeaderAnalyser.analyse(DocumentHeaderAnalyser.java:43)
 at 
 org.apache.rat.analysis.DefaultAnalyserFactory$DefaultAnalyser.analyse(DefaultAnalyserFactory.java:60)
 at 
 org.apache.rat.document.impl.util.DocumentAnalyserMultiplexer.analyse(DocumentAnalyserMultiplexer.java:37)
 at 
 org.apache.rat.report.claim.util.ClaimReporterMultiplexer.report(ClaimReporterMultiplexer.java:42)
 at org.apache.rat.mp.FilesReportable.run(FilesReportable.java:68)
 at org.apache.rat.Report.report(Report.java:393)
 at org.apache.rat.Report.report(Report.java:373)
 at 
 org.apache.rat.mp.AbstractRatMojo.createReport(AbstractRatMojo.java:462)
 at 
 org.apache.rat.mp.RatReportMojo.createReport(RatReportMojo.java:148)
 at org.apache.rat.mp.RatReportMojo.generate(RatReportMojo.java:310)
 at org.apache.rat.mp.RatReportMojo.execute(RatReportMojo.java:210)
 I assume there must be a problem with one of the REs which is triggering lots 
 of backtracking when applied to files under site-content/, which is a working 
 copy of:
 https://svn.apache.org/repos/infra/websites/production/commons/content/proper/commons-io
 Last Changed Rev: 861378
 This directory should not have been included in the RAT scan, but the files 
 don't cause problems for RAT 0.8.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

[jira] [Commented] (RAT-138) RAT runs very slowly on some input

[Sebb (JIRA)]

[ 
https://issues.apache.org/jira/browse/RAT-138?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13661134#comment-13661134
 ] 

Sebb commented on RAT-138:
--

Actually, the issue seems to be multi-line matching.

The OASIS license matcher looks for the initial copyright line, and only then 
tries using the full text matcher.

If the copyright line is not present in a file, it's very quick to scan.
However, if the OASIS copyright line is present, but the rest of the license is 
not, then the matching is very slow, even in 0.8.

It helps to use String.contains rather than regexes, but that does not entirely 
solve the slowness.
The technique used in FullTextMatchingLicense is clearly not very efficient.

I think the problem is that the text buffer keeps getting bigger even if there 
is no chance of a match for the first part of the license, so matching gets 
more and more expensive. The OASIS code avoids this for valid licences, but 
allows the initial Copyright to be far away from the rest of the license (which 
is why it is slow if that is missing)

If the initial line is not immediately followed by the rest of the license, 
then it should be possible to restart looking for the first line. However the 
entire buffer cannot be discarded without first checking whether the first line 
has been seen again already. This is unlikely, but possible.

 RAT runs very slowly on some input
 --

 Key: RAT-138
 URL: https://issues.apache.org/jira/browse/RAT-138
 Project: Apache Rat
  Issue Type: Bug
  Components: engine
Affects Versions: 0.9
Reporter: Sebb
  Labels: perfomance, regression

 Commons IO discovered that mvn site was spending a lot of time running RAT 
 0.9. Reverting to 0.8 fixes the problem.
 Turns out that certain files seem to cause RAT to chew CPU in the 
 Pattern.matcher; here is a sample stack trace from a thread dump:
 main prio=6 tid=0x003c8c00 nid=0xa4c runnable [0x00a5e000]
java.lang.Thread.State: RUNNABLE
 at java.util.regex.Pattern$Curly.match0(Pattern.java:4166)
 at java.util.regex.Pattern$Curly.match(Pattern.java:4132)
 at java.util.regex.Matcher.match(Matcher.java:1221)
 at java.util.regex.Matcher.matches(Matcher.java:559)
 at 
 org.apache.rat.analysis.license.FullTextMatchingLicense.match(FullTextMatchingLicense.java:79)
 at 
 org.apache.rat.analysis.util.HeaderMatcherMultiplexer.match(HeaderMatcherMultiplexer.java:42)
 at 
 org.apache.rat.analysis.HeaderCheckWorker.readLine(HeaderCheckWorker.java:113)
 at 
 org.apache.rat.analysis.HeaderCheckWorker.read(HeaderCheckWorker.java:84)
 at 
 org.apache.rat.analysis.DocumentHeaderAnalyser.analyse(DocumentHeaderAnalyser.java:43)
 at 
 org.apache.rat.analysis.DefaultAnalyserFactory$DefaultAnalyser.analyse(DefaultAnalyserFactory.java:60)
 at 
 org.apache.rat.document.impl.util.DocumentAnalyserMultiplexer.analyse(DocumentAnalyserMultiplexer.java:37)
 at 
 org.apache.rat.report.claim.util.ClaimReporterMultiplexer.report(ClaimReporterMultiplexer.java:42)
 at org.apache.rat.mp.FilesReportable.run(FilesReportable.java:68)
 at org.apache.rat.Report.report(Report.java:393)
 at org.apache.rat.Report.report(Report.java:373)
 at 
 org.apache.rat.mp.AbstractRatMojo.createReport(AbstractRatMojo.java:462)
 at 
 org.apache.rat.mp.RatReportMojo.createReport(RatReportMojo.java:148)
 at org.apache.rat.mp.RatReportMojo.generate(RatReportMojo.java:310)
 at org.apache.rat.mp.RatReportMojo.execute(RatReportMojo.java:210)
 I assume there must be a problem with one of the REs which is triggering lots 
 of backtracking when applied to files under site-content/, which is a working 
 copy of:
 https://svn.apache.org/repos/infra/websites/production/commons/content/proper/commons-io
 Last Changed Rev: 861378
 This directory should not have been included in the RAT scan, but the files 
 don't cause problems for RAT 0.8.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

[jira] [Commented] (RAT-139) FullTextMatchingLicense.prune uses inefficient deleteAtChar

[Sebb (JIRA)]

[ 
https://issues.apache.org/jira/browse/RAT-139?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13661375#comment-13661375
 ] 

Sebb commented on RAT-139:
--

Likewise for AppliedApacheSoftwareLicense20#prune

 FullTextMatchingLicense.prune uses inefficient deleteAtChar
 ---

 Key: RAT-139
 URL: https://issues.apache.org/jira/browse/RAT-139
 Project: Apache Rat
  Issue Type: Improvement
Reporter: Sebb

 FullTextMatchingLicense.prune is quite inefficient.
 It first copies the entire string to a StringBuilder, then scans the buffer 
 deleting characters that are not letters or digits.
 It should be a lot quicker to just copy the letters and digits once, skipping 
 the rest.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

[jira] [Updated] (RAT-139) FullTextMatchingLicense.prune uses inefficient deleteAtChar

[Sebb (JIRA)]

 [ 
https://issues.apache.org/jira/browse/RAT-139?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Sebb updated RAT-139:
-

Affects Version/s: 0.9

 FullTextMatchingLicense.prune uses inefficient deleteAtChar
 ---

 Key: RAT-139
 URL: https://issues.apache.org/jira/browse/RAT-139
 Project: Apache Rat
  Issue Type: Improvement
Affects Versions: 0.9
Reporter: Sebb

 FullTextMatchingLicense.prune is quite inefficient.
 It first copies the entire string to a StringBuilder, then scans the buffer 
 deleting characters that are not letters or digits.
 It should be a lot quicker to just copy the letters and digits once, skipping 
 the rest.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

[jira] [Updated] (RAT-139) FullTextMatchingLicense.prune uses inefficient deleteAtChar

[Sebb (JIRA)]

 [ 
https://issues.apache.org/jira/browse/RAT-139?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Sebb updated RAT-139:
-

Fix Version/s: 0.10

 FullTextMatchingLicense.prune uses inefficient deleteAtChar
 ---

 Key: RAT-139
 URL: https://issues.apache.org/jira/browse/RAT-139
 Project: Apache Rat
  Issue Type: Improvement
Affects Versions: 0.9
Reporter: Sebb
 Fix For: 0.10


 FullTextMatchingLicense.prune is quite inefficient.
 It first copies the entire string to a StringBuilder, then scans the buffer 
 deleting characters that are not letters or digits.
 It should be a lot quicker to just copy the letters and digits once, skipping 
 the rest.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

[jira] [Commented] (RAT-138) RAT runs very slowly on some input

[Sebb (JIRA)]

[ 
https://issues.apache.org/jira/browse/RAT-138?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13661378#comment-13661378
 ] 

Sebb commented on RAT-138:
--

URL: http://svn.apache.org/r1484128
Log:
RAT-138 RAT runs very slowly on some input
Use String matching by default rather than building patterns

Modified:

creadur/rat/trunk/apache-rat-core/src/main/java/org/apache/rat/analysis/generation/GeneratedLicenseNotRequired.java


 RAT runs very slowly on some input
 --

 Key: RAT-138
 URL: https://issues.apache.org/jira/browse/RAT-138
 Project: Apache Rat
  Issue Type: Bug
  Components: engine
Affects Versions: 0.9
Reporter: Sebb
  Labels: perfomance, regression

 Commons IO discovered that mvn site was spending a lot of time running RAT 
 0.9. Reverting to 0.8 fixes the problem.
 Turns out that certain files seem to cause RAT to chew CPU in the 
 Pattern.matcher; here is a sample stack trace from a thread dump:
 main prio=6 tid=0x003c8c00 nid=0xa4c runnable [0x00a5e000]
java.lang.Thread.State: RUNNABLE
 at java.util.regex.Pattern$Curly.match0(Pattern.java:4166)
 at java.util.regex.Pattern$Curly.match(Pattern.java:4132)
 at java.util.regex.Matcher.match(Matcher.java:1221)
 at java.util.regex.Matcher.matches(Matcher.java:559)
 at 
 org.apache.rat.analysis.license.FullTextMatchingLicense.match(FullTextMatchingLicense.java:79)
 at 
 org.apache.rat.analysis.util.HeaderMatcherMultiplexer.match(HeaderMatcherMultiplexer.java:42)
 at 
 org.apache.rat.analysis.HeaderCheckWorker.readLine(HeaderCheckWorker.java:113)
 at 
 org.apache.rat.analysis.HeaderCheckWorker.read(HeaderCheckWorker.java:84)
 at 
 org.apache.rat.analysis.DocumentHeaderAnalyser.analyse(DocumentHeaderAnalyser.java:43)
 at 
 org.apache.rat.analysis.DefaultAnalyserFactory$DefaultAnalyser.analyse(DefaultAnalyserFactory.java:60)
 at 
 org.apache.rat.document.impl.util.DocumentAnalyserMultiplexer.analyse(DocumentAnalyserMultiplexer.java:37)
 at 
 org.apache.rat.report.claim.util.ClaimReporterMultiplexer.report(ClaimReporterMultiplexer.java:42)
 at org.apache.rat.mp.FilesReportable.run(FilesReportable.java:68)
 at org.apache.rat.Report.report(Report.java:393)
 at org.apache.rat.Report.report(Report.java:373)
 at 
 org.apache.rat.mp.AbstractRatMojo.createReport(AbstractRatMojo.java:462)
 at 
 org.apache.rat.mp.RatReportMojo.createReport(RatReportMojo.java:148)
 at org.apache.rat.mp.RatReportMojo.generate(RatReportMojo.java:310)
 at org.apache.rat.mp.RatReportMojo.execute(RatReportMojo.java:210)
 I assume there must be a problem with one of the REs which is triggering lots 
 of backtracking when applied to files under site-content/, which is a working 
 copy of:
 https://svn.apache.org/repos/infra/websites/production/commons/content/proper/commons-io
 Last Changed Rev: 861378
 This directory should not have been included in the RAT scan, but the files 
 don't cause problems for RAT 0.8.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

[jira] [Created] (RAT-140) OASISLicense allows invalid text

[Sebb (JIRA)]

Sebb created RAT-140:


 Summary: OASISLicense allows invalid text
 Key: RAT-140
 URL: https://issues.apache.org/jira/browse/RAT-140
 Project: Apache Rat
  Issue Type: Bug
Affects Versions: 0.9
Reporter: Sebb


The OASIS License Copyright pattern currently matches the text

CopyrightOASIS Open

This is clearly incorrect; there should be at least one whitespace after the 
Copyright word.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

[jira] [Resolved] (RAT-138) RAT runs very slowly on some input

[Sebb (JIRA)]

 [ 
https://issues.apache.org/jira/browse/RAT-138?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Sebb resolved RAT-138.
--

   Resolution: Fixed
Fix Version/s: 0.10

URL: http://svn.apache.org/r1484209
Log:
RAT-138 RAT runs very slowly on some input
Ensure buffer only grows sufficiently large to allow a match
Speeds up processing considerably

Modified:

creadur/rat/trunk/apache-rat-core/src/main/java/org/apache/rat/analysis/license/FullTextMatchingLicense.java


 RAT runs very slowly on some input
 --

 Key: RAT-138
 URL: https://issues.apache.org/jira/browse/RAT-138
 Project: Apache Rat
  Issue Type: Bug
  Components: engine
Affects Versions: 0.9
Reporter: Sebb
  Labels: perfomance, regression
 Fix For: 0.10


 Commons IO discovered that mvn site was spending a lot of time running RAT 
 0.9. Reverting to 0.8 fixes the problem.
 Turns out that certain files seem to cause RAT to chew CPU in the 
 Pattern.matcher; here is a sample stack trace from a thread dump:
 main prio=6 tid=0x003c8c00 nid=0xa4c runnable [0x00a5e000]
java.lang.Thread.State: RUNNABLE
 at java.util.regex.Pattern$Curly.match0(Pattern.java:4166)
 at java.util.regex.Pattern$Curly.match(Pattern.java:4132)
 at java.util.regex.Matcher.match(Matcher.java:1221)
 at java.util.regex.Matcher.matches(Matcher.java:559)
 at 
 org.apache.rat.analysis.license.FullTextMatchingLicense.match(FullTextMatchingLicense.java:79)
 at 
 org.apache.rat.analysis.util.HeaderMatcherMultiplexer.match(HeaderMatcherMultiplexer.java:42)
 at 
 org.apache.rat.analysis.HeaderCheckWorker.readLine(HeaderCheckWorker.java:113)
 at 
 org.apache.rat.analysis.HeaderCheckWorker.read(HeaderCheckWorker.java:84)
 at 
 org.apache.rat.analysis.DocumentHeaderAnalyser.analyse(DocumentHeaderAnalyser.java:43)
 at 
 org.apache.rat.analysis.DefaultAnalyserFactory$DefaultAnalyser.analyse(DefaultAnalyserFactory.java:60)
 at 
 org.apache.rat.document.impl.util.DocumentAnalyserMultiplexer.analyse(DocumentAnalyserMultiplexer.java:37)
 at 
 org.apache.rat.report.claim.util.ClaimReporterMultiplexer.report(ClaimReporterMultiplexer.java:42)
 at org.apache.rat.mp.FilesReportable.run(FilesReportable.java:68)
 at org.apache.rat.Report.report(Report.java:393)
 at org.apache.rat.Report.report(Report.java:373)
 at 
 org.apache.rat.mp.AbstractRatMojo.createReport(AbstractRatMojo.java:462)
 at 
 org.apache.rat.mp.RatReportMojo.createReport(RatReportMojo.java:148)
 at org.apache.rat.mp.RatReportMojo.generate(RatReportMojo.java:310)
 at org.apache.rat.mp.RatReportMojo.execute(RatReportMojo.java:210)
 I assume there must be a problem with one of the REs which is triggering lots 
 of backtracking when applied to files under site-content/, which is a working 
 copy of:
 https://svn.apache.org/repos/infra/websites/production/commons/content/proper/commons-io
 Last Changed Rev: 861378
 This directory should not have been included in the RAT scan, but the files 
 don't cause problems for RAT 0.8.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

[jira] [Updated] (RAT-138) RAT runs very slowly on some input

[Sebb (JIRA)]

 [ 
https://issues.apache.org/jira/browse/RAT-138?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Sebb updated RAT-138:
-

Affects Version/s: 0.8

 RAT runs very slowly on some input
 --

 Key: RAT-138
 URL: https://issues.apache.org/jira/browse/RAT-138
 Project: Apache Rat
  Issue Type: Bug
  Components: engine
Affects Versions: 0.8, 0.9
Reporter: Sebb
  Labels: perfomance, regression
 Fix For: 0.10


 Commons IO discovered that mvn site was spending a lot of time running RAT 
 0.9. Reverting to 0.8 fixes the problem.
 Turns out that certain files seem to cause RAT to chew CPU in the 
 Pattern.matcher; here is a sample stack trace from a thread dump:
 main prio=6 tid=0x003c8c00 nid=0xa4c runnable [0x00a5e000]
java.lang.Thread.State: RUNNABLE
 at java.util.regex.Pattern$Curly.match0(Pattern.java:4166)
 at java.util.regex.Pattern$Curly.match(Pattern.java:4132)
 at java.util.regex.Matcher.match(Matcher.java:1221)
 at java.util.regex.Matcher.matches(Matcher.java:559)
 at 
 org.apache.rat.analysis.license.FullTextMatchingLicense.match(FullTextMatchingLicense.java:79)
 at 
 org.apache.rat.analysis.util.HeaderMatcherMultiplexer.match(HeaderMatcherMultiplexer.java:42)
 at 
 org.apache.rat.analysis.HeaderCheckWorker.readLine(HeaderCheckWorker.java:113)
 at 
 org.apache.rat.analysis.HeaderCheckWorker.read(HeaderCheckWorker.java:84)
 at 
 org.apache.rat.analysis.DocumentHeaderAnalyser.analyse(DocumentHeaderAnalyser.java:43)
 at 
 org.apache.rat.analysis.DefaultAnalyserFactory$DefaultAnalyser.analyse(DefaultAnalyserFactory.java:60)
 at 
 org.apache.rat.document.impl.util.DocumentAnalyserMultiplexer.analyse(DocumentAnalyserMultiplexer.java:37)
 at 
 org.apache.rat.report.claim.util.ClaimReporterMultiplexer.report(ClaimReporterMultiplexer.java:42)
 at org.apache.rat.mp.FilesReportable.run(FilesReportable.java:68)
 at org.apache.rat.Report.report(Report.java:393)
 at org.apache.rat.Report.report(Report.java:373)
 at 
 org.apache.rat.mp.AbstractRatMojo.createReport(AbstractRatMojo.java:462)
 at 
 org.apache.rat.mp.RatReportMojo.createReport(RatReportMojo.java:148)
 at org.apache.rat.mp.RatReportMojo.generate(RatReportMojo.java:310)
 at org.apache.rat.mp.RatReportMojo.execute(RatReportMojo.java:210)
 I assume there must be a problem with one of the REs which is triggering lots 
 of backtracking when applied to files under site-content/, which is a working 
 copy of:
 https://svn.apache.org/repos/infra/websites/production/commons/content/proper/commons-io
 Last Changed Rev: 861378
 This directory should not have been included in the RAT scan, but the files 
 don't cause problems for RAT 0.8.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

[jira] [Created] (RAT-141) JavaDocLicenseNotRequired seems to be redundant

[Sebb (JIRA)]

Sebb created RAT-141:


 Summary: JavaDocLicenseNotRequired seems to be redundant
 Key: RAT-141
 URL: https://issues.apache.org/jira/browse/RAT-141
 Project: Apache Rat
  Issue Type: Bug
Reporter: Sebb


JavaDocLicenseNotRequired does exactly the same as GeneratedLicenseNotRequired 
if it finds a match; they both set the family to GEN.

Perhaps the intention was to create a separate License family for Javadoc files?

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

[jira] [Reopened] (RAT-138) RAT runs very slowly on some input

[Sebb (JIRA)]

 [ 
https://issues.apache.org/jira/browse/RAT-138?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Sebb reopened RAT-138:
--


Same problem applies to AppliedApacheSoftwareLicense20.

This detects the copyright header and then buffers everything until it matches 
the rest of the license.

This could use the same approach as the FullText case, however that would allow 
the Copyright and body to be widely separated, which is not ideal. But at least 
it would avoid the long run time.

 RAT runs very slowly on some input
 --

 Key: RAT-138
 URL: https://issues.apache.org/jira/browse/RAT-138
 Project: Apache Rat
  Issue Type: Bug
  Components: engine
Affects Versions: 0.8, 0.9
Reporter: Sebb
  Labels: perfomance, regression
 Fix For: 0.10


 Commons IO discovered that mvn site was spending a lot of time running RAT 
 0.9. Reverting to 0.8 fixes the problem.
 Turns out that certain files seem to cause RAT to chew CPU in the 
 Pattern.matcher; here is a sample stack trace from a thread dump:
 main prio=6 tid=0x003c8c00 nid=0xa4c runnable [0x00a5e000]
java.lang.Thread.State: RUNNABLE
 at java.util.regex.Pattern$Curly.match0(Pattern.java:4166)
 at java.util.regex.Pattern$Curly.match(Pattern.java:4132)
 at java.util.regex.Matcher.match(Matcher.java:1221)
 at java.util.regex.Matcher.matches(Matcher.java:559)
 at 
 org.apache.rat.analysis.license.FullTextMatchingLicense.match(FullTextMatchingLicense.java:79)
 at 
 org.apache.rat.analysis.util.HeaderMatcherMultiplexer.match(HeaderMatcherMultiplexer.java:42)
 at 
 org.apache.rat.analysis.HeaderCheckWorker.readLine(HeaderCheckWorker.java:113)
 at 
 org.apache.rat.analysis.HeaderCheckWorker.read(HeaderCheckWorker.java:84)
 at 
 org.apache.rat.analysis.DocumentHeaderAnalyser.analyse(DocumentHeaderAnalyser.java:43)
 at 
 org.apache.rat.analysis.DefaultAnalyserFactory$DefaultAnalyser.analyse(DefaultAnalyserFactory.java:60)
 at 
 org.apache.rat.document.impl.util.DocumentAnalyserMultiplexer.analyse(DocumentAnalyserMultiplexer.java:37)
 at 
 org.apache.rat.report.claim.util.ClaimReporterMultiplexer.report(ClaimReporterMultiplexer.java:42)
 at org.apache.rat.mp.FilesReportable.run(FilesReportable.java:68)
 at org.apache.rat.Report.report(Report.java:393)
 at org.apache.rat.Report.report(Report.java:373)
 at 
 org.apache.rat.mp.AbstractRatMojo.createReport(AbstractRatMojo.java:462)
 at 
 org.apache.rat.mp.RatReportMojo.createReport(RatReportMojo.java:148)
 at org.apache.rat.mp.RatReportMojo.generate(RatReportMojo.java:310)
 at org.apache.rat.mp.RatReportMojo.execute(RatReportMojo.java:210)
 I assume there must be a problem with one of the REs which is triggering lots 
 of backtracking when applied to files under site-content/, which is a working 
 copy of:
 https://svn.apache.org/repos/infra/websites/production/commons/content/proper/commons-io
 Last Changed Rev: 861378
 This directory should not have been included in the RAT scan, but the files 
 don't cause problems for RAT 0.8.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

[jira] [Comment Edited] (RAT-138) RAT runs very slowly on some input

[Sebb (JIRA)]

[ 
https://issues.apache.org/jira/browse/RAT-138?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13661549#comment-13661549
 ] 

Sebb edited comment on RAT-138 at 5/19/13 6:20 PM:
---

Same problem applies to AppliedApacheSoftwareLicense20.

This detects the copyright header and then buffers everything until it matches 
the rest of the license.

This could use the same approach as the FullText case.

  was (Author: s...@apache.org):
Same problem applies to AppliedApacheSoftwareLicense20.

This detects the copyright header and then buffers everything until it matches 
the rest of the license.

This could use the same approach as the FullText case, however that would allow 
the Copyright and body to be widely separated, which is not ideal. But at least 
it would avoid the long run time.
  
 RAT runs very slowly on some input
 --

 Key: RAT-138
 URL: https://issues.apache.org/jira/browse/RAT-138
 Project: Apache Rat
  Issue Type: Bug
  Components: engine
Affects Versions: 0.8, 0.9
Reporter: Sebb
  Labels: perfomance, regression
 Fix For: 0.10


 Commons IO discovered that mvn site was spending a lot of time running RAT 
 0.9. Reverting to 0.8 fixes the problem.
 Turns out that certain files seem to cause RAT to chew CPU in the 
 Pattern.matcher; here is a sample stack trace from a thread dump:
 main prio=6 tid=0x003c8c00 nid=0xa4c runnable [0x00a5e000]
java.lang.Thread.State: RUNNABLE
 at java.util.regex.Pattern$Curly.match0(Pattern.java:4166)
 at java.util.regex.Pattern$Curly.match(Pattern.java:4132)
 at java.util.regex.Matcher.match(Matcher.java:1221)
 at java.util.regex.Matcher.matches(Matcher.java:559)
 at 
 org.apache.rat.analysis.license.FullTextMatchingLicense.match(FullTextMatchingLicense.java:79)
 at 
 org.apache.rat.analysis.util.HeaderMatcherMultiplexer.match(HeaderMatcherMultiplexer.java:42)
 at 
 org.apache.rat.analysis.HeaderCheckWorker.readLine(HeaderCheckWorker.java:113)
 at 
 org.apache.rat.analysis.HeaderCheckWorker.read(HeaderCheckWorker.java:84)
 at 
 org.apache.rat.analysis.DocumentHeaderAnalyser.analyse(DocumentHeaderAnalyser.java:43)
 at 
 org.apache.rat.analysis.DefaultAnalyserFactory$DefaultAnalyser.analyse(DefaultAnalyserFactory.java:60)
 at 
 org.apache.rat.document.impl.util.DocumentAnalyserMultiplexer.analyse(DocumentAnalyserMultiplexer.java:37)
 at 
 org.apache.rat.report.claim.util.ClaimReporterMultiplexer.report(ClaimReporterMultiplexer.java:42)
 at org.apache.rat.mp.FilesReportable.run(FilesReportable.java:68)
 at org.apache.rat.Report.report(Report.java:393)
 at org.apache.rat.Report.report(Report.java:373)
 at 
 org.apache.rat.mp.AbstractRatMojo.createReport(AbstractRatMojo.java:462)
 at 
 org.apache.rat.mp.RatReportMojo.createReport(RatReportMojo.java:148)
 at org.apache.rat.mp.RatReportMojo.generate(RatReportMojo.java:310)
 at org.apache.rat.mp.RatReportMojo.execute(RatReportMojo.java:210)
 I assume there must be a problem with one of the REs which is triggering lots 
 of backtracking when applied to files under site-content/, which is a working 
 copy of:
 https://svn.apache.org/repos/infra/websites/production/commons/content/proper/commons-io
 Last Changed Rev: 861378
 This directory should not have been included in the RAT scan, but the files 
 don't cause problems for RAT 0.8.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

[jira] [Resolved] (RAT-138) RAT runs very slowly on some input

[Sebb (JIRA)]

 [ 
https://issues.apache.org/jira/browse/RAT-138?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Sebb resolved RAT-138.
--

Resolution: Fixed

Hopefully that's the last such class with problems:

URL: http://svn.apache.org/r1484335
Log:
RAT-138 RAT runs very slowly on some input
Fix AppliedApacheSoftwareLicense

Added:
creadur/rat/trunk/apache-rat-core/src/test/resources/appliedASL20/
creadur/rat/trunk/apache-rat-core/src/test/resources/appliedASL20/bad/

creadur/rat/trunk/apache-rat-core/src/test/resources/appliedASL20/bad/aasl20bad1.txt
   (with props)

creadur/rat/trunk/apache-rat-core/src/test/resources/appliedASL20/bad/aasl20bad2.txt
   (with props)
creadur/rat/trunk/apache-rat-core/src/test/resources/appliedASL20/good/

creadur/rat/trunk/apache-rat-core/src/test/resources/appliedASL20/good/aasl20good1.txt
   (with props)
Modified:

creadur/rat/trunk/apache-rat-core/src/main/java/org/apache/rat/analysis/license/AppliedApacheSoftwareLicense20.java

creadur/rat/trunk/apache-rat-core/src/test/java/org/apache/rat/analysis/license/AppliedApacheSoftwareLicense20Test.java


 RAT runs very slowly on some input
 --

 Key: RAT-138
 URL: https://issues.apache.org/jira/browse/RAT-138
 Project: Apache Rat
  Issue Type: Bug
  Components: engine
Affects Versions: 0.8, 0.9
Reporter: Sebb
  Labels: perfomance, regression
 Fix For: 0.10


 Commons IO discovered that mvn site was spending a lot of time running RAT 
 0.9. Reverting to 0.8 fixes the problem.
 Turns out that certain files seem to cause RAT to chew CPU in the 
 Pattern.matcher; here is a sample stack trace from a thread dump:
 main prio=6 tid=0x003c8c00 nid=0xa4c runnable [0x00a5e000]
java.lang.Thread.State: RUNNABLE
 at java.util.regex.Pattern$Curly.match0(Pattern.java:4166)
 at java.util.regex.Pattern$Curly.match(Pattern.java:4132)
 at java.util.regex.Matcher.match(Matcher.java:1221)
 at java.util.regex.Matcher.matches(Matcher.java:559)
 at 
 org.apache.rat.analysis.license.FullTextMatchingLicense.match(FullTextMatchingLicense.java:79)
 at 
 org.apache.rat.analysis.util.HeaderMatcherMultiplexer.match(HeaderMatcherMultiplexer.java:42)
 at 
 org.apache.rat.analysis.HeaderCheckWorker.readLine(HeaderCheckWorker.java:113)
 at 
 org.apache.rat.analysis.HeaderCheckWorker.read(HeaderCheckWorker.java:84)
 at 
 org.apache.rat.analysis.DocumentHeaderAnalyser.analyse(DocumentHeaderAnalyser.java:43)
 at 
 org.apache.rat.analysis.DefaultAnalyserFactory$DefaultAnalyser.analyse(DefaultAnalyserFactory.java:60)
 at 
 org.apache.rat.document.impl.util.DocumentAnalyserMultiplexer.analyse(DocumentAnalyserMultiplexer.java:37)
 at 
 org.apache.rat.report.claim.util.ClaimReporterMultiplexer.report(ClaimReporterMultiplexer.java:42)
 at org.apache.rat.mp.FilesReportable.run(FilesReportable.java:68)
 at org.apache.rat.Report.report(Report.java:393)
 at org.apache.rat.Report.report(Report.java:373)
 at 
 org.apache.rat.mp.AbstractRatMojo.createReport(AbstractRatMojo.java:462)
 at 
 org.apache.rat.mp.RatReportMojo.createReport(RatReportMojo.java:148)
 at org.apache.rat.mp.RatReportMojo.generate(RatReportMojo.java:310)
 at org.apache.rat.mp.RatReportMojo.execute(RatReportMojo.java:210)
 I assume there must be a problem with one of the REs which is triggering lots 
 of backtracking when applied to files under site-content/, which is a working 
 copy of:
 https://svn.apache.org/repos/infra/websites/production/commons/content/proper/commons-io
 Last Changed Rev: 861378
 This directory should not have been included in the RAT scan, but the files 
 don't cause problems for RAT 0.8.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

[jira] [Commented] (RAT-128) Use the proper name for Apache License

[Sebb (JIRA)]

[ 
https://issues.apache.org/jira/browse/RAT-128?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13662245#comment-13662245
 ] 

Sebb commented on RAT-128:
--

Fixed some instances:

URL: http://svn.apache.org/r1484543
Log:
RAT-128 Use the proper name for Apache License

Modified:

creadur/rat/trunk/apache-rat-core/src/main/java/org/apache/rat/analysis/license/ApacheSoftwareLicense20.java

creadur/rat/trunk/apache-rat-core/src/main/java/org/apache/rat/annotation/ApacheV2LicenceAppender.java

URL: http://svn.apache.org/r1484549
Log:
RAT-128 Use the proper name for Apache License

Modified:

creadur/rat/trunk/apache-rat-plugin/src/site/apt/examples/custom-license.apt.vm

However Software is used in some class names:

ApacheSoftwareLicense20
AppliedApacheSoftwareLicense20

which is unfortunate.

Also ASL is used in various public variables.


 Use the proper name for Apache License
 --

 Key: RAT-128
 URL: https://issues.apache.org/jira/browse/RAT-128
 Project: Apache Rat
  Issue Type: Bug
  Components: license-meta-data
Reporter: David Crossley

 The old license was called the Apache Software License, but not the new 
 one. It is called the Apache License. However RAT mixes up the terminology 
 using Apache Software License and ASL20.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

[jira] [Commented] (RAT-128) Use the proper name for Apache License

[Sebb (JIRA)]

[ 
https://issues.apache.org/jira/browse/RAT-128?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13662257#comment-13662257
 ] 

Sebb commented on RAT-128:
--

URL: http://svn.apache.org/r1484559
Log:
RAT-128 Use the proper name for Apache License

Added:
creadur/rat/trunk/apache-rat-core/src/test/resources/appliedAL20/
  - copied from r1484335, 
creadur/rat/trunk/apache-rat-core/src/test/resources/appliedASL20/

creadur/rat/trunk/apache-rat-core/src/test/resources/appliedAL20/bad/aal20bad1.txt
  - copied unchanged from r1484335, 
creadur/rat/trunk/apache-rat-core/src/test/resources/appliedASL20/bad/aasl20bad1.txt

creadur/rat/trunk/apache-rat-core/src/test/resources/appliedAL20/bad/aal20bad2.txt
  - copied unchanged from r1484335, 
creadur/rat/trunk/apache-rat-core/src/test/resources/appliedASL20/bad/aasl20bad2.txt

creadur/rat/trunk/apache-rat-core/src/test/resources/appliedAL20/good/aal20good1.txt
  - copied unchanged from r1484335, 
creadur/rat/trunk/apache-rat-core/src/test/resources/appliedASL20/good/aasl20good1.txt
Removed:

creadur/rat/trunk/apache-rat-core/src/test/resources/appliedAL20/bad/aasl20bad1.txt

creadur/rat/trunk/apache-rat-core/src/test/resources/appliedAL20/bad/aasl20bad2.txt

creadur/rat/trunk/apache-rat-core/src/test/resources/appliedAL20/good/aasl20good1.txt
creadur/rat/trunk/apache-rat-core/src/test/resources/appliedASL20/
Modified:
creadur/rat/trunk/RELEASE_NOTES.txt

creadur/rat/trunk/apache-rat-core/src/main/java/org/apache/rat/analysis/license/AppliedApacheSoftwareLicense20.java

creadur/rat/trunk/apache-rat-core/src/test/java/org/apache/rat/ReportTest.java

creadur/rat/trunk/apache-rat-core/src/test/java/org/apache/rat/analysis/license/AppliedApacheSoftwareLicense20Test.java

creadur/rat/trunk/apache-rat-core/src/test/java/org/apache/rat/policy/DefaultPolicyTest.java

creadur/rat/trunk/apache-rat-core/src/test/java/org/apache/rat/report/xml/XmlReportTest.java
creadur/rat/trunk/apache-rat-core/src/test/resources/elements/Source.java

creadur/rat/trunk/apache-rat-plugin/src/test/java/org/apache/rat/mp/RatCheckMojoTest.java

creadur/rat/trunk/apache-rat-tasks/src/test/java/org/apache/rat/anttasks/ReportTest.java

creadur/rat/trunk/apache-rat-tasks/src/test/resources/antunit/report-junit.xml

creadur/rat/trunk/apache-rat-tasks/src/test/resources/antunit/report-normal-operation.xml


 Use the proper name for Apache License
 --

 Key: RAT-128
 URL: https://issues.apache.org/jira/browse/RAT-128
 Project: Apache Rat
  Issue Type: Bug
  Components: license-meta-data
Reporter: David Crossley

 The old license was called the Apache Software License, but not the new 
 one. It is called the Apache License. However RAT mixes up the terminology 
 using Apache Software License and ASL20.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

[jira] [Commented] (RAT-137) Website shows incorrect Maven goals in some pages

[Sebb (JIRA)]

[ 
https://issues.apache.org/jira/browse/RAT-137?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13662301#comment-13662301
 ] 

Sebb commented on RAT-137:
--

URL: http://svn.apache.org/r1484565
Log:
RAT-137 Website shows incorrect Maven goals in some pages

Modified:
creadur/rat/trunk/apache-rat-plugin/src/site/apt/examples/basic.apt.vm
creadur/rat/trunk/apache-rat-plugin/src/site/apt/index.apt
creadur/rat/trunk/apache-rat-plugin/src/site/apt/usage.apt.vm

URL: http://svn.apache.org/r1484568
Log:
RAT-137 Website shows incorrect Maven goals in some pages

Modified:
creadur/rat/trunk/apache-rat-plugin/src/site/fml/faq.fml

Website not yet rebuilt

 Website shows incorrect Maven goals in some pages
 -

 Key: RAT-137
 URL: https://issues.apache.org/jira/browse/RAT-137
 Project: Apache Rat
  Issue Type: Bug
  Components: docs
Affects Versions: 0.9
Reporter: Sebb

 Website shows incorrect Maven goals.
 rat:check should be apache-rat:check
 rat:rat = apache-rat:rat
 in the following pages:
 http://creadur.apache.org/rat/apache-rat-plugin/index.html
 http://creadur.apache.org/rat/apache-rat-plugin/usage.html
 There may be others that are wrong

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

[jira] [Resolved] (RAT-133) Unthrown Exceptions

[Sebb (JIRA)]

 [ 
https://issues.apache.org/jira/browse/RAT-133?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Sebb resolved RAT-133.
--

   Resolution: Fixed
Fix Version/s: 0.10

 Unthrown Exceptions
 ---

 Key: RAT-133
 URL: https://issues.apache.org/jira/browse/RAT-133
 Project: Apache Rat
  Issue Type: Bug
Reporter: Sebb
Priority: Minor
 Fix For: 0.10

 Attachments: RAT-133.patch


 Eclipse reports several unthrown Exceptions.
 Either these should be removed (as per patch to follow), or - if they are 
 needed - they should be documented to avoid the warning.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

[jira] [Reopened] (RAT-2) RAT reports should be able to skip certain file types or contents:

[Sebb (JIRA)]

 [ 
https://issues.apache.org/jira/browse/RAT-2?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Sebb reopened RAT-2:



Some more work needed to add the exclusions for Maven and CLI invocation

 RAT reports should be able to skip certain file types or contents:
 --

 Key: RAT-2
 URL: https://issues.apache.org/jira/browse/RAT-2
 Project: Apache Rat
  Issue Type: Improvement
  Components: engine
Reporter: Sebb

 RAT reports should be able to skip certain file types or contents:
 MANIFEST files
 *.css where the contents is a single @include line
 CHANGES file
 It would be useful if exceptions could be configured on a per-project basis

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

[jira] [Commented] (RAT-150) RAT should use Apache Tika to simply guess ignored [application/X] file types and focus on the [text/Y] family as a sensible default

[Sebb (JIRA)]

[ 
https://issues.apache.org/jira/browse/RAT-150?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13753490#comment-13753490
 ] 

Sebb commented on RAT-150:
--

Although for compatibility (and perhaps performance?) such lists should 
continue to be supported.

 RAT should use Apache Tika to simply guess ignored [application/X] file types 
 and focus on the [text/Y] family as a sensible default
 

 Key: RAT-150
 URL: https://issues.apache.org/jira/browse/RAT-150
 Project: Apache Rat
  Issue Type: New Feature
  Components: mime-meta-data, scan
Affects Versions: 0.8
Reporter: Chris A. Mattmann

 RAT could use Apache Tika to automatically guess file types, obviating the 
 need to specify an explicit white list or black list.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

[jira] [Commented] (RAT-98) Maven RAT report does not document skipped files

[Sebb (JIRA)]

[ 
https://issues.apache.org/jira/browse/RAT-98?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13753493#comment-13753493
 ] 

Sebb commented on RAT-98:
-

It would be helpful to show the active include and exclude configuration on the 
report as well; this should be after any defaults have been applied. [The 
defaults may change between releases, so it is helpful to have the active 
settings documented.]

For excludes of directory trees, it probably does not make sense to list 
individual files (there will generally be too many).
It's really only for the more specific excludes where the file names might be 
useful - the exclude may be too general.

 Maven RAT report does not document skipped files
 

 Key: RAT-98
 URL: https://issues.apache.org/jira/browse/RAT-98
 Project: Apache Rat
  Issue Type: Bug
Reporter: Sebb

 The Maven RAT report should document which files have been skipped using the 
 exclude option.
 Either by listing the configuration details, or better by listing the file 
 names with a marker, e.g. EX to show they were deliberately skipped.
 Note: this only refers to files listed in exclude entries, not files which 
 are excluded by default.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

[jira] [Resolved] (RAT-129) Add support for CDDL 1.0

[Sebb (JIRA)]

 [ 
https://issues.apache.org/jira/browse/RAT-129?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Sebb resolved RAT-129.
--

Resolution: Fixed

 Add support for CDDL 1.0
 

 Key: RAT-129
 URL: https://issues.apache.org/jira/browse/RAT-129
 Project: Apache Rat
  Issue Type: Improvement
Reporter: Francesco Chicchiriccò
 Fix For: 0.11

 Attachments: RAT-129.patch


 The CDDL 1.0 is not currently supported.
 The attached patch adds this feature.



--
This message was sent by Atlassian JIRA
(v6.1#6144)

[jira] [Updated] (RAT-129) Add support for CDDL 1.0

[Sebb (JIRA)]

 [ 
https://issues.apache.org/jira/browse/RAT-129?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Sebb updated RAT-129:
-

Assignee: (was: Sebb)

 Add support for CDDL 1.0
 

 Key: RAT-129
 URL: https://issues.apache.org/jira/browse/RAT-129
 Project: Apache Rat
  Issue Type: Improvement
Reporter: Francesco Chicchiriccò
 Fix For: 0.11

 Attachments: RAT-129.patch


 The CDDL 1.0 is not currently supported.
 The attached patch adds this feature.



--
This message was sent by Atlassian JIRA
(v6.2#6252)

[jira] [Updated] (RAT-129) Add support for CDDL 1.0

[Sebb (JIRA)]

 [ 
https://issues.apache.org/jira/browse/RAT-129?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Sebb updated RAT-129:
-

Assignee: (was: Sebb)

 Add support for CDDL 1.0
 

 Key: RAT-129
 URL: https://issues.apache.org/jira/browse/RAT-129
 Project: Apache Rat
  Issue Type: Improvement
Reporter: Francesco Chicchiriccò
 Fix For: 0.11

 Attachments: RAT-129.patch


 The CDDL 1.0 is not currently supported.
 The attached patch adds this feature.



--
This message was sent by Atlassian JIRA
(v6.2#6252)

[jira] [Commented] (RAT-129) Add support for CDDL 1.0

[Sebb (JIRA)]

[ 
https://issues.apache.org/jira/browse/RAT-129?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13962387#comment-13962387
 ] 

Sebb commented on RAT-129:
--

AIUI the assignee field is used to take ownership of the issue whilst working 
on it; this avoids other people duplicating work.

That is not relevant once the issue is complete.

 Add support for CDDL 1.0
 

 Key: RAT-129
 URL: https://issues.apache.org/jira/browse/RAT-129
 Project: Apache Rat
  Issue Type: Improvement
Reporter: Francesco Chicchiriccò
Assignee: Sebb
 Fix For: 0.11

 Attachments: RAT-129.patch


 The CDDL 1.0 is not currently supported.
 The attached patch adds this feature.



--
This message was sent by Atlassian JIRA
(v6.2#6252)

[jira] [Closed] (RAT-143) Should support 'skip' property to override pom invocation

[Sebb (JIRA)]

 [ 
https://issues.apache.org/jira/browse/RAT-143?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Sebb closed RAT-143.



 Should support 'skip' property to override pom invocation
 -

 Key: RAT-143
 URL: https://issues.apache.org/jira/browse/RAT-143
 Project: Apache Rat
  Issue Type: New Feature
Reporter: Sebb





--
This message was sent by Atlassian JIRA
(v6.2#6252)

[jira] [Resolved] (RAT-143) Should support 'skip' property to override pom invocation

[Sebb (JIRA)]

 [ 
https://issues.apache.org/jira/browse/RAT-143?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Sebb resolved RAT-143.
--

Resolution: Duplicate

 Should support 'skip' property to override pom invocation
 -

 Key: RAT-143
 URL: https://issues.apache.org/jira/browse/RAT-143
 Project: Apache Rat
  Issue Type: New Feature
Reporter: Sebb





--
This message was sent by Atlassian JIRA
(v6.2#6252)

[jira] [Updated] (RAT-129) Add support for CDDL 1.0

[Sebb (JIRA)]

 [ 
https://issues.apache.org/jira/browse/RAT-129?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Sebb updated RAT-129:
-

Assignee: (was: Sebb)

 Add support for CDDL 1.0
 

 Key: RAT-129
 URL: https://issues.apache.org/jira/browse/RAT-129
 Project: Apache Rat
  Issue Type: Improvement
Reporter: Francesco Chicchiriccò
 Fix For: 0.11

 Attachments: RAT-129.patch


 The CDDL 1.0 is not currently supported.
 The attached patch adds this feature.



--
This message was sent by Atlassian JIRA
(v6.2#6252)

[jira] [Commented] (RAT-129) Add support for CDDL 1.0

[Sebb (JIRA)]

[ 
https://issues.apache.org/jira/browse/RAT-129?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14087788#comment-14087788
 ] 

Sebb commented on RAT-129:
--

In that case, I think all the other issue assigments are wrong.

I don't want to have issues assigned to me that I am not actually working on.

 Add support for CDDL 1.0
 

 Key: RAT-129
 URL: https://issues.apache.org/jira/browse/RAT-129
 Project: Apache Rat
  Issue Type: Improvement
Reporter: Francesco Chicchiriccò
Assignee: Sebb
 Fix For: 0.11

 Attachments: RAT-129.patch


 The CDDL 1.0 is not currently supported.
 The attached patch adds this feature.



--
This message was sent by Atlassian JIRA
(v6.2#6252)

[jira] [Commented] (RAT-167) Cleanup Build Infrastructure

[Sebb (JIRA)]

[ 
https://issues.apache.org/jira/browse/RAT-167?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14091742#comment-14091742
 ] 

Sebb commented on RAT-167:
--

It may also be worth running a build that uses the latest Java version.
This should help find some issues, e.g. Javadoc - Java 8 is stricter.

 Cleanup Build Infrastructure
 

 Key: RAT-167
 URL: https://issues.apache.org/jira/browse/RAT-167
 Project: Apache Rat
  Issue Type: Bug
Affects Versions: 0.12
Reporter: Philipp Ottlinger

 Currently there are the following build jobs that need to be cleaned up and 
 properly documented:
 # buildbot
 # Creadur-Rat
 # Creadur-Rat-Site
 Each build should enforce the correct targetJdk version.
 Furthermore we need to discuss which maven version we rely on - see 
 WHISKER-12 for the same stuff in a different component.
 Since many maven plugins remain on JDK5-compliant compiler level we should 
 use the same for all creadur maven plugins.



--
This message was sent by Atlassian JIRA
(v6.2#6252)

[jira] [Resolved] (RAT-169) IT tests it2 and it3 don't appear to be run

[Sebb (JIRA)]

 [ 
https://issues.apache.org/jira/browse/RAT-169?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Sebb resolved RAT-169.
--

Resolution: Not a Problem

The tests are run, but they are run by RatCheckMojoTest.java.

Thus they don't appear in the output as separate integration tests

 IT tests it2 and it3 don't appear to be run
 ---

 Key: RAT-169
 URL: https://issues.apache.org/jira/browse/RAT-169
 Project: Apache Rat
  Issue Type: Bug
Affects Versions: 0.11
Reporter: Sebb

 The Maven build output does not show that the it2 and it3 tests have been run.
 I suspect this is because there are no it2/it3 folders under the invoker 
 folder.



--
This message was sent by Atlassian JIRA
(v6.2#6252)

[jira] [Updated] (RAT-175) SourceCodeManagementSystems.hasIgnoreFile() should return boolean

[Sebb (JIRA)]

 [ 
https://issues.apache.org/jira/browse/RAT-175?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Sebb updated RAT-175:
-
Fix Version/s: 0.12

 SourceCodeManagementSystems.hasIgnoreFile() should return boolean
 -

 Key: RAT-175
 URL: https://issues.apache.org/jira/browse/RAT-175
 Project: Apache Rat
  Issue Type: Bug
Affects Versions: 0.11
Reporter: Sebb
 Fix For: 0.12


 org.apache.rat.config.SourceCodeManagementSystems.hasIgnoreFile() currently 
 returns Boolean. It should return boolean, to avoid the boxing conversions.
 AFAICT it is never used as a Boolean, only as a boolean



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)