Step by Step Instruction to Upgrade Perforce to 2014

The step are as follows:

a) Check if the license is current.

p4 license -o

The expiry date must be later than the binary release date you are installing

b) Verify server archives using the command ‘p4 verify -q //… > verify.txt’

* Note – If the file ‘verify.txt’ contains a ‘BAD!’ or MISSING!’
signature during the verify command, please contact Perforce Support prior to upgrading.
** If the depot is large and you get an error message “Request too large for server memory”, you can split the verify to check chink of the depot:

Example:
p4 verify -q //depot/project1/… > prj1-verify.txt
p4 verify -q //depot/project2/… > prj2-verify.txt
p4 verify -q //depot/project3/… > prj3-verify.txt

c) Stop the Perforce Server.

p4 admin stop

d) Make a checkpoint of the database.

p4d -r P4ROOT -J journal -jc

e) Copy the db.* files to a safe location.

f) Backup your archive files.

g) Read the release notes so you are aware of the latest changes.

http://www.perforce.com/perforce/doc.current/user/relnotes.txt

h) Download the latest P4D version.

ftp://ftp.perforce.com/perforce/

i) Verify that the newly downloaded binary is the latest. You might need to copy the p4d.exe to p4s.exe

p4d.exe -V
p4s.exe -V

j) Install the upgraded version of the Perforce server.

k) Restore the Perforce Server using the new P4D Binary and the checkpoint taken from the old P4D binary, with the following command ‘p4d –r root –jr checkpoint.xxx’.

l) If the server contains more than 1000 changelists, please run the following command ‘p4d -r root -xu’ from the command line’.

m) Start the perforce Sever.

n) Verify server archive files.

p4 verify -q //… > upgrade-verify.txt

** Note – If the file ‘upgrade-verify.txt’ will contains a ‘BAD!’ or MISSING!’ signature during the verify command, please contact us.

o) Take a checkpoint
p4d -r root -J journal -jc

This is also explained in the below article:

Upgrading to 2013.3 and beyond – http://answers.perforce.com/articles/KB_Article/Upgrading-to-2013-3-and-beyond

Windows To Linux
Moving from Linux to Windows is not a trivial issue, and such a migration is also not supported and will most likely require consolidation of case sensitivity conflicts using our P4 Migrate product. Please see the link below:

Cross-Server Platform Migration
http://answers.perforce.com/articles/KB_Article/Cross-Platform-Perforce-Server-Migration/?q=linux+to+windows&l=en_US&fs=Search&pn=1
http://answers.perforce.com/articles/KB_Article/Cross-Platform-Perforce-Server-Migration

Change of Server is a “Self-serve” option, please fill out this form and licensing will update accordingly.
P4 Support Change of Server License Request
http://www.perforce.com/support-services/change-server-request

Please pass the -z switch during the replay as the checkpoint/journal you are replaying are compressed:
p4d -r P4ROOT -jr -z checkpoint.ckp.104.gz

You will need to request for a background user I believe to be able to do all the required command. This can be done by filling in this below form and using one background user for all of you build machines.
http://www.perforce.com/support-services/request-background-user

Moving a Perforce Server
http://answers.perforce.com/articles/KB_Article/Moving-a-Perforce-Server

 By Chris Lesemann <support@perforce.com

Our Knowledge Base has accurate and up to date information that will help you prepare your own procedure for upgrading. Because the database structures have changed, you will need to take an existing checkpoint and then replay that checkpoint with the 2014.1 version of the P4 Server.

It appear you are on a 32-bit Windows instance…will you be doing an inplace upgrade or moving to 64-bit hardware? If you are moving from 32-bit to -64bit you have to recover from checkpoint anyway.

Please review the two links below and if you have any further questions I would be happy to assist you:

 Upgrading to 2013.3 and beyond <– specific procedure for moving from 2013.2 and earlier P4 to 2013.3 and later

 Upgrading a Perforce Server <– in-place upgrade

 Moving a Perforce Server <– if you have to move to new hard – do NOT start a 64-bit P4D binary against 32-bit db.* databases, or vice versa.

 Upgrading the Perforce Proxy

General information on the new Btree structures and functionality:

 BTree Format Changed for Perforce Server Versions 2013.3 and Later

 Lockless Reads

The post Step by Step Instruction to Upgrade Perforce to 2014 appeared first on scmGalaxy.

DRAFT VERSION

1. Cleaning up Old Checkpoints
2. Playing with Symlink(Softlink) and Redirecting the ROOT folder to drive where we have enough place.
3. Deleting db.have and recreate it manually
4. Display disk space information on the server using “p4 diskspace”
5. Display size information for files in the depot using “p4 sizes”

The post Ways to Perforce server Disk Space Cleanup and Repos Size Management appeared first on scmGalaxy.

The post How to assign computer startup scripts? appeared first on scmGalaxy.

Original link: http://www.cmcrossroads.com/cm-articles/275-articles/14286-selecting-the-right-software-version-control-product

