Mailing-List: contact dev-help@geronimo.apache.org; run by ezmlm
Precedence: bulk
Reply-To: dev@geronimo.apache.org
Received-SPF: pass (asf.osuosl.org: local policy includes SPF record at
 spf.trusted-forwarder.org)
Mime-Version: 1.0 (Apple Message framework v746.2)
In-Reply-To: <C42218B9-7A01-41C4-845F-D52E465696DB@visi.com>
References: <F7A4D748-02E0-465A-83B0-2A972BCFFC7D@visi.com>
 <1BAFE9DF-0065-4FD1-90A7-C5E38E092BCC@gmail.com>
 <DDA9F37A-B7BF-4F3F-8F23-6F0A2CE23876@visi.com>
 <475C791A-5B61-493C-9ED4-436E2618B3A9@gmail.com>
 <C42218B9-7A01-41C4-845F-D52E465696DB@visi.com>
Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed
Message-Id: <20E7CA78-EC23-4CAA-B471-9F5EF1CC7AE0@gmail.com>
Content-Transfer-Encoding: 7bit
From: Sachin Patel <sppatel2@gmail.com>
Subject: Re: gbuild: need up with eclipse tools setup?
Date: Mon, 23 Jan 2006 22:08:39 -0500
To: dev@geronimo.apache.org


- sachin


On Jan 23, 2006, at 9:55 PM, David Blevins wrote:

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

Well XML is generating just binaries directly into target since the  
move to XMLBeans2 right, not any source?  Yes, the method level  
aspect makes it trickier. Any generated code I want to modify and  
source ctrl, needs to be at a different location, but at the same  
time during the build, the generator still needs to run on the  
modfied-gen'd code in case their is any updates to other methods.

>
> What tool is generating this code?

EMF (Eclipse Modeling Framework)

http://www.eclipse.org/emf/

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