openjpa-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Michael Dick <>
Subject Re: 80-column line width & auto-generated model classes
Date Fri, 05 Jun 2009 17:58:07 GMT
On Fri, Jun 5, 2009 at 11:58 AM, Donald Woods <> wrote:

> Michael Dick wrote:
>> On Fri, Jun 5, 2009 at 10:17 AM, Pinaki Poddar <>
>> 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.


>>  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

  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message