CVS Quick Reference

CVS Options
Use the following syntax to issue CVS Commands:
$ cvs [cvs-option] command [cmd-options] [args]

Replace cvs-options with one  or more of the following:
1. -a : Authenticate the data stream
2. --allow-root=directory : Set the repository root directory (used in server modes)
3. -d repository-path : Specify the repository path for the current command
4. -e editor : Use the specified editor in commit or import commands.
5. -f : Do not use the ~/.cvsrc file
6. -H or --help : Display help for CVS
7. --help-commands : Display a list of CVS Commands.
8. --help-options : Display a list of CVS Options.
9. --help-synonyms : Display a list of synonyms for CVS commands.
10. --H command or --help command : Display the options and help for the specified command.
11. -l : Do not log the current command to the history file.
12. -n : do not write to the repository or sandbox.
13. -q : Run in quiet mode.
14. -Q : Run in very quiet mode.
15. -r : Set files checked out to the sandbox read-only.
16. -s : variable=value : Set a user variable for use with one of the scripting files in CVSROOT
17. -t: Display messages that trance the execution of the command.
18. -v or --version : Display CVS version and copyright information.
19. -w : Set files checked out to the sandbox readable and writable.
20. -x : Encrypt all data that travels across the network.
21. -z # : Compress all network traffic using the specified gzip compression level.

Repository Access:
Repository path information is as follows:
[:method] [[[user][:password]@]hostname[:[port]]]/path 

Access method can be any of the following:
1. ext: Connection through external rsh or rsh-like program.
2. fork: Client / server mode on local computer.
3. gserver : Connection through the GSS-API and Kerberos 5
4. local : Local computer, no client / server mode.
5. pserver : Connection through password server.
6. kserver: Connection through kerberos 4.
7. server: Connection through internal rsh server key environment variables relating to repository access are
     CVS_RSH: Specifies rsh-like executable.
     CVSROOT: Specifies repository path.

Common CVS Tasks:
The following lists show the syntax to use in performing common CVS tasks. Remember that for any CVS command you can specify the repository path using the -d option. For example:
$ cvs -d repository_path checkout project
For brevity, the -d option is not shown in any of the example commands. However, it can be added to any of the commands.

Sandbox Commands:
Create a new sandbox: $ cvs checkout project
Remove a sandbox: $ cvs release directory
Check out files as of a specific tag name or revision: $ cvs checkout -r [tagname | revision] project
Check out files as of a specific date or time:  $ cvs checkout -D [date|time] project

Synchronization Commands:
Upload changes to the repository: $ cvs commit [filenames]
Force upload of unchanged files: $ cvs commit -f [filenames]
Download changes from the repository: $ cvs update [filenames]
Download changes and download new directories: $ cvs update -d [filenames]
Download changes. but not empty directories : $ cvs update -P [filenames]
Download changes, clear sticky revision, date, keyword mode or branch: $ cvs update -A [filenames]
Convert an existing sandbox to a specific tag name or revision: $ cvs update -r [tagname | revision] project
Convert an existing sandbox to a specific date or time: $ cvs update -D [date|time] project

File Commands:
Add new files or directories to the repository: $ cvs add [filenames]
Add new binary files to the repository: $ cvs add -kb [filenames]
Remove files or directories from the repository: $ cvs remove [filenames]

Branch Commands:
Create a branch from within a sandbox: $ cvs tag -b branchname [filenames]
Create a branch from anywhere using a tag name or revision: $ cvs rtag -r [tagname|revision] -b branchname project
Create a branch from anywhere using a date or time: $ cvs rtag -D [date|time] branchname project
Checkout a branch sandbox: $ cvs checkout -r branchname project
Convert an existing sandbox to a branch sandbox: $ cvs update -r branchname [filenames]

Tag Commands:
Tag files from within a sandbox: $ cvs tag tagname [filenames]
Tag files from anywhere using a tag name or revision: $ cvs rtag -r [existing_tagname | revision] new_tagname project
Tag files from anywhere using a date or time: $ cvs rtag -D [date|time] tagname project
Move a tag from within a sandbox: $ cvs tag -F tagname [filenames]
Move a tag from anywhere using a tag name or revision: $ cvs rtag -r [tagname_at_location|revision] -F tagname_to_more project
Move a tag form anywhere using a date or time: $ cvs rtag -D [date|time] -F tagname project
Delete a tag from within a sandbox: $ cvs tag -d tagname [filenames]
Delete a tag from anywhere: $cvs rtag -d tagname project

The -r [tagname|revision] option accepts a tag name or revision, but cannot have both tag name and revision. The -D [date|time] option accepts a date, a time, or both date and time.

CVSROOT: :ssh:adixit3034c@cmputl-po-3p:/opt/cm/cmsys/cvs/root
Server: cmputl-po-3p
Repository Folder: /opt/cm/cmsys/cvs/root

Username: adixit3034c

[Working]$ cvs -d adixit3034c@cmputl-po-3p:/opt/cm/cmsys/cvs/root checkout -P -r CFX_BR_EEPBill_DDPMediation_2_0_0_5 CFX_BR_EEPBill_DDPMediation

$ cd /data/Release_elements/current/US242513
$ tar -czvf CFX_BR_EEPBill_DDPMediation_2_0_0_5.tar.gz CFX_BR_EEPBill_DDPMediation_2_0_0_5

