Mailing-List: contact derby-dev-help@db.apache.org; run by ezmlm
Precedence: bulk
Reply-To: <derby-dev@db.apache.org>
Received-SPF: pass (nike.apache.org: domain of rick.hillegas@oracle.com
 designates 156.151.31.81 as permitted sender)
Message-ID: <52444D13.3050209@oracle.com>
Date: Thu, 26 Sep 2013 08:04:51 -0700
From: Rick Hillegas <rick.hillegas@oracle.com>
User-Agent: Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.7; en-US;
 rv:1.9.2.18) Gecko/20110616 Thunderbird/3.1.11
MIME-Version: 1.0
To: derby-dev@db.apache.org
Subject: Re: A couple of questions on building derby on the trunk and using
 that built version
References: <D7990B85-100A-427A-8289-642669E7D080@canoga.com>
 <524391AF.5070709@oracle.com>
 <03C6C175-9B18-42AC-9605-F24DB39A8893@canoga.com>
In-Reply-To: <03C6C175-9B18-42AC-9605-F24DB39A8893@canoga.com>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit

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<rick.hillegas@oracle.com>  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
>>>
>>>
>>>
>>
>
>