You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@oodt.apache.org by Andrew Hart <an...@jpl.nasa.gov> on 2010/09/01 19:29:23 UTC
Question about RAT blocking the standard build process
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]
------------------------------------------------------------------------
[ERROR] BUILD FAILURE
[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.
Re: Question about RAT blocking the standard build process
Posted by David M Woollard <wo...@jpl.nasa.gov>.
Andrew,
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 RAT.
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?
-Dave
[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]
> ------------------------------------------------------------------------
> [ERROR] BUILD FAILURE
> [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.
>
>
>
>
Re: Question about RAT blocking the standard build process
Posted by David M Woollard <wo...@jpl.nasa.gov>.
Guys,
I might also include in the discussion an email that I found useful in deciding how to incorporate RAT [1]. I'd invite others, including Ross, to comment as well, but I think there is great value in knowing immediately if something is potentially problematic from a licensing perspective.
Some use cases in which I think this is helpful:
1) Vetting a contributed patch. The committer will immediately be informed of any licensing issues that need to be addressed with the patch.
2) Smaller, incremental additions of new project artifacts. You know when you have a licensing problem.
Some cases were it is less useful:
3) Porting a larger set of existing artifacts.
To date, we have only included RAT in the build for components that have already been fully ported from JPL land to Apache and have been vetted for licensing (see OODT-3 [2]), so this should mainly be applicable to scenarios one and two.
-Dave
[1] http://mail-archives.apache.org/mod_mbox/incubator-rat-dev/200911.mbox/%3c61c9bc470911171514u41825c9ud28bd3276ab3babc@mail.gmail.com%3e
[2] https://issues.apache.org/jira/browse/OODT-3
---------------------------------------------------------
David M. Woollard, Software Engineer
Data Management Systems and Technologies Group (388J)
NASA Jet Propulsion Laboratory, Pasadena, CA, 91109, USA
Office: 171-243D Phone: (818) 354-4291
"Anybody who wants to make a revolution shouldn't grab a gun.
Just go and start working to change the world by using science
and technology." -Stanford Ovshinsky
On Sep 1, 2010, at 10:54 AM, Mattmann, Chris A (388J) wrote:
> Hi Andrew and Dave,
>
> Interesting. Yeah I think that RAT shouldn't per se block a build unless we specifically ask it to (i.e., where it matters, on releases and distribution). That said, I think this can be overcome by commenting out the RAT plugin in your xmlps code. Question: the code you are developing with xmlps for OODT-29: does that have license info in it? If not, then that's likely why RAT is choking, but you're probably already aware of that. If the answer there is, the priority is functionality over license stuff before the patch, I totally understand and my suggesting would be to just remove the RAT parts from the xmlps POM for now, until you're ready to integrate.
>
> HTH,
> Chris
>
>
>
> On 9/1/10 10:29 AM, "Andrew Hart" <an...@jpl.nasa.gov> 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]
> ------------------------------------------------------------------------
> [ERROR] BUILD FAILURE
> [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.
>
>
>
>
>
>
>
> ++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
> Chris Mattmann, Ph.D.
> Senior Computer Scientist
> NASA Jet Propulsion Laboratory Pasadena, CA 91109 USA
> Office: 171-266B, Mailstop: 171-246
> Email: Chris.Mattmann@jpl.nasa.gov
> WWW: http://sunset.usc.edu/~mattmann/
> ++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
> Adjunct Assistant Professor, Computer Science Department
> University of Southern California, Los Angeles, CA 90089 USA
> ++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
>
Re: Question about RAT blocking the standard build process
Posted by "Mattmann, Chris A (388J)" <ch...@jpl.nasa.gov>.
Hi Andrew and Dave,
Interesting. Yeah I think that RAT shouldn't per se block a build unless we specifically ask it to (i.e., where it matters, on releases and distribution). That said, I think this can be overcome by commenting out the RAT plugin in your xmlps code. Question: the code you are developing with xmlps for OODT-29: does that have license info in it? If not, then that's likely why RAT is choking, but you're probably already aware of that. If the answer there is, the priority is functionality over license stuff before the patch, I totally understand and my suggesting would be to just remove the RAT parts from the xmlps POM for now, until you're ready to integrate.
HTH,
Chris
On 9/1/10 10:29 AM, "Andrew Hart" <an...@jpl.nasa.gov> 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]
------------------------------------------------------------------------
[ERROR] BUILD FAILURE
[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.
++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
Chris Mattmann, Ph.D.
Senior Computer Scientist
NASA Jet Propulsion Laboratory Pasadena, CA 91109 USA
Office: 171-266B, Mailstop: 171-246
Email: Chris.Mattmann@jpl.nasa.gov
WWW: http://sunset.usc.edu/~mattmann/
++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
Adjunct Assistant Professor, Computer Science Department
University of Southern California, Los Angeles, CA 90089 USA
++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++