$ chmod 755 CFX_BR_EEPBill_DDPMediation_2_0_0_5 -R
$ cd /data/Release_elements/current/US242513/CFX_BR_EEPBill_DDPMediation_2_0_0_5/_EEPBill_DDPMediation/app

$ mvn clean install -Dmaven.test.skip=true

Location: http://cmputl-po-4p/cm_workareas/current/

Maven Important Command

Command 1. The install:install goal
In most cases, install:install goal doesn't need any configuration, it needs the project's POM and the artifact file to be installed during the install phase of the default build lifecycle. mvn install :: install:install-file goal
The install:install-file goal is used primarily for installing artifacts to the local repository which were not built by Maven. The project's development team may or may not provide a POM for the artifact. Here's a list of some of the available parameters for the install-file goal:

$mvn install:install-file -Dfile=your-artifact-1.0.jar [-DpomFile=your-pom.xml] [-Dsources=src.jar] [-Djavadoc=apidocs.jar] [-DgroupId=org.some.group] [-DartifactId=your-artifact] [-Dversion=1.0] [-Dpackaging=jar] [-Dclassifier=sources] [-DgeneratePom=true] [-DcreateChecksum=true]

• The groupId, artifactId, version and packaging of the file to install. These can be taken from the specified pomFile, and overridden or specified using the command line. When the pomFile contains a parent section, the parent's groupId can be considered if the groupId is not specified further for the current project or on the command line.
• The optional classifier parameter can be used to install secondary artifacts for a project, like a javadoc or sources JAR. If a classifier is not given, Maven assumes the file is the main artifact for the project.

Command 2: The deploy:deploy Mojo
In most cases, this mojo is invoked when you call the deploy phase of the default build lifecycle.
To enable this mojo to function, you must include a valid section POM, which at the minimum provides a defining the remote repository location for your artifact. To separate snapshot artifacts from release artifacts, you can also specify a location. Finally, to deploy a project website, you must specify a section here as well. It's also important to note that this section can be inherited, allowing you to specify the deployment location one time for a set of related projects.
If your repository is secured, you may also want to configure your settings.xml file to define corresponding entries which provides authentication information. Server entries are matched to the different parts of the distributionManagement using their elements. For example, your project may have a distributionManagement section similar to the following:
[...]
 
   
      internal.repo
      MyCo Internal Repository
      Host to Company Repository
   
 
[...]
In this case, you can specify a server definition in your settings.xml to provide authentication information for both of these repositories at once. Your server section might look like this:
[...]
   
      internal.repo
      maven
      foobar
   
[...]
Please see the article about Password Encryption for instructions on how to avoid clear text passwords in the settings.xml.
Once you've configured your repository deployment information correctly deploying your project's artifact will only require invocation of the deploy phase of the build:
mvn deploy
The deploy:deploy-file Mojo
The deploy:deploy-file mojo is used primarily for deploying artifacts to which were not built by Maven. The project's development team may or may not provide a POM for the artifact, and in some cases you may want to deploy the artifact to an internal remote repository. The deploy-file mojo provides functionality covering all of these use cases, and offers a wide range of configurability for generating a POM on-the-fly. Additionally, you can specify what layout your repository uses. The full usage statement of the deploy-file mojo can be described as:
mvn deploy:deploy-file -Durl=file://C:\m2-repo -DrepositoryId=some.id -Dfile=your-artifact-1.0.jar [-DpomFile=your-pom.xml] [-DgroupId=org.some.group] [-DartifactId=your-artifact] [-Dversion=1.0] [-Dpackaging=jar] [-Dclassifier=test] [-DgeneratePom=true] [-DgeneratePom.description="My Project Description"] [-DrepositoryLayout=legacy] [-DuniqueVersion=false]
If the following required information is not specified in some way, the goal will fail:
•The artifact file to deploy
•The group, artifact, version and packaging of the file to deploy. These can be taken from the specified pomFile, and overriden or specified using the command line. When the pomFile contains a parent section, the parent's groupId can be considered if the groupId is not specified further for the current project or on the command line.
•The repository information: the url to deploy to and the repositoryId mapping to a server section in the settings.xml file. If you don't specify a repositoryId, Maven will try to extract authentication information using the id 'remote-repository'.


More about maven:
1. Plugins
2. Maven & Source Code

J B O S S

EAP: Enterprise Application Platform

JBoss Developer Studio:
Configure Maven in JBoss Developer Studio:
Click Window→Preferences, expand JBoss T ools and select JBoss Maven Integration.

Add a repository [jboss-earlyaccess-repository] > 
Profile Id: jboss-ga-repository
Repository: ID: jboss-ga-repository; Name:jboss-ga-repository; URL: http://maven.repository.redhat.com/techpreview/all

Add early access repository[jboss-earlyaccess-repository]>
Profile Id:jboss-earlyaccess-repository
Repository: ID:jboss-earlyaccess-repository ; Name:jboss-earlyaccess-repository ; URL:http://maven.repository.redhat.com/earlyaccess/all/


First Time when we start JBOSS EAP Server, it will give following message:

- - - - - - - - - - - - - - - - - - - - - 

Welcome to EAP 6
The Enterprise Application Platform 6 is running.
However you have not yet added any users to be able to access the admin console.
To add a new user execute the add-user.sh script within the bin folder of your EAP 6 installation and enter the requested information.
By default the realm name used by EAP is "ManagementRealm" this is already selected by default.
After you have added the user follow this link to Try Again.

- - - - - - - - - - - - - - - - - - - - -