Selecting the Right Software Version Control Product Written by Mike Feighner For many years, I worked loyally for the same company where my expertise was restricted to one single software version control tool—the one that was already in place. I was not involved with determining whether the selected tool was appropriate for the company’s needs; my role was to learn it well and use it within the accepted standards, guidelines, and internally approved processes. When I recently found myself back in the job market, I realized that there were many other version control tools in use in the industry. I then began to consult with other engineers in the field and gathered data from them on which version control tools their organizations were using and the selection criteria they used in choosing a version control tool for their organization. This experience opened up a whole new world for me and soon I realized that selecting and implementing the right tools was essential for the success of any software or systems development effort. From this experience, I have drawn up a checklist of version-control-tool criteria to aid an organization in selecting the best tool. Although there are many good descriptions available on the Internet about the many tools currently on the market, I do not recommend one specific tool over the other, because some tools may fit great in one organization, but fail in another. My goal here is to suggest a partial framework for deciding which tool best fits your needs while at the same time adhering to configuration management best practices. First, you will need to define your organization’s goals, which could include any or all of the following: Good documentation should accompany your tool purchase. The tool should be portable to more than one platform. If your organization is spread out over different time zones or even across international borders, your tool should support a multi-site rather than a single-site function. The cost should be affordable. The tool should be easy to use. The tool should easily support branching and merging. The tool should have the ability to lock a file when being edited to prevent two engineers from editing the same file simultaneously. The tool should be able to accurately merge changes between two or more files. The tool should log a history of changes with notes on who made the change and why the change was made. The tool should have the ability to establish immutable baselines. Next, you will need to review your organization’s requirements for software version control and carefully review the various software tools on the market to determine which one best matches your organization’s needs. Some may be better suited for your project than others. Selecting the wrong tool can have devastating effects on your team’s effort. Lack of a good version control tool can be a major cause for delays and problems during your organization’s application development. The project will run over cost and behind schedule and can be prone to risks associated with the manual management and distribution of your project’s dependencies. Unauthorized changes and results will occur, and the customer will not be satisfied. The tool you select should not impede the implementation of configuration management best practices, which serve as a means to add value to the process, improve quality, and increase productivity. The following are some, but not all, of the questions you will need to consider. Documentation Is the tool well documented? Is support documentation available on this tool’s installation and for the tool’s use by both administrators and developers? As a reference manual, the tool’s documentation should adequately describe the tool’s features—each dialog box, tab, field, button, etc. It should answer a user’s questions about completing a specific task in a clear and concise way. Frequently, the user documentation is available in the tool’s help pull-down menu or can be downloaded electronically from the vendor’s website. Portability Is the tool portable? Can it be used on multiple platforms and operating systems? From a business perspective, your software team will be supporting a broad user market occupying various platforms, including Windows, Mac OS, or some flavor of UNIX. Your tool should be compatible on any of these platforms, as each release will simultaneously need a separate version to support each platform of your user base. Multi-site vs. Single Site Is your team located at one location site, or is your team globally distributed across the nation and across different time zones throughout the world? A “single site” constitutes one physical location such as a single building or office. A “multisite” constitutes an organization in more than one office or location in a single time zone, in multiple time zones within one country or in multiple countries. If your organization is spread out over various time zones or even across international borders, your tool should support a multi-site rather than a single-site function. A multi-site project established as a set of several individual independent single-site systems would be prone to added costs and risks associated with the manual management and distribution of the project’s dependencies. Life for a multisite organization would be a lot easier to maintain a single multisite system with access to one shared repository. A single-site organization would be wise to select a single-site system over the additional costs of a multi-site system Cost What are the costs and terms of licensing of the tool? Is it something your organization can afford? Generally, a tool designed for a large organization will have a much larger cost than one designed for a smaller organization. No one should assume paying a higher cost for your tool will solve all of your problems. Even a high cost tool may fall sort of satisfying your organization’s needs. Your decision should consider overall cost and your organization’s needs. Supporting your organization’s needs should never be underfunded. Ease of Use How easy is it to install and deploy the system? Will the tool be dependent on other tools to conduct software builds, or are some of these capabilities already an integral part of the tool? Is this a tool that is easy to use from the first day of installation throughout the entire development lifecycle? Will training and customer support be available? Will the tool require training an in-house administrator dedicated to the administration of the tool? If you are not able to immediately pick up a source code management system and start building your site, odds are it is not entirely user friendly. Ultimately, the key to a successful deployment of a source code management system is reliability and ease-of-use. A tool that is difficult to use will likely conceal the functional benefits that it would otherwise provide. If training is an affordable option for your organization, consider whether it is available through the vendor or through an unbiased third party. For a lower-cost approach in the long term, consider sending a representative from your organization to a vendor training event who will later write up a training program for your own company-based organization. Branching Does the tool accommodate branch creation? The capability to create a branch should allow duplication of an object under revision control. Thus, code modifications can happen securely in parallel along both branches at the same time whether the change involves adding a new requirement or attempting to resolve an issue from an earlier release. The tool you select should support your particular choice of branching strategy, be it by revision or release via a simple copybranch or by creating adelta branch off of the main branch or trunk. Or the tool may go a step further by creating streams that include supporting metadata and workflow automation as an enhancement in managing multiple variants in the code. Branching is one of the most important features to consider in your choice of a good source control management system as it allows you to easily support at the same time the same source code and a parallel subset of the same code being modified securely to support either a new requirement or a bugfix from an earlier release. Merging Does the tool allow merges of changes and assists in resolving conflicts between different edits to the same file? Can a merge be done via a graphical user interface or on a command line? Take into consideration that merging concurrent changes made by different developers can increase the amount of effort to resolve conflicts and achieve a merge safely. The best advice in such cases is to merge little and merge often. File Locking Does the system have a means of preventing concurrent access to the same file? Does it prevent more than one user at a time from writing to the file until the current user either checks in the file or cancels the checkout? History of Changes Does the tool maintain a log of the history of changes? Can the tool display the history of changes graphically, as in a version tree? Does the tool easily identify the current baselined version and list previous baselined versions? A history change log that maintains accurate records facilitates traceability through the code’s lifecycle, from its beginning to its eventual release and beyond. A change history log can trace a change back its origins to who made the change and to the authority who authorized the change. It plays a vital role in baselining the code. This is a basic requirement of any organization wishing to maintain proper controls and compliance. Baselining Baselining, also known as setting a control point for your code, lets you know the exact versions of all source code and other configuration items that were included in a release. Does the tool have a way of baselining the code (be it via labeling, tagging, or snapshots) to a particular version that would allow us to back out and return to the previous baselined version in the event of a problem? Is the baseline immutable? If the tool allows changes to the previously released baseline, it jeopardizes the integrity of the software. A baseline must be locked down to prevent modifications. Any subsequent release should be based on a previously release baseline. Conclusion No one software version control tool can possibly fit every organization’s needs. There is no one size fits all. The right tool should help you safeguard your code and help your process improve productivity and quality. Remember that thorough evaluation and selection of the right tool will require funding, but this vetting must stay within your organization’s budget. Careful selection of the appropriate version control tool will help your firm improve productivity and quality and ensure that you are adhering to industry standards regarding configuration management best practices. About the Author Mike Feighner has more than twenty years’ experience in information technology in the aerospace industry, including more than ten years in configuration management. Mike graduated from San Jose State University with a bachelor’s degree in German and has a master’s degree in political science from the University of Tübingen in Germany and a master’s degree in software engineering from National University.

The post How to Select the Right Software version Control Product? appeared first on scmGalaxy.

Situation

1. For one of our clients, Build is taking 8 hours and nightly build is failing frequently.
2. Test case execution is consuming more time than the compilation.
3. Low confidence levels for developers on nightly builds and subsequently during integration cycle.

Approach

1. We reviewed the whole set of build scripts being used and test case suite to check how we can refatcor them.
2. Verified the build infrastructure i.e., build server capacity from hardware point of view.
3. Feasibility study done to check how a CI environment help in giving faster feedback on the quality.

Solution

1. Refactoring done for build scripts to make modules compilation parallel (wherever possible).
2. Some test cases are selected (which don’t require external services like database) to run as part of the build.
3. CI environment (using open source cruise control) is established to run builds per commit and execute only above set of test cases as part of the build.
4. Set up low-cost remote agent machine which will run remaining test suite once per day.

