[
https://issues.apache.org/jira/browse/UIMA-3310?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13780061#comment-13780061
]
Marshall Schor commented on UIMA-3310:
--------------------------------------
I took a look to see what's different between uima-as and uimaj. Based on
that, here's my conclusions:
RAT is best (recommend) run on each module of a multi-module project. You can
see this because the automatic rat excludes for eclipse (when
"useDefaultExcludes" is true, which is the default, and which is how we're
configured), have implicit excludes of target/**/* and .classpath and .project,
etc., but not patterns like: **/target/**/* and **/.classpath, etc.
In other words, these patterns are expected to be applied at the project level.
This works fine when the submodules are built. When a containing module (which
physically has the submodules as child directories within it, which is the
Maven convention) are built, RAT has a provision to exclude these submodules
from the checking: the parameter excludeSubProjects. The doc for this says
"Whether to exclude subprojects. This is recommended, if you want a separate
apache-rat-plugin report for each subproject. Default value is: true."
This is defaulted to true in our builds. So you would think that running RAT
at the top level would exclude the subproject, but there's an unfixed bug in
this: it doesn't work if the module structure is more than one deep. See
https://issues.apache.org/jira/browse/RAT-97 .
The module structure of uima-as:
uima-as
parent
aggregate-uima-as
uimaj-as-activemq
uimaj-as-core
...
aggregate-uima-as-eclipse-plugins
uimaj-ep-deployeditor
...
Two things have to be true for the failure to show:
1) the module structure has to be multi-level
2) the particular project being built has to physically have a subdirectory
with the subprojects.
Now, we only satisfy condition 2) for the top level project. That is, our
sublevel projects are not physically nested under the aggregate-... projects.
With this, the "workaround" for projects is as follows:
(NOTE This may need a bit of debugging, please try and see if it works :-) )
1) add the rat excludes that are common across the whole project and which are
not already in the uima-wide parent pom :-) to the multi-module parent-pom (in
this case, uima-as-parent. Don't add these to the uima-as (e.g. top level),
because we want them to be inherited by all the project's poms.
2) add a workaround exclude that excludes all the projects as subprojects.
This looks like:
<exclude>[subprojectName]/**</exclude>
where subproject would be the top level subdirectories of the subprojects
nested in the top level uima-as directory, like: aggregate-uima-as/**,
uima-as-parent/**, etc.
If you don't need any custom overrides then you can put the special work-around
configuration into just the top level project pom, rather than the parent-pom.
This is what uimaj does (although it has a bunch of other unneeded excludes -
these are duplicating ones contained in the main parent-pom).
> Modify Top UIMA-AS pom to add uima-as-eclipse-update-site to RAT excludes
> -------------------------------------------------------------------------
>
> Key: UIMA-3310
> URL: https://issues.apache.org/jira/browse/UIMA-3310
> Project: UIMA
> Issue Type: Bug
> Components: Async Scaleout
> Reporter: Jerry Cwiklik
> Assignee: Jerry Cwiklik
> Priority: Minor
> Fix For: 2.4.2AS
>
>
> Add
> <exclude>uima-as-eclipse-update-site/.classpath</exclude>
> <exclude>uima-as-eclipse-update-site/.project</exclude>
> <exclude>uima-as-eclipse-update-site/.settings/**</exclude>
> to UIMA-AS top pom.xml to keep rat plugin happy
--
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
