You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@geronimo.apache.org by David Blevins <da...@visi.com> on 2006/01/17 05:10:21 UTC
gbuild: need up with eclipse tools setup?
Hey Sachin,
Things were good with the Eclipse tools a while back, but seem to be
having trouble lately:
http://ci.gbuild.org/continuum/servlet/continuum/target/
ProjectBuilds.vm/view/ProjectBuilds/id/11
Is there something I can help with?
-David
Re: gbuild: need up with eclipse tools setup?
Posted by David Blevins <da...@visi.com>.
On Jan 23, 2006, at 7:08 PM, Sachin Patel wrote:
> 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/
>
You might consider making a maven 2 plugin for it and switch the
tools build to maven 2.
-David
Re: gbuild: need up with eclipse tools setup?
Posted by Sachin Patel <sp...@gmail.com>.
- 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
>>>
>>
>
Re: gbuild: need up with eclipse tools setup?
Posted by David Blevins <da...@visi.com>.
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
>>
>
Re: gbuild: need up with eclipse tools setup?
Posted by Sachin Patel <sp...@gmail.com>.
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
>
Re: gbuild: need up with eclipse tools setup?
Posted by David Blevins <da...@visi.com>.
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
Re: gbuild: need up with eclipse tools setup?
Posted by Sachin Patel <sp...@gmail.com>.
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?
- sachin
On Jan 16, 2006, at 11:10 PM, David Blevins wrote:
> Hey Sachin,
>
> Things were good with the Eclipse tools a while back, but seem to
> be having trouble lately:
>
> http://ci.gbuild.org/continuum/servlet/continuum/target/
> ProjectBuilds.vm/view/ProjectBuilds/id/11
>
> Is there something I can help with?
>
> -David
Re: gbuild: need up with eclipse tools setup?
Posted by David Blevins <da...@visi.com>.
Odd brain misfire ... subject was supposed to be "need help" not
"need up" which makes no kind of sense....
-David
On Jan 16, 2006, at 8:10 PM, David Blevins wrote:
> Hey Sachin,
>
> Things were good with the Eclipse tools a while back, but seem to
> be having trouble lately:
>
> http://ci.gbuild.org/continuum/servlet/continuum/target/
> ProjectBuilds.vm/view/ProjectBuilds/id/11
>
> Is there something I can help with?
>
> -David
>