db-derby-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Knut Anders Hatlen <Knut.Hat...@Sun.COM>
Subject Re: VOTE: Approach for sharing code
Date Fri, 09 Sep 2005 08:16:50 GMT
David, I think this is a very good proposal! Much better than the
class-version scheme proposed earlier in my opinion. Read my comments
to your questions below.

"David W. Van Couvering" <David.Vancouvering@Sun.COM> writes:

> I thought Kathey/Dan's idea of generating copies of the common code
> into two separate directories was interesting and solved a lot of problems,
> and I thought it would be worthwhile to walk through this in a bit more
> detail.
>
> I took a look at all the relevant use cases I could think of and describe
> the steps involved and what the user experience will be like.  Through
> this effort I did find a couple of possible issues that may make us want
> to think twice about this approach.  Perhaps others can think of ways around
> these issues.  I have labelled issues uncovered with the tag <ISSUE> in
> the text below, rather than try and summarize them here.
>
>
> CREATING A COMMON CLASS

[snip]

> <ISSUE>
> QUESTION: is there a need for mixed versions between the tools and
> engine code?  If so we will need to generate a third package hierarchy
> org.apache.derby.tools.common.*.
> </ISSUE>

Don't know, but when one first has a framework for common code this
should be relatively easy, don't you think? One more issue will arise
if the shared code is copied into three or more locations: What if
only two of the components use a file? Should that file only be copied
to those two components or to all the components? (Probably not a big
issue. I don't care if a jar gets a couple of KB bigger, but maybe
someone does.)

[snip]

> DEBUGGING A COMMON CLASS
>
> Stack traces and debug stacks will point to the generated code
> under engine/common or client/common depending on whether you
> are debugging engine/tools/network code or client code.
>
> <ISSUE>
> If the debugger takes a developer to a common file and they see a bug,
> the temptation will be to fix it in place and recompile.  This will
> not work -- their changes will be lost when they run the build script.
>
> The developer must instead go to the original source file in
> org/apache/derby/common and fix it there.  I suspect this is going
> to be confusing and annoying.
>
> We could avoid this confusion by removing the generated source file
> after compilation, but I think that this would be even more annoying,
> as you wouldn't be able to do interactive source-level debugging.  Most
> debugging is just stepping through code that you aren't modifying; you
> just want to follow the logic.
> </ISSUE>

We already have a similar issue in the existing Derby code. The Java
source files for the SQL parser are generated with JavaCC. When you
debug Derby you might find a bug there and fix it the wrong place, as
you said. However, the changes are not lost when you run the build
script because you have to run "ant clobber" or something before you
can regenerate the parser source.

Possible solutions for this issue in the common-code case:

  1. Write a header in each generated file saying that it is generated
     from another source and should not be modified.

  2. Don't delete the copies in an ordinary build, only when running
     "ant clobber". This would be annoying for developers working on
     the common code since they would have to run "ant clobber" for
     every small change they would test.

  3. I haven't used ant much, but couldn't ant check whether the main
     source file is newer than the copy? Then one would only overwrite
     the generated files when the main source is modified. This could
     also be extended with creating a timestamp file after each
     successful build, and ant could check whether any of the
     generated files were modified after the last build and possibly
     print a warning.

> CHECKING IN A COMMON CLASS
>
> You check in the original source, NOT the generated source.
>
> <ISSUE>
> This is another potential source of errors.  A newbie developer
> could check in the generated source, and we would have to clean
> it out
> </ISSUE>

Well, a newbie developer couldn't check in the generated source, it
would have to be a newbie _committer_. Who could that be? ;)

Seriously, I don't think this is going to be a big problem. I'm sure
subversion has an ignore property or something that could be used to
solve this.

-- 
Knut Anders


Mime
View raw message