oodt-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From David M Woollard <wooll...@jpl.nasa.gov>
Subject Re: Question about RAT blocking the standard build process
Date Wed, 01 Sep 2010 17:44:30 GMT

I introduced RAT as part of the build process while working toward closing out OODT-3 [1].
The reason for running RAT as part of the builds for some components is that we know immediately
when we introduce code that is not compliant with licensing, nor do will build and push out
anything that does not have the correct headers.

To clarify further, RAT is part of the build process for the established components that have
been vetted for licensing issues at this point. If you are making modifications to one of
these components locally, then you have three choices right now if you're build breaks on

1) Make sure the files you are including are correctly licensed w/ Apache headers

2) If the files should not have Apache licenses for some reason  (e.g., third party licensing,
test files that much be of a particular format, files that do not contain any intellectual
property), add the files to the RAT exceptions in the pom file.

3) If you are building locally, you can always comment out RAT (but I would say that you do
so at your own risk in as much as any patch, etc much be rat compliant eventually)

We can certainly have a discussion on the merits of incorporating RAT via a target separate
from the main build cycle, but I for one see substantial benefits to incorporating RAT so
we all know as soon as we introduce something incompatible with licensing. Might I ask what
you are working on and perhaps have you submit a patch that currently breaks the build?


[1] https://issues.apache.org/jira/browse/OODT-3

On Sep 1, 2010, at 10:29 AM, Andrew Hart wrote:

> Hey guys,
> Can anyone provide me with a little bit of information as to what is 
> going on here?
> I'm working with Dave Kale to implement OODT-29 (import web-grid into 
> apache oodt) and we've recently been frustrated by something which 
> appears to be related to RAT being a little (too?) controlling.
> We're in the debug stages of OODT-29, we've got a lot of work to do to 
> change jpl.eda namespaces, unit tests, etc over to o.a.oodt and, in the 
> process, we're attempting to compile and build occasionally as a sanity 
> check. The problem is, RAT won't let us do this at the moment:
> mvn -e install (from within xmlps)
> gives us:
> ....
> INFO] [rat:check {execution: default}]
> [INFO] 
> ------------------------------------------------------------------------
> [INFO] 
> ------------------------------------------------------------------------
> [INFO] Too many unapproved licenses: 0
> [INFO] 
> ------------------------------------------------------------------------
> [INFO] Trace
> org.apache.maven.BuildFailureException: Too many unapproved licenses: 0
>     at 
> org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoals(DefaultLifecycleExecutor.java:715)
>     .......
> Caused by: org.codehaus.mojo.rat.RatCheckException: Too many unapproved 
> licenses: 0
>     at org.codehaus.mojo.rat.RatCheckMojo.check(RatCheckMojo.java:224)
>     at org.codehaus.mojo.rat.RatCheckMojo.check(RatCheckMojo.java:216)
>     at org.codehaus.mojo.rat.RatCheckMojo.execute(RatCheckMojo.java:172)
>     at 
> org.apache.maven.plugin.DefaultPluginManager.executeMojo(DefaultPluginManager.java:490)
>     at 
> org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoals(DefaultLifecycleExecutor.java:694)
>     ... 17 more
> [INFO] 
> ------------------------------------------------------------------------
> [INFO] Total time: 7 seconds
> [INFO] Finished at: Wed Sep 01 09:54:25 PDT 2010
> [INFO] Final Memory: 50M/1132M
> [INFO] 
> ------------------------------------------------------------------------
> This didn't seem to be happening on earlier builds.
> A warning about licenses would be welcome, but forcing the build to fail 
> is maybe excessive? In fact, the jar actually DOES build, the only 
> effect this apparently has is that it prevents mvn from copying the jar 
> into the local  .m2 repository.
> I'm interested to know when this behavior became a part of the standard 
> build. Given that there are multiple other checkpoints at which RAT is 
> run to verify license compliance, I'm curious as to why have this here? 
> As an alternative, could we consider making a special build target, i.e.:
> "mvn validate install"
> that might include the added RAT checks and could be run when we 
> explicitly wish to confirm compliance?
> - Andrew.

View raw message