David, it looks good. Just a few comments.
* Regarding "Mixed Version Support", it might be good at some point to
elaborate on "As much as possible, two applications should be able to
use different
versions of Derby within the same Java VM without having to resort to
creating specialized classloaders." - Were you referring to 2 different
Derby engines or/and Clients or/and mix of the 2 running in the same
JVM? If an application is expected to run at a certain level of Derby
and it is not because of class order loading issues which could cause
the application not to use the appropriate level of Derby classes.
Depending what the statement meant I don't think we can completely rule
out specialized class loaders to isolate loading of a specific and
expected level of classes for certain configuration. More
clarifications on what the statement meant to say would be nice...
* As a guideline, we should try to have the
<ComponentName>Info class at the top level of the package for
that component (in the case of Common component, one would expect to
have the class be defined under the org.apache.derby.common package. I may have missed this being mentioned in the proposal.
* Would be nice to run JVM / Derby incompatibility test harness suite
when a new 'common' class is introduced (not just a new package).
+1
--francois
- Re: VOTE: Shared Components Guidelines Francois Orsini
- Re: VOTE: Shared Components Guidelines David W. Van Couvering
- Re: VOTE: Shared Components Guidelines Francois Orsini
- Re: VOTE: Shared Components Guidelines Daniel John Debrunner
- Re: VOTE: Shared Components Guidelines David Van Couvering
- Re: VOTE: Shared Components Guidelines Kathey Marsden
- Re: VOTE: Shared Components Guidelines David Van Couvering
- Re: VOTE: Shared Components Guidelines David W. Van Couvering
- Re: VOTE: Shared Components Guidelines Andrew McIntyre
- Re: VOTE: Shared Components Guidelines Rick Hillegas
- Re: VOTE: Shared Components Guidel... Daniel John Debrunner
