geronimo-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From David Blevins <david.blev...@visi.com>
Subject Re: gbuild: need up with eclipse tools setup?
Date Tue, 24 Jan 2006 02:55:11 GMT
Great.  You might want to check out the xmlbeans generation code.   
There might be something in there for you.  The mixed generated and  
not generate on a per method level aspect of this certainly presents  
an interesting spin on the problem.

What tool is generating this code?

-David

On Jan 23, 2006, at 5:36 PM, Sachin Patel wrote:

> Thanks David, you're exactly right.  This would hit other  
> developers as well.  I think I should be able to separate things out.
>
> - sachin
>
>
>
> On Jan 23, 2006, at 7:58 PM, David Blevins wrote:
>
>> On Jan 17, 2006, at 5:52 AM, Sachin Patel wrote:
>>
>>> I was tired of seeing all the BUILD FAILED errors so I disabled  
>>> it temorarily due to the one svn issue that keeps on appearing  
>>> stating a resource already exists when it updates.
>>>
>>> I know what exactly scenario triggers the error, and I'll  
>>> probably need your help debugging it.
>>>
>>> The problem is the following, perhaps you can make some sense out  
>>> of it...
>>>
>>> I have a project that consists of autogenerated EMF code. Most of  
>>> the generated code is not source controled and is created only  
>>> during the build.  In EMF, any generated class can be modified by  
>>> the developer to contain custom implementations of a method.  A  
>>> methods custom implementation can be preserved by adding a  
>>> @generated NOT comment on that method.  The next time the  
>>> generator is run, that method implementation is not overridden.
>>>
>>> So for all the classes where I do have custom implementations I  
>>> check only those into source control.  Anytime these source files  
>>> are committed, GBuild fails during the update stating the given  
>>> class already exists.
>>>
>>> So what happens on the gbuild end is the following...
>>>
>>> (1) An initial fresh checkout of the code
>>> (2) The plugin builds successfully, so there exist in the work  
>>> directory a file "N" that was generated during the build.
>>> (3) Now I end up making a custom changes to  "N" locally and commit.
>>> (4) GBuild does an update, but since the generated code never was  
>>> removed, "N" exists but the delta from the commit is "N" as well  
>>> so it complains that "N" is already there. Only if the existing  
>>> generated "N" from the previous build was removed, would the  
>>> update for the committed "N" work.
>>>
>>> Does that make sense?
>>>
>>
>> I follow, though I'm not sure why you'd set it up that way.   
>> Anyone who attempts to work with you on the eclipse tooling will  
>> run into the same issue when they checkout.
>>
>> Why don't you separate the generated source from the once- 
>> generated source?  In the main geronimo build we code generate  
>> tons and tons of xmlbeans classes and whatnot right into the  
>> target/ directory so they are never generated on top of anything  
>> that is scm controlled.
>>
>> Mixing build-time generated code in with your regular source  
>> doesn't seem like the best approach.  Not sure what kind of  
>> constraints you are working with but at the very least you can  
>> keep them separate and do some footwork to compile the class files  
>> into the same dir.
>>
>>
>> -David
>>
>


Mime
View raw message