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 2015/07/10 09:41:33 UTC
[04/10] isis git commit: ISIS-1133: pulling together the contributors
guide.
http://git-wip-us.apache.org/repos/asf/isis/blob/8ad6101a/adocs/documentation/src/main/asciidoc/key-generation.adoc
----------------------------------------------------------------------
diff --git a/adocs/documentation/src/main/asciidoc/key-generation.adoc b/adocs/documentation/src/main/asciidoc/key-generation.adoc
deleted file mode 100644
index aa8ca53..0000000
--- a/adocs/documentation/src/main/asciidoc/key-generation.adoc
+++ /dev/null
@@ -1,572 +0,0 @@
-[[key-generation]]
-= Key Generation
-:notice: licensed to the apache software foundation (asf) under one or more contributor license agreements. see the notice file distributed with this work for additional information regarding copyright ownership. the asf licenses this file to you under the apache license, version 2.0 (the "license"); you may not use this file except in compliance with the license. you may obtain a copy of the license at. http://www.apache.org/licenses/license-2.0 . unless required by applicable law or agreed to in writing, software distributed under the license is distributed on an "as is" basis, without warranties or conditions of any kind, either express or implied. see the license for the specific language governing permissions and limitations under the license.
-:_basedir: ./
-:_imagesdir: images/
-:toc: right
-
-
-pass:[<br/><br/>]
-
-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 http://www.apache.org/dev/release-signing.html[release signing page] and the http://www.apache.org/dev/openpgp.html#generate-key[openpgp page] 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:
-
-[source,bash]
-----
-personal-digest-preferences SHA512
-cert-digest-algo SHA512
-default-preference-list SHA512 SHA384 SHA256 SHA224 AES256 AES192 AES CAST5 ZLIB BZIP2 ZIP Uncompressed
-----
-
-
-
-
-== Key Generation
-
-The Apache Software Foundation requires that keys are signed with a key (or subkey) based on RSA 4096 bits. To do this:
-
-[source]
-----
-$ 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?
-----
-
-Specify RSA key:
-
-[source]
-----
-Your selection? 1
-
-RSA keys may be between 1024 and 4096 bits long.
-What keysize do you want? (2048)
-----
-
-Specify key length as 4096 bits:
-
-[source]
-----
-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)
-----
-
-Specify key as non-expiring:
-
-[source]
-----
-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:
-----
-
-Enter your name, email and comment:
-
-* use your apache.org email
-* the comment should be "CODE SIGNING KEY"
-
-Real name: Xxx Xxxxxxxxx
-Email address: link:mailto:xxx@apache.org[xxx@apache.org]
-Comment: CODE SIGNING KEY
-You selected this USER-ID:
- "Xxx Xxxxxxxxx (CODE SIGNING KEY) link:mailto:xxx@apache.org[xxx@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:
-
-Provide a passphrase to secure your key.
-
-[source]
-----
-Enter passphrase:
-Repeat passphrase:
-----
-
-GPG will goes on to generate your key:
-
-[source]
-----
-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
-----
-
-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:
-
-[source]
-----
-$ gpg --list-keys --fingerprint
-----
-
-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:
-
-[source]
-----
-$ gpg --edit-key nnnnnnnnn
->gpg
-----
-
-where `nnnnnnnn` is your key id. Now, use the 'showpref' subcommand to list details:
-
-[source]
-----
-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>
-----
-
-The Digest line should list SHA-512 first and SHA-1 last. If it doesn't, use the "setpref" command:
-
-[source]
-----
-setpref SHA512 SHA384 SHA256 SHA224 AES256 AES192 AES CAST5 ZLIB BZIP2 ZIP Uncompressed
-----
-
-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:
-
-[source]
-----
-gpg --edit-key xxxxxxxx
-gpg>
-----
-
-Type 'addkey' to create a subkey, and enter your passphrase for the main key:
-
-[source]
-----
-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?
-----
-
-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
-====
-
-
-[source]
-----
-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?
-----
-
-Specify that the key is valid for 1 year:
-
-[source]
-----
-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>
-----
-
-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 http://www.apache.org/dev/openpgp.html#revocation-certs[gpg page] on the Apache wiki for more background on this topic.
-
-First, generate a "no reason specified" key:
-
-[source]
-----
-$ 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?
-----
-
-Select 0.
-
-[source]
-----
-Your decision? 0
-
-Enter an optional description; end it with an empty line:
-----
-
-Provide a description:
-
-[source]
-----
-> 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)
-----
-
-Confirm this is ok.
-
-[source]
-----
-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!
-----
-
-The file `revoke-nnnnnnnn-0.asc` should be created: Then, backup this file.
-
-Now repeat the process to create two further revocation certificates:
-
-[source,bash]
-----
-gpg --output revoke-nnnnnnnn-1.asc --armor --gen-revoke nnnnnnnn
-----
-
-Specify reason as "1 = Key has been compromised"
-
-and:
-
-[source,bash]
-----
-gpg --output revoke-nnnnnnnn-3.asc --armor --gen-revoke nnnnnnnn
-----
-
-Specify reason as "3 = Key is no longer used"
-
-Backup these files also.
-
-
-
-
-
-== 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:
-
-[source]
-----
-$ gpg --armor --export nnnnnnnn > nnnnnnnn.asc
-----
-
-where `nnnnnnnn` is the id of your public key.
-
-You'll also need the fingerprint of your key. This can be generated using:
-
-[source]
-----
-$ gpg --fingerprint nnnnnnnn
-----
-
-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 http://www.apache.org/dev/release-signing.html#keyserver-upload[release signing page] on the Apache wiki, and the http://maven.apache.org/developers/release/pmc-gpg-keys.html[gpg key page] on the Maven wiki.
-
-To send the key up to the key server:
-
-[source]
-----
-$ gpg --send-keys --keyserver pgp.mit.edu nnnnnnnn
-----
-
-where `nnnnnnnn` is the key Id.
-
-Alternatively, you can browse to the http://pgp.mit.edu/[MIT key server] 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:
-
-Go to Apache http://people.apache.org/foaf/foafamatic.html[FOAF-a-matic] 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:
-
-[source,xml]
-----
-<?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>
-----
-
-(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`:
-
-[source,xml]
-----
-<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>
-----
-
-Then, manually add in a `<wot:pubkeyAddress>` element within `<wot:PubKey>`:
-
-[source,xml]
-----
-<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>
-----
-
-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 Apache 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 Apache Isis).
-
-First, in a new directory, checkout this file:
-
-[source]
-----
-svn -N co https://svn.apache.org/repos/asf/isis/ .
-----
-
-This should bring down the `KEYS` file.
-
-Then, export your signature and armored representation.
-
-[source]
-----
-gpg --list-sigs nnnnnnnn >>KEYS
-gpg --armor --export nnnnnnnn >>KEYS
-----
-
-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 http://www.apache.org/dev/release-signing.html#key-signing-party[here] and http://wiki.apache.org/apachecon/PgpKeySigning[here].
-
-== 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:
-
-[source,xml]
-----
-<settings>
- ...
- <profiles>
- <profile>
- <id>apache-release</id>
- <properties>
- <gpg.passphrase>xxx xxx xxx xxx xxx xxx xxx</gpg.passphrase>
- </properties>
- </profile>
- </profiles>
-</settings>
-----
-
-In addition, to allow the release plugin to tag SVN changes, you must either add in your LDAP username/password or configure `.ssh`:
-
-[source,xml]
-----
-<settings>
- ...
- <servers>
- ...
- <server>
- <id>apache.releases.https</id>
- <username>xxxx</username>
- <password>xxxx</password>
- </server>
- </servers>
-</settings>
-----
\ No newline at end of file
http://git-wip-us.apache.org/repos/asf/isis/blob/8ad6101a/adocs/documentation/src/main/asciidoc/pmc-notes.adoc
----------------------------------------------------------------------
diff --git a/adocs/documentation/src/main/asciidoc/pmc-notes.adoc b/adocs/documentation/src/main/asciidoc/pmc-notes.adoc
deleted file mode 100644
index 8ccbadb..0000000
--- a/adocs/documentation/src/main/asciidoc/pmc-notes.adoc
+++ /dev/null
@@ -1,73 +0,0 @@
-[[pmc-note]]
-= PMC Notes
-:notice: licensed to the apache software foundation (asf) under one or more contributor license agreements. see the notice file distributed with this work for additional information regarding copyright ownership. the asf licenses this file to you under the apache license, version 2.0 (the "license"); you may not use this file except in compliance with the license. you may obtain a copy of the license at. http://www.apache.org/licenses/license-2.0 . unless required by applicable law or agreed to in writing, software distributed under the license is distributed on an "as is" basis, without warranties or conditions of any kind, either express or implied. see the license for the specific language governing permissions and limitations under the license.
-:_basedir: ./
-:_imagesdir: images/
-:toc: right
-
-
-pass:[<br/><br/>]
-
-
-[NOTE]
-====
-These are some general jottings on occasionally performed tasks by the PMC. ASF documents can be found http://www.apache.org/dev/pmc.html[here]
-====
-
-
-
-== Accessing `people.apache.org`
-
-Must be accessed via ssh.
-
-eg:
-
-[source]
-----
-ssh danhaywood@people.apache.org
-----
-
-and when prompted, provide passphrase for private key... though 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:
-
-[source]
-----
-list_unix_group.pl isis
-----
-
-to list committers
-
-[source]
-----
-list_committee.pl isis
-----
-
-to list the PMC committee members (in Apache Isis, every committer should be on the PMC committee)
-
-To change membership of either the committers or the PMC, use:
-
-[source]
-----
-modify_unix_group.pl isis --add joebloggs
-modify_unix_group.pl isis --remove joebloggs
-----
-
-and
-
-[source]
-----
-modify_committee.pl gump --add joebloggs
-modify_committee.pl gump --remove joebloggs
-----
-
-respectively.
-
-Further details are in http://www.apache.org/dev/pmc.html#SVNaccess[these ASF docs]. (They talk about SVN access, but really it is LDAP access).
\ No newline at end of file
http://git-wip-us.apache.org/repos/asf/isis/blob/8ad6101a/adocs/documentation/src/main/asciidoc/recreating-an-archetype.adoc
----------------------------------------------------------------------
diff --git a/adocs/documentation/src/main/asciidoc/recreating-an-archetype.adoc b/adocs/documentation/src/main/asciidoc/recreating-an-archetype.adoc
deleted file mode 100644
index 8073dc4..0000000
--- a/adocs/documentation/src/main/asciidoc/recreating-an-archetype.adoc
+++ /dev/null
@@ -1,337 +0,0 @@
-[[recreating-an-archetype]]
-= Recreating an Archetype
-:notice: licensed to the apache software foundation (asf) under one or more contributor license agreements. see the notice file distributed with this work for additional information regarding copyright ownership. the asf licenses this file to you under the apache license, version 2.0 (the "license"); you may not use this file except in compliance with the license. you may obtain a copy of the license at. http://www.apache.org/licenses/license-2.0 . unless required by applicable law or agreed to in writing, software distributed under the license is distributed on an "as is" basis, without warranties or conditions of any kind, either express or implied. see the license for the specific language governing permissions and limitations under the license.
-:_basedir: ./
-:_imagesdir: images/
-:toc: right
-
-
-pass:[<br/><br/>]
-
-Apache 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:
-
-[source,bash]
-----
-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 Apache 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 Apache Isis core:
-
-[source,xml]
-----
-<properties>
- <isis.version>1.8.0</isis.version>
- ...
-</properties>
-----
-
-Alternatively, you could just load up each `pom.xml` and inspect manually:
-
-[source,bash]
-----
-vi `/bin/find . -name pom.xml | grep -v target`
-----
-
-... and search for `SNAPSHOT`.
-
-Next, check for and fix any missing license header notices:
-
-[source,bash]
-----
-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]):
-
-[source,bash]
-----
-mvn clean install
-mvn antrun:run -P self-host
-----
-
-then using mvn jetty plugin:
-
-[source,bash]
-----
-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 Apache Isis jars.
-
-
-
-=== Create the archetype (manual)
-
-[IMPORTANT]
-====
-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`:
-
-[source,bash]
-----
-mvn clean
-----
-
-To view the remaining files/directories that needs removing, use:
-
-[source,bash]
-----
-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:
-
-[source,bash]
-----
-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:
-
-[source,bash]
-----
-/bin/find .
-----
-
-Now we can create the archetype.
-
-[source,bash]
-----
-mvn archetype:create-from-project
-----
-
-and then update the generated files:
-
-[source,bash]
-----
-groovy ../../../scripts/updateGeneratedArchetypeSources.groovy -n $ISISCPN -v $ISISPAR
-----
-
-where:
-
-* `$ISISCPN` is the component name set earlier (`simpleapp`)
-* `$ISISPAR` is the version of Apache 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:
-
-[source,bash]
-----
-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:
-
-[source,bash]
-----
-export ISISTMP=/c/tmp # or as required
-export ISISCPN=simpleapp
-env | grep ISIS | sort
-----
-
-Then recreate:
-
-[source,bash]
-----
-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:
-
-[source,bash]
-----
-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:
-
-[source,bash]
-----
-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:
-
-[source,bash]
-----
-mv target/generated-sources/archetype ../../archetype/$ISISCPN
-git add ../../archetype/$ISISCPN
-----
-
-Next, confirm that the `-SNAPSHOT` version of the archetype is correct:
-
-[source,bash]
-----
-vi ../../archetype/$ISISCPN/pom.xml
-----
-
-If this a new archetype, then add a reference to the archetype to the root `pom.xml`, eg:
-
-[source,xml]
-----
-<modules>
- ...
- <module>example/archetype/newapp</module>
- ...
-</modules>
-----
-
-Finally, commit the changes:
-
-[source,bash]
-----
-git commit -am "ISIS-nnn: updating $ISISCPN archetype"
-----
-
-=== Create the archetype (scripted)
-
-[IMPORTANT]
-====
-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:
-
-[source,bash]
-----
-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:
-
-[source,bash]
-----
-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:
-
-[source,bash]
-----
-env | grep ISIS | sort
-----
-
-Then switch the correct directory and release:
-
-[source]
-----
-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 http://repository.apache.org[repository.apache.org] and close the staging repo.
-
-Then push branch:
-
-[source,bash]
-----
-git push -u origin prepare/$ISISART-$ISISREL
-----
-
-and push tag:
-
-[source]
-----
-git push origin refs/tags/$ISISART-$ISISREL-$ISISRC:refs/tags/$ISISART-$ISISREL-$ISISRC
-git fetch
-----
-
-See the link:release-process.html[release process] for full details.
\ No newline at end of file
http://git-wip-us.apache.org/repos/asf/isis/blob/8ad6101a/adocs/documentation/src/main/asciidoc/release-checklist.adoc
----------------------------------------------------------------------
diff --git a/adocs/documentation/src/main/asciidoc/release-checklist.adoc b/adocs/documentation/src/main/asciidoc/release-checklist.adoc
deleted file mode 100644
index 5747096..0000000
--- a/adocs/documentation/src/main/asciidoc/release-checklist.adoc
+++ /dev/null
@@ -1,87 +0,0 @@
-[[release-checklist]]
-= Release Checklist
-:notice: licensed to the apache software foundation (asf) under one or more contributor license agreements. see the notice file distributed with this work for additional information regarding copyright ownership. the asf licenses this file to you under the apache license, version 2.0 (the "license"); you may not use this file except in compliance with the license. you may obtain a copy of the license at. http://www.apache.org/licenses/license-2.0 . unless required by applicable law or agreed to in writing, software distributed under the license is distributed on an "as is" basis, without warranties or conditions of any kind, either express or implied. see the license for the specific language governing permissions and limitations under the license.
-:_basedir: ./
-:_imagesdir: images/
-:toc: right
-
-
-pass:[<br/><br/>]
-
-This page contains a release checklist to support the link:./release-process.html[full release process] and link:./release-process-one-pager.html[one-pager].
-
-
-
-
-.Prepare
-[cols="1,1,1,1,1,1,1,1,1,1", options="header"]
-|===
-
-
-|Artifact
-|Env?
-|Update parent POM ver.
-|Newer plugin versions
-|Newer deps
-|Formatting
-|License headers (RAT)
-|License check
-|Recreate archetype
-|Commit changes
-
-|isis
-|
-|
-|
-|
-|
-|
-|
-|n/a
-|
-
-|simpleapp-archetype
-|
-|
-|
-|
-|
-|
-|
-|
-|
-
-|===
-
-
-
-.Release
-[cols="1,1,1,1,1,1,1", options="header"]
-|===
-
-|Artifact
-|prepare dryrun
-|prepare
-|confirm
-|perform
-|stage (nexus)
-|git push
-
-|isis
-|
-|
-|
-|
-|
-|
-
-|simpleapp-archetype
-|
-|
-|
-|
-|
-|
-
-|===
-
http://git-wip-us.apache.org/repos/asf/isis/blob/8ad6101a/adocs/documentation/src/main/asciidoc/release-process-one-pager.adoc
----------------------------------------------------------------------
diff --git a/adocs/documentation/src/main/asciidoc/release-process-one-pager.adoc b/adocs/documentation/src/main/asciidoc/release-process-one-pager.adoc
deleted file mode 100644
index 2e78554..0000000
--- a/adocs/documentation/src/main/asciidoc/release-process-one-pager.adoc
+++ /dev/null
@@ -1,240 +0,0 @@
-[[release-process-1-pager]]
-= Release Process (1 pager)
-:notice: licensed to the apache software foundation (asf) under one or more contributor license agreements. see the notice file distributed with this work for additional information regarding copyright ownership. the asf licenses this file to you under the apache license, version 2.0 (the "license"); you may not use this file except in compliance with the license. you may obtain a copy of the license at. http://www.apache.org/licenses/license-2.0 . unless required by applicable law or agreed to in writing, software distributed under the license is distributed on an "as is" basis, without warranties or conditions of any kind, either express or implied. see the license for the specific language governing permissions and limitations under the license.
-:_basedir: ./
-:_imagesdir: images/
-:toc: right
-
-
-pass:[<br/><br/>]
-
-See also the link:release-process.html[full release process] and the link:release-checklist.html[release checklist].
-
-
-
-== Switch to correct directory, parameterize the release
-
-[WARNING]
-====
-Make sure you are in the correct directory (eg `core`, or `example/archetype/zzz`)
-====
-
-
-if you are releasing `core`:
-
-[source]
-----
-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
-----
-
-See link:recreating-an-archetype.html[here] for details on recreating and releasing an archetype.
-
-
-== Get code
-
-Pull down latest, create branch (eg `prepare/isis-1.8.0`):
-
-[source]
-----
-git checkout master
-git pull --ff-only
-git checkout -b $ISISART-$ISISREL
-----
-
-
-== Update parent pom
-
-Check:
-
-* parent is `org.apache:apache` (non-SNAPSHOT version)
-
-
-== Check for SNAPSHOT dependencies
-
-Search for any non-`SNAPSHOT` usages (including tck project, if any):
-
-[source]
-----
-grep SNAPSHOT `/bin/find . -name pom.xml | grep -v target | sort`
-----
-
-or (more thoroughly):
-
-[source]
-----
-vi `/bin/find . -name pom.xml | grep -v target | sort`
-----
-
-== Sanity check
-
-[WARNING]
-====
-Make sure you are in the correct directory (eg `core`, or `example/archetype/zzz`)
-====
-
-
-Clean all local mvn artifacts and rebuild with `-o` flag:
-
-[source]
-----
-cd core
-
-rm -rf ~/.m2/repository/org/apache/isis
-mvn clean install -o
-----
-
-== Check versions
-
-[TIP]
-====
-Actually, you may want to defer this and do after cutting the release (ie beginning of a new dev cycle)
-====
-
-=== Update plugin versions
-
-
-[source]
-----
-mvn versions:display-plugin-updates > /tmp/foo
-grep "\->" /tmp/foo | /bin/sort -u
-----
-
-=== Newer dependencies:
-
-[source]
-----
-mvn versions:display-dependency-updates > /tmp/foo
-grep "\->" /tmp/foo | /bin/sort -u
-----
-
-== Update license information
-
-=== Missing license headers in files:
-
-[source]
-----
-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`
-
-[source]
-----
-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:
-
-[source]
-----
-git commit -am "ISIS-nnnn: updates to pom.xml etc for release"
-----
-
-== Release
-
-[WARNING]
-====
-Make sure you are in the correct directory (eg `core`, or `example/archetype/zzz`)
-====
-
-=== Prepare:
-
-
-first the dry run:
-
-[source]
-----
-mvn release:prepare -P apache-release \
- -DdryRun=true \
- -DreleaseVersion=$ISISREL \
- -DdevelopmentVersion=$ISISDEV \
- -Dtag=$ISISART-$ISISREL-$ISISRC
-----
-
-then "for real":
-
-[source]
-----
-mvn release:prepare -P apache-release -DskipTests=true -Dresume=false \
- -DreleaseVersion=$ISISREL \
- -DdevelopmentVersion=$ISISDEV \
- -Dtag=$ISISART-$ISISREL-$ISISRC
-----
-
-=== Confirm:
-
-[source]
-----
-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:
-
-[source]
-----
-mvn release:perform -P apache-release \
- -DworkingDirectory=$ISISTMP/$ISISART-$ISISREL/checkout
-----
-
-[NOTE]
-====
-The `workingDirectory` property is to avoid 260 char path issue if building on Windows.
-====
-
-
-== Nexus staging
-
-Log onto http://repository.apache.org[repository.apache.org] and close the staging repo.
-
-== Git branches/tags
-
-Push branch:
-
-[source]
-----
-git push -u origin $ISISART-$ISISREL
-----
-
-Then push tag:
-
-[source]
-----
-git push origin refs/tags/$ISISART-$ISISREL-$ISISRC:refs/tags/$ISISART-$ISISREL-$ISISRC
-git fetch
-----
http://git-wip-us.apache.org/repos/asf/isis/blob/8ad6101a/adocs/documentation/src/main/asciidoc/release-process.adoc
----------------------------------------------------------------------
diff --git a/adocs/documentation/src/main/asciidoc/release-process.adoc b/adocs/documentation/src/main/asciidoc/release-process.adoc
deleted file mode 100644
index 72d19a6..0000000
--- a/adocs/documentation/src/main/asciidoc/release-process.adoc
+++ /dev/null
@@ -1,1046 +0,0 @@
-[[formal-release-process]]
-= Formal Release Process
-:notice: licensed to the apache software foundation (asf) under one or more contributor license agreements. see the notice file distributed with this work for additional information regarding copyright ownership. the asf licenses this file to you under the apache license, version 2.0 (the "license"); you may not use this file except in compliance with the license. you may obtain a copy of the license at. http://www.apache.org/licenses/license-2.0 . unless required by applicable law or agreed to in writing, software distributed under the license is distributed on an "as is" basis, without warranties or conditions of any kind, either express or implied. see the license for the specific language governing permissions and limitations under the license.
-:_basedir: ./
-:_imagesdir: images/
-:toc: right
-
-
-pass:[<br/><br/>]
-
-This page details the process for formally releasing Isis modules.
-
-If you've done this before and just want the bare essentials, see this link:release-process-one-pager.html[one-pager]
-(that also parameterizes some of the steps listed here 'long-hand'. There is also an experimental
-link:resources/release.sh[script] for automating the latter part of the process.
-
-See also the link:release-checklist.html[release checklist] for keeping track of where you are while releasing (possibly multiple) components.
-
-
-
-== Intro
-
-Apache Isis consists of two separately releasable modules. Relative to the root of the
-https://git-wip-us.apache.org/repos/asf/isis/repo?p=isis.git;a=tree[source code repo], these are:
-
-* `core`
-* `component/example/archetypes/simpleapp`
-
-Previously there were many other components, but these have either been mothballed or moved into core. The only
-remaining component that is not in core (though has not yet been released) is `component/viewer/scimpi`. There is
-currently no plan to release this component.
-
-
-
-== Process Prerequisites
-
-Before releasing `core`, ensure there is consensus on the link:../support.html[dev mailing list] that this is the right
-time for a release. The discussion should include confirming the version number to be used, and to confirm content.
-
-Once agreed, the formal release can begin. The steps are:
-
-* create a branch locally in which to prepare the release
-* use `mvn release:prepare` to generate the signed artifacts and create a tag in the source code control system
-* use `mvn release:perform` to upload the signed artifacts to the Apache staging repository
-* vote on the staged artifacts (in particular, the signed source release ZIP from which the remaining artifacts are derivable)
-* on a successful vote:
-* promote the staged artifacts
-* distribute the source zip
-* merge in the branch back to into master
-* on a failed vote:
-* drop the staging repository
-* delete the branch and tag
-* fix the problems and go round round the loop again.
-
-Before any of this can happen, there are a number of prerequisites, in terms of (a) the codebase itself,
-(b) the community process, and (c) the committer acting as release manager and performing the release.
-
-
-
-
-=== Set up local environment
-
-==== Public/private key
-
-The most important configuration you require is to set up public/private key pair. This is used by the `maven-release-plugin` to sign the code artifacts. See the page on link:key-generation.html[key generation] for more details.
-
-In order to prepare the release, you'll (need to) have a `~/.gnupg` directory with the relevant files (`gpg.conf`, `pubring.gpg`, `secring.gpg` etc), and have `gpg` on your operating system PATH.
-
-
-[NOTE]
-====
-If on Windows, the equivalent directory is `c:\users\xxx\appdata\roaming\gnupg`. For `gpg`, use either http://cygwin.com[cygwin.com] or http://www.gpg4win.org[gpg4win.org]. Note also that the mSysGit version of `gpg` (as provided by GitHub's bash client) is not compatible with that provided by cygwin; move it to one side and check that `gpg.exe` being used is that from gpg4win.
-
-====
-
-
-
-==== Maven `settings.xml`
-
-During the release process the `maven-deploy-plugin` uploads the generated artifacts to a staging repo on the http://repository.apache.org[Apache repository manager]. This requires your Apache LDAP credentials to be specified in your `~/.m2/settings.xml` file:
-
-[source,xml]
-----
-<settings>
- <servers>
- <server>
- <id>apache.releases.https</id>
- <username>xxxxxxx</username>
- <password>yyyyyyy</password>
- </server>
- ...
- </servers>
- ...
-</settings>
-----
-
-where `xxxxxxx` and `yyyyyyy` are your Apache LDAP username and password. For more information, see these http://www.apache.org/dev/publishing-maven-artifacts.html#dev-env[ASF docs].
-
-
-[NOTE]
-====
-It is also possible to configure to use `.ssh` secure keys, and thereby avoid hardcoding your Apache LDAP password into your `.m2/settings.xml` file. A description of how to do this can be found, for example, http://bval.apache.org/release-setup.html[here].
-====
-
-
-Also, set up keyphrase for `gpg`; this avoids being prompted during release:
-
-[source,xml]
-----
-<profiles>
- <profile>
- <id>gpg</id>
- <properties>
- <gpg.executable>gpg2</gpg.executable>
- <gpg.passphrase>this is not really my passphrase</gpg.passphrase>
- </properties>
- </profile>
- ...
-</profiles>
-
-<activeProfiles>
- <activeProfile>gpg</activeProfile>
- ...
-</activeProfiles>
-----
-
-
-==== Pull down code to release
-
-Set the HEAD of your local git repo to the commit to be released. In many cases this will be the tip of the origin's `master` branch:
-
-[source,bash]
-----
-git checkout master
-git pull --ff-only
-----
-
-Then, determine/confirm the version number of the module being released. This should be in line with our link:versioning-policy.html[semantic versioning policy].
-
-Next, create a release branch in your local Git repo, using the version number determined and as per link:release-branch-and-tag-names.html[these standards]. For example, to prepare release candidate #1 for a release 1.9.0 of `core`, use:
-
-[source,bash]
-----
-git checkout -b isis-1.9.0
-----
-
-All release preparation is done locally; if we are successful, this branch will be pushed back to master.
-
-Finally, make sure you have a JIRA ticket open against which to perform all commits.
-
-
-
-
-== Set Environment Variables
-
-If you are releasing `core`:
-
-[source,bash]
-----
-cd core
-
-export ISISTMP=/c/tmp # or whatever
-export ISISART=isis
-export ISISDEV=1.10.0-SNAPSHOT
-export ISISREL=1.9.0
-export ISISRC=RC1
-
-export ISISCOR="Y"
-env | grep ISIS | sort
-----
-
-== Code Prerequisites
-
-{note
-Unless otherwise stated, you should assume that all remaining steps should be performed in the base directory of the module being released.
-}
-
-Before making any formal release, there are a number of prerequisites that should always be checked.
-
-=== Update the version number
-
-The version number of the parent pom should reflect the branch name that you are now on (with a `-SNAPSHOT` suffix). In many cases this will have been done already during earlier development; but confirm that it has been updated. If it has not, make the change.
-
-For example, if releasing `core` version `1.9.0`, the POM should read:
-
-[source,xml]
-----
-<groupId>org.apache.isis.core</groupId>
-<artifactId>isis</artifactId>
-<version>1.9.0</version>
-----
-
-=== Update parent (Apache Isis Core)
-
-If releasing Apache Isis Core, check (via link:http://search.maven.org/#search%7Cga%7C1%7Cg%3A%22org.apache%22%20a%3A%22apache%22[search.maven.org]) whether there is a newer version of the Apache parent `org.apache:apache`.
-
-
-If there is, update the `<version>` in the `<parent>` element in the parent POM to match the newer version:
-
-[source,xml]
-----
-<parent>
- <groupId>org.apache</groupId>
- <artifactId>apache</artifactId>
- <version>NN</version>
- <relativePath />
-</parent>
-----
-
-where `NN` is the updated version number.
-
-=== Check no SNAPSHOT dependencies
-
-There should be no snapshot dependencies; the only mention of `SNAPSHOT` should be for the Isis modules about to be released.
-
-As a quick check, do a grep for `SNAPSHOT`:
-
-[source,bash]
-----
-grep SNAPSHOT `/bin/find . -name pom.xml | grep -v target | sort`
-----
-
-Or, for a more thorough check, load up each `pom.xml` and inspect manually:
-
-[source,bash]
-----
-vi `/bin/find . -name pom.xml | grep -v target | sort`
-----
-
-... and search for `SNAPSHOT`.
-
-
-[TIP]
-====
-Obviously, don't update Apache Isis' `SNAPSHOT` references; these get updated by the `mvn release:prepare` command we run later.
-====
-
-
-
-=== Update plugin versions
-
-The `maven-versions-plugin` should be used to determine if there are newer versions of any of the plugins used to build Apache Isis. Since this goes off to the internet, it may take a minute or two to run:
-
-[source,bash]
-----
-mvn versions:display-plugin-updates > /tmp/foo
-grep "\->" /tmp/foo | /bin/sort -u
-----
-
-Review the generated output and make updates as you see fit. (However, if updating, please check by searching for known issues with newer versions).
-
-
-
-=== Update dependency versions
-
-The `maven-versions-plugin` should be used to determine if there are newer versions of any of Isis' dependencies. Since this goes off to the internet, it may take a minute or two to run:
-
-[source,bash]
-----
-mvn versions:display-dependency-updates > /tmp/foo
-grep "\->" /tmp/foo | /bin/sort -u
-----
-
-Update any of the dependencies that are out-of-date. That said, do note that some dependencies may show up with a new dependency, when in fact the dependency is for an old, badly named version. Also, there may be new dependencies that you do not wish to move to, eg release candidates or milestones.
-
-For example, here is a report showing both of these cases:
-
-[source,bash]
-----
-[INFO] asm:asm ..................................... 3.3.1 -> 20041228.180559
-[INFO] commons-httpclient:commons-httpclient .......... 3.1 -> 3.1-jbossorg-1
-[INFO] commons-logging:commons-logging ......... 1.1.1 -> 99.0-does-not-exist
-[INFO] dom4j:dom4j ................................. 1.6.1 -> 20040902.021138
-[INFO] org.datanucleus:datanucleus-api-jdo ................ 3.1.2 -> 3.2.0-m1
-[INFO] org.datanucleus:datanucleus-core ................... 3.1.2 -> 3.2.0-m1
-[INFO] org.datanucleus:datanucleus-jodatime ............... 3.1.1 -> 3.2.0-m1
-[INFO] org.datanucleus:datanucleus-rdbms .................. 3.1.2 -> 3.2.0-m1
-[INFO] org.easymock:easymock ................................... 2.5.2 -> 3.1
-[INFO] org.jboss.resteasy:resteasy-jaxrs ............. 2.3.1.GA -> 3.0-beta-1
-----
-
-For these artifacts you will need to search http://search.maven.org[Maven central repo] directly yourself to confirm there are no newer dependencies not shown in this list.
-
-=== Code cleanup / formatting
-
-Make sure that all source code has been cleaned up and formatted according to the Apache Isis and ASF conventions. Use link:resources/Apache-code-style-formatting.xml[this] Eclipse template and link:resources/isis.importorder[this] import order.
-
-=== License header notices (RAT tool)
-
-The Apache Release Audit Tool `RAT` (from the http://creadur.apache.org[Apache Creadur] project) checks for missing license header files. The parent `pom.xml` of each releasable module specifies the RAT Maven plugin, with a number of custom exclusions.
-
-To run the RAT tool, use:
-
-[source,bash]
-----
-mvn org.apache.rat:apache-rat-plugin:check -D rat.numUnapprovedLicenses=50 -o
-----
-
-where `rat.numUnapprovedLicenses` property is set to a high figure, temporarily overriding the default value of 0. This will allow the command to run over all submodules, rather than failing after the first one.
-
-
-[WARNING]
-====
-Do _not_ use `mvn rat:check`; depending on your local Maven configuratoin this may bring down the obsolete `mvn-rat-plugin` from the Codehaus repo.
-====
-
-
-All being well the command should complete. For each failing submodule, it will have written out a `target\rat.txt`; missing license notes are indicated using the key `!???`. You can collate these together using something like:
-
-[source,bash]
-----
-for a in `/bin/find . -name rat.txt -print`; do grep '!???' $a; done
-----
-
-Investigate and fix any reported violations, typically by either:
-
-* adding genuinely missing license headers from Java (or other) source files, or
-* updating the `<excludes>` element for the `apache-rat-plugin` plugin to ignore test files, log files and any other non-source code files
-* also look to remove any stale `<exclude>` entries
-
-To add missing headers, you can if you wish use the groovy script `addmissinglicenses.groovy` (in the `scripts` directory) to automatically insert missing headers for certain file types. The actual files checked are those with extensions specified in the line `def fileEndings = [".java", ".htm"]`:
-
-Run this in dry run mode first (shown here relative to the `core` module):
-
-[source,bash]
-----
-groovy ../scripts/addmissinglicenses.groovy
-----
-
-When happy, perform the updates by specifying the `-x` (execute) flag:
-
-[source,bash]
-----
-groovy addmissinglicenses.groovy -x
-----
-
-Once you've fixed all issues, confirm once more that `apache-rat-plugin` no longer reports any license violations, this time leaving the `rat.numUnapprovedLicenses` property to its default, 0:
-
-[source,bash]
-----
-mvn org.apache.rat:apache-rat-plugin:check -D rat.numUnapprovedLicenses=0 -o
-for a in `find . -name rat.txt -print`; do grep '!???' $a; done
-----
-
-=== Missing License Check
-
-Although Apache Isis has no dependencies on artifacts with incompatible licenses, the POMs for some of these dependencies (in the Maven central repo) do not necessarily contain the required license information. Without appropriate additional configuration, this would result in the generated `DEPENDENCIES` file and generated Maven site indicating dependencies as having "unknown" licenses.
-
-Fortunately, Maven allows the missing information to be provided by configuring the `maven-remote-resources-plugin`. This is stored in the `src/main/appended-resources/supplemental-models.xml` file, relative to the root of each releasable module.
-
-To capture the missing license information, use:
-
-[source,bash]
-----
-mvn license:download-licenses
-----
-
-This Maven plugin creates a `license.xml` file in the `target/generated-resources` directory of each module.
-
-Then, run the following script (shown here relative to the `core` module).
-
-[source,bash]
-----
-groovy ../scripts/checkmissinglicenses.groovy
-----
-
-This searches for all `licenses.xml` files, and compares them against the contents of the `supplemental-models.xml` file. For example, the output could be something like:
-
-[source,bash]
-----
-licenses to add to supplemental-models.xml:
-
-[org.slf4j, slf4j-api, 1.5.7]
-[org.codehaus.groovy, groovy-all, 1.7.2]
-
-licenses to remove from supplemental-models.xml (are spurious):
-
-[org.slf4j, slf4j-api, 1.5.2]
-----
-
-If any missing entries are listed or are spurious, then update `supplemental-models.xml` and try again.
-
-
-[NOTE]
-====
-Ignore any missing license warnings for the TCK modules; this is a result of the TCK modules for the viewers (eg `isis-viewer-bdd-concordion-tck`) depending on the TCK dom, fixtures etc.
-====
-
-
-
-== Sanity check
-
-Before you cut the release, perform one last sanity check on the codebase.
-
-=== Sanity check for `core`
-
-First, check that there are _NO SNAPSHOT_ dependencies in any of the `pom.xml` of the modules of the core.
-
-Next, delete all Isis artifacts from your local Maven repo:
-
-[source,bash]
-----
-rm -rf ~/.m2/repository/org/apache/isis
-----
-
-Next, check that `core` builds independently, using the `-o` offline flag:
-
-[source,bash]
-----
-mvn clean install -o
-----
-
-Confirm that the versions of the Isis artifacts now cached in your local repository are correct.
-
-=== Sanity check for non-`core` components
-
-You should already have changed the parent POM of the releasable module to reference a released version of `org.apache.isis.core:isis`. Now, also check that there are remaining _NO SNAPSHOT_ dependencies in any of the `pom.xml` of the modules of the component.
-
-Next, delete all Isis artifacts from your local Maven repo:
-
-[source,bash]
-----
-rm -rf ~/.m2/repository/org/apache/isis
-----
-
-Next, build the component, though without the offline flag. Maven should pull down the component's dependencies from the Maven central repo, including the non-spshot of Apache Isis core:
-
-[source,bash]
-----
-mvn clean install
-----
-
-Confirm that the versions of the Isis artifacts now cached in your local repository are correct (both those pulled down from Maven central repo, as well as those of the component built locally). The versions of `core` should not be a SNAPSHOT.
-
-
-
-== Commit changes
-
-Before going any further, remember to commit any changes from the preceding steps:
-
-[source,bash]
-----
-git commit -am "ISIS-nnn: updates to pom.xml etc for release"
-----
-
-== Preparing a Release (`mvn release:prepare`)
-
-Most of the work is done using the `mvn release:prepare` goal. Since this makes a lot of changes, we run it first in "dry run" mode; only if that works do we run the goal for real.
-
-=== Dry-run
-
-Run the dry-run as follows:
-
-[source,bash]
-----
-mvn release:prepare -P apache-release -D dryRun=true \
- -DreleaseVersion=$ISISREL \
- -Dtag=$ISISART-$ISISREL \
- -DdevelopmentVersion=$ISISDEV
-----
-
-where:
-
-* `releaseVersion` just strip off the `-SNAPSHOT` suffix:
-* `tag` should follow our link:release-branch-and-tag-names.html[standard] (concatenation of the `artifactId` and the version entered above _without a `-RCn` suffix_)
-* `developmentVersion` should increment as required, and have `-SNAPSHOT` appended.
-
-This is not quite fully automated; you may be prompted for the gpg passphrase. (Experiments in using `--batch-mode -Dgpg.passphrase="..."` to fully automate this didn't work; for more info, see http://maven.apache.org/plugins/maven-gpg-plugin/sign-mojo.html[here] (maven release plugin docs) and http://maven.apache.org/maven-release/maven-release-plugin/examples/non-interactive-release.html[here] (maven gpg plugin docs).
-
-Or, if you want to be prompted for the versions, you can omit the properties, eg:
-
-[source,bash]
-----
-mvn release:prepare -P apache-release -D dryRun=true
-----
-
-Some modules might have additional profiles to be activated. For example, the (now mothballed) SQL ObjectStore required `-P apache-release,integration-tests` so that its integration tests are also run.
-
-This should generate something like:
-
-[source,bash]
-----
-$ mvn release:prepare -P apache-release -D dryRun=true
-[INFO] Scanning for projects...
-[INFO] ------------------------------------------------------------------------
-[INFO] Reactor Build Order:
-[INFO]
-[INFO] Apache Isis Core
-[INFO] Apache Isis Core AppLib
-[INFO] Apache Isis Core Unit Test Support
-[INFO] Apache Isis Core MetaModel
-[INFO] Apache Isis Core Runtime
-[INFO] Apache Isis Core WebServer
- ...
-[INFO] Apache Isis Core Integration Testing Support
-[INFO]
-[INFO] ------------------------------------------------------------------------
-[INFO] Building Apache Isis Core 1.9.0
-[INFO] ------------------------------------------------------------------------
-[INFO]
-[INFO] --- maven-release-plugin:2.3.2:prepare (default-cli) @ isis ---
-[INFO] Resuming release from phase 'map-release-versions'
-What is the release version for "Apache Isis Core"? (org.apache.isis.core:isis)
-1.9.0: :
-----
-
-If you didn't provide the `releaseVersion`, `tag` and `developmentVersion` tags, then you'll be prompted for them. You can generally accept the defaults that Maven offers.
-
-Assuming this completes successfully, re-run the command, but without the `dryRun` flag and specifying `resume=false` (to ignore the generated `release.properties` file that gets generated as a side-effect of using `git`). You can also set the `skipTests` flag since they would have been run during the previous dry run:
-
-[source,bash]
-----
-mvn release:prepare -P apache-release -D resume=false -DskipTests=true
- -DreleaseVersion=$ISISREL \
- -Dtag=$ISISART-$ISISREL \
- -DdevelopmentVersion=$ISISDEV
-----
-
-
-[TIP]
-====
-If any issues here, then explicitly delete the generated `release.properties` file first.
-====
-
-
-
-=== Post-prepare sanity check
-
-You should end up with artifacts in your local repo with the new version `1.9.0`. There are then a couple of sanity checks that you can perform:
-
-* unzip the source-release ZIP and check it builds. +
-+
-For example, if building core, then the ZIP file will be called `isis-1.9.0-source-release.zip` and should reside in `~/.m2/repository/org/apache/isis/core/isis/1.9.0` directory. +
-+
-Unzip in a new directory, and build.
-
-* Inspect the `DEPENDENCIES` file. +
-+
-This file should be in the root of the extracted ZIP. In particular, check that there are no category-x dependencies.
-
-If you find problems and the release was performed on a branch, then just delete the branch and start over.
-
-
-
-
-== Upload Release for Voting
-
-Once the release has been built locally, it should be uploaded for voting. This is done by deploying the Maven artifacts to a staging directory (this includes the source release ZIP file which will be voted upon).
-
-The Apache staging repository runs on Nexus server, hosted at https://repository.apache.org[repository.apache.org]. The process of uploading will create a staging repository that is associated with the host (IP address) performing the release. Once the repository is staged, the newly created staging repository is "closed" in order to make it available to others.
-
-Before you start, make sure you've defined the staging repo in your local `~/.m2/settings.xml` file (see earlier on this page).
-
-
-=== Perform the Release
-
-If running on *nix, then the command to stage the release is:
-
-[source,bash]
-----
-mvn release:perform -P apache-release
-----
-
-but if using mSysGit on windows, specify a different working directory:
-
-[source,bash]
-----
-mvn release:perform -P apache-release \
- -DworkingDirectory=$ISISTMP/$ISISART-$ISISREL/checkout
-----
-
-You may (again) be prompted for gpg passphrase.
-
-The command starts off by checking out the codebase from the tag (hence different working directory under Windows to avoid 260 char path limit). It then builds the artifacts, then uploads them to the Apache staging repository:
-
-[source,bash]
-----
-...
-[INFO] --- maven-release-plugin:2.3.2:perform (default-cli) @ isis ---
-[INFO] Performing a LOCAL checkout from scm:git:file:///C:\APACHE\isis-git-rw\co
-re
-[INFO] Checking out the project to perform the release ...
-[INFO] Executing: cmd.exe /X /C "git clone --branch isis-1.9.0 file:///C:\APACHE\isis-git-rw\core C:\APACHE\isis-git-rw\core\target\checkout"
-[INFO] Working directory: C:\APACHE\isis-git-rw\core\target
-[INFO] Performing a LOCAL checkout from scm:git:file:///C:\APACHE\isis-git-rw
-[INFO] Checking out the project to perform the release ...
-[INFO] Executing: cmd.exe /X /C "git clone --branch isis-1.9.0 file:///C:\APACHE\isis-git-rw C:\APACHE\isis-git-rw\core\target\checkout"
-[INFO] Working directory: C:\APACHE\isis-git-rw\core\target
-[INFO] Executing: cmd.exe /X /C "git ls-remote file:///C:\APACHE\isis-git-rw"
-[INFO] Working directory: C:\Users\ADMINI~1\AppData\Local\Temp
-[INFO] Executing: cmd.exe /X /C "git fetch file:///C:\APACHE\isis-git-rw"
-[INFO] Working directory: C:\APACHE\isis-git-rw\core\target\checkout
-[INFO] Executing: cmd.exe /X /C "git checkout isis-1.9.0"
-[INFO] Working directory: C:\APACHE\isis-git-rw\core\target\checkout
-[INFO] Executing: cmd.exe /X /C "git ls-files"
-[INFO] Working directory: C:\APACHE\isis-git-rw\core\target\checkout
-[INFO] Invoking perform goals in directory C:\APACHE\isis-git-rw\core\target\checkout\core
-[INFO] Executing goals 'deploy'...
-...
-----
-
-All being well this command will complete successfully. Given that it is uploading code artifacts, it could take a while to complete.
-
-=== Check the Repository
-
-If the `mvn release:perform` has worked then it will have put release artifacts into a newly created staging repository .
-
-Log onto http://repository.apache.org[repository.apache.org] (using your ASF LDAP account):
-
-image::{_imagesdir}release-process/nexus-staging-0.png[width="600px",link="{_imagesdir}release-process/nexus-staging-0.png"]
-
-And then check that the release has been staged (select `staging repositories` from left-hand side):
-
-image::{_imagesdir}release-process/nexus-staging-1.png[width="600px",link="{_imagesdir}release-process/nexus-staging-1.png"]
-
-If nothing appears in a staging repo you should stop here and work out why.
-
-Assuming that the repo has been populated, make a note of its repo id; this is needed for the voting thread. In the screenshot above the id is `org.apache.isis-008`.
-
-=== Close the Repository
-
-After checking that the staging repository contains the artifacts that you expect you should close the staging repository. This will make it available so that people can check the release.
-
-Press the Close button and complete the dialog:
-
-image::{_imagesdir}release-process/nexus-staging-2.png[width="600px",link="{_imagesdir}release-process/nexus-staging-2.png"]
-
-Nexus should start the process of closing the repository.
-
-image::{_imagesdir}release-process/nexus-staging-2a.png[width="600px",link="{_imagesdir}release-process/nexus-staging-2a.png"]
-
-All being well, the close should (eventually) complete successfully (keep hitting refresh):
-
-image::{_imagesdir}release-process/nexus-staging-3.png[width="600px",link="{_imagesdir}release-process/nexus-staging-3.png"]
-
-The Nexus repository manager will also email you with confirmation of a successful close.
-
-If Nexus has problems with the key signature, however, then the close will be aborted:
-
-image::{_imagesdir}release-process/nexus-staging-4.png[width="600px",link="{_imagesdir}release-process/nexus-staging-4.png"]
-
-Use `gpg --keyserver hkp://pgp.mit.edu --recv-keys nnnnnnnn` to confirm that the key is available.
-
-
-[NOTE]
-====
-Unfortunately, Nexus does not seem to allow subkeys to be used for signing. See link:key-generation.html[Key Generation] for more details.
-====
-
-
-=== Push changes
-
-Finally, push both the branch and the tag created locally to the central origin server. For the tag, we append an `-RCn` suffix until the vote succeeds.
-
-To push the branch, for example:
-
-[source,bash]
-----
-git checkout prepare/$ISISART-$ISISREL
-git push -u origin prepare/$ISISART-$ISISREL
-----
-
-To push the tag, with the `-RCn` suffix, for example:
-
-[source,bash]
-----
-git push origin refs/tags/$ISISART-$ISISREL:refs/tags/$ISISART-$ISISREL-$ISISRC
-git fetch
-----
-
-The remote tag isn't visible locally (eg via `gitk --all`), but can be seen https://git-wip-us.apache.org/repos/asf/isis/repo?p=isis.git;a=summary[online].
-
-
-
-== Voting
-
-Once the artifacts have been uploaded, you can call a vote.
-
-In all cases, votes last for 72 hours and require a +3 (binding) vote from members.
-
-=== Start voting thread on link:mailto:dev@isis.apache.org[dev@isis.apache.org]
-
-The following boilerplate is for a release of the Apache Isis Core. Adapt as required:
-
-Use the following subject:
-
-[source,bash]
-----
-[VOTE] Apache Isis Core release 1.8.0 RC1
-----
-
-And use the following body:
-
-[source,bash]
-----
-I've cut a release for Apache Isis Core and the simpleapp archetype:
-* Core 1.8.0
-* SimpleApp Archetype 1.8.0
-
-The source code artifacts have been uploaded to staging repositories on repository.apache.org:
-
-* http://repository.apache.org/content/repositories/orgapacheisis-10xx/org/apache/isis/core/isis/1.9.0/isis-1.9.0-source-release.zip
-* http://repository.apache.org/content/repositories/orgapacheisis-10xx/org/apache/isis/archetype/simpleapp-archetype/1.9.0/simpleapp-archetype-1.9.0-source-release.zip
-
-For each zip there is a corresponding signature file (append .asc to the zip's url).
-
-In the source code repo the code has been tagged as isis-1.8.0-RC1 and simpleapp-archetype-1.8.0-RC1.
-
-For instructions on how to verify the release (build from binaries and/or use in Maven directly), see http://isis.apache.org/contributors/verifying-releases.html
-
-Please verify the release and cast your vote. The vote will be open for a minimum of 72 hours.
-
-[ ] +1
-[ ] 0
-[ ] -1
-----
-
-Remember to update:
-
-* the version number (1.9.0 or whatever)
-* the release candidate number (`RC1` or whatever)
-* the repository id, as provided by Nexus earlier (`orgapacheisis-10xx` or whatever)
-
-Note that the email also references the procedure for other committers to link:verifying-releases.html[verify the release].
-
-== After the vote
-
-Once the vote has completed, post the results to the isis-dev mailing list.
-
-For example, use the following subject for a vote on Apache Isis Core:
-
-[source,bash]
-----
-[RESULT] [VOTE] Apache Isis Core release 1.9.0
-----
-
-using the body (alter last line as appropriate):
-
-[source,bash]
-----
-The vote has completed with the following result :
-
- +1 (binding): <i>list of names</i>
- +1 (non binding): <i>list of names</i>
-
- -1 (binding): <i>list of names</i>
- -1 (non binding): <i>list of names</i>
-
-The vote is (UN)SUCCESSFUL.
-----
-
-=== For a successful vote
-
-If the vote has been successful, then replace the `-RCn` tag with another without the qualifier.
-
-You can do this using the `scripts/promoterctag.sh` script; for example:
-
-[source,bash]
-----
-sh scripts/promoterctag isis-1.9.0 RC1 # $ISISART-$SISREL $ISISRC
-----
-
-Or, if you like to execute the steps in that script by hand:
-
-* add the new remote tag, for example: +
-+
-[source,bash]
-----
-git push origin refs/tags/isis-1.9.0:refs/tags/isis-1.9.0
-git fetch
-----
-
-* delete the `-RCn` remote tag, for example: +
-+
-[source,bash]
-----
-git push origin –delete refs/tags/isis-1.9.0-RC1 # $ISISART-$SISREL-$ISISRC
-git fetch
-----
-
-
-* delete the `-RCn` local tag, for example: +
-+
-[source,bash]
-----
-git tag -d isis-1.9.0-RC1 # $ISISART-$SISREL-$ISISRC
-git fetch
-----
-
-
-
-Then, continue onto the next section for the steps to promote and announce the release.
-
-=== For an unsuccessful vote
-
-If the vote has been unsuccessful, then:
-
-* delete the remote branch, for example: +
-+
-[source,bash]
-----
-git push origin –delete isis-1.9.0 # $ISISART-$SISREL
-----
-
-
-
-* delete your local branch, for example: +
-+
-[source,bash]
-----
-git branch -D isis-1.9.0 # $ISISART-$SISREL
-----
-
-
-* delete the remote origin server's tag, for example: +
-+
-[source,bash]
-----
-git push origin –delete refs/tags/isis-1.9.0-RC1
-----
-
-
-* delete the tag that was created locally, for example: +
-+
-[source,bash]
-----
-git tag -d isis-1.9.0 # $ISISART-$SISREL
-----
-
-
-* drop the staging repository in http://repository.apache.org[Nexus]
-
-Address the problems identified in the vote, and go again.
-
-
-
-
-== Promoting Release to Distribution
-
-=== Release Binaries to Maven Central Repo
-
-From the Nexus pages, select the staging repository and select 'release' from the top menu.
-
-
-image::{_imagesdir}release-process/nexus-release-1.png[width="600px",link="{_imagesdir}release-process/nexus-release-1.png"]
-
-This moves the release artifacts into an Apache releases repository; from there they will be automatically moved to the Maven repository.
-
-=== Release Source Zip
-
-As described in the http://www.apache.org/dev/release-publishing.html#distribution_dist[Apache documentation], each Apache TLP has a `release/TLP-name` directory in the distribution Subversion repository at https://dist.apache.org/repos/dist[https://dist.apache.org/repos/dist]. Once a release vote passes, the release manager should `svn add` the artifacts (plus signature and hash files) into this location. The release is then automatically pushed to http://www.apache.org/dist/[http://www.apache.org/dist/] by `svnpubsub`. Only the most recent release of each supported release line should be contained here, old versions should be deleted.
-
-Each project is responsible for the structure of its directory. The directory structure of Apache Isis reflects the directory structure in our git source code repo:
-
-[source]
-----
-isis/
- core/
- component/
- objectstore/ # empty, JDO now part of core
- security/ # empty, Shiro now part of core
- viewer/ # empty, Restful and Wicket viewers now part of core
- example/
- archetype/
- simpleapp/
- tool/
- maven-isis-plugin/ # not yet released
-----
-
-If necessary, checkout this directory structure:
-
-[source,bash]
-----
-svn co https://dist.apache.org/repos/dist/release/isis isis-dist
-----
-
-Next, add the new release into the appropriate directory, and delete any previous release. You can use link:upd_sh[the upd.sh script] to help; this downloads the artefacts from the Nexus release repository, adds the artefacts to subsversion and deletes the previous version.
-
-At the end, commit the changes:
-
-[source]
-----
-svn commit -m "publishing isis source releases to dist.apache.org"
-----
-
-== Update JIRA and generate Release notes
-
-=== Close All JIRA tickets for the release
-
-Close all JIRA tickets for the release, or moved to future releases if not yet addressed. Any tickets that were partially implemented should be closed, and new tickets created for the functionality on the ticket not yet implemented.
-
-=== Generate Release Notes in JIRA
-
-Use JIRA to http://confluence.atlassian.com/display/JIRA/Creating+Release+Notes[generate release notes]:
-
-image::{_imagesdir}release-process/jira-create-release-notes.png[width="400px",link="{_imagesdir}release-process/jira-create-release-notes.png"]
-<img src="resources/jira-create-release-notes.png" width="400px"></img>
-
-If any of the tickets closed are tasks/subtasks, then please edit the contents of the file to associate them back together again.
-
-=== Mark the JIRA versions as released
-
-In JIRA, go to the administration section for the Apache Isis project and update the versions as released.
-
-=== Update ISIS website
-
-Update the Apache Isis CMS website:
-
-* Using the JIRA-generated release notes as a guide, update the relevant page of the Apache Isis site. +
-+
-Use this regex to convert links. From:
-+
-[source,bash]
-----
-<li>\[<a href='(.+)?'>(.+?)<\/a>\].*-[\s]*(.*)$
-----
-+
-to:
-+
-[source,bash]
-----
-* link:$1[$2] - $3
-----
-+
-and use this regex to convert headings. From:
-+
-[source,bash]
-----
-<h2>\s+(\S+)\n</h2>
-----
-+
-to:
-+
-[source,bash]
-----
-=== $1
-----
-
-
-
-Typically this be will a new page in the core section or for one of the components. Make a note of the URL of this new page (for use in the mailing list announcement).
-
-For example, a new release of Apache Isis Core would require:
-
-* Do a search for `x.y.0-SNAPSHOT` and replace with `x.y.0`
-
-* Update the version number on the link:./index.html[home (index)] pages.
-
-* Update the version number on the link:./simpleapp-archetype.html[simpleapp archetype] pages.
-
-
-In addition:
-
-* Update the link:./download.html[download page] with a link to the source release zip file (under https://dist.apache.org/repos/dist/release/isis[https://dist.apache.org/repos/dist/release/isis])
-
-* The link:./doap_isis.rdf[DOAP RDF] file (which provides a machine-parseable description of the project) should also be updated with details of the new release. Validate using the http://www.w3.org/RDF/Validator/[W3C RDF Validator] service.
-
-For more information on DOAP files, see these http://projects.apache.org/doap.html[Apache policy docs].
-
-* The `STATUS` file (in root of Apache Isis' source) should be updated with details of the new release.
-
-
-
-== Announce the release
-
-Announce the release to link:mailto:users@isis.apache.org[users mailing list].
-
-For example, for a release of Apache Isis Core, use the following subject:
-
-[source,bash]
-----
-[ANN] Apache Isis version 1.9.0 Released
-----
-
-And use the following body (summarizing the main points as required):
-
-[source]
-----
-The Apache Isis team is pleased to announce the release of:
-* Apache Isis Core version 1.9.0
-* SimpleApp Archetype 1.9.0
-
-New features in this release include:
-- ...
-
-Full release notes are available on the Apache Isis website at [1].
-
-Note that:
-* ...
-
-You can access this release directly from the Maven central repo [2],
-or download the release and build it from source [3].
-
-Enjoy!
-
---The Apache Isis team
-
-[1] http://isis.apache.org/core/release-notes/isis-1.9.0.html
-[2] http://search.maven.org
-[3] http://isis.apache.org/download.html
-----
-
-=== Blog post
-
-Finally, https://blogs.apache.org/roller-ui/login.rol[log onto] the http://blogs.apache.org/isis/[Apache blog] and create a new post. Copy-n-paste the above mailing list announcement should suffice.
-
-== Prepare for next iteration
-
-=== Merge changes from branch back into `master` branch
-
-Because we release from a branch, the changes made in the branch (changes to `pom.xml` made by the `maven-release-plugin`, or any manual edits) should be merged back from the release branch back into the `master` branch:
-
-[source,bash]
-----
-git checkout master # update master with latest
-git pull
-git merge isis-1.9.0 # merge branch onto master
-git branch -d isis-1.9.0 # branch no longer needed
-git push origin --delete isis-1.9.0 # remote branch no longer needed
-----
-
-If the core was updated, then you'll most likely need to update other POMs to the new `-SNAPSHOT`.
-
-Next, do a sanity check that everything builds ok:
-
-[source,bash]
-----
-rm -rf ~/.m2/repository/org/apache/isis
-mvn clean install
-----
-
-... and run up an Isis application.
-
-=== Update `STATUS` file
-
-The trunk holds a https://git-wip-us.apache.org/repos/asf/isis/repo?p=isis.git;a=blob_plain;f=STATUS;hb=HEAD[STATUS] file which is a brief summary of the current status of the project. Update this file with details of the release.
-
-=== Push changes
-
-Finally, push the changes up to origin:
-
-[source,bash]
-----
-git fetch # check no new commits on origin/master
-git push
-----
\ No newline at end of file
http://git-wip-us.apache.org/repos/asf/isis/blob/8ad6101a/adocs/documentation/src/main/asciidoc/screencasts.adoc
----------------------------------------------------------------------
diff --git a/adocs/documentation/src/main/asciidoc/screencasts.adoc b/adocs/documentation/src/main/asciidoc/screencasts.adoc
index df3207d..3714490 100644
--- a/adocs/documentation/src/main/asciidoc/screencasts.adoc
+++ b/adocs/documentation/src/main/asciidoc/screencasts.adoc
@@ -53,7 +53,7 @@ _How to import an Apache Isis maven-based application into Eclipse and configure
NB: when configuring DataNucleus for the *dom* project, make sure you are in the 'Java perspective', not the 'Java EE perspective'). +
-Learn more link:./guides/dg.html#_dg_eclipse[here]
+Learn more link:./guides/cg.html#_cg_ide_eclipse[here]
|video::RgcYfjQ8yJA[youtube,width="420px",height="315px"]
@@ -63,7 +63,7 @@ Learn more link:./guides/dg.html#_dg_eclipse[here]
_How to import an Apache Isis maven-based application into IntelliJ and run the app._ +
-Learn more link:./guides/dg.html#_dg_intellij[here]
+Learn more link:./guides/cg.html#_cg_ide_intellij[here]
|video::lwKsyTbTSnA[youtube,width="420px",height="315px"]
http://git-wip-us.apache.org/repos/asf/isis/blob/8ad6101a/adocs/documentation/src/main/asciidoc/simpleapp-archetype.adoc
----------------------------------------------------------------------
diff --git a/adocs/documentation/src/main/asciidoc/simpleapp-archetype.adoc b/adocs/documentation/src/main/asciidoc/simpleapp-archetype.adoc
deleted file mode 100644
index 2ee008e..0000000
--- a/adocs/documentation/src/main/asciidoc/simpleapp-archetype.adoc
+++ /dev/null
@@ -1,208 +0,0 @@
-[[simpleapp-archetype]]
-= SimpleApp Archetype
-:notice: licensed to the apache software foundation (asf) under one or more contributor license agreements. see the notice file distributed with this work for additional information regarding copyright ownership. the asf licenses this file to you under the apache license, version 2.0 (the "license"); you may not use this file except in compliance with the license. you may obtain a copy of the license at. http://www.apache.org/licenses/license-2.0 . unless required by applicable law or agreed to in writing, software distributed under the license is distributed on an "as is" basis, without warranties or conditions of any kind, either express or implied. see the license for the specific language governing permissions and limitations under the license.
-:_basedir: ./
-:_imagesdir: images/
-:toc: right
-
-
-
-pass:[<br/><br/>]
-
-The quickest way to get started with Apache Isis is to run the simple archetype. This will generate a very simple one-class domain model, called `SimpleObject`, with a single property `name`. There is also a corresponding `SimpleObjectRepository` domain service. From this you can easily rename these initial classes, and extend to build up your own Apache Isis domain application.
-
-
-
-
-
-== Generating the App
-
-Create a new directory, and `cd` into that directory.
-
-Then run the following command:
-
-[source,bash]
-----
-mvn archetype:generate \
- -D archetypeGroupId=org.apache.isis.archetype \
- -D archetypeArtifactId=simpleapp-archetype \
- -D archetypeVersion=1.8.0 \
- -D groupId=com.mycompany \
- -D artifactId=myapp \
- -D version=1.0-SNAPSHOT \
- -B
-----
-
-where:
-
-- `groupId` represents your own organization, and
-- `artifactId` is a unique identifier for this app within your organization.
-- `version` is the initial (snapshot) version of your app
-
-The archetype generation process will then run; it only takes a few seconds.
-
-
-
-
-=== Snapshot release
-
-We also maintain the archetype for the most current `-SNAPSHOT`; an app generated with this archetype will contain the latest features of Apache Isis, but the usual caveats apply: some features still in development may be unstable.
-
-The process is almost identical to that for stable releases, however the `archetype:generate` goal is called with slightly different arguments:
-
-[source,bash]
-----
-mvn archetype:generate \
- -D archetypeGroupId=org.apache.isis.archetype \
- -D archetypeArtifactId=simpleapp-archetype \
- -D archetypeVersion=1.9.0-SNAPSHOT \
- -D groupId=com.mycompany \
- -D artifactId=myapp \
- -D version=1.0-SNAPSHOT \
- -D archetypeRepository=http://repository-estatio.forge.cloudbees.com/snapshot/ \
- -B
-----
-
-where as before:
-
-- `groupId` represents your own organization, and
-- `artifactId` is a unique identifier for this app within your organization.
-- `version` is the initial (snapshot) version of your app
-
-but also:
-
-- `archetypeVersion` is the SNAPSHOT version of Apache Isis.
-- `archetypeRepository` specifies the location of our snapshot repo (hosted on [CloudBees](http://www.cloudbees.com)), and
-
-The archetype generation process will then run; it only takes a few seconds.
-
-
-
-
-== Building the App
-
-Switch into the root directory of your newly generated app, and build your app:
-
-[source,bash]
-----
-cd myapp
-mvn clean install
-----
-
-where `myapp` is the `artifactId` entered above.
-
-
-
-
-== Running the App
-
-The `simpleapp` archetype generates a single WAR file, configured to run both the link:./guides/ug.html#_ug_wicket-viewer[Wicket viewer] and the link:./guides/ug.html#_ug_restfulobjects-viewer[Restful Objects viewer]. The archetype also configures the JDO/DataNucleus objectstore to use an in-memory HSQLDB connection.
-
-Once you've built the app, you can run the WAR in a variety of ways.
-
-The recommended approach when getting started is to run the self-hosting version of the WAR, allowing Apache Isis to run as a standalone app; for example:
-
-[source,bash]
-----
-java -jar webapp/target/myapp-webapp-1.0-SNAPSHOT-jetty-console.jar
-----
-
-
-
-This can also be accomplished using an embedded Ant target provided in the build script:
-
-
-[source,bash]
-----
-mvn -P self-host antrun:run
-----
-
-
-
-The first is to simply deploying the generated WAR (`webapp/target/myapp-webapp-1.0-SNAPSHOT.war`) to a servlet container.
-
-
-Alternatively, you could run the WAR in a Maven-hosted Jetty instance, though you need to `cd` into the `webapp` module:
-
-[source,bash]
-----
-cd webapp
-mvn jetty:run -D jetty.port=9090
-----
-
-
-In the above, we've passed in a property to indicate a different port from the default port (8080).
-
-Note that if you use `mvn jetty:run`, then the context path changes; check the console output (eg [http://localhost:9090/myapp-webapp](http://localhost:9090/myapp-webapp)).
-
-Finally, you can also run the app by deploying to a standalone servlet container such as [Tomcat](http://tomcat.apache.org).
-
-
-
-
-=== With Fixtures
-
-It is also possible to start the application with a pre-defined set of data; useful for demos or manual exploratory
-testing. This is done by specifying a _fixture script_ on the command line:
-
-
-[source,bash]
-----
-java -jar webapp/target/myapp-webapp-1.0-SNAPSHOT-jetty-console.jar \
- --initParam isis.persistor.datanucleus.install-fixtures=true \
- --initParam isis.fixtures=fixture.simple.SimpleObjectsFixture
-----
-
-
-where (in the above example) `fixture.simple.SimpleObjectsFixture` is the fully qualified class name of the fixture
-script to be run.
-
-
-
-
-== Using the App
-
-The archetype provides a welcome page that explains the classes and files generated, and provides detailed guidance and what to do next.
-
-The app itself is configured to run using shiro security, as configured in the `WEB-INF/shiro.ini` config file. To log in, use `sven/pass`.
-
-
-
-== Modifying the App
-
-Once you are familiar with the generated app, you'll want to start modifying it. Check out our the link:.guides/ug.html[User Guide], which has how-tos and a complete reference guide (as well as some background concepts and discussion of more advanced techniques).
-
-If you use IntelliJ or Eclipse, you'll also want to set up your IDE; this is also described in the link:dg.adoc[Developers' Guide].
-
-
-== App Structure
-
-As noted above, the generated app is a very simple application consisting of a single domain object that can be easily renamed and extended. The intention is not to showcase all of Apache Isis' capabilities; rather it is to allow you to very easily modify the generated application (eg rename `SimpleObject` to `Customer`) without having to waste time deleting lots of generated code.
-
-
-.Table caption
-[cols="1,1a", options="header"]
-|===
-| Module
-| Description
-
-
-|myapp
-|The parent (aggregator) module
-
-|myapp-dom
-|The domain object model, consisting of <tt>SimpleObject</tt> and <tt>SimpleObjects</tt> (repository) domain service.
-
-|myapp-fixture
-|Domain object fixtures used for initializing the system when being demo'ed or for unit testing.
-
-|myapp-integtests
-|End-to-end integration tests, that exercise from the UI through to the database
-
-|myapp-webapp
-|Run as a webapp (from `web.xml`) using either the Wicket viewer or the RestfulObjects viewer
-
-|===
-
-
-If you run into issues, please don't hesitate to ask for help on the link:../../support.html[users mailing list].