Results

1. Build took only 1 hour and gave faster feedback to dev team.
2. CI environment provided good confidence to dev team.
3. Team is able to implement more best practices.
4. Effective use of existing build  infrastructure (hardware) ensured no further cost is required.
5. This helped the client in ensuring smooth release management.

The post How we reduced build time from 8 hours to 1 hour ? – Complete Guide appeared first on scmGalaxy.

This was like the first time where I had to write something that will be able to read something out of a XML file using a shell script. Usually I would use Python/Perl as my favorite choices in such a scenario but in this one I really *had* to do all within a shell script.

This is an example of the type of XML file I had to read:

Fixed a new bug
Shoaib Mir
Sun, 02 May 2010
shoaibmir[@]gmail.com

I ended up having a shell script like this:

#!/bin/bash

#Looking for four keywords in here
for key in changelog name date email
do
OUTPT=`grep $key log.xml | tr -d '\t' | sed 's/^\([^<].*\)$/\1/' `
eval ${key}=`echo -ne \""${OUTPT}"\"`
done

# Getting the results in four specific arrays
changelogarr=( `echo ${changelog}` )
namearr=( `echo ${name}` )
datearr=( `echo ${date}` )
emailarr=( `echo ${email}` )

#Print all Arrays
echo ${changelogarr[@]}
echo ${namearr[@]}
echo ${datearr[@]}
echo ${emailarr[@]}


Which gives me an output:

shoaib@shoaib-desktop:~/Desktop$ ./readxml.sh
Fixed a new bug Shoaib Mir
Sun, 02 May 2010
shoaibmir[@]gmail.com

Reference:

Reading XML file using shell script

The post How to read XML file by using shell script ? appeared first on scmGalaxy.

Usage of ANT_OPTS in Ant Script | ANT_OPTS capabilities

Ant has three environment variables that you can use to set its default behavior.
• ANT_ARGS Set this variable to include those options you use frequently.
• ANT_OPTS is a list of arguments that you want to pass to the JVM that will run Ant.
• JAVACMD is the absolute path to the Java executable you want Ant to use. you may specify a value for the JAVACMD environment variable. This defaults to %JAVA_HOME%\bin\java, typically invoking the JVM provided in Sun’s Java Development Kit. Ant provides JAVACMD for those who wish to specify an alternate JVM. full path of the Java executable. Use this to invoke a different JVM than JAVA_HOME/bin/java(.exe).

These are useful environment variables that the Ant wrapper scripts use when
invoking Ant: ANT_OPTS and ANT_ARGS. Neither of these is typically set by users,
but each can provide value for certain situations.

The ANT_OPTS environment variable provides options to the JVM executing Ant,
such as system properties and memory configuration. ANT_OPTS – command-line arguments that should be passed to the JVM. For example, you can define system properties or set the maximum Java heap size here.

For authenticated proxy:
Set your ANT_OPTS environment variable to configure your proxy if you have one. For instance:
set ANT_OPTS=-Dhttp.proxyHost=myproxy -Dhttp.proxyPort=3128

You can set these properties by either modifying Ant’s startup script, or by
using the ANT_OPTS environment variable. The following example shows the Windows commands to specify these properties using ANT_OPTS, and then to invoke Ant:
set ANT_OPTS=-DproxySet=true -DproxyHost=localhost -DproxyPort=80
ant mytarget
The same trick works on Unix, although the syntax is slightly different depending on which
shell you use:
$ export ANT_OPTS=”-DproxySet=true -DproxyHost=localhost -DproxyPort=80″
$ ant mytarget

set ANT_OPTS=-Dhttp.proxyHost=myproxyhost -Dhttp.proxyPort=8080 -Dhttp.proxyUserName=myproxyusername -Dhttp.proxyPassword=myproxypassword -Dhttps.proxyHost=myproxyhost -Dhttps.proxyPort=8080

Use ANT_OPTS to control Ant’s virtual machine settings.
Some tasks may require more memory, which you can set in the ANT_OPTS environment variable, using the appropriate mechanism for your platform:
set ANT_OPTS=-Xmx500M
export ANT_OPTS=-Xmx500M

Setting the maximum heap size is another common use of ANT_OPTS. Here is how we set the maximum size to 128 MB when using Sun’s JDK:
set ANT_OPTS=-Xmx128m

One environment variable you may wish to set is ANT_OPTS. The value of this variable is passed as a JVM argument. Specifying system properties is a common use. In this simple
example, we pass the log.dir system property to the JVM running Ant:
$ set ANT_OPTS=-Dlog.dir=C:\logs
$ ant run
Now this property is available within the buildfile, for instance:
<echo>Log directory is set to: ${log.dir}</echo>
If the buildfile runs a Java application, the property may be retrieved from within it as
follows:
String logDir = System.getProperty(“log.dir”);

Troubleshoot: Illegal Java options in the ANT_OPTS variable
The environment variable ANT_OPTS provides a means to pass options into Ant,
such as a permanent definition of some properties, or the memory parameters for
Java. The variable must contain only options the local JVM recognizes. Any invalid
parameter will generate an error message such as the following (where ANT_OPTS was
set to –3):
Unrecognized option: -3
Could not create the Java virtual machine.

If the variable contains a string that is mistaken for the name of the Java class to run
as the main class, then a different error appears:

Exception in thread “main” java.lang.NoClassDefFoundError: error-string
Test: Examine ANT_OPTS and verify that the variable is unset or contains valid
JVM options.
Fix: Correct or clear the variable.

The post Usage of ANT_OPTS in Ant Script | ANT_OPTS capabilities appeared first on scmGalaxy.

Power Point PPT: Using Ant To Build J2 Ee Application

The post Power Point PPT: Using Ant To Build J2 Ee Application – Complete Guide appeared first on scmGalaxy.

Running Java EE applications on Amazon EC2: deploying to 20 machines with no money down

Computer hardware has traditionally been a scarce, expensive resource. In the early days of computing developers had to share a single machine. Today each developer usually has their own machine but it’s rare for a developer to have more than one. This means that running performance tests often involves scavenging for machines.  Likewise, replicating even just part of a production environment is a major undertaking. With Amazon’s Elastic Compute Cloud (EC2), however, things are very different. A set of Linux servers is now just a web service call away. Depending on the type of the servers you simply pay 10-80 cents per server per hour for up to 20 servers! No more upfront costs or waiting for machines to be purchased and configured.

