geronimo-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Sachin Patel <>
Subject Re: gbuild: need up with eclipse tools setup?
Date Tue, 24 Jan 2006 01:36:40 GMT
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

View raw message