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/%3c61c9bc470911171514u41825c9ud28bd3276ab3b...@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" <andrew.f.h...@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.mattm...@jpl.nasa.gov > WWW: http://sunset.usc.edu/~mattmann/ > ++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++ > Adjunct Assistant Professor, Computer Science Department > University of Southern California, Los Angeles, CA 90089 USA > ++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++ >