To make it easier for enterprise Java developers to use EC2, I have created EC2Deploy.  It’s a Groovy framework for deploying an enterprise Java application on a set of Amazon EC2 servers. EC2Deploy provides a simple, easy to use API for launching a set of EC2 instances; configuring MySQL, Apache and one or more Tomcat servers; and deploying one or more web applications. In addition, it can also run JMeter and collect performance metrics.

Here is an example script that launches some EC2 instances; configures MySQL with one slave, Tomcat and Apache; deploys a single web application on the Tomcat server; and runs a JMeter test with first one thread and then two.

class ClusterTest extends GroovyTestCase {

  void testSomething() {

    AWSProperties awsProperties = new

        AWSProperties("/…/aws.properties")

    def ec2 = new EC2(awsProperties)

    def explodedWar = '…/projecttrack/webapp/target/ptrack'

    ClusterSpec clusterSpec =

       new ClusterSpec()

            .schema("ptrack", ["ptrack": "ptrack"],

                    ["src/test/resources/testdml1.sql",

                     "src/test/resources/testdml2.sql"])

            .slaves(1)

            .tomcats(1)

            .webApp(explodedWar, "ptrack")

            .catalinaOptsBuilder({builder, databasePrivateDnsName ->

                 builder.arg("-Xmx500m")

                 builder.prop("com.sun.management.jmxremote")

                 builder.prop("com.sun.management.jmxremote.port", 8091)

                 builder.prop("com.sun.management.jmxremote.authenticate",

                                     false)

                 builder.prop("com.sun.management.jmxremote.ssl", false)

                 builder.prop("ptrack.application.environment", "ec2")

                 builder.prop("log4j.configuration",

                               "log4j-minimal.properties")

                 builder.prop("jdbc.db.server", databasePrivateDnsName)})

    SimpleCluster cluster = new SimpleCluster(ec2, clusterSpec)

    cluster.loadTest("…/projecttrack/functionalTests/jmeter/SimpleTest.jmx",

        [1, 2])

    cluster.stop()

  }

}

Let’s look at each of the pieces.

First, we need to configure the framework as follows:

    AWSProperties awsProperties = new

        AWSProperties("/…/aws.properties")

    def ec2 = new EC2(awsProperties)

The aws.properties file contains various properties including the Amazon WS security credentials and the EC2 AMI (i.e. OS image) to launch. All servers use my EC2 appliance AMI that has Java, MySQL, Apache, Tomcat, Jmeter and some other useful tools pre-installed.

Next we need to configure the servers:

     ClusterSpec clusterSpec =

        new ClusterSpec()

             .schema("ptrack", ["ptrack": "ptrack"],

                    ["src/test/resources/testdml1.sql",

                     "src/test/resources/testdml2.sql"])

             .slaves(1)

             .tomcats(1)

             .webApp(explodedWar, "ptrack")

             .catalinaOptsBuilder({builder, databasePrivateDnsName ->

                 builder.arg("-Xmx500m")

                 builder.prop("com.sun.management.jmxremote")

                 builder.prop("com.sun.management.jmxremote.port", 8091)

                 builder.prop("com.sun.management.jmxremote.authenticate",

                                     false)

                 builder.prop("com.sun.management.jmxremote.ssl", false)

                 builder.prop("ptrack.application.environment", "ec2")

                 builder.prop("log4j.configuration",

                               "log4j-minimal.properties")

                 builder.prop("jdbc.db.server", databasePrivateDnsName)})

     SimpleCluster cluster = new SimpleCluster(ec2, clusterSpec)

This code first creates a ClusterSpec, which defines the configuration of the machines and the applications:

• schema() – specifies the name of the database schema to create; names of the users and their passwords; the DML scripts to execute once the database has been create
• slaves() – specifies how many MySql slaves to create
• tomcats() – specifies how many Tomcats to run.
• webApp() – configures a web application. This method takes two parameters: the path to the exploded WAR directory (conveniently created by Maven) and the context to deploy the web application under.
• catalinaOptsBuilder() – supplies a closure that takes a builder and the DNS name of the MySQL server as arguments and returns the CATALINA_OPTS used to launch Tomcat. It’s primary purpose is to configure the web application(s) to use the correct database server

It then creates a cluster with that specification.

We then start the cluster:

    cluster.start()

At this point EC2Deploy will:

1. Launch the EC2 instances running my appliance AMI.
2. Initialize the MySql master database
3. Create the MySql slave
4. Create the database schema and the users
5. Run any DML scripts (these are cached on S3 in a bucket called “tmp–dml” for the reasons described next)
6. Upload the web applications to Amazon S3 (Simple Storage Service) where they are cached in order to avoid time consuming uploads (over slow DSL connections, for example). EC2Deploy only uploads new and changed files, which means that the bulky 3^rd party libraries are only uploaded once. Each web application is stored in an S3 bucket called -tmp-war. If this bucket does not exist you will see some warning messages and the bucket will be created.
7. Deploy the web applications on each of the Tomcat servers
8. Configure Apache to load balance across the Tomcat servers

Once the cluster is started we can run a JMeter load test:

    cluster.loadTest("…/projecttrack/functionalTests/jmeter/SimpleTest.jmx", [1, 2])

The first argument specifies the test to run and the second argument is a list of JMeter thread counts. In this example, EC2deploy first runs the load test with one thread and then two threads. For each test run, it generates a report describing CPU utilization for each machine, average response time and throughput.

Finally, we stop the EC2 instances:

cluster.stop()

As you can see, EC2Deploy makes it pretty easy to deploy and test your enterprise Java application. I’ve used it to clone a production environment and run load tests. NOTE 1/28/08: The source code EC2Deploy along with a very cool Maven plugin is now available !

The post How to Run/Deploy Java EE applications on Amazon EC2? appeared first on scmGalaxy.

While working with Cloud Tools and Cloud Foundry users, I have noticed that EC2 key pairs and security group configuration are common stumbling blocks for people who are new to Amazon EC2. When you sign up for an AWS account you get what can be, at first, a confusing set of credentials:  an access key id,  a secret access key, X509 certificate and a corresponding private key. You authenticate an AWS request using either the access key id and secret access key or the X509 certificate and private key. Some APIs and tools support both options, where was others support just one. And, to make matters worse, to launch an EC2 instance and access it via SSH you must use a (named) EC2 key pair. This EC2 key pair is not the same as the X509 certificate/private key given to you by AWS during sign up. But they are easily confused since they both consist of private and public keys.

You create a EC2 key pair by using one of the AWS tools: command line tools, ElasticFox plugin or the rather nice AWS console. Under the covers these tools make an AWS request to create the key pair.

Here is a screenshot of the AWS Console showing how you create a key pair.

There are three steps:

