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
