This is an appendix to the overall Derby release instructions found here: DerbySnapshotOrRelease
This page contains deprecated release instructions.
Table of Contents
Contents
Publishing
Maven deploy
- Deploy to Maven repository.
If you do not already have the latest Maven 1 distribution, download it, unpack it, and put the bin directory into your path so that you can run maven commands.
As of this writing, the latest 1.x version of Maven was 1.1.
cd into Derby's maven directory. Typically this will be in the same sandbox that you used to build the release, but this is not strictly required.
Edit project.xml so that it contains the correct version number for this release between the <currentversion> tags.
Edit project.properties:
Add username, and password for your account on people.apache.org so you can properly authenticate and copy the files to people. The scpexe protocol should work without problems, especially if you have an ssh public key already on people.
Make sure derby.jars points to the directory holding the release jars. jars/insane is the default, so if you backed up the jars somewhere else when you built the release you must adjust this property accordingly. You also need modify this property if you are using a sandbox other than the one you used to build the release.
Uncomment #maven.repo.list=apache. It commented out by default to prevent accidental deployments. Your local diff should look something like:
sanity=insane -derby.jars=../../jars/${sanity} +derby.jars=/path/to/maven/jars -#maven.repo.list=apache +maven.repo.list=apache maven.repo.apache=scpexe://people.apache.org maven.repo.apache.directory=/www/people.apache.org/repo/m1-ibiblio-rsync-repository -maven.repo.apache.username= -maven.repo.apache.password= +maven.repo.apache.username=you +maven.repo.apache.password=secret maven.repo.apache.group=db
- Run the Maven commands.
Run maven to attain the multiproject:install goal to install the artifacts into your local maven repo.
Note: For 10.3.2.1 I had to type maven multiproject:install to get this to work.
Run maven clean to attain the multiproject:clean goal to clean up the maven tree.
Run maven multiproject:deploy to copy all the artifacts into the apachecvs repository.
The multiproject:deploy command will not work unelss you uncomment the maven.repo.list property in project.properties.
This does not build using maven, it works by copying the jars pointed to by ${derby.jars} (jars/${sanity} by default).
- Sign the individual jars.
Unfortunately, Maven renames the jars during deployment, so the jars now found in the Maven repository have the version number embedded in the file name. E.g derby.jar has become derby-x.y.z.w.jar. The name of the signature file needs to same as the name of jar with the asc extension, but Maven apparently knows nothing about signatures, so we have to create correctly named signatures by hand. The following script signs and renames the jars appropriately, and should be run in the ${derby.jars} directory.
for i in *.jar do gpg --armor --detach-sign $i // enter your PGP passphrase for each iteration. done for i in *.jar.asc do PREFIX=`echo $i | sed 's/.jar.asc//g'` NEWNAME=$PREFIX-x.y.z.w.jar.asc //use the correct version number for this release. mv $i $NEWNAME done
- Upload the signatures to the jars directory:
sftp {username}@people.apache.org cd /www/people.apache.org/repo/m1-ibiblio-rsync-repository/org.apache.derby/jars/ put *.jar.asc
If you don't upload the signatures for the jar files, you will probably receive an email saying that you did not upload appropriate PGP signatures for the new files added to www.apache.org/dist/.
Ensure that the uploaded files have useful permissions. They need to be rw-r--r-- (chmod 644). Revert local modifications in the maven directory.
The deployment of the jars and poms to the Maven 1 repository will be automatically converted to appropriate jars and poms for Maven 2 and deployed to that repository as well. See DERBY-1378 for more information on the automatic conversion to Maven 2.
The maven deploy step expects to do scp without prompting for passwords. If you can normally do scp, but get an error reflecting 'Failed to deploy', in org.apache.maven.wagon.providers.ssh.external.ScpExternalWagon.put, you may not have this set up. If this is the problem, one workaround is to do the copying manually, as outlined in the next section. Or you can do the following steps (and ensure that you append .ssh/authorized_keys, not overwrite): $ ssh-keygen -t dsa --> press ENTER when prompted for a pass-phrase to get a null phrase. $ scp ~/.ssh/id_dsa.pub you@people.apache.org: >Password:... $ ssh you@people.apache.org >Password:... $ cat id_dsa.pub >> .ssh/authorized_keys
Maven may not work for you especially on Windows. If Maven does not copy the build artifacts to subdirectories under /www/people.apache.org/repo/m1-ibiblio-rsync-repository/org.apache.derby/, then you will have to do this yourself. In this scenario, you must use Maven to deploy the build artifacts to your local file system, sign them and then sftp the results to people.apache.org. - To deploy the build artifacts to your local file system, set up project.properties something like this:
maven.repo.list=apache maven.repo.apache=file:///home/myself/zdir maven.repo.apache.directory=garbage maven.repo.apache.username=garbage maven.repo.apache.password=garbage maven.repo.apache.group=garbage
- Then do
- $ maven clean $ maven multiproject:deploy This will build the artifacts into a subtree rooted at /home/myself/zdir/garbage.
- Sign the jars using the following script:
for i in `ls *.jar` do gpg --armor --detach-sign $i done
Use sftp to bulk put the artifacts into the corresponding subdirectories of www/people.apache.org/repo/m1-ibiblio-rsync-repository/org.apache.derby/. Note that there are 3 directories of files (jars, poms, wars) which must be sftp'd from your machine to the tree on people.apache.org.
- To deploy the build artifacts to your local file system, set up project.properties something like this:
Current symlinks
Symlinks to the current release were dropped in September 2011 (see thread on derby-dev).
- If the new release is the most current release, link the -current links to the new files. Here's a quick-and-dirty shell script for doing so:
ln -s $1/$1-bin.tar.gz db-derby-current-bin.tar.gz ln -s $1/$1-bin.tar.gz.asc db-derby-current-bin.tar.gz.asc ln -s $1/$1-bin.tar.gz.md5 db-derby-current-bin.tar.gz.md5 ln -s remove old versions from the mirror directory ln -s $1/$1-bin.tar.gz db-derby-current-bin.tar.gz ln -s $1/$1-bin.tar.gz.asc db-derby-current-bin.tar.gz.asc ln -s $1/$1-bin.tar.gz.md5 db-derby-current-bin.tar.gz.md5 ln -s remove old versions from the mirror directory ln -s $1/$1-bin.tar.gz db-derby-current-bin.tar.gz ln -s $1/$1-bin.tar.gz.asc db-derby-current-bin.tar.gz.asc ln -s $1/$1-bin.tar.gz.md5 db-derby-current-bin.tar.gz.md5 ln -s remove old versions from the mirror directory ln -s $1/$1-bin.tar.gz db-derby-current-bin.tar.gz ln -s $1/$1-bin.tar.gz.asc db-derby-current-bin.tar.gz.asc ln -s $1/$1-bin.tar.gz.md5 db-derby-current-bin.tar.gz.md5 ln -s $1/$1-bin.zip db-derby-current-bin.zip ln -s $1/$1-bin.zip.asc db-derby-current-bin.zip.asc ln -s $1/$1-bin.zip.md5 db-derby-current-bin.zip.md5 ln -s $1/$1-src.tar.gz db-derby-current-src.tar.gz ln -s $1/$1-src.tar.gz.asc db-derby-current-src.tar.gz.asc ln -s $1/$1-src.tar.gz.md5 db-derby-current-src.tar.gz.md5 ln -s $1/$1-src.zip db-derby-current-src.zip ln -s $1/$1-src.zip.asc db-derby-current-src.zip.asc ln -s $1/$1-src.zip.md5 db-derby-current-src.zip.md5
which, if you called the script linkcurrent.sh and put it in your home directory, could be run as follows:cd /www/www.apache.org/dist/db/derby ~/linkcurrent.sh db-derby-10.1.1.0
using db-derby-10.1.1.0 as the release to link to -current as an example.