1. Select Key Pairs
2. Click  Create Key Pair
3. Enter the name of the Key Pair you want to create – you chose the name

The console will then create the key pair and prompt you to save the private key.

You specify the key pair name in the AWS request that launches the instances and specify the private key file as the -i argument to ssh when connecting to the instance.Just make sure you save the key pair in safe place.

Another stumbling block is that you need to enable SSH in the AWS firewall. Both Cloud Tools and Cloud Foundry use SSH to configure the instances and deploy the application. If SSH is blocked then they won’t work. Fortunately, the AWS firewall (a.k.a. security groups) is extremely easy to configure using the AWS tools – command line tools, ElasticFox plugin or the nice AWS console – by editing the default security group to allow SSH traffic.

The good news is that these are relatively minor hurdles to overcome. Once you have sorted out your EC2 key pair and edited the security groups to enable SSH using Cloud Tools or Cloud Foundry to deploy your web application is very easy.

The post Amazon EC2 key pairs and other stumbling blocks – Guide appeared first on scmGalaxy.

Recently I upgraded a project of mine (the Dimecasts code base) to use VisualStudio 2010.  In the process everything worked just fine from the IDE, but when I tried to compile it from the command line I would get the following errors:

Error MSB4064: The “Retries” parameter is not supported by the “Copy” task.
Error MSB4063: THe “Copy” task could be initialized with its input parameter.

After a bit a googling I came across a post which (and of course i cannot find it now) said that if you open up your .proj files and change the line that pointed to the v10.0 build of web applications and reset it back to 9.0 everything would compile.  And this did work… BUT when you try to open that project up again in VS 2010 it will simply revert your changes… this is not a working solution.

Next I decided to switch my target framework in Nant from 3.5 to 4.0, but of course my nant.exe.config file does not support 4.0 yet.  So after a bit more googling I found this post that gives details on how to add the missing values to the config file.

When I added the config information to my Nant.exe.config file things were better, but still not great.  Now I was getting an error that said:

The “vendor” attribute does not exist, or has no value.

To resolve this I added the following under the node in my config
vendor=”Microsoft”

After this I got another error…. This time it said that .Net Framework 4.0 was not installed.  But I know this is not valid.  After looking at the information for a few more seconds I realized the issue.  The example config from the post above was build on an older version of the 4.0 framework (.20506) and I have .30128.

I changed all values in the nant.exe.config value that was v4.0.20506 to be v4.0.30128 and NOW I am able to compile.

So long story short, if you are getting the MSB4064 error you need to do the following:

1. Point nant to use the 4.0 framework tools
2. Follow this post  and copy the framework section to your Nant.exe.config file
3. Add the missing ‘vendor’ attribute to the new framework section
4. Update the version in the new framework section to match the version you have on disk (check C:\Windows\Microsoft.NET\Framework for versions)
5. Compile again

The post Issues Compiling VS2010 solutions (with web projects) from Nant | MSB4064 error appeared first on scmGalaxy.

When writing JUnit tests developers often add log statements that can help provide information on test failures. During the initial attempt to find a failure a simple System.out.println() statement is usually the first resort of most developers.

Replacing these System.out.println() statements with log statements is the first improvement on this technique. Using SLF4J (Simple Logging Facade for Java) provides some neat improvements using parameterized messages. Combining SLF4J with JUnit 4 rule implementations can provide more efficient test class logging techniques.

Some examples will help to illustrate how SLF4J and JUnit 4 rule implementation offers improved test logging techniques. As mentioned the inital solution by developers is to use System.out.println() statements. The simple example code below shows this method.

01    import org.junit.Test;
02
03    public class LoggingTest {
04
05      @Test
06      public void testA() {
07        System.out.println(“testA being run…”);
08      }
09
10      @Test
11      public void testB() {
12        System.out.println(“testB being run…”);
13      }
14    }

The obvious improvement here is to use logging statements rather than the System.out.println() statements. Using SLF4J enables us to do this simply whilst allowing the end user to plug in their desired logging framework at deployment time. Replacing the System.out.println() statements with SLF4J log statements directly results in the following code.
view source

01    import org.junit.Test;
02    import org.slf4j.Logger;
03    import org.slf4j.LoggerFactory;
04
05    public class LoggingTest {
06
07      final Logger logger =
08        LoggerFactory.getLogger(LoggingTest.class);
09
10      @Test
11      public void testA() {
12        logger.info(“testA being run…”);
13      }
14
15      @Test
16      public void testB() {
17        logger.info(“testB being run…”);
18      }
19    }

Looking at the code it feels that the hard coded method name in the log statements would be better obtained using the @Rule TestName JUnit 4 class. This Rule makes the test name available inside method blocks. Replacing the hard coded string value with the TestName rule implementation results in the following updated code.

01    import org.junit.Rule;
02    import org.junit.Test;
03    import org.junit.rules.TestName;
04    import org.slf4j.Logger;
05    import org.slf4j.LoggerFactory;
06
07    public class LoggingTest {
08
09      @Rule public TestName name = new TestName();
10
11      final Logger logger =
12        LoggerFactory.getLogger(LoggingTest.class);
13
14      @Test
15      public void testA() {
16        logger.info(name.getMethodName() + ” being run…”);
17      }
18
19      @Test
20      public void testB() {
21        logger.info(name.getMethodName() + ” being run…”);
22      }
23    }

SLF4J offers an improved method to the log statement in the example above which provides faster logging. Use of parameterized messages enable SLF4J to evaluate whether or not to log the message at all. The message parameters will only be resolved if the message will be logged. According to the SLF4J manual this can provide an improvement of a factor of at least 30, in case of a disabled logging statement.

Updating the code to use SLF4J parameterized messages results in the following code.

01    import org.junit.Rule;
02    import org.junit.Test;
03    import org.junit.rules.TestName;
04    import org.slf4j.Logger;
05    import org.slf4j.LoggerFactory;
06
07    public class LoggingTest {
08
09      @Rule public TestName name = new TestName();
10
11      final Logger logger =
12        LoggerFactory.getLogger(LoggingTest.class);
13
14      @Test
15      public void testA() {
16        logger.info(“{} being run…”, name.getMethodName());
17      }
18
19      @Test
20      public void testB() {
21        logger.info(“{} being run…”, name.getMethodName());  }
22      }
23    }

Quite clearly the logging statements in this code don’t conform to the DRY principle.

Another JUnit 4 Rule implementation enables us to correct this issue. Using the TestWatchman we are able to create an implementation that overrides the starting(FrameworkMethod method) to provide the same functionality whilst maintaining the DRY principle. The TestWatchman Rule also enables developers to override methods invoked when the test finishes, fails or succeeds.

