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
