mina-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Ashish <paliwalash...@gmail.com>
Subject Re: Re : [CONF] Apache MINA: Developer Guide (page edited)
Date Sat, 17 Jan 2009 12:11:14 GMT
Agreed!

Since I don't have much exposure to this. Shall try in my local SVN
setup and update the page accordingly.


On Sat, Jan 17, 2009 at 5:33 PM, Edouard De Oliveira
<doe_wanted@yahoo.fr> wrote:
> Maybe inserting directly the needed content in the page would prevent this problem in
the future as this is rather an important section of the developper doc
>
>  Cordialement, Regards,
> -Edouard De Oliveira-
> http://tedorg.free.fr/en/main.php
>
>
>
>
> ________________________________
> De : "confluence@apache.org" <confluence@apache.org>
> À : commits@mina.apache.org
> Envoyé le : Samedi, 17 Janvier 2009, 11h05mn 00s
> Objet : [CONF] Apache MINA: Developer Guide (page edited)
>
>
> Page Edited : MINA : Developer Guide
> Developer Guide has been edited by Ashish Paliwal (Jan 17, 2009).
> Change summary:
> Updated link to Trustin's blog for SVN Keyword property
> (View changes) Content:
>
> Please read the Developer Infrastructure Information if you haven't yet before you proceed.
> Table of Contents
>     * Table of Contents
>     * Building MINA
>     * Coding Convention
>     * SVN tags in header
>     * Working with Multiple Branches in One Eclipse Workspace
>     * Deploying Snapshots (Commiters Only)
>     * Releasing a Point Release (Committers Only)
>     * Step 1: Tagging and Deploying
>     * Step 2: PGP Signing the Repository Content
>     * Step 3: Building Tarballs and Bzballs
>     * Step 4: PGP Signing the Distributions and Uploading
>     * Step 5: Deploy Web Reports (JavaDoc and JXR)
>     * Step 6: Wait 24 hours
>     * Step 7: Update the Links in Web Site
>     * Step 8: Update related metadata file(s)
>     * Step 9: Wait another 24 hours
>     * Step 10: Announce the New Release
>     * Creating a New Release Branch
> Building MINA
> You need Subversion to check out the source code from our source code repository, and
Maven 2 to build the source code. The following example shows how to build the current stable
branch (1.0).
> $ svn co https://svn.apache.org/repos/asf/mina/branches/1.0/ mina
> $ cd mina
> $ mvn -Dwith-LGPL-dependencies clean install     # Build packages (JARs) for the core
API and other extensions and install them to the local Maven repository.
> $ mvn -Dwith-LGPL-dependencies site              # Generate reports (JavaDoc and JXR)
> $ mvn -Dwith-LGPL-dependencies assembly:assembly # Generate a tarball
> $ mvn -Dwith-LGPL-dependencies eclipse:eclipse   # Generate Eclipse project files if
you want
> 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
> There are also other branches that might interest you:
>     * 1.1: Java 5 port of the current stable branch - http://svn.apache.org/repos/asf/mina/branches/1.1/
>     * trunk: Where big changes take place everyday - http://svn.apache.org/repos/asf/mina/trunk/
> If you want to check out the source code of previous releases, you could try:
>     * http://svn.apache.org/repos/asf/mina/tags/
> Coding Convention
> We follow Sun's standard Java coding convention except that we always use spaces instead
of tabs. Please download the Eclipse Java formatter settings file before you make any changes
to the code.
> SVN tags in header
> For having nice headers with revisions tags like :
> /**
> * @version $Rev: 529576 $, $Date: 2007-04-17 14:25:07 +0200 (mar., 17 avr. 2007) $
> */
> You need to set SVN properties on the files. Everything is explained there :
> http://gleamynode.net/articles/1551/setting-svnkeyword-property-automatically
> Working with Multiple Branches in One Eclipse Workspace
> Just running mvn -Dwith-LGPL-dependencies eclipse:eclipse won't allow you to import MINA
projects from more than one branches into one Eclipse workspace. You have to rename all project
names in the generated .project and .classpath files to do that. Maven Eclipse plugin should
provide an option that appends the version number to the project name, but this issue is not
being resolved yet. Until this issue is resolved, please put the attached shell script files
(mvnroot and mvn-eclipse) to your local path (e.g. /usr/local/bin) and run mvn-eclipse.
> $ svn co https://svn.apache.org/repos/asf/mina/all/ mina
> $ cd mina/branches/1.0
> $ mvn-eclipse
> $ cd ../1.1
> $ mvn-eclipse
> $ cd ../../trunk
> $ mvn-eclipse
> Then mvn eclipse:eclipse command is executed internally, and the branch name will be
appended to all sub-module project files generated by Maven Eclipse plugin.
> 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.
> $ svn co https://svn.apache.org/repos/asf/mina/branches/1.0 mina
> $ cd mina
> $ mvn -Dwith-LGPL-dependencies clean deploy site site:deploy    # Make sure to run 'clean'
goal first to prevent side effects from your IDE.
> 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)
> 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/java/maven/bin/mvn)
> $ type java
> java is /opt/java/jdk1.6.0_01/bin/java
> 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 :
> <settings>
>   <servers>
>     <!--  secured repo -->
>     <server>
>       <id>apache.snapshots</id>
>       <username>apacheusername</username>
>     </server>
>     <server>
>       <id>apache.websites</id>
>       <username>apacheusername</username>
>     </server>
>     <server>
>       <id>apache.releases</id>
>       <username>apacheusername</username>
>     </server>
>   </servers>
> </settings>
> Run the following commands :
> $ svn co https://svn.apache.org/repos/asf/mina/branches/1.0 mina
> $ cd mina
> $ mvn -Dwith-LGPL-dependencies -DdryRun=true release:prepare    # Dry-run first.
> Answer to maven question, most of time default value are ok, except for :
> "What is SCM release tag or label for "Apache MINA Root Build POM"? (org.apache.mina:build)
build-1.0.X:"
> the answer is "1.0.X", not the default one with the "build-" prefix proposed by mvn
> Be Careful
>
> Make sure the change made by the release plugin is correct! (pom.xml, tags created)
> Then you can do in real with the following commands :
> $ mvn -Dwith-LGPL-dependencies release:clean      # Clean up the temporary files created
by the dry-run.
> $ mvn -Dwith-LGPL-dependencies release:prepare    # Copy to tags directory.
> $ mvn -Dwith-LGPL-dependencies release:clean      # Clean up the temporary files.
>
> $ cd <TMP_DIR>
> $ svn co [https://svn.apache.org/repos/asf/mina/tags/1.0.x] mina
> $ cd mina
> $ mvn -Dwith-LGPL-dependencies deploy
> $ cd ..
> $ rm \-fr mina
> Step 2: PGP Signing the Repository Content
> Deployed artifacts are located at scp://people.apache.org/www/people.apache.org/repo/m2-ibiblio-sync-repository/org/apache/mina/.
Please download the deployed artifacts and related maven-metadata.xml files, PGP-sign it,
and upload the signatures (*.asc files).
> Tip
> Use gpg-sign-all script to save your time. The gpg-sign-all script signs all files under
current directory recursively. Please don't forget to replace YOU@apache.org with your PGP
key name before running.
> # Download the updated files.
> $ ssh people.apache.org
> [minotaur] $ cd /www/people.apache.org/repo/m2-ibiblio-rsync-repository/org/apache/
> [minotaur] $ tar cnvf ~/mina-changes.tar mina
> [minotaur] $ find mina -mtime 1 -exec tar rnvf ~/mina-changes.tar "{}" ";"
> [minotaur] $ rm -f bsdtar.core
> [minotaur] $ exit
> $ scp people.apache.org:mina-changes.tar mina-changes.tar
>
> # Sign the updated files.
> $ tar xvf mina-changes.tar
> $ cp -R mina mina-signed
> $ cd mina-signed
> $ find . -name "*.asc" -exec rm "{}" ";"    # Just in case you deployed more than once
today
> $ gpg-sign-all
>
> # Create the patch for the signature.
> $ cd ..
> $ diff -urN mina mina-signed > mina-changes.diff
>
> # Upload the signature files.
> $ scp mina-changes.diff people.apache.org:mina-changes.diff
> $ ssh people.apache.org
> [minotaur] $ cd /www/people.apache.org/repo/m2-ibiblio-rsync-repository/org/apache/mina
> [minotaur] $ patch -p1 < ~/mina-changes.diff
> [minotaur] $ find . -name "*.orig" -exec rm "{}" ";"
> [minotaur] $ exit
>
> # Remove the temporary files.
> $ rm -fr mina mina-signed mina-changes.*
> $ ssh people.apache.org "rm -f mina-changes.*"
> Step 3: Building Tarballs and Bzballs
> $ svn co https://svn.apache.org/repos/asf/mina/tags/<version> mina
> $ cd mina
> $ mvn -Dwith-LGPL-dependencies clean package site assembly:assembly
> Generated distributions are located at mina/target directory.
> Step 4: PGP Signing the Distributions and Uploading
> The distributions you generated at the Step 3 must be PGP-signed before uploaded. Please
PGP Sign them, and upload them to scp://people.apache.org/www/www.apache.org/dist/mina/<version>/.
gpg-sign-all script, which was mentioned at the Step 2, can be used here, too.
> $ cd target
> $ tar ztvf mina-1.0.x.tar.gz | grep -q docs/
>
> # Make sure reports are generated and included. (Must print '0')
> $ echo $?
> 0
>
> # Remove the temporary files.
> $ rm -fr archive-tmp site
>
> # Sign and upload the files.
> $ gpg-sign-all
> $ ssh people.apache.org mkdir /www/www.apache.org/dist/mina/1.0.x
> $ scp mina-* people.apache.org:/www/www.apache.org/dist/mina/1.0.x
> Step 5: Deploy Web Reports (JavaDoc and JXR)
> $ svn co https://svn.apache.org/repos/asf/mina/tags/<version> mina
> $ cd mina
> $ mvn -Dwith-LGPL-dependencies clean compile site site:deploy
> Step 6: 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 7: Update the Links in Web Site
> Update the links to new distributions in Downloads page.
> Step 8: Update related metadata file(s)
> Update any related metadata file(s).
> Step 9: Wait another 24 hours
> We need to wait until any changes made in the web site and metadata file(s) go live.
> Step 10: Announce the New Release
> An announcement message can be sent to announce@apache.org, announce@apachenews.org,
users@mina.apache.org and 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 CWiki space, and run Confluence auto-export plugin manually.
> Creating a New Release Branch
> When you create a new branch, you have to make sure the sections that specifies branch
version numbers are configured appropriately in the root pom.xml.
> ...
> <version>1.1.0-SNAPSHOT</version>
> ...
> <scm>
>   <connection>scm:svn:http://svn.apache.org/repos/asf/mina/branches/1.1</connection>
>   <url>http://svn.apache.org/viewvc/directory/mina/branches/1.1</url>
>   <developerConnection>scm:svn:https://svn.apache.org/repos/asf/mina/branches/1.1</developerConnection>
> </scm>
> ...
> <distributionManagement>
>   <site>
>     <id>apache.websites</id>
>     <url>scp://people.apache.org/www/mina.apache.org/report/1.1/</url>
>   </site>
> </distributionManagement>
> ...
> Please note that the example above is for branches/1.1. For example, you have to replace
branches/1.1 with branches/3.0 if the version number of the new branch is 3.0. In case of
trunk, it's just trunk rather than branches/<version>.
> Powered by Atlassian Confluence (Version: 2.2.9 Build:#527 Sep 07, 2006) - Bug/feature
request
>
> Unsubscribe or edit your notifications preferences
>
>
>
>



-- 
thanks
ashish

Blog: http://www.ashishpaliwal.com/blog

My Photo Galleries: http://www.pbase.com/ashishpaliwal

Mime
View raw message