Using the TestWatchman Rule results in the following code.

01    import org.junit.Rule;
02    import org.junit.Test;
03    import org.junit.rules.MethodRule;
04    import org.junit.rules.TestWatchman;
05    import org.junit.runners.model.FrameworkMethod;
06    import org.slf4j.Logger;
07    import org.slf4j.LoggerFactory;
08
09    public class LoggingTest {
10
11      @Rule public MethodRule watchman = new TestWatchman() {
12        public void starting(FrameworkMethod method) {
13          logger.info(“{} being run…”, method.getName());
14        }
15      };
16
17      final Logger logger =
18        LoggerFactory.getLogger(LoggingTest.class);
19
20      @Test
21      public void testA() {
22
23      }
24
25      @Test
26      public void testB() {
27
28      }
29    }

And there you have it. A nice test code logging technique using JUnit 4 rules taking advantage of SLF4J parameterized messages.

I would be interested to hear from anyone using this or similar techniques based on JUnit 4 rules and SLF4J.

Reference: http://www.catosplace.net/

The post JUnit 4 Test Logging Tips using SLF4J appeared first on scmGalaxy.

This article is a summary of a seminar I had on the topic. If it seems like it’s a continuation of an existing discussion that’s because, to some extent, it is. If you haven’t been discussing exchanging your app server, this article probably isn’t very interesting to you.

By putting the application server inside my application instead of the other way around, I was able to leap tall buildings in a single bound.

The embedded application server

This is how I deploy my sample application to a new test environment (or to production):

1. mvn install
2. scp -server/target/-1.0.onejar.jar appuser@appserver:/home/appuser/test-env1/
3. ssh appuser@appserver “cd /home/appuser/test-env1/ && java -jar -1.0.onejar.jar&”

This require no prior installed software on the appserver (with the exception of the JVM). It requires no prior configuration. Rolling back is a matter of replacing one jar-file with another. Clustering is a matter of deploying the same application several times.

In order to make this work in a real environment, there are a many details you as a developer need to take care of. As a matter of fact, you will have to take responsibility for your operational environment. The good news is that creating a good operational environment is not more time-consuming than trying to cope with the feed and care of a big-a Application Server.

In this scheme every application comes with its own application server in the form of jetty’s jar-files embedded in the deployed jar-file.

The advantages

Why would you want to do something like this?

• Independent application: If you’ve ever been told that you can’t use Java 1.5 because that would require an upgrade of the application server. And if we upgrade the application server, that could affect someone else adversely. So we need to start a huge undertaking to find out who could possibly be affected.
• Developer managed libraries: Similar problems can occur with libraries. Especially those that come with the application server. For example: Oracle OC4J helpfully places a preview version of JPA 1.0 first in your classpath. If you want to use Hibernate with JPA 1.0-FINAL, it will mostly work. Until you try to use a annotation that was changed after the preview version (@Discriminator, for example). The general rule is: If an API comes with your app server, you’re better served by staying away from it. A rather bizarre state of affairs.
• Deployment, configuration and upgrades: Each version of the application, including all its dependencies is packaged into a single jar-file that can be deployed on several application server, or several times on the same application server (with different ports). The configuration is read from a properties-file in the current working directory. On the minus side, there’s no fancy web UI where you can step through a wizard to deploy the application or change the configuration. On the plus side, there is no fancy web UI …. If you’ve used one such web UI, you know what I mean.
• Continuous deployment: As your maven-repository will contain stand alone applications, creating a continuous deployment scheme is very easy. In my previous environment, a cron job running wget periodically was all that was needed to connect the dots. Having each server environment PULL the latest version gives a bit more flexibility if you want many test environments. (However, if you’re doing automated PUSH deployment, it’s probably just as practical for you).
• Same code in test and production: The fact that you can start Jetty inside a plain old JUnit test means that it is ideal for taking your automated tests one step further. However, if you test with Jetty and deploy on a different Application Server, the difference will occasionally trip you. It’s not a big deal. You have to test in the server environment anyway. But why not eliminate the extra source of pain if you can?
• Licenses: Sure, you can afford to pay a few million $ for an application server. You probably don’t have any better use for that money, anyway, right? However, if you have to pay licenses for each test-server in addition, it will probably mean that you will test less. We don’t want that.
• Operations: In my experience, operations people don’t like to mess around with the internals of an Application Server. An executable jar file plus a script that can be run with [start|status|stop] may be a much better match.

The missing bits

Taking control of the application server takes away a lot of complex technology. This simplifies and makes a lot of stuff cheaper. It also puts you back in control of the environment. However, it forces you to think about some things that might’ve been solved for you before:

• Monitoring: The first step of monitoring is simple: Just make sure you write to a log file that is being monitored by your operations department. The second step requires some work: Create a servlet (or a Jetty Handler) that a monitoring tool can ping to check that everything is okay. Taking control of this means that you can improve it: Check if your data sources can connect, if your file share is visible, if that service answers. Maybe add application-calibrated load reporting. Beyond that, Jetty has good JMX support, but I’ve never needed it myself.
• Load balancing: My setup supports no load balancing or failover out of the box. However, this is normally something that the web server or routers in front of the application server anyway. You might want to look into Jetty’s options for session affinity, if you need that.
• Security: Jetty supports JAAS, of course. Also: In all the environments I’ve been working with (CA SiteMinder, Sun OpenSSO, Oracle SSO), the SSO server sends the user name of the currently logged in user as an HTTP header. You can get far by just using that.
• Consistency: If you deploy more than one application as an embedded application server, the file structure used by an application (if any) should be standardized. As should the commands to start and stop the application. And the location of logs. Beyond that, reuse what you like, recreate what you don’t.

Taking control of your destiny

Using an embedded application server means using the application server as a library instead of a framework. It means taking control of your “main” method. There’s a surprisingly small number of things you need to work out yourself. In exchange, you get the control to do many things that are impossible with a big-A Application Server.

Reference: http://www.javaworld.com/community/

The post Why and how to use Jetty in mission-critical production appeared first on scmGalaxy.

Bamboo is available in two ‘distributions’ — Standalone or EAR-WAR. The Standalone distribution is recommended (even for organisations with an existing application server environment).
Standalone Installation Guide — Windows

Download and Install Bamboo Standalone for Windows (Windows Installer)

