You are viewing a plain text version of this content. The canonical link for it is here.
Posted to commits@isis.apache.org by da...@apache.org on 2017/04/03 23:29:54 UTC
[40/59] [abbrv] [partial] isis-site git commit: ISIS-1521: deletes
content-OLDSITE
http://git-wip-us.apache.org/repos/asf/isis-site/blob/365806f1/content-OLDSITE/contributors/git-cookbook.md
----------------------------------------------------------------------
diff --git a/content-OLDSITE/contributors/git-cookbook.md b/content-OLDSITE/contributors/git-cookbook.md
deleted file mode 100644
index dcbdfb4..0000000
--- a/content-OLDSITE/contributors/git-cookbook.md
+++ /dev/null
@@ -1,307 +0,0 @@
-Title: Git Cookbook
-
-[//]: # (content copied to _user-guide_xxx)
-
-This page describes the commands often used while working with git.
-
-In addition to these basic commands, please make sure you have read:
-
-* [development environment](development-environment.html)
-* [git policy](git-policy.html)
-* [contributing](contributing.html)
-
-#### Modifying existing files
-
-To modify existing files:
-
-<pre>
-git add <i>filename</i>
-git commit -m "ISIS-nnn: yada yada"
-</pre>
-
-The `git add` command adds the changes to the file(s) to the git index (aka staging area). If you were to make subsequent changes to the file these would not be committed.
-
-The `git commit` takes all the staged changes and commits them locally. Note that these changes are not shared public with Isis' central git repo.
-
-You can combine these two commands using `-am` flag to git commit:
-
-<pre>
-git commit -am "ISIS-nnn: yada yada"
-</pre>
-
-#### Adding new files
-
-To add a new file:
-
-<pre>
-git add .
-git commit -m "ISIS-nnn: yada yada"
-</pre>
-
-Note that this sequence of commands is identical to modifying an existing file. However, it isn't possible to combine the two steps using `git commit -am`; the `git add` is always needed when adding new files to the repo.
-
-#### Deleting files
-
-To delete a file:
-
-<pre>
-git rm filename
-git commit -m "ISIS-nnn: yada yada"
-</pre>
-
-#### Renaming or moving files
-
-To rename or move a file:
-
-<pre>
-git mv <i>filename</i> <i>newfilename</i>
-git commit -m "ISIS-nnn: yada yada"
-</pre>
-
-
-## Common Workflows (Committers only)
-
-The [contributing](contributing.html) page describes the workflow for non-committers. This section is therefore primarily for the benefit of Isis **committers**.
-
-### Working on `master`
-
-The easiest way of working is to make your commits directly on your local `master`. This is perhaps somewhat hacky, but acceptable for very small changes.
-
-When you are ready to push your changes, use:
-
-<pre>
-git pull --rebase
-</pre>
-
-This will bring down all the latest commits made to the central repo, and update *origin/master*. It will then apply all commits made in your master branch on top of that.
-
-Alternatively, you can do this in two stages:
-
-<pre>
-git fetch
-git rebase origin/master
-</pre>
-
-After the `git fetch`, you will see that `gitk --all` shows the new set of commits as a branch separate from your own commits on branch. The `git rebase` command then applies all your changes on top of that branch. (Your original commits are orphaned and are eventually garbage collected by git).
-
-Once you're happy with all your changes, push your local repository onto the central repo:
-<pre>
-git push
-</pre>
-
-
-### Creating a local branch
-
-If you are working on a branch for a significant period (eg to implement a ticket), then it probably makes sense to create a local branch:
-
-<pre>
-git checkout -b <i>branchname</i>
-</pre>
-
-If you use `gitk --all`, then you'll see a new tag for the current commit. The command line in the shell also changes.
-
-Any commits made now advance the new branch, but leave the `master` branch alone.
-
-If you want to switch to some other branch, use:
-
-<pre>
-git checkout <i>branchname</i>
-</pre>
-
-Any changes in your working directory and index/staging area are *preserved*. This makes it easy to separate out different strands of work... you realize that some set of changes just made should be on a different ticket, so you create a new branch and commit those changes there.
-
-## Updating branch with latest
-
-When you want to 'catch-up' with the changes made by others and in the remote `origin`, use:
-
-<pre>
-git checkout <i>branchname</i>
-git rebase master
-</pre>
-
-This will reapply the commits from `origin` on top of the `master` branch. If there are conflicts then they will occur a this point. Conflicts are resolved by editing the file, then:
-
-<pre>
-git add <i>filename</i>
-git rebase --continue
-</pre>
-
-Once the rebase is finished, you'll see the branch *branchname* as a direct descendent of `master` (use `gitk --all` to confirm). You will still be on the *branchname*. To catch up `master`, use:
-
-<pre>
-git checkout master
-git merge <i>branchname</i> --ff-only
-</pre>
-
-The `--ff-only` ensures that the merge is a fast-forward; ie all commits will have only a single parent, and no conflicts.
-
-At this point you can delete the branch:
-
-<pre>
-git branch -d <i>branchname</i>
-</pre>
-
-## Push the changes
-
-Immediately prior to pushing your changes, check one more time that you are up-to-date:
-
-<pre>
-git fetch
-</pre>
-
-If this pulls down any commits, then reintegrate first (using `git rebase`) and try again.
-
-Assuming that now new commits were brought down, you can now simply do a fast forward merge of master, and then push the changes:
-
-<pre>
-git checkout master
-git merge --ff-only ISIS-123-blobs
-git push
-</pre>
-
-Because the `master` branch is a direct ancestor of the topic branch, the fast-forward merge should work. The `git push` then pushes those changes back to the master Isis repo.
-
-To clean up, you can delete your topic branch:
-<pre>
-git branch -d ISIS-123-blobs
-</pre>
-
-
-## Backing up a local branch
-
-If committing to a local branch, the changes are still just that: local, and run risk of a disk failure or other disaster.
-
-To create a new, similarly named branch on the central repo, use:
-
-<pre>
-git push -u origin <i>branchname</i>
-</pre>
-
-Using `gitk --all` will show you this new branch, named *origin/branchname*.
-
-Thereafter, you can push subsequent commits using simply:
-
-<pre>
-git push
-</pre>
-
-Doing this also allows others to collaborate on this branch, just as they would for `master`.
-
-When, eventually, you have reintegrated this branch, you can delete the remote branch using:
-
-<pre>
-git push origin --delete <i>branchname</i>
-</pre>
-
-For more detail, see these blogs/posts [here](http://www.mariopareja.com/blog/archive/2010/01/11/how-to-push-a-new-local-branch-to-a-remote.aspx) and [here](http://stackoverflow.com/questions/2003505/how-do-i-delete-a-git-branch-both-locally-and-in-github).
-
-### Quick change: stashing changes
-
-If you are working on something but are not ready to commit, then use:
-
-<pre>
-git stash
-</pre>
-
-If you use `gitk --all` then you'll see new commits are made that hold the current state of your working directory and staging area.
-
-You can then, for example, pull down the latest changes using `git pull --rebase` (see above).
-
-To reapply your stash, then use:
-
-<pre>
-git stash pop
-</pre>
-
-Note that stashing works even if switching branches
-
-
-## Ignoring files
-
-Put file patterns into `.gitignore`. There is one at the root of the git repo, but they can additionally appear in subdirectories (the results are cumulative).
-
-See also:
-
-- [github's help page](https://help.github.com/articles/ignoring-files)
-- [man page](http://www.kernel.org/pub/software/scm/git/docs/gitignore.html)
-
-
-## More advanced use cases
-
-### If accidentally push to remote
-
-Suppose you committed to `master`, and then pushed the change, and then decided that you didn't intend to do that:
-
-<pre>
-C1 - C2 - C3 - C4 - C5 - C6 - C7
- ^
- master
- ^
- origin/master
-</pre>
-
-To go back to an earlier commit, first we wind back the local `master`:
-
-<pre>
-git reset --hard C5
-</pre>
-where `C5` is the long sha-id for that commit.
-
-This gets us to:
-
-<pre>
-C1 - C2 - C3 - C4 - C5 - C6 - C7
- ^
- master
- ^
- origin/master
-</pre>
-
-Then, do a force push:
-
-<pre>
-git push origin master --force
-</pre>
-
-If this doesn't work, it may be that the remote repo has disabled this feature. There are other hacks to get around this, see for example [here](http://stackoverflow.com/questions/1377845/git-reset-hard-and-a-remote-repository).
-
-
-
-
-
-## If you've accidentally worked on `master` branch
-
-If at any time the `git pull` from your upstream fails, it most likely means that you must have made commits on the `master` branch. You can use `gitk --all` to confirm; at some point in time both `master` and `origin\master` will have a common ancestor.
-
-You can retrospectively create a topic branch for the work you've accidentally done on `master`.
-
-First, create a branch for your current commit:
-<pre>
-git branch <i>newbranch</i>
-</pre>
-
-Next, make sure you have no outstanding edits. If you do, you should commit them or stash them:
-
-<pre>
-git stash
-</pre>
-
-Finally, locate the shaId of the commit you want to roll back to (easily obtained in `gitk -all`), and wind `master` branch back to that commit:
-<pre>
-git checkout master
-git reset --hard <i>shaId</i> # move master branch shaId of common ancestor
-</pre>
-
-
-## If you've forgotten to prefix your commits (but not pushed)
-
-One of our committers, Alexander Krasnukhin, has put together some git scripts to help his workflow. Using one of these, `git prefix`, you:
-
-> can just commit with proper message without bothering about prefix and add prefix only in the end *before* the final push.
-
->For example, to prefix all not yet prefixed commits `master..isis/666` with `ISIS-666` prefix, use:
-<pre>
- git prefix ISIS-666 master..isis/666
-</pre>
-
-You can grab this utility, and others, from [this repo](https://github.com/themalkolm/git-boots).
http://git-wip-us.apache.org/repos/asf/isis-site/blob/365806f1/content-OLDSITE/contributors/git-policy.md
----------------------------------------------------------------------
diff --git a/content-OLDSITE/contributors/git-policy.md b/content-OLDSITE/contributors/git-policy.md
deleted file mode 100644
index 0843593..0000000
--- a/content-OLDSITE/contributors/git-policy.md
+++ /dev/null
@@ -1,51 +0,0 @@
-Title: Git Policy
-
-[//]: # (content copied to _user-guide_xxx)
-
-## Introduction
-
-These notes recommend how contributors should work with git. To understand these notes, the only real concepts that you need to grok are:
-
-- git commits form an acyclic graph, with each commit pointing to its parent commit (or commit**s**, if a merge)
-
-- a branch is merely a pointer to one of these commits; git calls the main branch `master`
-
-- git commits happen in two steps: first they are added to the index (also called the staging area), then they are committed.
-
-For more background reading, see:
-
-- [Pro Git](http://git-scm.com/book) book (free in electronic form)
-- [Git community book](https://github.s3.amazonaws.com/media/book.pdf)
-- [git reset demystified](http://git-scm.com/2011/07/11/reset.html) - differentiating the working directory vs index/staging area
-
-And, of course, there is loads of good advice on [stackoverflow.com](http://stackoverflow.com/questions/tagged/git)
-
-## General principle
-
-There are many ways of using Git, but the only real prescriptive advice here is:
-
-**commits should only have one parent**.
-
-Doing this keeps the commit history clean; even though work actually happens in parallel, in the commit history it will look like all work was done serially.
-
-This is accomplished using `git rebase`; the idea being that any changes that you make locally are re-applied on top of the latest fetch from the `master` branch. The [cookbook](git-cookbook.html) page describes how to do this in detail.
-
-Many other projects also work this way; a good write-up of how SpringSocial use git can be found [here](https://github.com/SpringSource/spring-social/wiki/Contributing).
-
-## Commit message
-
-#### Commit message format
-
-The minimum we expect in a commit messages is:
-
-<pre>
-ISIS-nnn: brief summary here
-
-- optionally, longer details
-- should be written here
-- in bullet points
-</pre>
-
-where `ISIS-nnn` is a ticket raised in our [JIRA issue tracker](https://issues.apache.org/jira/browse/ISIS).
-
-For non-committers we typically expect more detail again; see the [contributing](contributing.html) page for the longer format recommended for contributors to use.
\ No newline at end of file
http://git-wip-us.apache.org/repos/asf/isis-site/blob/365806f1/content-OLDSITE/contributors/key-generation.md
----------------------------------------------------------------------
diff --git a/content-OLDSITE/contributors/key-generation.md b/content-OLDSITE/contributors/key-generation.md
deleted file mode 100644
index 27fc01f..0000000
--- a/content-OLDSITE/contributors/key-generation.md
+++ /dev/null
@@ -1,535 +0,0 @@
-Title: Key Generation
-
-[//]: # (content copied to _user-guide_xxx)
-
-In order that a contributor can make a release it is necessary for them to have generated a key and had that key recognized by other members of the Apache Software Foundation.
-
-For further background information on this topic, see the [release signing page](http://www.apache.org/dev/release-signing.html) and the [openpgp page](http://www.apache.org/dev/openpgp.html#generate-key) on the Apache wiki.
-
-## Install and Configure gpg
-
-Download and install GnuPG (gpg), version 1.4.10 or higher.
-
-Then, edit `~/.gnupg/gpg.conf` (on Windows, the file to edit is `C:\Users\xxx\AppData\Roaming\gnupg\gpg.conf`) so that the default is to generate a strong key:
-
-<pre>
-personal-digest-preferences SHA512
-cert-digest-algo SHA512
-default-preference-list SHA512 SHA384 SHA256 SHA224 AES256 AES192 AES CAST5 ZLIB BZIP2 ZIP Uncompressed
-</pre>
-
-
-## Key Generation
-
-The ASF requires that keys are signed with a key (or subkey) based on RSA 4096 bits. To do this:
-
-<pre>
-$ gpg --gen-key
-gpg (GnuPG) 1.4.11; Copyright (C) 2010 Free Software Foundation, Inc.
-This is free software: you are free to change and redistribute it.
-There is NO WARRANTY, to the extent permitted by law.
-
-Please select what kind of key you want:
- (1) RSA and RSA (default)
- (2) DSA and Elgamal
- (3) DSA (sign only)
- (4) RSA (sign only)
-Your selection?
-</pre>
-
-Specify RSA key:
-
-<pre>
-Your selection? 1
-
-RSA keys may be between 1024 and 4096 bits long.
-What keysize do you want? (2048)
-</pre>
-
-Specify key length as 4096 bits:
-
-<pre>
-What keysize do you want? (2048) 4096
-Requested keysize is 4096 bits
-
-Please specify how long the key should be valid.
- 0 = key does not expire
- <n> = key expires in n days
- <n>w = key expires in n weeks
- <n>m = key expires in n months
- <n>y = key expires in n years
-Key is valid for? (0)
-</pre>
-
-Specify key as non-expiring:
-
-<pre>
-Key is valid for? (0) 0
-Key does not expire at all
-Is this correct? (y/N) y
-
-You need a user ID to identify your key; the software constructs the user ID
-from the Real Name, Comment and Email Address in this form:
- "Heinrich Heine (Der Dichter) <he...@duesseldorf.de>"
-
-Real name:
-</pre>
-
-Enter your name, email and comment:
-
-- use your apache.org email
-- the comment should be "CODE SIGNING KEY"
-
-<pre>
-Real name: Xxx Xxxxxxxxx
-Email address: <xx...@apache.org>
-Comment: CODE SIGNING KEY
-You selected this USER-ID:
- "Xxx Xxxxxxxxx (CODE SIGNING KEY) <xx...@apache.org>"
-
-Change (N)ame, (C)omment, (E)mail or (O)kay/(Q)uit? O
-
-You need a Passphrase to protect your secret key.
-Enter passphrase:
-</pre>
-
-Provide a passphrase to secure your key.
-
-<pre>
-Enter passphrase:
-Repeat passphrase:
-</pre>
-
-GPG will goes on to generate your key:
-
-<pre>
-We need to generate a lot of random bytes. It is a good idea to perform
-some other action (type on the keyboard, move the mouse, utilize the
-disks) during the prime generation; this gives the random number
-generator a better chance to gain enough entropy.
-...+++++
-.........................+++++
-We need to generate a lot of random bytes. It is a good idea to perform
-some other action (type on the keyboard, move the mouse, utilize the
-disks) during the prime generation; this gives the random number
-generator a better chance to gain enough entropy.
-....+++++
-...+++++
-gpg: key nnnnnnnn marked as ultimately trusted
-public and secret key created and signed.
-
-gpg: checking the trustdb
-gpg: 3 marginal(s) needed, 1 complete(s) needed, PGP trust model
-gpg: depth: 0 valid: 1 signed: 0 trust: 0-, 0q, 0n, 0m, 0f, 1u
-pub 4096R/nnnnnnnn yyyy-mm-dd
- Key fingerprint = xxxx xxxx xxxx xxxx xxxx xxxx xxxx xxxx xxxx xxxx
-uid Xxx Xxxxxx <xx...@apache.org>
-sub 4096R/kkkkkkkk yyyy-mm-dd
-</pre>
-
-The public key with id nnnnnnnn should now be stored in `~/.gnupg/pubring.pgp` (on Windows 7, this is in `c:/Users/xxx/AppData/Roaming/gnupg/pubring.pgp`).
-
-To confirm the key has been generated, use:
-
-<pre>
-$ gpg --list-keys --fingerprint
-</pre>
-
-The key Id is the one true way to identify the key, and is also the last 8 digits of the fingerprint. The corresponding secret key for id `nnnnnnnn` is stored in `~/.gnupg/secring.pgp` (on Windows 7, this is in `c:/Users/xxx/AppData/Roaming/gnupg/secring.pgp`).
-
-It's also worth confirming the key has the correct preference of algorithms (reflecting the initial configuration we did earlier). For this, enter the gpg shell for your new key:
-
-<pre>
-$ gpg --edit-key nnnnnnnnn
->gpg
-</pre>
-
-where `nnnnnnnn` is your key id. Now, use the 'showpref' subcommand to list details:
-
-<pre>
-gpg> showpref
-[ultimate] (1). Xxx Xxxxxxxx (CODE SIGNING KEY) <xx...@apache.org>
- Cipher: AES256, AES192, AES, CAST5, 3DES
- Digest: SHA512, SHA384, SHA256, SHA224, SHA1
- Compression: ZLIB, BZIP2, ZIP, Uncompressed
- Features: MDC, Keyserver no-modify
-
-gpg>
-</pre>
-
-The Digest line should list SHA-512 first and SHA-1 last. If it doesn't, use the "setpref" command:
-<pre>
-setpref SHA512 SHA384 SHA256 SHA224 AES256 AES192 AES CAST5 ZLIB BZIP2 ZIP Uncompressed
-</pre>
-
-Finally, remember to take a backup of your key and the keyring (ie, backup the `.gnupg` directory and its contents).
-
-
-## Subkey Generation
-
-It's recommended to use a subkey with an expiry date to sign releases, rather than your main, non-expiring key. If a subkey is present, then gpg will use it for signing in preference to the main key.
-
-{note
-
-After (binary) release artifacts are created, they are deployed to the ASF's Nexus staging repository. However, Nexus seems unable to retrieve a subkey from the public key server. Until we find a fix/workaround for this, all releases should be signed just with a regular non-expiring main key.
-
-}
-
-To create a subkey Enter the gpg shell using (the identifier of) your main key:
-
-<pre>
-gpg --edit-key xxxxxxxx
-gpg>
-</pre>
-
-Type 'addkey' to create a subkey, and enter your passphrase for the main key:
-
-<pre>
-gpg> addkey
-Key is protected.
-[enter your secret passphrase]
-
-You need a passphrase to unlock the secret key for
-user: "Dan Haywood (CODE SIGNING KEY) <da...@apache.org>"
-4096-bit RSA key, ID xxxxxxxx, created 2011-02-01
-
-Please select what kind of key you want:
- (3) DSA (sign only)
- (4) RSA (sign only)
- (5) Elgamal (encrypt only)
- (6) RSA (encrypt only)
-Your selection?
-</pre>
-
-Select (6) to choose an RSA key for encryption:
-
-{note
-
-It would seem that Nexus repository manager does not recognize RSA subkeys with an 'S'ign usage; see this discussion on a mailing list and this issue on Sonatype's JIRA
-
-}
-
-<pre>
-Your selection? 6
-
-RSA keys may be between 1024 and 4096 bits long.
-What keysize do you want? (2048) 4096
-
-Requested keysize is 4096 bits
-
-Please specify how long the key should be valid.
- 0 = key does not expire
- <n> = key expires in n days
- <n>w = key expires in n weeks
- <n>m = key expires in n months
- <n>y = key expires in n years
-Key is valid for?
-</pre>
-
-Specify that the key is valid for 1 year:
-
-<pre>
-Key is valid for? (0) 1y
-
-Key expires at yy/MM/dd hh:mm:ss
-Is this correct? (y/N) y
-Really create? (y/N) y
-We need to generate a lot of random bytes. It is a good idea to perform
-some other action (type on the keyboard, move the mouse, utilize the
-disks) during the prime generation; this gives the random number
-generator a better chance to gain enough entropy.
-...+++++
-.+++++
-
-pub 4096R/xxxxxxxx created: yyyy-mm-dd expires: never usage: SC
- trust: ultimate validity: ultimate
-sub 4096R/xxxxxxxx created: yyyy-mm-dd expires: yyYY-mm-dd usage: E
-[ultimate] (1). Dan Haywood (CODE SIGNING KEY) <da...@apache.org>
-
-gpg>
-</pre>
-
-Quit the gpg shell; you now have a subkey.
-
-
-## Generate a Revocation Certificate
-
-It's good practice to generate a number of revocation certificates so that the key can be revoked if it happens to be compromised. See the [gpg page](http://www.apache.org/dev/openpgp.html#revocation-certs) on the Apache wiki for more background on this topic.
-
-First, generate a "no reason specified" key:
-
-<pre>
-$ gpg --output revoke-nnnnnnnn-0.asc --armor --gen-revoke nnnnnnnn
-
-sec 4096R/nnnnnnnn yyyy-mm-dd Xxx Xxxxxxx (CODE SIGNING KEY) <xx...@apache.org>
-Create a revocation certificate for this key? (y/N) Y
-
-Please select the reason for the revocation:
- 0 = No reason specified
- 1 = Key has been compromised
- 2 = Key is superseded
- 3 = Key is no longer used
- Q = Cancel
-(Probably you want to select 1 here)
-Your decision?
-</pre>
-
-Select 0.
-
-<pre>
-Your decision? 0
-
-Enter an optional description; end it with an empty line:
-</pre>
-
-Provide a description:
-
-<pre>
-> Generic certificate to revoke key, generated at time of key creation.
->
-Reason for revocation: No reason specified
-Generic certificate to revoke key, generated at time of key creation.
-Is this okay? (y/N)
-</pre>
-
-Confirm this is ok.
-
-<pre>
-Is this okay? y
-
-You need a passphrase to unlock the secret key for
-user: "Xxx Xxxxxxx (CODE SIGNING KEY) <xx...@apache.org>"
-4096-bit RSA key, ID nnnnnnnn, created yyyy-mm-dd
-
-Enter passphrase:
-</pre>
-
-Enter a passphrase:
-
-<pre>
-Enter passphrase:
-Revocation certificate created.
-
-Please move it to a medium which you can hide away; if Mallory gets
-access to this certificate he can use it to make your key unusable.
-It is smart to print this certificate and store it away, just in case
-your media become unreadable. But have some caution: The print system of
-your machine might store the data and make it available to others!
-</pre>
-
-The file `revoke-nnnnnnnn-0.asc` should be created: Then, backup this file.
-
-Now repeat the process to create two further revocation certificates:
-
-- `gpg --output revoke-nnnnnnnn-1.asc --armor --gen-revoke nnnnnnnn`
-
- Specify reason as "1 = Key has been compromised"
-
-- `gpg --output revoke-nnnnnnnn-3.asc --armor --gen-revoke nnnnnnnn`
-
- Specify reason as "3 = Key is no longer used"
-
-Backup these files also.
-
-{note
-
-if you find that you need to revoke your certificate, this blog post explains how.
-
-}
-
-## Publish Key
-
-It is also necessary to publish your key. There are several places where this should be done. In most cases, you'll need the "armored" " (ie ASCII) representation of your key. This can be generated using:
-
-<pre>
-$ gpg --armor --export nnnnnnnn > nnnnnnnn.asc
-</pre>
-
-where `nnnnnnnn` is the id of your public key.
-
-You'll also need the fingerprint of your key. This can be generated using:
-
-<pre>
-$ gpg --fingerprint nnnnnnnn
-</pre>
-
-The output from this command includes a line beginning "Key fingerprint", followed by a (space delimited) 40 character hexadecimal fingerprint. The last 8 characters should be the same as the key id (`nnnnnnnn`).
-
-### Publish to a public key server
-
-To a publish your key to a public key server (eg the MIT key server hosted at [http://pgp.mit.edu](http://pgp.mit.edu)), use the procedure below. Public key servers synchronize with each other, so publishing to one key server should be sufficient. For background reading on this, see the [release signing page](http://www.apache.org/dev/release-signing.html#keyserver-upload) on the Apache wiki, and the [gpg key page](http://maven.apache.org/developers/release/pmc-gpg-keys.html) on the Maven wiki.
-
-To send the key up to the key server:
-
-<pre>
-$ gpg --send-keys --keyserver pgp.mit.edu nnnnnnnn
-</pre>
-
-where `nnnnnnnn` is the key Id.
-
-Alternatively, you can browse to the [MIT key server](http://pgp.mit.edu/) and paste in the armored representation of your key.
-
-Confirm the key has been added by browsing to submitting the following URL:
-
-`http://pgp.mit.edu:11371/pks/lookup?search=0xnnnnnnnnn&op=vindex`
-
-again, where `nnnnnnnn` is the key Id.
-
-### Publish to your Apache home directory
-
-The armored representation of your public key should be uploaded to your home directory on `people.apache.org`, and renamed as `.pgpkey`. Make sure this is readable by all.
-
-### Publish to your Apache HTML home directory
-
-The armored representation of your public key should be uploaded to your `public_html` home directory on `people.apache.org`, named `nnnnnnnn.asc`. Make sure this is readable by all.
-
-Check the file is accessible by browsing to:
-
-`http://people.apache.org/~xxxxxxxx/nnnnnnnn.asc`
-
-where
-
-- `xxxxxxxx` is your apache LDAP user name
-- `nnnnnnnn` is your public key id.
-
-### FOAF
-
-First, check out the committers/info directory:
-
-<pre>
-svn co https://svn.apache.org/repos/private/committers/info
-</pre>
-
-Go to Apache [FOAF-a-matic](http://people.apache.org/foaf/foafamatic.html) web page to generate the FOAF file text (we copy this text out in a minute):
-
-- enter ASF LDAP user name
-- enter First name, Last name
-- for PGP key fingerprints, add Key
- - paste in the key id
- - paste in the fingerprint
-- press "Create"
-
-In the box below, you should have a FOAF file, something like:
-
-<pre>
-<?xml version="1.0" encoding="UTF-8"?>
-<rdf:RDF
- xmlns:rdf="http://www.w3.org/1999/02/22-rdf-syntax-ns#"
- xmlns:rdfs="http://www.w3.org/2000/01/rdf-schema#"
- xmlns:foaf="http://xmlns.com/foaf/0.1/"
- xmlns:geo="http://www.w3.org/2003/01/geo/wgs84_pos#"
- xmlns:pm="http://www.web-semantics.org/ns/pm#"
- xmlns:wot="http://xmlns.com/wot/0.1/"
- xmlns:rss="http://purl.org/rss/1.0/"
- xmlns:dc="http://purl.org/dc/elements/1.1/"
- xmlns:ical="http://www.w3.org/2002/12/cal/ical#"
- xmlns:doap="http://usefulinc.com/ns/doap#">
- <foaf:Person rdf:ID="danhaywood">
- <foaf:name>Xxx Xxxxxxxx</foaf:name>
- <foaf:givenname>Xxx</foaf:givenname>
- <foaf:family_name>Xxxxxxxx</foaf:family_name>
- <wot:hasKey>
- <wot:PubKey>
- <wot:fingerprint>nnnn nnnn nnnn nnnn nnnn nnnn nnnn nnnn nnnn nnnn</wot:fingerprint>
- <wot:hex_id>nnnnnnnn</wot:hex_id>
- </wot:PubKey>
- </wot:hasKey>
- </foaf:Person>
-</rdf:RDF>
-</pre>
-
-(If you are creating the FOAF file for the first time, you may want to add additional details).
-
-From this, copy out the `wot:key`, and paste into your FDF file in `committers/info`:
-
-<pre>
- <wot:hasKey>
- <wot:PubKey>
- <wot:fingerprint>nnnn nnnn nnnn nnnn nnnn nnnn nnnn nnnn nnnn nnnn</wot:fingerprint>
- <wot:hex_id>nnnnnnnn</wot:hex_id>
- </wot:PubKey>
- </wot:hasKey>
-</pre>
-
-Then, manually add in a `<wot:pubkeyAddress>` element within `<wot:PubKey>`:
-
-<pre>
- <wot:hasKey>
- <wot:PubKey>
- <wot:fingerprint>nnnn nnnn nnnn nnnn nnnn nnnn nnnn nnnn nnnn nnnn</wot:fingerprint>
- <wot:hex_id>nnnnnnnn</wot:hex_id>
- <wot:pubkeyAddress
- rdf:resource="http://people.apache.org/~username/nnnnnnnn.asc/>
- </wot:PubKey>
- </wot:hasKey>
-</pre>
-
-ie, referencing your publically exported public key
-
-Finally, commit your changes.
-
-### Save to `KEYS`
-
-The armored representation of the public key should be saved to Isis' `KEYS` file, [http://www.apache.org/dist/isis/KEYS](http://www.apache.org/dist/isis/KEYS) (that is, in the ASF distribution directory for Isis).
-
-First, in a new directory, checkout this file:
-
-<pre>
-svn -N co https://svn.apache.org/repos/asf/isis/ .
-</pre>
-This should bring down the `KEYS` file.
-
-Then, export your signature and armored representation.
-
-<pre>
-gpg --list-sigs nnnnnnnn >>KEYS
-gpg --armor --export nnnnnnnn >>KEYS
-</pre>
-
-Then commit.
-
-### id.apache.org
-
-Log onto `id.apache.org` and ensure that the finger print of your public key is correct.
-
-
-## Attend Key Signing Party (Apache web of trust)
-
-It is strongly advised that the contributor attend a key signing party at an Apache event, in order that other Apache committers/members can in person verify their identity against the key. The process for this is described [here](http://www.apache.org/dev/release-signing.html#key-signing-party) and [here](http://wiki.apache.org/apachecon/PgpKeySigning).
-
-
-## Update Maven Settings file (`~/.m2/settings.xml`)
-
-The Maven release plugin will automatically sign the release, however it is necessary to update the `~/.m2/settings.xml` file with your GPG acronym passphrase in order that it can use your secret key. This is defined under a profile so that it is activated only when we perform a release (as defined by `[org,apache:apache]` parent POM.
-
-Therefore, make the following edits:
-
-<pre>
-<settings>
- ...
- <profiles>
- <profile>
- <id>apache-release</id>
- <properties>
- <gpg.passphrase>xxx xxx xxx xxx xxx xxx xxx</gpg.passphrase>
- </properties>
- </profile>
- </profiles>
-</settings>
-</pre>
-
-In addition, to allow the release plugin to tag SVN changes, you must either add in your LDAP username/password or configure `.ssh`:
-
-<pre>
-<settings>
- ...
- <servers>
- ...
- <server>
- <id>apache.releases.https</id>
- <username>xxxx</username>
- <password>xxxx</password>
- </server>
- </servers>
-</settings>
-</pre>
http://git-wip-us.apache.org/repos/asf/isis-site/blob/365806f1/content-OLDSITE/contributors/pmc-notes.md
----------------------------------------------------------------------
diff --git a/content-OLDSITE/contributors/pmc-notes.md b/content-OLDSITE/contributors/pmc-notes.md
deleted file mode 100644
index 9f12815..0000000
--- a/content-OLDSITE/contributors/pmc-notes.md
+++ /dev/null
@@ -1,48 +0,0 @@
-Title: PMC Notes
-
-[//]: # (content copied to _user-guide_xxx)
-
-> These are some general jottings on occasionally performed tasks by the PMC
-
-ASF documents can be found [here](http://www.apache.org/dev/pmc.html)
-
-## Accessing `people.apache.org`
-
-Must be accessed via ssh.
-
-eg:
-
- ssh danhaywood@people.apache.org
-
-and when prompted, provide passphrase for private key.
-
-> I've forgotten what I did to set this up in the first place, though :-(
-
-## LDAP Access (UNIX groups)
-
-Whenever we get a new committer, the ASF LDAP entries must be maintained to grant access to our repos and various other 'karma'.
-
-Log onto `people.apache.org`, then use:
-
- list_unix_group.pl isis
-
-to list committers
-
- list_committee.pl isis
-
-to list the PMC committee members (in Isis, every committer should be on the PMC committee)
-
-To change membership of either the committers or the PMC, use:
-
- modify_unix_group.pl isis --add joebloggs
- modify_unix_group.pl isis --remove joebloggs
-
-and
-
- modify_committee.pl gump --add joebloggs
- modify_committee.pl gump --remove joebloggs
-
-respectively.
-
-Further details are in [these ASF docs](http://www.apache.org/dev/pmc.html#SVNaccess). (They talk about SVN access, but really it is LDAP access).
-
http://git-wip-us.apache.org/repos/asf/isis-site/blob/365806f1/content-OLDSITE/contributors/recreating-an-archetype.md
----------------------------------------------------------------------
diff --git a/content-OLDSITE/contributors/recreating-an-archetype.md b/content-OLDSITE/contributors/recreating-an-archetype.md
deleted file mode 100644
index ba0d66b..0000000
--- a/content-OLDSITE/contributors/recreating-an-archetype.md
+++ /dev/null
@@ -1,243 +0,0 @@
-Title: Recreating an Archetype
-
-[//]: # (content copied to _user-guide_xxx)
-
-Isis archetypes are reverse engineered from example applications. Once reverse engineered, the source is checked into git (replacing any earlier version of the archetype) and released.
-
-### Setup environment variables
-
-To recreate the **simpleapp** archetype:
-
- cd example/application/simpleapp
-
- export ISISTMP=/c/tmp # or as required
- export ISISART=simpleapp-archetype
- export ISISDEV=1.9.0-SNAPSHOT
- export ISISREL=1.8.0
- export ISISPAR=1.8.0
- export ISISRC=RC1
-
- export ISISCPT=$(echo $ISISART | cut -d- -f2)
- export ISISCPN=$(echo $ISISART | cut -d- -f1)
-
- env | grep ISIS | sort
-
-nb: `$ISISPAR` is the version of the Isis core that will act as the archetype's parent. Usually this is the same as `$ISISREL`.
-
-### Check the example app
-
-Make sure you are in the correct directory, and update the parent `pom.xml` to reference the *released* version of Isis core<!--and the other components-->:
-
- <properties>
- <isis.version>1.8.0</isis.version>
- ...
- </properties>
-
-Alternatively, you could just load up each `pom.xml` and inspect manually:
-
- vi `/bin/find . -name pom.xml | grep -v target`
-
-... and search for `SNAPSHOT`.
-
-
-Next, check for and fix any missing license header notices:
-
- mvn org.apache.rat:apache-rat-plugin:check -D rat.numUnapprovedLicenses=50 -o
- for a in `/bin/find . -name rat.txt -print`; do grep '!???' $a; done
-
-Finally, double check that the app is running satisfactorily:
-
-first, as self-hosted webconsole (browse to [http://localhost:8080](http://localhost:8080)):
-
- mvn clean install
- mvn antrun:run -P self-host
-
-then using mvn jetty plugin:
-
- cd webapp
- mvn jetty:run
-
-Browse to [http://localhost:8080/simpleapp-webapp/](http://localhost:8080/simpleapp-webapp/).
-
-
-
-Check the about page and confirm built against non-SNAPSHOT versions of the Isis jars.
-
-### Create the archetype (manual)
-
-
-{note
-The archetype can be created either by hand or with a script. The section describes the manual approach; the scripted approach is in the section after.
-}
-
-Before we generate the archetype, we clear out all non source code artifacts.
-
-Start by doing the regular `mvn clean`:
-
- mvn clean
-
-To view the remaining files/directories that needs removing, use:
-
- for a in .project .classpath .settings bin .idea target-ide; do /bin/find . -name $a -print; done
- /bin/find . -name "*.iml" -print
- /bin/find . -name "*.log" -print
- /bin/find . -name "pom.xml.*" -print
-
-To actually delete these files, use:
-
- for a in .project .classpath .settings bin .idea target-ide; do /bin/find . -name $a -exec rm -r {} \;; done
- /bin/find . -name "*.iml" -exec rm {} \;
- /bin/find . -name "*.log" -exec rm {} \;
- /bin/find . -name "pom.xml.*" -exec rm {} \;
-
-Quickly check that the remaining files are all source files:
-
- /bin/find .
-
-Now we can create the archetype.
-
- mvn archetype:create-from-project
-
-and then update the generated files:
-
- groovy ../../../scripts/updateGeneratedArchetypeSources.groovy -n $ISISCPN -v $ISISPAR
-
-where:
-
-- `$ISISCPN` is the component name set earlier (`simpleapp`)
-- `$ISISPAR` is the version of isis core that is to be the parent of the generated archetype,
- - this will usually be the same as `$ISISREL` unless a patch/interim release of the archetype.
-
-### Test the archetype
-
-First, build the archetype:
-
- cd target/generated-sources/archetype
- mvn clean install
- cd ../../..
-
-Then, *in a different session*, create a new app from the archetype:
-
-Set up environment variables:
-
-To test the **simpleapp** archetype:
-
- export ISISTMP=/c/tmp # or as required
- export ISISCPN=simpleapp
- env | grep ISIS | sort
-
-Then recreate:
-
- rm -rf $ISISTMP/test-$ISISCPN
-
- mkdir $ISISTMP/test-$ISISCPN
- cd $ISISTMP/test-$ISISCPN
- mvn archetype:generate \
- -D archetypeCatalog=local \
- -D groupId=com.mycompany \
- -D artifactId=myapp \
- -D archetypeGroupId=org.apache.isis.archetype \
- -D archetypeArtifactId=$ISISCPN-archetype
-
-Build the newly generated app and test:
-
- cd myapp
- mvn clean install
- mvn antrun:run -P self-host # runs as standalone app using webconsole
- cd webapp
- mvn jetty:run # runs as mvn jetty plugin
-
-### Check the archetype source code into git
-
-Back in the *original session* (at `example/application/simpleapp`), we are ready to check the archetype source code into git:
-
- git rm -rf ../../archetype/$ISISCPN
- rm -rf ../../archetype/$ISISCPN
-
-In either case make sure that the `archetype/$ISISCPN` directory was fully removed, otherwise the next command will not copy the regenerated source into the correct location.
-
-Then, copy over the generated source of the archetype:
-
- mv target/generated-sources/archetype ../../archetype/$ISISCPN
- git add ../../archetype/$ISISCPN
-
-Next, confirm that the `-SNAPSHOT` version of the archetype is correct:
-
- vi ../../archetype/$ISISCPN/pom.xml
-
-If this a new archetype, then add a reference to the archetype to the root `pom.xml`, eg:
-
- <modules>
- ...
- <module>example/archetype/newapp</module>
- ...
- </modules>
-
-Finally, commit the changes:
-
- git commit -am "ISIS-nnn: updating $ISISCPN archetype"
-
-
-### Create the archetype (scripted)
-
-{note
-Using the script does not generate an app from the archetype to test it works.
-}
-
-Make sure you are in the correct directory and environment variables are correct.
-
-To recreate the **simpleapp** archetype:
-
- cd example/application/simpleapp
-
- env | grep ISIS | sort
-
-If the environment variables look wrong, use the commands at the top of this page to setup.
-The script will also double check that all required environment variables are set.
-
-Then, run the script:
-
- sh ../../../scripts/recreate-archetype.sh ISIS-nnn
-
-The script automatically commits changes; if you wish use `git log` and
-`git diff` (or a tool such as SourceTree) to review changes made.
-
-### Releasing the Archetype
-
-{note
-Releasing the archetype is performed from the **example/archetype** directory,
-NOT the *example/application* directory.
-}
-
-The procedure for releasing the archetype is the same as for any other releasable module.
-
-First, confirm environment variables set correctly:
-
- env | grep ISIS | sort
-
-Then switch the correct directory and release:
-
- cd ../../../example/archetype/$ISISCPN
-
- rm -rf $ISISTMP/checkout
-
- mvn release:prepare -P apache-release \
- -DreleaseVersion=$ISISREL \
- -DdevelopmentVersion=$ISISDEV \
- -Dtag=$ISISART-$ISISREL
- mvn release:perform -P apache-release \
- -DworkingDirectory=$ISISTMP/checkout
-
-Next, log onto [repository.apache.org](http://repository.apache.org) and close the staging repo.
-
-Then push branch:
-
- git push -u origin prepare/$ISISART-$ISISREL
-
-and push tag:
-
- git push origin refs/tags/$ISISART-$ISISREL-$ISISRC:refs/tags/$ISISART-$ISISREL-$ISISRC
- git fetch
-
-See the [release process](release-process.html) for full details.
-
http://git-wip-us.apache.org/repos/asf/isis-site/blob/365806f1/content-OLDSITE/contributors/release-branch-and-tag-names.md
----------------------------------------------------------------------
diff --git a/content-OLDSITE/contributors/release-branch-and-tag-names.md b/content-OLDSITE/contributors/release-branch-and-tag-names.md
deleted file mode 100644
index 469055c..0000000
--- a/content-OLDSITE/contributors/release-branch-and-tag-names.md
+++ /dev/null
@@ -1,49 +0,0 @@
-Title: Release Branch and Tag Names
-
-[//]: # (content copied to _user-guide_xxx)
-
-As described in the [release process](release-process.html) documentation, each release of core or a component is prepared in a separate branch, and ultimately results in a tag in the central repo.
-
-In Isis the version numbers of core and each component can vary independently
-(they are not synchronized); therefore the branches and the tag names must
-distinguish the releasable module that they refer to.
-
-The table below shows the tag name to use when running the `release:prepare` command itself, as well as the local branch name to use while preparing the release:
-
-* We've chosen to base the tag name on the `artifactId` of the pom of the parent module being released, as this also happens to be the default provided by the `maven-release-plugin`.
-
-* The branch name to use is not actually that important, because it would not usually be pushed to the origin (unless you were preparing the release with some other committer). However, we recommend that is similar (though not identical to) the tag name.
-
-<table>
-<tr>
-<th>Releasable module</th>
- <th>Branch name to use while <br/>readying the release locally</th>
- <th>Tag name for <tt>release:prepare</tt></th>
- <th>Tag name manually pushed.</th>
-</tr>
-<tr>
- <td>core</td>
- <td>prepare/isis-x.y.z</td>
- <td>isis-x.y.z</td>
- <td>isis-x.y.z-RCn</td>
-</tr>
-<tr>
- <td>viewer/xxx</td>
- <td>prepare/isis-x.y.z<br/>(reuse same branch as core)</td>
- <td>isis-viewer-xxx-x.y.z</td>
- <td>isis-viewer-xxx-x.y.z-RCn</td>
-</tr>
-<tr>
- <td>example/archetype/<br/> xxxxapp</td>
- <td>prepare/isis-x.y.z<br/>(reuse same branch as core)</td>
- <td>xxxapp-archetype-x.y.z</td>
- <td>xxxapp-archetype-x.y.z-RCn</td>
-</tr>
-</table>
-
-where `xxx` represents a specific component or archetype being released.
-
-{note
-In fact, git allows the same name to be used for both branches and for tags; within git they are namespaced to be unique. However, using the same name for the branch confuses `maven-release-plugin`; thus the branch name is slightly different from the tag name.
-}
-
http://git-wip-us.apache.org/repos/asf/isis-site/blob/365806f1/content-OLDSITE/contributors/release-checklist.md
----------------------------------------------------------------------
diff --git a/content-OLDSITE/contributors/release-checklist.md b/content-OLDSITE/contributors/release-checklist.md
deleted file mode 100644
index cbbc19b..0000000
--- a/content-OLDSITE/contributors/release-checklist.md
+++ /dev/null
@@ -1,113 +0,0 @@
-Title: Release Checklist
-
-[//]: # (content copied to _user-guide_xxx)
-
-See also the [full release process](release-process.html) and [one-pager](release-process-one-pager.html).
-
-## Checklist
-
-also as a (published) <a href="https://docs.google.com/a/haywood-associates.co.uk/spreadsheet/pub?key=0Ahw-_f4BrwqAdGpJNzY4T1I1dmRFcTJtcTdmcjVVLXc&single=true&gid=2&output=html">google doc spreadsheet</a>.
-
-<table class="table table-bordered table-striped table-condensed table-hover">
- <thead>
- <tr>
- <th>Artifact</th>
- <th>Env?</th>
- <th>Update parent POM ver.</th>
- <th>Update TCK POM ver.</th>
- <th>Newer plugin versions</th>
- <th>Newer deps</th>
- <th>Formatting</th>
- <th>License headers (RAT)</th>
- <th>License check</th>
- <th>Recreate archetype</th>
- <th>Commit changes</th>
- </tr>
- </thead>
- <tbody>
- <tr>
- <th>isis</th>
- <td> </td>
- <td> </td>
- <td>n/a</td>
- <td> </td>
- <td> </td>
- <td> </td>
- <td> </td>
- <td> </td>
- <td>n/a</td>
- <td> </td>
- </tr>
-<!--
- <tr>
- <th>isis-viewer-wicket</th>
- <td> </td>
- <td> </td>
- <td> </td>
- <td> </td>
- <td> </td>
- <td> </td>
- <td> </td>
- <td> </td>
- <td>n/a</td>
- <td> </td>
- </tr>
--->
- <tr>
- <th>simpleapp-archetype</th>
- <td> </td>
- <td> </td>
- <td>n/a</td>
- <td> </td>
- <td> </td>
- <td> </td>
- <td> </td>
- <td> </td>
- <td> </td>
- <td> </td>
- </tr>
- </tbody>
- <thead>
- <tr>
- <th>Artifact</th>
- <th>prepare dryrun</th>
- <th>prepare</th>
- <th>confirm</th>
- <th>perform</th>
- <th>stage (nexus)</th>
- <th>git push</th>
- </tr>
- </thead>
- <tbody>
- <tr>
- <th>isis</th>
- <td> </td>
- <td> </td>
- <td> </td>
- <td> </td>
- <td> </td>
- <td> </td>
- </tr>
-<!--
- <tr>
- <th>isis-viewer-wicket</th>
- <td> </td>
- <td> </td>
- <td> </td>
- <td> </td>
- <td> </td>
- <td> </td>
- </tr>
--->
- <tr>
- <th>simpleapp-archetype</th>
- <td> </td>
- <td> </td>
- <td> </td>
- <td> </td>
- <td> </td>
- <td> </td>
- </tr>
- </tbody>
-</table>
-
http://git-wip-us.apache.org/repos/asf/isis-site/blob/365806f1/content-OLDSITE/contributors/release-process-one-pager.md
----------------------------------------------------------------------
diff --git a/content-OLDSITE/contributors/release-process-one-pager.md b/content-OLDSITE/contributors/release-process-one-pager.md
deleted file mode 100644
index 13b699d..0000000
--- a/content-OLDSITE/contributors/release-process-one-pager.md
+++ /dev/null
@@ -1,225 +0,0 @@
-Title: Release Process (1 pager)
-
-[//]: # (content copied to _user-guide_xxx)
-
-See also the [full release process](release-process.html) and the [release checklist](release-checklist.html).
-
-## Switch to correct directory, parameterize the release
-
-{note
-Make sure you are in the correct directory (eg core, or example/archetype/zzz)
-}
-
-if you are releasing `core`:
-
- cd core
-
- export ISISTMP=/c/tmp # or whatever
- export ISISART=isis
- export ISISDEV=1.9.0-SNAPSHOT
- export ISISREL=1.8.0
- export ISISRC=RC1
-
- export ISISCOR="Y"
- env | grep ISIS | sort
-
-<!--
-if releasing a `component/xxx/yyy`, eg:
-
- cd component/xxx/yyy
-
- export ISISTMP=/c/tmp # or whatever
- export ISISART=isis-xxx-yyy
- export ISISDEV=1.9.0-SNAPSHOT
- export ISISREL=1.8.0
- export ISISRC=RC1
-
- export ISISCOR="N"
- export ISISCPT=$(echo $ISISART | cut -d- -f2)
- export ISISCPN=$(echo $ISISART | cut -d- -f3)
- env | grep ISIS | sort
--->
-
-See [here](recreating-an-archetype.html) for details on recreating and releasing an archetype.
-
-
-## Get code
-
-<--If **releasing core**, then pull -->
-Pull down latest, create branch (eg `prepare/isis-1.8.0`):
-
- git checkout master
- git pull --ff-only
- git checkout -b $ISISART-$ISISREL
-
-<!--
-If **releasing a component without also releasing core**, then pull down latest, create branch (eg `isis-xxx-yyy-1.8.0`):
-
- git checkout master
- git pull --ff-only
- git checkout -b $ISISART-$ISISREL
-
-If **releasing a component on top of a core release**, then omit this step (just continue in the same branch as for core).
--->
-
-##Update parent pom
-
-<!--If **releasing core**, check:-->
-Check:
-
-* parent is `org.apache:apache` (non-SNAPSHOT version)
-
-<!--
-If **releasing a component**, check:
-
-* parent of component is `o.a.isis.core:isis` (non-SNAPSHOT version)
- * eg `component/viewer/wicket/pom.xml`
-* parent of tck modules is `o.a.isis.core:isis-core-tck` (non-SNAPSHOT version)
- * eg `component/viewer/wicket/tck/pom.xml`
--->
-
-##Check for SNAPSHOT dependencies
-
-Search for any non-`SNAPSHOT` usages (including tck project, if any):
-
- grep SNAPSHOT `/bin/find . -name pom.xml | grep -v target | sort`
-
-or (more thoroughly):
-
- vi `/bin/find . -name pom.xml | grep -v target | sort`
-
-
-## Sanity check
-
-{note
-Make sure you are in the correct directory (eg core, <!--component/xxx/yyy--> or example/archetype/zzz)
-}
-
-<!--If **releasing core**, then clean-->
-Clean all local mvn artifacts and rebuild with `-o` flag:
-
- cd core
-
- rm -rf ~/.m2/repository/org/apache/isis
- mvn clean install -o
-
-<!--
-If **releasing a component without also releasing core**, then clean all local mvn artifacst and rebuild **without `-o`** flag:
-
- cd component/xxx/yyy
-
- rm -rf ~/.m2/repository/org/apache/isis
- mvn clean install
-
-If **releasing a component on top of a core release**, then do not clean, just rebuild with `-o` flag:
-
- mvn clean install -o
--->
-
-## Check versions
-
-####Update plugin versions
-
-> Actually, you may want to defer this and do after cutting the release (ie beginning of a new dev cycle)
-
- mvn versions:display-plugin-updates > /tmp/foo
- grep "\->" /tmp/foo | /bin/sort -u
-
-####Newer dependencies:
-
-> Actually, you may want to defer this and do after cutting the release (ie beginning of a new dev cycle)
-
- mvn versions:display-dependency-updates > /tmp/foo
- grep "\->" /tmp/foo | /bin/sort -u
-
-## Update license information
-
-####Missing license headers in files:
-
- mvn org.apache.rat:apache-rat-plugin:check -D rat.numUnapprovedLicenses=50 -o
- for a in `/bin/find . -name rat.txt -print`; do grep '!???' $a; done
-
-####Missing/spurious `supplemental-models.xml`
-
- mvn license:download-licenses
- if [ "$ISISCOR" == "Y" ]; then
- groovy ../scripts/checkmissinglicenses.groovy
- else
- groovy ../../../scripts/checkmissinglicenses.groovy
- fi
-
-
-## Commit changes
-
-Commit any changes from the preceding steps:
-
- git commit -am "ISIS-nnnn: updates to pom.xml etc for release"
-
-## Release
-
-#### Prepare:
-
-{note
-Make sure you are in the correct directory (eg core, <!--component/xxx/yyy--> or example/archetype/zzz)
-}
-
-first the dry run:
-
- mvn release:prepare -P apache-release \
- -DdryRun=true \
- -DreleaseVersion=$ISISREL \
- -DdevelopmentVersion=$ISISDEV \
- -Dtag=$ISISART-$ISISREL-$ISISRC
-
-then "for real":
-
- mvn release:prepare -P apache-release -DskipTests=true -Dresume=false \
- -DreleaseVersion=$ISISREL \
- -DdevelopmentVersion=$ISISDEV \
- -Dtag=$ISISART-$ISISREL-$ISISRC
-
-#### Confirm:
-
- rm -rf $ISISTMP/$ISISART-$ISISREL
- mkdir $ISISTMP/$ISISART-$ISISREL
-
- if [ "$ISISCOR" == "Y" ]; then
- ZIPDIR="$M2_REPO/repository/org/apache/isis/core/$ISISART/$ISISREL"
- else
- ZIPDIR="$M2_REPO/repository/org/apache/isis/$ISISCPT/$ISISART/$ISISREL"
- fi
- echo "cp \"$ZIPDIR/$ISISART-$ISISREL-source-release.zip\" $ISISTMP/$ISISART-$ISISREL/."
- cp "$ZIPDIR/$ISISART-$ISISREL-source-release.zip" $ISISTMP/$ISISART-$ISISREL/.
-
- pushd $ISISTMP/$ISISART-$ISISREL
- unzip $ISISART-$ISISREL-source-release.zip
-
- cd $ISISART-$ISISREL
- mvn clean install
-
- cat DEPENDENCIES
-
- popd
-
-#### Perform:
-
- mvn release:perform -P apache-release \
- -DworkingDirectory=$ISISTMP/$ISISART-$ISISREL/checkout
-
-> The `workingDirectory` property is to avoid 260char path issue if building on Windows.
-
-## Nexus staging
-
-Log onto [repository.apache.org](http://repository.apache.org) and close the staging repo.
-
-## Git branches/tags
-
-Push branch:
-
- git push -u origin $ISISART-$ISISREL
-
-Then push tag:
-
- git push origin refs/tags/$ISISART-$ISISREL-$ISISRC:refs/tags/$ISISART-$ISISREL-$ISISRC
- git fetch
-