openjpa-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Michael Dick <michael.d.d...@gmail.com>
Subject Re: 80-column line width & auto-generated model classes
Date Mon, 15 Jun 2009 16:59:58 GMT
Hi all,

The main problem with using ant to generate the metamodel classes is that a
vanilla checkout from SVN will not compile until you run a maven build.
You'd probably see this is you checked out directly from your IDE of choice.


One can argue that we're already in that boat with the javacc classes in
openjpa-kernel, but there's no real good reason to compound the issue.

Bearing that in mind I don't think we need to apply the 80 column rule to
metamodel classes. If anyone else has a compelling reason why we should
apply the rule please respond here (and I'll pull out the change again).

-mike

On Fri, Jun 5, 2009 at 12:58 PM, Michael Dick <michael.d.dick@gmail.com>wrote:

> On Fri, Jun 5, 2009 at 11:58 AM, Donald Woods <dwoods@apache.org> wrote:
>
>>
>>
>> Michael Dick wrote:
>>
>>> On Fri, Jun 5, 2009 at 10:17 AM, Pinaki Poddar <ppoddar@apache.org>
>>> 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
>>>
>>>
>

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