·  Download Bamboo Standalone for Windows. Bamboo Standalone for Windows is available for download from the Bamboo Download Center. Choose the Windows Installer (.exe) download.
·  Launch the Bamboo Windows installer (atlassian-bamboo-x.x-standalone.exe) to begin the installation wizard.
·  The installer requires you to specify two directories:
Bamboo installation directory — This is the directory where Bamboo’s application files will be installed. The default is:
C:/Program Files/Bamboo
Bamboo home directory — This is the directory where Bamboo will store its configuration data. If the directory you specify doesn’t exist, Bamboo will create the directory when it launches. The default is:
C:/Documents and Settings//Bamboo-home
Note: You must use forward-slashes in your directory path. Backslashes are not recognised by Bamboo. Please ensure that the Bamboo home directory is not located inside the Bamboo installation directory

Download and Install Bamboo Standalone for Windows (ZIP Archive)

·  Download Bamboo Standalone for Windows. Bamboo Standalone for Windows is available for download from the Bamboo Download Center. Choose the ZIP Archive (.zip) download (click the ‘Show all‘ link to show the ‘ZIP Archive‘ download link).
·  Extract the files from the ZIP Archive (atlassian-bamboo-x.x-standalone.zip) to a Bamboo installation directory of your choice. By default, the root directory in your zip file is named “Bamboo”.
·  Set up your Bamboo home directory — this is the directory where Bamboo will store its root configuration data. To do this, edit the file named bamboo-init.properties in the Bamboo/webapp/WEB-INF/classes directory. In this file, insert the property “bamboo.home”, with an absolute path to your Bamboo home directory. Your file should look something like this:

    bamboo.home=C:/test/bamboo-home

Alternatively, you can specify an environment variable ‘BAMBOO_HOME’ which specifies the absolute path to your {BAMBOO_HOME} directory. Bamboo will check if an environment variable is defined.
·  If you are going to use Bamboo remote agents, set the following in the bamboo-init.properties file in the /webapp/WEB-INF/classes directory:
bamboo.jms.broker.uri=tcp://localhost:54663

• Replace ‘localhost’ with the real host name or IP address of your Bamboo server.
• If port number 54663 is already in use, specify a different port number.

Launch Bamboo

Launch via the Start Menu
If you have used the ‘Windows Installer’ to install Bamboo, you can start Bamboo via the Start Menu in Windows (generally under the ‘Bamboo’ folder by default). The following options will be available in your Start Menu:

• ‘Bamboo Continuous Integration Server Uninstaller‘ — uninstalls Bamboo from your computer
• ‘Install Service‘ — installs Bamboo as a Windows service (note, this will not start Bamboo)
• ‘Remove Service‘ — removes the Bamboo Windows service, if you have previously installed it (note, Bamboo will not be uninstalled from your computer)
• ‘Start in Console‘ — starts Bamboo in a Windows console
• ‘Start Service‘ — starts your installed Bamboo Windows service
• ‘Stop Service‘ — stops your installed Bamboo Windows service

You can run Bamboo in two modes, either in a Windows console or as a Windows service:

• To run Bamboo in a Windows console, click the ‘Start in Console‘ option.
• To run Bamboo as a Windows service, click the ‘Install service‘ option. After the service is installed, click ‘Start Service‘. Once you have installed Bamboo as a service, Bamboo will start up automatically every time Windows restarts.

Launch via batch file
You can start Bamboo via the batch files that are shipped with Bamboo. If you have installed Bamboo via the ZIP Archive, you will need to use the batch files to start Bamboo. You can find the following batch files in your installation directory:

• ‘BambooConsole.bat‘ — this starts Bamboo in a Windows console.
• ‘InstallAsService.bat‘ — this installs Bamboo as a Windows service. Note that this will not start Bamboo.
• ‘StartBamboo.bat‘ — this starts your installed Bamboo Windows service.
• ‘StopBamboo.bat‘ — this stops your installed Bamboo Windows service
• ‘UninstallService.bat‘ — this un-installs the Bamboo Windows service from your machine. Note that your Bamboo installation still remains.

You can run Bamboo in two modes, either in a Windows console or as a Windows service:

• To run Bamboo in a Windows console, run ‘BambooConsole.bat‘
• To run Bamboo as a Windows service, run ‘InstallAsService.bat‘. After the service is installed, run ‘StartBamboo.bat‘. Once you have installed Bamboo as a service, Bamboo will start up automatically every time Windows restarts.

Configure Bamboo

1. Access your running Bamboo instance by going to your web browser and entering the address: http://localhost:8085/.
2. Configure Bamboo via the Setup Wizard which will display. Read Running the Setup Wizard for further instructions.

For more details on Installation and Configuration, please review following links
http://confluence.atlassian.com/pages/viewpage.action?pageId=55246864

• Bamboo Installation Guide
  • Bamboo EAR-WAR Installation Guide
  • Bamboo Remote Agent Installation Guide
  • Bamboo Standalone Installation Guide (Linux)
  • Bamboo Standalone Installation Guide (Mac)
  • Bamboo Standalone Installation Guide (Windows)
  • Connecting Bamboo to an external database
  • Running the Setup Wizard

The post Installation and Configuration Guide: Bamboo appeared first on scmGalaxy.

If you have any of the following questions in your mind, then this article is the perfect destination for you.

• How to copy VSS project from one VSS database to another one without loosing history
• How to move VSS project from one location to another location
• Moving Visual SourceSafe projects or databases to a new location?
• Moving a project or projects from one database to another, while preserving the project’s history?

The procedures within each scenario may vary depending on the version of Visual SourceSafe you are running.

APPLIES TO

Microsoft Visual SourceSafe 5.0 Standard Edition

Microsoft Visual SourceSafe 6.0 Standard Edition

NOTE: This process is for Visual SourceSafe 5.0 or greater only.

Requirement:

1.   Use the SSARC and SSRESTOR utilities included in Visual SourceSafe 5.0. With these utilities, you can archive projects, preserve their histories, and restore them to a new database.

2.   You must have SourceSafe Admin privileges to use these utilities

3.   In order to restore a project successfully your archive must include the latest versions all the files in the project. If you use the -v switch with SSARC to archive off earlier versions of your files, you will not be able to restore that archive to a different database because it needs the later versions.

4.   Because the physical file names get renamed when you restore a project to a new database, it may be necessary to reconnect projects that are integrated with Visual SourceSafe.

Warning:

1.   always be very careful when archiving and deleting files

2.   Backing up source files is like voting, do it early and often (warning, this may not be legal in your jurisdiction).

3.   Test your backups out before you actually need them, avoid permanent deletes and keep copies in multiple locations.

There are two ways to Archive and Restore Project/Files from one database to another.

To Archive:

1.   Using To archive a database using Visual SourceSafe Administrator

2.   SSARC

Archival of a database allows you to:

