directory-commits mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From elecha...@apache.org
Subject svn commit: r1671079 - in /directory/site/trunk/content/fortress: coding-standards.mdtext developer-guide.mdtext
Date Fri, 03 Apr 2015 14:49:40 GMT
Author: elecharny
Date: Fri Apr  3 14:49:40 2015
New Revision: 1671079

URL: http://svn.apache.org/r1671079
Log:
Added the pages for the developer guide and codeing standards

Added:
    directory/site/trunk/content/fortress/coding-standards.mdtext
    directory/site/trunk/content/fortress/developer-guide.mdtext

Added: directory/site/trunk/content/fortress/coding-standards.mdtext
URL: http://svn.apache.org/viewvc/directory/site/trunk/content/fortress/coding-standards.mdtext?rev=1671079&view=auto
==============================================================================
--- directory/site/trunk/content/fortress/coding-standards.mdtext (added)
+++ directory/site/trunk/content/fortress/coding-standards.mdtext Fri Apr  3 14:49:40 2015
@@ -0,0 +1,167 @@
+Title: Coding Standards
+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.
+
+# Coding Standards
+
+Welcome to you, developper ! You have been elected committer on the project, or you want
to contribute some code or some patch? This is great news. However, in order to be able to
share your 'vision' and your code, some rules must be followed.
+
+Hey, remember that those rules are not the best nor the worst, they are pretty much what
they are for historical reasons, or for technical reasons, however, please, accept them as
they are, and avoid religious war (please, oh please, no mail to say "WTF ? You are using
spaces instead of tab ??? How stupid is this rule etc etc.) Rules are **alway*s* stupid, but
smart people follow them ;)
+
+**eclipse IDE**
+
+Eclipse users can import those two files to enfore the code formating : [formatting.xml](http://svn.apache.org/repos/asf/directory/project/trunk/resources/formatting.xml)
and [codetemplates.xml](http://svn.apache.org/repos/asf/directory/project/trunk/resources/codetemplates.xml)
+
+**IDEA IDE**
+
+IDEA users can import [this file](settings.jar) to enfore the code formating.
+
+
+## Headers
+
+First, you **must** (and this rule accept no exception) use this header in top of all source
file, or each file in which you can have comments :
+
+
+	:::java
+	/*
+	 *  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.
+	 *
+	 */
+
+### Class/Interface headers
+
+Each **Class** or *Interface* should have an header which must contains :
+
+* A descrption of this class/interface
+* an *author* tag which should be :
+
+		:::java
+		@author <a href="mailto:dev@directory.apache.org">Apache Directory Project</a>
+
+<DIV class="note" markdown="1">
+Thanks to avoid to put your name. The code is not yours, and much more important, but putting
ypur name and e-mail, you will intimidate other developper ("Oh, no, I won't mess with this
code, it has been developped by XXXX \!") and second, you will receive mail in three years
even if you have stopped all commitment on the project (and those who have sent you an e-mail
will think that the project's memeber are not responsive...)
+</DIV>
+
+If you use **html** tags, remember to escape '<' and '>' characters...
+
+### Static members and other members
+
+Just add a single line javadoc comment like : _/** blah ... */_ before each member
+
+### Methods
+
+Follow the standard **javadoc** rules : Description, **@param**, **@exception** and **@return**.
It should be enough. Avoid **@tags**, **@todo** tags, etc...
+
+Escape **html** characters
+
+## Comments
+
+No special rules, except that you should avoid :
+
+* Useless comments like : i++; /\* Increment i \*/
+* Overusing comments : if you have to heavily comment a peice of code, then this piece of
code might be too complex ...
+* Speading little comments all over a method : if possible, write blocs of comments. The
method header could hgenerally contains a full description of the code, and if it's not the
case, just consider your method might be too long !
+* Dead code commented. If it's dead, then put it in a cuffin. We use SVN, the Ressuscitator
!
+
+Basically, use your common sense :-)
+
+## Naming
+
+Naming ! Sounds like Blaming :-). Ok. We use **Sun(tm/c/r)** style :
+
+* Constants are in UPPER CASE with accepted '_'
+* Class starts with an uppercase and each starting word is upper cased. No '_', please !
+* Methods starts with lower case and then follow the same rule than classes. No '_', please
!
+* Interfaces should not start with an 'I'
+* Classes which implements an Interface must be followed by the postfix 'impl'
+* Variables follow the method naming convention. No '_', please !
+* Use meaningfull names.
+* No double letter variables like ii, jj etc...
+
+If you browse the code, you will see that many classes does not respect those rules. That's
life ! Don't fix it if you don't touch a class. If you are fixing a method in a class, then
you can change the code to respect the rules. Little by little, we may reach a stable state
where all the code respect the rules ;)
+
+Naming is really important for **APIs**. Be smart. If you are not sure, ask.
+
+## Spaces vs tabs
+
+<DIV class="warning" markdown="1">
+**FOUR SPACES, NO TAB. Final.**
+</DIV>
+
+No discussion. Using tabs break diffs. Modify your **IDE** to insert spaces when you use
tabs, before it saves the file.
+
+## Formatting
+
+Use the **formatting.xml** file which can be found in the **resources** directory in the
root of the project. This is for *Eclipse*. If you don't use eclipse, then translate the formating
to your favorite **IDE**.
+
+Use the **codetemplates.xml** file if you are using *Eclipse* too. You will find it at the
same location. It brings you some standard headers for new classes, nex methods, etc.
+
+Use **UTF-8** as a default for your files (except for properties, thanks to **java**, which
should be in **ISO-8859-1**). Forget about exotic encoding...
+
+<DIV class="warning" markdown="1">
+**DO NOT USE AN AUTOMATIC FORMATER FOR COMMENTS!!!**
+</DIV>
+
+People spend a lot of time making their comment looks like pretty, so if you just format
them, you will have to recover the previous comments...
+
+Some general rules :
+
+* Always use '{' and '}' even for a single instruction, or if you have an empty block (don't
use ';' for empty blocks)
+* No more than one instruction on a single line, the only exception is the '?' ':' operation
+* Use *this* to address the class variable if there is a risk of confusion (for instanc eif
you have a parameter with the same name.
+* Don't add a 'a_', or 'the_' before a parameter's name to distinguish it from the class
variable which has the same name. Use **this** instead.
+* Don't add **final** everywhere. Even if **final** is a substitute for **const**, it's semantic
is not clear enough that you use it everywhere.
+* Add spaces in method calls after '(' and before ')'
+* '{' and '}' must be on the same column
+
+This is a code example :
+
+	:::java    
+	...
+    int result = myMethod( param1, param2 )
+    
+    if ( result > 0 )
+    {
+        // do something
+    }
+    ...
+
+
+## Imports
+
+Always declare all the classes you import, do not use **x.y.\***
+
+## What else ?
+
+Well, this was a very short introduction about coding rules. Use commen sense, look at what
you see around you when adding some code, ask people about format, if you have a question.
+
+That's it ! (I wait your comments, guys :-)
\ No newline at end of file

Added: directory/site/trunk/content/fortress/developer-guide.mdtext
URL: http://svn.apache.org/viewvc/directory/site/trunk/content/fortress/developer-guide.mdtext?rev=1671079&view=auto
==============================================================================
--- directory/site/trunk/content/fortress/developer-guide.mdtext (added)
+++ directory/site/trunk/content/fortress/developer-guide.mdtext Fri Apr  3 14:49:40 2015
@@ -0,0 +1,568 @@
+Title: Developer Guide
+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.
+
+# Building FORTRESS
+
+<DIV class="note" markdown="1">
+	Please read <a href="http://www.apache.org/dev/" class="external-link" rel="nofollow">the
Developer Infrastructure Information</a> if you haven't yet before you proceed.
+</DIV>
+
+[TOC]
+
+# Checking out the code
+
+You need Git to check out the source code from our source code repository, and [Maven(http://maven.apache.org/)
3.0 to build the source code.  The following example shows how to get the Fortress projects.
+
+## Fortress-core
+
+    $ git clone http://git-wip-us.apache.org/repos/asf/directory-fortress-core.git fortress-core
+    $ cd fortress-core
+    $ mvn clean install             # Build packages (JARs) for the Fortress core API and
other 
+                                    # extensions and install them to the local Maven repository.
+    $ mvn site                      # Generate reports (JavaDoc and various other reports)
+    $ mvn package                   # Generate a tarball
+
+Eclipse users:
+Don't forget to declare a classpath variable named M2_REPO, pointing to `~/.m2/repository`,
otherwise many links to existing jars will be broken.
+You can declare new variables in Eclipse in Windows -> Preferences... and selecting Java
-> Build Path -> Classpath Variables
+
+If you want to check out the source code of previous releases, you have to select the branch
you want to work on :
+
+  $ git clone http://git-wip-us.apache.org/repos/asf/directory-fortress-core.git fortress-core
+  $ git checkout <tag>
+
+
+## Fortress-realm
+
+    $ git clone http://git-wip-us.apache.org/repos/asf/directory-fortress-realm.git fortress-realm
+    $ cd fortress-realm
+    $ mvn clean install             # Build packages (JARs) for the Fortress realm API and
other 
+                                    # extensions and install them to the local Maven repository.
+    $ mvn site                      # Generate reports (JavaDoc and various other reports)
+    $ mvn package                   # Generate a tarball
+
+Eclipse users:
+Don't forget to declare a classpath variable named M2_REPO, pointing to `~/.m2/repository`,
otherwise many links to existing jars will be broken.
+You can declare new variables in Eclipse in Windows -> Preferences... and selecting Java
-> Build Path -> Classpath Variables
+
+If you want to check out the source code of previous releases, you have to select the branch
you want to work on :
+
+  $ git clone http://git-wip-us.apache.org/repos/asf/directory-fortress-realm.git fortress-realm
+  $ git checkout <tag>
+
+
+## Fortress-enmasse
+
+    $ git clone http://git-wip-us.apache.org/repos/asf/directory-fortress-enmasse.git fortress-enmasse
+    $ cd fortress-enmasse
+    $ mvn clean install             # Build packages (JARs) for the Fortress enmasse API
and other 
+                                    # extensions and install them to the local Maven repository.
+    $ mvn site                      # Generate reports (JavaDoc and various other reports)
+    $ mvn package                   # Generate a tarball
+
+Eclipse users:
+Don't forget to declare a classpath variable named M2_REPO, pointing to `~/.m2/repository`,
otherwise many links to existing jars will be broken.
+You can declare new variables in Eclipse in Windows -> Preferences... and selecting Java
-> Build Path -> Classpath Variables
+
+If you want to check out the source code of previous releases, you have to select the branch
you want to work on :
+
+  $ git clone http://git-wip-us.apache.org/repos/asf/directory-fortress-enmasse.git fortress-enmasse
+  $ git checkout <tag>
+
+
+## Fortress-commander
+
+    $ git clone http://git-wip-us.apache.org/repos/asf/directory-fortress-commander.git fortress-commander
+    $ cd fortress-commander
+    $ mvn clean install             # Build packages (JARs) for the Fortress commander API
and other 
+                                    # extensions and install them to the local Maven repository.
+    $ mvn site                      # Generate reports (JavaDoc and various other reports)
+    $ mvn package                   # Generate a tarball
+
+Eclipse users:
+Don't forget to declare a classpath variable named M2_REPO, pointing to `~/.m2/repository`,
otherwise many links to existing jars will be broken.
+You can declare new variables in Eclipse in Windows -> Preferences... and selecting Java
-> Build Path -> Classpath Variables
+
+If you want to check out the source code of previous releases, you have to select the branch
you want to work on :
+
+  $ git clone http://git-wip-us.apache.org/repos/asf/directory-fortress-commander.git fortress-commander
+  $ git checkout <tag>
+
+# Coding Convention
+
+The applicable coding standards for Fortress are described in [Coding Standards](coding-standards.html)
+
+# Deploying Snapshots (Commiters Only)
+
+Before running Maven to deploy artifacts, *please make sure if your umask is configured correctly*.
 Unless configured properly, other committers will experience annoying 'permission denied'
errors.  If your default shell is `bash`, please update your umask setting in the `~/.bashrc`
file (create one if it doesn't exist.) by adding the following line:
+
+    umask 002
+
+Please note that you have to edit the correct `shrc` file.  If you use `csh`, then you will
have to edit `~/.cshrc` file.
+
+Now you are ready to deploy the artifacts if you configured your umask correctly.
+
+    $ git clone http://git-wip-us.apache.org/repos/asf/directory-fortress-core.git fortress-core
+    $ cd fortress-core
+    $ mvn clean deploy site site:deploy    # Make sure to run 'clean' goal first to prevent
side effects from your IDE.
+
+(do the same thing for the *enmasse, realm and commander* projects)
+
+Please double-check the mode (i.e. `0664` or `-rw-rw-r--`, a.k.a permission code) of the
deployed artifacts, otherwise you can waste other people's time significantly.
+
+# Releasing a Point Release (Committers Only)
+
+## Preparing the release for the vote
+
+Before starting be sure to have the java and mvn command in your PATH.
+On linux you can check with the following commands :
+
+    $ type mvn
+    mvn is hashed (/opt/apache-maven-3.2.5/bin/mvn)
+    $ type java
+    java is /usr/bin/java
+
+### Step 0: Building Fortress-xxx
+
+<DIV class="note" markdown="1">
+Here, 'xxx' is one of the four fortress mdules : core, enmasse, realm or comander
+</DIV>
+
+### Step 1: Tagging and Deploying
+
+First you need to configure maven for using the good username for scp and operation.
+
+In the `~/.m2/settings.xml` you need the following lines :
+
+	:::xml
+    <settings xmlns="http://maven.apache.org/POM/4.0.0"
+      xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
+      xsi:schemaLocation="http://maven.apache.org/POM/4.0.0
+                          http://maven.apache.org/xsd/settings-1.0.0.xsd">
+    
+      <!-- SERVER SETTINGS -->
+      <servers>
+        <!-- To publish a snapshot of some part of Maven -->
+        <server>
+          <id>apache.snapshots.https</id>
+          <username>elecharny</username>
+          <password>-----Your password here-----</password>
+        </server>
+        <!-- To publish a website of some part of Maven -->
+        <server>
+          <id>apache.websites</id>
+          <username>elecharny</username>
+          <filePermissions>664</filePermissions>
+          <directoryPermissions>775</directoryPermissions>
+        </server>
+        <!-- To stage a release of some part of Maven -->
+        <server>
+          <id>apache.releases.https</id>
+          <username>elecharny</username>
+          <password>-----Your password here-----</password>
+        </server>
+        <!-- To stage a website of some part of Maven -->
+        <server>
+          <id>stagingSite</id> <!-- must match hard-coded repository identifier
in site:stage-deploy -->
+          <username>elecharny</username>
+          <filePermissions>664</filePermissions>
+          <directoryPermissions>775</directoryPermissions>
+        </server>
+      </servers>
+    
+      <!-- PROFILE SETTINGS -->
+      <profiles>
+        <profile>
+          <id>apache-release</id>
+          <properties>
+            <!-- Configuration for artifacts signature -->
+            <gpg.passphrase>-----Your passphrase here-----</gpg.passphrase>
+          </properties>
+        </profile>
+      </profiles>
+    
+    </settings>
+
+### step 2 : Processing with a dry run
+
+After having checked out the trunk, and built it (see step 0), 
+
+    $ git clone http://git-wip-us.apache.org/repos/asf/directory-fortress-core.git directory-fortress-core
+    $ cd directory-fortress-core
+    $ mvn clean install
+
+run the following commands :
+
+    $ mvn -Papache-release -DdryRun=true release:prepare    # Dry-run first.
+
+Answer to maven questions :
+
+    "What is the release version for "Apache Fortress Core"? (org.apache.directory.project:fortress-core)
1.0-RC40: :" 
+    <either use the default version as suggested, or type in the version you@qot;d like
to be used>
+    [..]
+
+Then some other questions will be asked, about the next version to use. The default values
should be fine :
+
+    What is SCM release tag or label for "Apache Fortress Core"? (org.apache.directory.project:fortress-core)
1.0-RC40: : 
+    <Same here : keep 1.0-RC40, or change it if needed>
+    What is the new development version for "Apache Fortress Core"? (org.apache.directory.project:fortress-core)
1.0-RC41-SNAPSHOT: : 
+    <Same here...>
+
+<DIV class="info" markdown="1">
+**Be Careful**
+	
+Make sure the change made by the release plugin is correct! (pom.xml, tags created)
+</DIV>
+	
+### Step 3 : Processing with the real release
+When the dry run is successful, then you can do in real with the following commands:
+
+    $ mvn -Papache-release release:clean      # Clean up the temporary files created by the
dry-run.
+    $ mvn -Papache-release release:prepare    # Copy to tags directory.
+
+The first step will clean up the local sources, the second step will release for real. The
same questions will be asked as those we had during the dry run step.
+
+At some point, it will ask for your passphrase (the one you used when you created your PGP
key). Type it in.
+
+
+Three mails will be generated, and sent to commits@directory.apache.org :
+
+    git commit: [maven-release-plugin] prepare release 2.0.9
+    Git Push Summary
+    git commit: [maven-release-plugin] prepare for next development iteration
+
+  Repository: directory-fortress-core
+  Updated Branches:
+    refs/heads/master 7f1f90d2b -> bb9137136
+
+
+  [maven-release-plugin] prepare release 1.0-RC40
+
+
+  Project: http://git-wip-us.apache.org/repos/asf/directory-fortress-core/repo
+  Commit: http://git-wip-us.apache.org/repos/asf/directory-fortress-core/commit/bb913713
+  Tree: http://git-wip-us.apache.org/repos/asf/directory-fortress-core/tree/bb913713
+  Diff: http://git-wip-us.apache.org/repos/asf/directory-fortress-core/diff/bb913713
+
+  Branch: refs/heads/master
+  Commit: bb9137136d58f334415825b15f58c3173c923de2
+  Parents: 7f1f90d
+  Author: Emmanuel Lecharny <elecharny@symas.com>
+  Authored: Fri Apr 3 15:35:20 2015 +0200
+  Committer: Emmanuel Lecharny <elecharny@symas.com>
+  Committed: Fri Apr 3 15:35:20 2015 +0200
+  ...
+
+The first mail tells you that the SNAPSHOT has been moved to the release version in trunk,
the second mails tells you that this version has been tagged, and the last mail tells you
that trunk has moved to the next version.
+
+
+### Step 4 : perform the release
+
+The last step before launching a vote is to push the potential release to Nexus so that every
user can test the created packages. Perform the following actions
+
+    $ mvn -Papache-release release:perform
+    ...
+    [INFO] [INFO] ------------------------------------------------------------------------
+    [INFO] [INFO] BUILD SUCCESS
+    [INFO] [INFO] ------------------------------------------------------------------------
+    [INFO] [INFO] Total time: 01:00 min
+    [INFO] [INFO] Finished at: 2015-04-03T15:41:26+02:00
+    [INFO] [INFO] Final Memory: 50M/247M
+    [INFO] [INFO] ------------------------------------------------------------------------
+    [INFO] Cleaning up after release...
+    [INFO] ------------------------------------------------------------------------
+    [INFO] BUILD SUCCESS
+    [INFO] ------------------------------------------------------------------------
+    [INFO] Total time: 01:16 min
+    [INFO] Finished at: 2015-04-03T15:41:26+02:00
+    [INFO] Final Memory: 17M/247M
+    [INFO] ------------------------------------------------------------------------
+
+Done !
+
+### Step 5 : closing the staging release on nexus
+
+Now, you have to close the staged project on nexus. In order to do that you *must* have exported
your PGP key to a PGP public server [see](http://www.apache.org/dev/openpgp.html)
+
+Connect to the [Nexus server](https://repository.apache.org), login, and select the MINA
staging repository you just created, then click on the 'close' button. You are home...
+
+### Step 6 : Build the Site
+
+    $ cd target/checkout
+    $ mvn site
+
+This creates the site.
+
+### Step 7 : Sign the packages 
+
+Now, you have to sign the binary packages which are in target/checkout/target.
+
+<DIV class="note" markdown="1">
+Use your PGP key ID (the pub key, 4096R/[XXXXXXX] where [XXXXXXX] is the key ID)
+</DIV>
+
+You can get the keys by typing :
+
+    gpg --list-keys
+
+You'll get something like :
+
+  $ gpg --list-keys
+  /Users/elecharny/.gnupg/pubring.gpg
+  -----------------------------------
+  pub   2048D/xxxxxxxx 2009-12-03
+  uid                  Emmanuel Lecharny <elecharny@nextury.com>
+  sub   2048g/yyyyyyyy 2009-12-03
+
+  pub   4096R/zzzzzzzz 2010-09-13
+  uid                  Emmanuel Lecharny (CODE SIGNING KEY) <elecharny@apache.org>
+  sub   4096R/tttttttt 2010-09-13
+  ...
+
+Take the <zzzzzzzz> part of your 4096 bit key.
+
+Use a shell script to sign the packages which are stored in target/checkout/target. You will
first have to delete the created .asc files :
+
+  $ cd target/checkout/target
+  $ rm *.asc
+  $ ~/sign.sh 
+  PGP Key ID: 
+  <your PGP key>
+  PGP Key Password: 
+  <Your PGP passphrase>
+
+  -n Signing: ./fortress-core-1.0-RC40-javadoc.jar ... 
+    - Generated './fortress-core-1.0-RC40-javadoc.jar.md5'
+    - Generated './fortress-core-1.0-RC40-javadoc.jar.sha1'
+    - Generated './fortress-core-1.0-RC40-javadoc.jar.asc'
+  -n Signing: ./fortress-core-1.0-RC40-source-release.zip ... 
+    - Generated './fortress-core-1.0-RC40-source-release.zip.md5'
+    - Generated './fortress-core-1.0-RC40-source-release.zip.sha1'
+    - Generated './fortress-core-1.0-RC40-source-release.zip.asc'
+  -n Signing: ./fortress-core-1.0-RC40-sources.jar ... 
+    - Generated './fortress-core-1.0-RC40-sources.jar.md5'
+    - Generated './fortress-core-1.0-RC40-sources.jar.sha1'
+    - Generated './fortress-core-1.0-RC40-sources.jar.asc'
+  -n Signing: ./fortress-core-1.0-RC40.jar ... 
+    - Generated './fortress-core-1.0-RC40.jar.md5'
+    - Generated './fortress-core-1.0-RC40.jar.sha1'
+    - Generated './fortress-core-1.0-RC40.jar.asc'
+  ...
+
+
+Here is the sign.sh script you can use :
+
+    #!/bin/sh
+
+    echo "PGP Key ID: "
+    read DEFAULT_KEY
+
+    echo "PGP Key Password: "
+    stty -echo
+    read PASSWORD
+    stty echo
+    echo ""
+
+    for FILE in $(find . -maxdepth 1 -not '(' -name "sign.sh" -or -name ".*" -or -name "*.md5"
-or -name "*.sha1" -or -name "*.asc" ')' -and -type f) ; do
+        if [ -f "$FILE.asc" ]; then
+            echo "Skipping: $FILE"
+            continue
+        fi
+
+        echo -n "Signing: $FILE ... "
+
+        # MD5
+        if [ ! -f "$FILE.md5" ];
+        then
+            openssl md5 < "$FILE" | cut "-d " -f2 > "$FILE.md5"
+            echo "  - Generated '$FILE.md5'"
+        else
+            echo "  - Skipped '$FILE.md5' (file already existing)"
+        fi
+
+        # SHA1
+        if [ ! -f "$FILE.sha1" ];
+        then
+            gpg -v --default-key "$DEFAULT_KEY" --print-md SHA1 "$FILE" > "$FILE".sha1
+            echo "  - Generated '$FILE.sha1'"
+        else
+            echo "  - Skipped '$FILE.sha1' (file already existing)"
+        fi
+
+        # ASC
+        if [ ! -f "$FILE.asc" ];
+        then
+            echo "$PASSWORD" | gpg --default-key "$DEFAULT_KEY" --detach-sign --armor --no-tty
--yes --passphrase-fd 0 "$FILE"
+            echo "  - Generated '$FILE.asc'"
+        else
+            echo "  - Skipped '$FILE.asc' (file already existing)"
+        fi
+    done
+
+### Step 8 : Publish Source and Binary Distribution Packages
+
+First of all, create a new directory on people.apache.org/public_html to store the pacckages
:
+
+    $ ssh people.apache.org
+    $ mkdir public_html/fortress-core-<version>
+    $ exit
+
+Then copy the packages :
+
+    $ cd target/checkout/target
+    $ scp fortress-core-<version>-source-release.zip* people.apache.org:public_html/fortress-core-<version>/
+
+Update your index.html file on people.apach.org/public_html to make the packages visible.
Here is an example of possible content :
+
+  <h2>Last Fortress core 1.0.0-RC40 arballs</h2>
+    <h3>Sources</h3>
+
+      <img src="/icons/compressed.gif" alt="[   ]"><a href="fortress-core-1.0-RC40/fortress-core-1.0-RC40-source-release.zip">fortress-core-1.0-RC40-source-release.zip</a><br/>
+      <img src="/icons/compressed.gif" alt="[   ]"><a href="fortress-core-1.0-RC40/fortress-core-1.0-RC40-source-release.zip.asc">fortress-core-1.0-RC40-source-release.zip.asc</a><br/>
+      <img src="/icons/compressed.gif" alt="[   ]"><a href="fortress-core-1.0-RC40/fortress-core-1.0-RC40-source-release.zip.md5">fortress-core-1.0-RC40-source-release.zip.md5</a><br/>
+      <img src="/icons/compressed.gif" alt="[   ]"><a href="fortress-core-1.0-RC40/fortress-core-1.0-RC40-source-release.zip.sha1">fortress-core-1.0-RC40-source-release.zip.sha1</a><br/>
+
+## Step 9 : Voting a release
+
+Once the tarballs have been created, and the binaries available in Nexus, a vote can be launched.
Simply send a mail on the dev@directory.apache.org mailing list describing the new release.
+
+Here is how you  send a [VOTE] mail on the dev mailing list :
+
+
+    Hi,
+    
+    <blah blah blah>
+    
+    Here is the list of fixed issues :
+     
+    
+       * [FC-83 <https://issues.apache.org/jira/browse/FC-83>] Cleanup core test processing
+       * ...
+    
+    
+    Here's the Jira link for this version if you'd like to review issues in more details:
+    
+    https://issues.apache.org/jira/secure/ReleaseNote.jspa?projectId=10670&styleName=Html&version=12313702
+    
+    A temporary tag has been created (it can be removed if the vote is not approved)
+    
+    The newly approved Nexus has been used for the preparation of this release and all final
artifacts are stored 
+    in a staging repository:
+    https://repository.apache.org/content/repositories/orgapachedirectory-1028
+    
+    
+    The distributions are available for download on :
+    https://repository.apache.org/content/repositories/orgapachedirectory-1028/org/apache/directory/project/fortress-core/1.0-RC40/
+    
+    Let us vote :
+    [ ] +1 | Release Fortress-core 1.0-RC40
+    [ ] +/- | Abstain
+    [ ] -1 | Do *NOT* Fortress-core 1.0-RC40
+	
+    Thanks !
+
+The vote will be open for 72 hours. Once the delay is over, collect the votes, and count
the binding +1/-1. If the vote is positive, then we can release.
+
+### Step 11 : Close the vote
+
+You can officially close the vote now. There are some more steps to fulfill :
+
+* Release the project on https://repository.apache.org
+* Copy the tarballs and heir signature in people.apache.org /www/www.apache.org/dist/fortress
+
+This can be done on people.apache.org :
+
+    $ ssh people.apache.org
+    # svn co https://dist.apache.org/repos/dist/release/directory/fortress/ fortress-dist
+    # cd fortress-dist
+    # mkdir <version>
+    # cp ../public_html/fortress-core-<version>/* <version>
+    # svn add <version>
+    # svn ci <version>
+    ...
+    # exit
+    $
+
+### Step 12: Deploy Web Reports (JavaDoc and JXR)
+
+The javadoc and xref files have been generated in step 6, it's now time to push them into
the production site. They are generated in the following directory :
+
+    target/checkout/target/site
+
+We will copy two directories :
+
+    apidocs
+    xref
+
+Staging or Production?
+
+
+<DIV class="info" markdown="1">
+Those files will be stored on the production server only !!! And some extra caution ust be
taken not to delete them when we will publish the staging site too...
+</DIV>
+
+First of all, you must checkout the two CMS store for the site : staging and production.
+
+    $ svn co https://svn.apache.org/repos/infra/websites/staging/mina/trunk staging
+    ...
+    $ svn co https://svn.apache.org/repos/infra/websites/production/mina production
+    ...
+
+Then copy the generated docs :
+
+    $ cp -r ~/mina/target/checkout/target/site/apidocs production/content/mina/mina-project/
+    $ cp -r ~/mina/target/checkout/target/site/xref production/content/mina/mina-project/
+    $ 
+
+You have to check in those directories :
+
+    $ svn add apidocs
+    $ svn add xref
+    $ svn ci apidocs xref -m "Injected MINA <version> javadocs"
+
+Now, you have to update the staging site <em>extpaths.txt</em>
+
+This file list the file on the production site that will not be overriden by the publication
of the staging site. It has to be updated
+
+    $ cd ~/apacheds/staging/content/
+    $ vi extpaths.txt
+
+The following lines should be present. If not, add them and commit the file :
+
+    mina-project/apidocs
+    mina-project/testapidocs
+    mina-project/xref
+    mina-project/xref-test
+    ...
+
+### Step 13: Wait 24 hours
+
+We have to wait at least 24 hours for all mirrors to retrieve the uploaded files before making
any announcement.  I'd recommend you to wait for 48 hours because some mirrors might lag due
to various issues.
+
+### Step 14: Update the Links in Web Site
+
+Update the links to new distributions in [Downloads] page.
+
+### Step 15: Wait another 24 hours
+
+We need to wait until any changes made in the web site and metadata file(s) go live.
+
+### Step 16: Announce the New Release
+
+An announcement message can be sent to [mailto:announce@apache.org], [mailto:announce@apachenews.org],
[mailto:users@mina.apache.org] and [mailto:dev@mina.apache.org].  Please note that announcement
messages are rejected unless your from-address ends with `@apache.org`.  Plus, you shouldn't
forget to post a news to the MINA site main page.
+



Mime
View raw message