On Fri, Jun 5, 2009 at 11:58 AM, Donald Woods <[email protected]> wrote:
> > > Michael Dick wrote: > >> On Fri, Jun 5, 2009 at 10:17 AM, Pinaki Poddar <[email protected]> >> wrote: >> >> Hi Mike, >>> >>>> Are the files generated during the build process or are they committed >>>> to >>>> SVN? >>>> >>> They are committed to SVN. Other Junit Test code needs them at >>> development/compile time. >>> >>> >> Why can't we run the tool to generate the code during the build? Ideally >> after running checkstyle, but if we can't do that then we can always >> disable >> the check. >> >> > Agree. Maybe by using the process-resource goal and antrun plugin? > > But, I could also see where we would want a handful of these checked in, > as a test to compare what the mapping tool is creating versus what we > expect. > Good idea. In that case we'd want to exclude those files from checkstyle (might list them explicitly or keep the wildcard I put in this morning). Antrun + test-compile might be where we want to go (after checkstyle runs for test classes). Could be a little ticklish getting the order right, I don't think maven allows you to specify orders within a phase. Should be doable though. -mike > > >> I think they should comply before we commit them. >>>> >>> They are generated by an automatic source code writer. The writer/code >>> generator does not have a notion of line length limit during output. To >>> enforce it via that code generator is neither trivial for the way it >>> emits >>> different code elements nor I have bandwidth to invest. If compliance to >>> line length limit is paramount, then whichever issue (I still could not >>> find >>> that JIRA) is handling that task may take that up. >>> >>> >> I think that compliance to code conventions is paramount for anything we >> commit to SVN. What the line length is set to is debatable, but if it's >> committed then it should conform. >> >> <snip> >> >> -mike >> >>
