On 9/26/13 4:34 AM, Bergquist, Brett wrote:
Thanks Rick I appreciate the time you take to answer my questions!
On Sep 25, 2013, at 9:45 PM, Rick Hillegas<[email protected]> wrote:
Hi Brett,
Some responses inline...
On 9/25/13 5:55 PM, Bergquist, Brett wrote:
When trying to open an existing database with the derby that I built from the
trunk I get:
ERROR XJ040: Failed to start database '/Users/brett/.netbeans-derby/csemdb'
with class loader sun.misc.Launcher$AppClassLoader@39172e08, see the next
exception for details.
ERROR XCW00: Unsupported upgrade from '10.9' to '10.11 beta'.
This is a safety mechanism to prevent someone from accidentally soft or
hard upgrading a database to the rev level of the development trunk.
There are a couple reasons that you don't want people to do this:
1) Soft-downgrade from the development trunk version may not have been
adequately tested.
2) The next major feature release will have the same major release
number as the development trunk. Since the work on that release is not
complete, upgrade trajectories are not well defined and follow-on
upgrade to the next release may not work properly.
I understand this problem exactly as I just had to go through this when
providing what we cal an Engineering Build (EB) of our software to a customer
for their lab use and then provided an General Availability (GA) build with the
same version. Of course the customer wants this to be installed seemlessly
but we typically do not support upgrades from one EB build to another or a EB
build to a GA build.
when I connect. What do I need to do to let derby know that it is okay to
open this database (it is just a test database that can be easily rebuilt)?
You can subvert this check by specifying the following system property
when you boot the jvm:
-Dderby.database.allowPreReleaseUpgrade=true
Second question. I see an ant target called "snapshot" which I execute and it appears to build a snapshot distribution
under "releases". If I expand the ".zip" file out however, I don't see the the
"startNetworkServer" or "stopNetworkServer" scripts (I do see that Windows .bat versions but not the Unix
versions). Note I am building on OSX. Should these not be present?
Snapshots don't necessarily contain all the bits that regular releases
do. The contents of snapshots are not very well defined. It has been a
long time since the community has vetted a snapshot and the
snapshot-generating machinery may be rusty now. More information on
snapshots can be found here:
http://wiki.apache.org/db-derby/SnapshotsAndQuickBuilds
What is the recommended way of build a engineering "release" of all of the
"bits" so that it can be installed just like a real release? A lot of times, I wish to
just rename a copy of derby on a test system (copy of a production system) and then drop in a
patched version and restart. It is easer for me if the patched version that I want to drop in will
be a complete release? Maybe there is some magic in the build process that I have not found yet as
I though that maybe the snapshot could be it.
Hi Brett,
A real release consists of several distributions. Typically, someone
interested in Derby will be interested in only one of these distros:
1) Code source - This is the *src.zip distro and the equivalent
*src.tar.gz distro. It contains everything in the code and doc source
trees, everything that you'd get if you checked out one of the Derby
source tags at https://svn.apache.org/repos/asf/db/derby/code/tags/
along with the corresponding docs tag at
https://svn.apache.org/repos/asf/db/derby/docs/tags/ From ASF's point of
view, this distro is the real release, the complete source machinery
which you need to build Derby yourself. However, I don't know any real
Derby user who downloads this distro.
2) Binaries - This is the *bin.zip distro and the equivalent *bin.tar.gz
distro. This contains the built user guides, the built jar files, the
built public javadoc, the demo programs, the templates, and the sample
startup scripts. Of the distros which people really download, this is
the most complete.
3) Libraries - This is the *lib.zip distro and the equivalent
*lib.tar.gz distro. This contains the built jar files. It is the leanest
of the Derby distros, the essence of the release from an application
developer's point of view.
4) Debug libraries - This is the *lib-debug.zip distro and the
corresponding *lib-debug.tar.gz distro. This is equivalent to the
library distro except that the jar files have been built with extra
debug machinery.
All of these distros are intended for use by application developers. I
can't imagine dropping any of these distros, as is, into a production
application which is installed on an end-user's machine. In assembling
an end-user application, I would expect that someone building a
production application would cherry-pick bits from one of these distros.
If the application needed the latest code from a Derby branch, I would
expect that the release process for the application would just build the
insane (non-debug) jars from an up-to-date Derby subversion client and
then add whatever other bits are needed from the Derby source tree.
I would not recommend bothering with the actual release-generation target:
1) It's overkill. I can't imagine that you really need to build any of
the full Derby distros, let alone all of them. I suspect that all you
need to do is "ant all" followed by "ant buildjars".
2) Only a committer can actually run the "ant release" target. That is
because the release process involves bumping version ids on a Derby
branch. The full release process is quite complicated. It is described
here: http://wiki.apache.org/db-derby/DerbySnapshotOrRelease
Hope I'm not misunderstanding the point of your question,
-Rick
Hope this helps,
-Rick