* Save disk space on the Visual SourceSafe server or other machine hosting the database.
* Make the Show History command work more quickly.
* Transport files and projects between Visual SourceSafe databases, keeping history information intact.
* Provide a compressed file backing up all or part of a database.

How to Archive Visual SourceSafe (VSS) Project?

Method1: Using Visual SourceSafe Administrator:

The Visual SourceSafe Administrator program allows you to archive your databases using the Archive Projects command, and to restore them from backup using the Restore Projects command.

To archive a database using Visual SourceSafe Administrator:

1. Ensure that no one is using the database and that the ANALYZE utility will not run during the archive operation.
2. Open the database for which you want to archive information.
3. On the Archive menu of Visual SourceSafe Administrator, click Archive Projects.
4. In the Archive wizard, select the project(s) to archive, and click OK.
5. If there are additional projects to be archived, indicate this in step 1 of the wizard, and click Next when finished.
6. In step 2 of the wizard, specify how you want the project(s) to be archived, and click Next when finished. For each choice, you can use Browse to search for and select an archived file to overwrite the existing file.
7. In step 3 of the wizard, specify the versions for the data to archive, using the Version box.
8. Add a comment to the Comment box to document the archive operation.
9. Click Finish to complete the wizard. The archive is written to a *.ssa file in the directory that you have specified.

Method2: Using SSARC: –

Another way of making an archive is to use the Visual SourceSafe SSARC utility from the command line.
Examples

SSARC -d- -yadmin,password archive.ssa $/
Backup the entire default Sourcesafe database to archive.ssa, leaving the database exactly as it is.

SSARC -d- “-vlProduction Release” -yadmin,password -olog.txt archive.ssa $/Test

Backup everything since the version labelled ‘Production Release’ and create a log file with the results of the archiving process.

SSARC -d -x -yadmin,password archive.ssa “$/Project Global Domination” $/OtherProject

Description:  Archive, and delete the deleted files from two projects.

SSARC -i -yadmin,password -olog.txt “-cArchive Everything” archive.ssa $/

Description:  Archive the entire Sourcesafe database, while creating a log file, adding a comment, and running non-interactively, suitable for a scheduled task.
To Restore Project/Files from one database to another.

To Restore:

1.   Using To archive a database using Visual SourceSafe Administrator

2.   SSRESTOR

How to Restore Visual SourceSafe(VSS)Project?

Method 1: Using Visual SourceSafe Administrator

Visual SourceSafe Administrator supports restoration of a database from an archive using its Restore Projects command.

To restore a database using Visual SourceSafe Administrator

1. Make sure that no one is using the database and that the ANALYZE utility will not run during the restore operation.
2. On the Archive menu of Visual SourceSafe Administrator, click Restore Projects.
3. In the Restore wizard, enter or locate the archive file from which to restore, and then click Next.
4. In step 2 of the wizard, you can choose the items to restore to the database, and click Next to proceed.
5. Use step 3 of the wizard to specify options for restoring the selected items to the database.
6. Add a comment to the Comment box to document the restore operation.
7. Click Finish to complete the wizard.
8. Verify the database directories carefully to make sure that the restore operation has put the restored items where you intended.

Method 2: Using SSRESTOR Utility

Restores information from a previously created archive. If the restore operation attempts to create a duplicate file or project name, the operation fails. Visual SourcSafe also implements restore operations through its Restore wizard, available in Visual SourceSafe Administrator.
Examples

SSRESTOR -la -yadmin,password archive.ssa $/

Display a list of all of the files archived in archive.ssa.

SSRESTOR “-p$/Test 2” -sD:\newfolder\ -yadmin,password backup.ssa $/Test

Restores project $/Test to the database to a new location, $/Test 2, from the archive file backup.ssa, in a different Sourcesafe database.

The post How to copy VSS project from one VSS database to another one without loosing history appeared first on scmGalaxy.

As I have mentioned in a previous blog entry, I have come to love using ANT in my development environment. One of the things that I like about it is how well it integrates with my Subversion repository using SVNAnt. If you are not using either ANT or Subversion, you owe it to yourself and your team to check it out.

Here we’ll go over a simple build script that exports application files from the Subversion repository into a local folder in the CFEclipse project. You can then view the following entry on how to ftp that into your production/staging server.
First we need to make sure that your ANT install has the necessary SVNAnt jar files. You can download them here: http://subclipse.tigris.org/svnant.html. Once you unpack the svnant-1.0.0.zip file, you’ll find three jar files: svnant.jar, svnClientAdapter.jar, svnjavahl.jar. Place them on your
[ANTInstall]/lib* folder.

Once you have the jar files in place, you can define them in your build file’s property section like so:
<!– svnant lib –>
<property name=”svnant.lib” value=”lib” />
<property name=”svnant.jar” value=”${svnant.lib}/svnant.jar” />
<property name=”svnClientAdapter.jar” value=”${svnant.lib}/svnClientAdapter.jar” />
<property name=”svnjavahl.jar” value=”${svnant.lib}/svnjavahl.jar” />
Followed by this path definition after all your properties have been defined:

<!– path to the svnant libraries. Usually they will be located in ANT_HOME/lib –>
<path id=”project.classpath”>
<pathelement location=”${svnjavahl.jar}” />
<pathelement location=”${svnant.jar}” />
<pathelement location=”${svnClientAdapter.jar}” />
</path>

Now all you have left to do is add the following task definition:
<!– load the svn task –>
<taskdef resource=”svntask.properties” classpathref=”project.classpath”/>

Now you are all set! You can now call tasks like the following export target:

<!– define properties –>
<!– svn repo url –>
<property name=”svn.url” value=”http://[mysvnhost]/svn/repo/myprojectFiles/” />
<property name=”svn.exportPath” value=”[yourDirectory]:\\[pathToYourCFEclipseProject\\build” />

<target name=”svn.export”>
<echo message=”Exporting application files from svn repository:” />
<input message=”Please enter svn repo username:” addproperty=”svn.username” />
<input message=”Please enter svn repo password:” addproperty=”svn.password” />
<mkdir dir=”${svn.destPath}” />
<svn username=”${svn.username}” password=”${svn.password}”>
<export srcUrl=”${svn.url}” destPath=”${svn.exportPath}” revision=”HEAD” />
</svn>
<echo message=” … finished exporting files.” />
</target>

That’s it. No more running command line tasks to get your subversion commands. For additional info and other SVN tasks you can go to http://subclipse.tigris.org/svnant/svn.html

The post ANT Builds and Subversion (SVN) | Ant integration with Subversion guide appeared first on scmGalaxy.

The post How to run Remote Desktop Console by using command line? appeared first on scmGalaxy.