THIS IS A TEST INSTANCE. ALL YOUR CHANGES WILL BE LOST!!!!
...
This
...
document
...
describes
...
how
...
to
...
make
...
a
...
release
...
of
...
Sqoop
...
2
...
from
...
git
...
branch
...
"sqoop2".
...
It
...
is
...
a
...
work
...
in
...
progress
...
and
...
should
...
be
...
refined
...
by
...
the
...
...
...
(RM)
...
as
...
they
...
come
...
across
...
aspects
...
of
...
the
...
release
...
process
...
not
...
yet
...
documented
...
here.
...
NOTE:
...
For
...
the
...
purpose
...
of
...
illustration,
...
this
...
document
...
assumes
...
that
...
the
...
version
...
being
...
released
...
is
...
1.99.1,
...
and
...
the
...
following
...
development
...
version
...
will
...
become
...
1.99.2
...
| Table of Contents | ||
|---|---|---|
|
...
Prerequisites
...
Policy documents
Frequently asked questions for making Apache releases are available on Releases FAQ page.
The Release Manager (RM) must go through the policy document to understand all the tasks and responsibilities of running a release.
Give a heads up
The RM should first create an umbrella issue and then setup a timeline for release branch point. The time for the day the umbrella issue is created to the release branch point must be at least two weeks in order to give the community a chance to prioritize and commit any last minute features and issues they would like to see in the upcoming release.
The RM should then send the pointer to the umbrella issue along with the tentative timeline for branch point to the user and developer lists. Any work identified as release related that needs to be completed should be added as a subtask of the umbrella issue to allow users to see the overall release progress in one place.
| No Format |
|---|
---- {toc:maxLevels=3} ---- h1. Prerequisites ---- h2. Policy documents Frequently asked questions for making Apache releases are available on [Releases FAQ|http://www.apache.org/dev/release.html] page. The Release Manager (RM) must go through the policy document to understand all the tasks and responsibilities of running a release. h2. Give a heads up The RM should first create an umbrella issue and then setup a timeline for release branch point. The time for the day the umbrella issue is created to the release branch point must be at least two weeks in order to give the community a chance to prioritize and commit any last minute features and issues they would like to see in the upcoming release. The RM should then send the pointer to the umbrella issue along with the tentative timeline for branch point to the user and developer lists. Any work identified as release related that needs to be completed should be added as a subtask of the umbrella issue to allow users to see the overall release progress in one place. {noformat} To: dev@sqoop.apache.org Subject: Work on $release release has started We are starting the process to prepare for Sqoop $release release. I have opened JIRA $jira to cover the tasks under this release. If you have any JIRA in progress and would like to include it in this release, please follow the process to do so. Feel free to comment on the JIRA if you have any comments/suggestions. Thanks, $RM {noformat} h2. Sanitize JIRA Before a release is done, make sure that any issues that are _fixed_ have their fix version setup correctly. Run the following JIRA query to see which resolved issues do not |
Sanitize JIRA
Before a release is done, make sure that any issues that are fixed have their fix version setup correctly. Run the following JIRA query to see which resolved issues do not have their fix version set up correctly:
| Code Block |
|---|
have their fix version set up correctly: {code} project = sqoop and resolution = fixed and fixVersion is empty {code} |
The
...
result
...
of
...
the
...
above
...
query
...
should
...
be
...
empty.
...
If
...
some
...
issues
...
do
...
show
...
up
...
in
...
this
...
query
...
that
...
have
...
been
...
fixed
...
since
...
the
...
last
...
release,
...
please
...
bulk-edit
...
them
...
to
...
set
...
the
...
fix
...
version
...
to
...
'1.4.3'.
...
You
...
can
...
also
...
run
...
the
...
following
...
query
...
to
...
make
...
sure
...
that
...
the
...
issues
...
fixed
...
for
...
the
...
to-be-released
...
version
...
look
...
accurate:
| Code Block |
|---|
} project = sqoop and resolution = fixed and fixVersion = '1.99.1' {code} h2. Monitor active issues |
Monitor active issues
It is important that between the time that the umbrella issue is filed to the time when the release branch is created, no experimental or potentially destabilizing work is checked into the trunk. While it is acceptable to introduce major changes, they must be thoroughly reviewed and have good test coverage to ensure that the release branch does not start of being unstable.
If necessary the RM can discuss if certain issues should be fixed on the trunk in this time, and if so what is the gating criteria for accepting them.
Creating Release Artifacts
Create a release branch
Creating branches in git is easy, simple, cheap, fast and race condition less with comparison to SVN. There is no need explicitly announce that you're going to create release branch and ask everyone to stop committing.
1. Clone fresh repository copy
| Code Block |
|---|
It is important that between the time that the umbrella issue is filed to the time when the release branch is created, no experimental or potentially destabilizing work is checked into the trunk. While it is acceptable to introduce major changes, they must be thoroughly reviewed and have good test coverage to ensure that the release branch does not start of being unstable. If necessary the RM can discuss if certain issues should be fixed on the trunk in this time, and if so what is the gating criteria for accepting them. h1. Creating Release Artifacts h3. Create a release branch Creating branches in git is easy, simple, cheap, fast and race condition less with comparison to SVN. There is no need explicitly announce that you're going to create release branch and ask everyone to stop committing. 1. Clone fresh repository copy {code} git clone https://git-wip-us.apache.org/repos/asf/sqoop.git cd sqoop {code} |
2. Checkout Sqoop 2 branch
| Code Block |
|---|
Checkout Sqoop 2 branch {code} git checkout sqoop2 {code} |
3.
...
Check
...
that
...
current
...
HEAD
...
points
...
to
...
commit
...
on
...
which
...
you
...
want
...
to
...
base
...
new release branch.
...
Checkout
...
particular
...
commit
...
if
...
not.
| Code Block |
|---|
} git log # Check current branch history. HEAD should point to commit that you want to be base for your release branch git checkout abcdef123 # Check out particular commit that should be base for release branch if -^ {code} |
4.
...
Create
...
new
...
release
...
branch
...
with
...
name
...
"branch-$version"
| Code Block |
|---|
} git branch branch-1.99.1 {code} |
5.
...
Push
...
new
...
branch
...
to
...
Apache
...
repository
| Code Block |
|---|
{code} git push origin branch-1.99.1 {code} |
6.
...
Check
...
that
...
branch
...
was
...
correctly
...
propagated
...
to
...
Apache
...
repository.
...
You
...
should
...
be
...
able
...
to
...
see
...
your
...
branch
...
on
...
following
...
git
...
...
.
7. Update version to your release version in all pom.xml files (.pom.xml,
...
*/pom.xml
...
and
...
*/
...
/pom.xml).
...
You
...
should
...
be
...
changing
...
the
...
version
...
only
...
in
...
<parent>
...
tag
...
(with
...
exception
...
of
...
root
...
pom.xml
...
file
...
that
...
obviously
...
do
...
not
...
have
...
a
...
parent).
...
8.
...
Check
...
your
...
changes
...
by
...
running
...
package
...
build
| Code Block |
|---|
} mvn package {code} |
9.
...
Commit
...
your
...
changes
...
and
...
push
...
them
...
to
...
Apache
...
repository
| Code Block |
|---|
} git commit -a -m "Changing version to 1.99.1" git push origin branch-1.99.1 {code} |
10.
...
Send
...
an
...
...
announcing
...
new
...
branch
To:
...
dev@sqoop.apache.org
...
Subject:
...
New
...
release
...
branch
...
1.99.1
...
I've
...
just
...
created
...
new
...
release
...
branch
...
for
...
upcoming
...
1.99.1
...
release.
...
Please
...
continue
...
committing
...
to
...
main
...
Sqoop
...
2
...
branch
...
"sqoop2"
...
as
...
usual,
...
I'll
...
cherry-pick
...
commits
...
to
...
branch-1.99.1
...
on
...
per
...
needed
...
basis.
...
https://git-wip-us.apache.org/repos/asf?p=sqoop.git;a=shortlog;h=refs/heads/branch-1.99.1
Thanks,
$RM
Update change log file
1. It's important to update changelog file with all changes that went it to the release. JIRA is generating list of all changes in particular release in "Release notes" section:
- On main page click "versions" from left menu
- Click on your version
- There is link "Release notes" on top left corner of the context area.
2. You can use ruby script jira2changelog.rb attached to this page to transform this page into desired output.
| Code Block |
|---|
|https://git-wip-us.apache.org/repos/asf?p=sqoop.git;a=shortlog;h=refs/heads/branch-1.99.1] Thanks, $RM {quote} h3. Update change log file 1. It's important to update changelog file with all changes that went it to the release. JIRA is generating list of all changes in particular release in "Release notes" section: * On main page click "versions" from left menu * Click on your version * There is link "Release notes" on top left corner of the context area. 2. You can use ruby script jira2changelog.rb attached to this page to transform this page into desired output. {code} jira2changelog.rb 'https://issues.apache.org/jira/secure/ReleaseNote.jspa?projectId=12311320&version=12323641' # Change with your version Release notes {code} |
3.
...
Update
...
CHANGELOG.txt
...
file
...
in
...
branches
...
sqoop2
...
and
...
branch-<your-version>.
...
4.
...
It's
...
important
...
to
...
keep
...
this
...
file
...
up-to-date
...
with
...
each
...
committed
...
change
...
after
...
initial
...
branch
...
cut.
...
Create
...
release
...
tarballs
...
1.
...
Check
...
out
...
release
...
branch
| Code Block |
|---|
} git clone https://git-wip-us.apache.org/repos/asf/sqoop.git git checkout branch-1.99.1 {code} |
2.
...
Make
...
sure
...
that
...
LICENSE.txt
...
contains
...
license
...
information
...
for
...
all
...
third-party
...
libraries.
...
In
...
order
...
to
...
do
...
this
...
check
...
properly,
...
you
...
will
...
need
...
to
...
quickly
...
create
...
all
...
packages.
...
You
...
need
...
to
...
check
...
jars
...
available
...
in
...
client/lib,
...
server/lib
...
and
...
insider
...
sqoop
...
server
...
war
...
file
...
(server/webapps/sqoop.war).
| Code Block |
|---|
} mvn package -DskipTest mvn package -DskipTests -Pbinary -Dhadoop.profile=100 mvn package -DskipTests -Pbinary -Dhadoop.profile=200 {code} |
2.
...
Create
...
tag
...
on
...
this
...
commit
...
to
...
identify
...
precise
...
point
...
where
...
the
...
RC
...
was
...
generated
...
and
...
push
...
this
...
tag
...
to
...
main
...
repository
| Code Block |
|---|
} git tag -a release-1.99.1-rc0 -m "Sqoop 1.99.1-rc0 release" git push origin release-1.99.1-rc0 {code} |
3.
...
Create
...
temporary
...
directory
...
where
...
you'll
...
be
...
preparing
...
all
...
required
...
artifacts
| Code Block |
|---|
} mkdir -p /tmp/sqoop-release-preparations {code} |
4.
...
Create source artifact and move it to your temporary directory
| Code Block |
|---|
source artifact and move it to your temporary directory {code} mvn clean verify package mv dist/target/sqoop-1.99.1.tar.gz /tmp/sqoop-release-preparations {code} 5. Create binary artifact for each supported hadoop version and move generated artifacts to your temporary directory {code} for version in 200 100; do mvn clean verify package -Pbinary -Dhadoop.profile=$version; mv dist/target/sqoop-1.99.1-bin-hadoop${version}.tar.gz /tmp/sqoop-release-preparations ; done {code} |
5. Create binary artifact for each supported hadoop version and move generated artifacts to your temporary directory
| Code Block |
|---|
for version in 200 100 200; do mvn clean verify package \-Pbinary \-Dhadoop.profile=$version; mv dist/target/sqoop-1.99.1-bin-hadoop${version}.tar.gz /tmp/sqoop-release-preparations ; done h3. |
Update
...
KEYS
...
file
...
If
...
your
...
PGP
...
key
...
is
...
not
...
yet
...
in
...
the
...
project's
...
KEYS
...
file,
...
you
...
need
...
to
...
first
...
add
...
that
...
in.
...
To
...
do
...
this,
...
checkout
...
the
...
KEYS
...
file
...
and
...
update
...
it
...
using
...
the
...
following
...
commands:
| Code Block |
|---|
} $ svn co https://svn.apache.org/repos/asf/sqoop/dist sqoop-dist ... $ cd sqoop-dist $ (gpg --list-sigs <KEY-ID> && gpg --armor --export <KEY-ID> ) >> KEYS $ svn commit -m "Adding PGP public key to KEYS file" KEYS ... {code} |
Once
...
this
...
file
...
has
...
been
...
updated,
...
you
...
need
...
to
...
publish
...
it
...
in
...
the
...
appropriate
...
dist
...
directory
...
for
...
the
...
project
...
on
...
http://www.apache.org/dist/sqoop/KEYS
...
.
...
To
...
do
...
this,
...
you
...
must
...
copy
...
the
...
file
...
as
...
follows:
| Code Block |
|---|
} $ scp KEYS people.apache.org:/www/www.apache.org/dist/sqoop/KEYS {code} |
This
...
will
...
take
...
some
...
time
...
to
...
propagate
...
in
...
which
...
you
...
can
...
continue
...
with
...
the
...
other
...
steps
...
of
...
the
...
release
...
process.
...
Create
...
signatures
...
and
...
check
...
sums
...
1.
...
Change
...
your
...
working
...
directory to the temporal one
| Code Block |
|---|
to the temporal one {code} cd /tmp/sqoop-release-preparations {code} |
2.
...
Sing
...
each
...
file
...
with
...
your
...
key
| Code Block |
|---|
} for file in *.tar.gz; do gpg --armor --output $file.asc --detach-sig $file; done {code} |
3.
...
You
...
can
...
immediately
...
verify
...
your
...
signature
| Code Block |
|---|
} for file in *.tar.gz; do gpg --verify $file.asc $file; done {code} |
4.
...
Create
...
md5
...
check
...
sum
| Code Block |
|---|
} for file in *.tar.gz; do md5sum $file > $file.md5; done {code} |
5.
...
Create
...
sha1
...
check
...
sum
| Code Block |
|---|
} for file in *.tar.gz; do sha1sum $file > $file.sha1; done {code} |
6.
...
Upload
...
artifacts
...
and
...
all
...
created
...
check
...
sums
...
with
...
signatures to your own web-space
...
on
...
people.apache.org
| Code Block |
|---|
}
ssh people.apache.org "mkdir -p ~/public_html/sqoop-1.99.1"
scp * people.apache.org:~/public_html/sqoop-1.99.1
|
Running the vote
...
Call for sqoop dev list votes
Send an email to dev@ list. For example,
| No Format |
|---|
{code} h1. Running the vote ---- h2. Call for sqoop dev list votes Send an email to dev@ list. For example, {noformat} To: dev@sqoop.apache.org Subject: [VOTE] Release Sqoop version 1.4.3 This is the first incubator release for Apache Sqoop, version 1.4.3 *** Please cast your vote by [3 working days after sending] *** The list of fixed issues: http://svn.apache.org/repos/asf/sqoop/branches/branch-1.4.3/CHANGES.txt The tarball (*.tar.gz), signature (*.asc), checksum (*.md5), and test result (log/*.ant_test.log): http://people.apache.org/~blee/sqoop-1.4.2-rc0/ The tag to be voted upon: http://svn.apache.org/repos/asf/sqoop/tags/release-1.4.3-rc0 The KEYS file: http://www.apache.org/dist/incubator/sqoop/KEYS {noformat} |
Need
...
3
...
+1
...
votes
...
from
...
...
...
.
Rolling out the Release
...
Upload the artifacts
Sqoop is using SVN based release procedure. In order to release you have to checkout release repository located on https://dist.apache.org/repos/dist/release/sqoop
...
and
...
add
...
release
...
artifacts
...
there.
| No Format |
|---|
} svn co https://dist.apache.org/repos/dist/release/sqoop sqoop-release cd sqoop-release mkdir 1.4.3 cp $source_to_your_artifacts 1.4.3 svn add 1.4.2 # Optionally change KEYS file in case that you've added your key for the first time svn commit {noformat} h2. Wait for 24 Hours It may take up to 24 hours for all mirrors to sync up. h2. Announce the release Send an email to announce@apache.org (the from: address must be |
Wait for 24 Hours
It may take up to 24 hours for all mirrors to sync up.
Announce the release
Send an email to announce@apache.org (the from: address must be @apache.org).
...
For
...
example,
| No Format |
|---|
} To: announce@apache.org, user@sqoop.apache.org, dev@sqoop.apache.org Subject: [ANNOUNCE] Apache Sqoop 1.4.3 released The Apache Sqoop team is pleased to announce the release of Sqoop 1.4.3. This is the second release of Apache Sqoop as a TLP project. Sqoop is a tool designed for efficiently transferring bulk data between Apache Hadoop and structured datastores, such as relational databases. The release is available here: http://www.apache.org/dyn/closer.cgi/sqoop/ The full change log is available here: https://issues.apache.org/jira/secure/ReleaseNote.jspa?projectId=12311320&version=12317345 Your help and feedback is more than welcome. For more information on how to report problems and to get involved, visit the project website at http://sqoop.apache.org/. The Apache Sqoop Team {noformat} h2. Publish binary artifacts in Maven Repository {note:title=These instructions will change when Sqoop moves to maven builds} Currently Sqoop is built using ant and thus the process necessary for publishing its binary artifacts in Maven repository is manual. Once Sqoop migrates to using Maven build (_which is the default in Sqoop 2_), these steps will need to be updated accordingly. {note} Sqoop already has a Nexus repository setup, thanks to [INFRA-4310|https://issues.apache.org/jira/browse/INFRA-4310]. The following steps outline how you can publish Sqoop binaries to this repository. h3. Setup Maven settings Follow the details provided in [Maven Password Encryption Guide|http://maven.apache.org/guides/mini/guide-encryption.html] to set up a master password for your system. Once the master password has been created, update your maven settings file |
Publish binary artifacts in Maven Repository
| Note | ||
|---|---|---|
| ||
Currently Sqoop is built using ant and thus the process necessary for publishing its binary artifacts in Maven repository is manual. Once Sqoop migrates to using Maven build (which is the default in Sqoop 2), these steps will need to be updated accordingly. |
Sqoop already has a Nexus repository setup, thanks to INFRA-4310. The following steps outline how you can publish Sqoop binaries to this repository.
Setup Maven settings
Follow the details provided in Maven Password Encryption Guide to set up a master password for your system.
Once the master password has been created, update your maven settings file (~/.m2/settings.xml)
...
to
...
have
...
the
...
following
...
server
...
entries:
| Code Block |
|---|
} <settings> ... <servers> <server> <id>apache.snapshots.https</id> <username>your-asf-user-name</username> <password>your-encrypted-asf-password</password> </server> <server> <id>apache.releases.https</id> <username>your-asf-user-name</username> <password>your-encrypted-asf-password</password> </server> <server> <id>apache.staging.https</id> <username>your-asf-user-name</username> <password>your-encrypted-asf-password</password> </server> </servers> ... </settings> {code} h3. Prepare artifacts to publish In a newly created directory, checkout the sources from the appropriate release tag location. For example, for the release |
Prepare artifacts to publish
In a newly created directory, checkout the sources from the appropriate release tag location. For example, for the release 1.4.0-incubating
...
the
...
sources
...
will
...
need
...
to
...
be
...
checked
...
out
...
from
...
https://svn.apache.org/repos/asf/incubator/sqoop/tags/release-1.4.0-rc1/
...
.
...
Once
...
you
...
have
...
the
...
sources,
...
build
...
them
...
to
...
generate
...
the
...
binaries.
...
For
...
example:
| Code Block |
|---|
}
$ svn co https://svn.apache.org/repos/asf/incubator/sqoop/tags/release-1.4.0-rc1/
...
$ cd release-1.4.0-rc1
$ ant jar-all
...
BUILD SUCCESSFUL
Total time: 11 seconds
$
|
Install to local maven cache
Before you do this step, remove any previously installed Sqoop artifacts from your local maven cache. You can do this by running the following command:
| Code Block |
|---|
{code} h3. Install to local maven cache Before you do this step, remove any previously installed Sqoop artifacts from your local maven cache. You can do this by running the following command: {code} $ rm -rf ~/.m2/repository/com/cloudera/sqoop ~/.m2/repository/org/apache/sqoop {code} |
Now
...
run
...
the
...
following
...
command
...
to
...
install
...
the
...
newly
...
checked-out
...
and
...
built
...
artifacts
...
of
...
Sqoop
...
from
...
the
...
previous
...
step
...
to
...
your
...
local
...
maven
...
cache.
| Code Block |
|---|
} $ ant mvn-install ... BUILD SUCCESSFUL Total time: 6 seconds $ {code} |
This
...
will
...
result
...
in
...
copying
...
of
...
the
...
built
...
artifacts
...
and
...
generated
...
POM
...
file
...
into
...
your
...
local
...
maven
...
cache.
...
Deploy
...
main
...
artifact
...
to
...
staging
...
repo
...
Once
...
the
...
artifacts
...
are
...
in
...
your
...
local
...
cache,
...
you
...
can
...
now
...
deploy
...
them
...
to
...
Nexus
...
staging
...
repository.
...
Start
...
out
...
by
...
going
...
into
...
the
...
directory
...
where
...
the
...
main
...
artifact
...
is
...
generated.
...
Once
...
there,
...
make
...
sure
...
that
...
the
...
generated
...
POM
...
file
...
looks
...
accurate
...
and
...
if
...
not,
...
fix
...
it
...
manually.
...
Then
...
run
...
the
...
following
...
commands
...
to
...
deploy
...
the
...
main
...
artifact.
| Code Block |
|---|
} $ cd ~/.m2/repository/org/apache/sqoop/sqoop/1.4.0-incubating $ ls -l total 1108 -rw-r--r-- 1 arvind staff 532981 Jan 11 16:32 sqoop-1.4.0-incubating-sources.jar -rw-r--r-- 1 arvind staff 590086 Jan 11 16:32 sqoop-1.4.0-incubating.jar -rw-r--r-- 1 arvind staff 1670 Jan 11 16:32 sqoop-1.4.0-incubating.pom $ mvn gpg:sign-and-deploy-file -Dfile=./sqoop-1.4.0-incubating.jar -DrepositoryId=apache.staging.https -Durl=https://repository.apache.org/service/local/staging/deploy/maven2/ -DpomFile=./sqoop-1.4.0-incubating.pom -Dgpg.keyname=<your-gpg-keyname> ... [INFO] Metadata[project org.apache.sqoop:sqoop].filename = sqoop-1.4.0-incubating.pom [INFO] ------------------------------------------------------------------------ [INFO] BUILD SUCCESS [INFO] ------------------------------------------------------------------------ [INFO] Total time: 9.169s [INFO] Finished at: Wed Jan 11 16:58:35 PST 2012 [INFO] Final Memory: 6M/81M [INFO] ------------------------------------------------------------------------ {code} |
This
...
will
...
result
...
in
...
the
...
signing
...
and
...
deployment
...
of
...
the
...
main
...
artifact
...
sqoop-1.4.0-incubating.jar
...
in
...
this
...
case,
...
to
...
the
...
staging
...
repository.
...
If
...
all
...
goes
...
well
...
you
...
should
...
be
...
able
...
to
...
point
...
your
...
browser
...
to
...
...
...
...
and
...
clicking
...
on
...
the
...
Staging
...
Repository
...
link
...
on
...
the
...
left
...
navigation
...
column.
...
When
...
you
...
select
...
the
...
staging
...
repository
...
in
...
the
...
right
...
pane,
...
the
...
pane
...
will
...
split
...
into
...
a
...
content
...
pane
...
below
...
that
...
shows
...
how
...
the
...
content
...
of
...
the
...
staging
...
repository
...
created
...
by
...
the
...
above
...
command.
...
The
...
following
...
screenshot
...
illustrates
...
what
...
this
...
looks like.
Deploy test artifact to staging repo
To deploy the test artifact to the staging repo, you must copy the generated test artifact to the same directory as that of the main directory so that you can use the main artifact POM and specify a classifier. Here are the commands to do that:
| Code Block |
|---|
like. !staging-repo-main-artifact.png! h3. Deploy test artifact to staging repo To deploy the test artifact to the staging repo, you must copy the generated test artifact to the same directory as that of the main directory so that you can use the main artifact POM and specify a classifier. Here are the commands to do that: {code} $ ls -l total 1116 -rw-r--r-- 1 arvind staff 532981 Jan 11 16:32 sqoop-1.4.0-incubating-sources.jar -rw-r--r-- 1 arvind staff 590086 Jan 11 16:32 sqoop-1.4.0-incubating.jar -rw-r--r-- 1 arvind staff 833 Jan 11 16:58 sqoop-1.4.0-incubating.jar.asc -rw-r--r-- 1 arvind staff 1668 Jan 11 16:58 sqoop-1.4.0-incubating.pom -rw-r--r-- 1 arvind staff 833 Jan 11 16:58 sqoop-1.4.0-incubating.pom.asc $ cp ../../sqoop-test/1.4.0-incubating/sqoop-test-1.4.0-incubating.jar . $ ls -l total 1392 -rw-r--r-- 1 arvind staff 532981 Jan 11 16:32 sqoop-1.4.0-incubating-sources.jar -rw-r--r-- 1 arvind staff 590086 Jan 11 16:32 sqoop-1.4.0-incubating.jar -rw-r--r-- 1 arvind staff 833 Jan 11 16:58 sqoop-1.4.0-incubating.jar.asc -rw-r--r-- 1 arvind staff 1668 Jan 11 16:58 sqoop-1.4.0-incubating.pom -rw-r--r-- 1 arvind staff 833 Jan 11 16:58 sqoop-1.4.0-incubating.pom.asc -rw-r--r-- 1 arvind staff 278892 Jan 11 17:06 sqoop-test-1.4.0-incubating.jar $ mvn gpg:sign-and-deploy-file -Dfile=./sqoop-test-1.4.0-incubating.jar -DrepositoryId=apache.staging.https -Durl=https://repository.apache.org/service/local/staging/deploy/maven2/ -DpomFile=./sqoop-1.4.0-incubating.pom -Dgpg.keyname=<your-gpg-keyname> -Dclassifier=tests ... [INFO] Metadata[project org.apache.sqoop:sqoop].filename = sqoop-1.4.0-incubating.pom [INFO] ------------------------------------------------------------------------ [INFO] BUILD SUCCESS [INFO] ------------------------------------------------------------------------ [INFO] Total time: 11.160s [INFO] Finished at: Wed Jan 11 17:10:01 PST 2012 [INFO] Final Memory: 6M/81M [INFO] ------------------------------------------------------------------------ $ {code} |
If
...
this
...
command
...
succeeds,
...
you
...
can
...
now
...
see
...
the
...
test
...
artifacts
...
deployed
...
in
...
the
...
staging
...
repository
...
as
...
well.
...
Go
...
the
...
the
...
browser
...
and
...
click
...
on
...
the
...
refresh
...
button
...
on
...
the
...
content
...
area
...
to
...
reload
...
the
...
contents
...
of
...
the
...
staging
...
repository.
...
The
...
following
...
screen
...
shot
...
is
...
an
...
example
...
of
...
how
...
the
...
staging
...
repository
...
may
...
look
...
like
...
after
...
these steps.
Close and Release staging repository
In the Nexus main content pane, make sure the staging repository you are working with is selected with a check mark, and click the "Close" button on top. This causes Nexus to verify the signatures and if everything is valid, it will result in successful closing of the repository. If there are any failures due to invalid signatures, you will have to drop the repository and redo the steps outlined in this section again.
Once the repository is closed, you can promote it to release status by clicking on the "Release" button on top. This allows the artifacts in this staging repository to be published to release repository immediately. Once the release has propagated, you should receive a confirmation email from Nexus stating that the artifacts are now available in the release repository.
Updating the website and the wiki with the new Sqoop bits:
https://cwiki.apache.org/confluence/display/SQOOP/How+to+Update+Project+Website
...