Tag: Instruction

Issues Compiling VS2010 solutions (with web projects) from Nant | MSB4064 error

by scmgalaxy KNantLeave a Comment on Issues Compiling VS2010 solutions (with web projects) from Nant | MSB4064 error

vs2010-compiling-issues

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

Tagged : / / / / / / / / / / / / / / / / / / /

JUnit 4 Test Logging Tips using SLF4J

by scmgalaxy KTesting ToolsLeave a Comment on JUnit 4 Test Logging Tips using SLF4J

junit-4-test-logging-using-slf4j

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/

Tagged : / / / / / / / / / / / / / / / / / /

Why and how to use Jetty in mission-critical production

by scmgalaxy KApp / Web ServersLeave a Comment on Why and how to use Jetty in mission-critical production

how-to-use-jetty

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/

Tagged : / / / / / / / / / / / / / / /

Installation and Configuration Guide: Bamboo

by scmgalaxy KConfiguration Management ToolsLeave a Comment on Installation and Configuration Guide: Bamboo

bamboo-installation-and-configuration

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

Tagged : / / / / / / / / / / / / / / / / / / / / /

How to copy VSS project from one VSS database to another one without loosing history

by scmgalaxy KVSSLeave a Comment on How to copy VSS project from one VSS database to another one without loosing history

copy-vss-project-from-one-vss-database-to-another-one-without-loosing-history

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.

Tagged : / / / / / / / / / / / / / / / / / / /

ANT Builds and Subversion (SVN) | Ant integration with Subversion guide

by scmgalaxy KApache Ant / SVN(Subversion)Leave a Comment on ANT Builds and Subversion (SVN) | Ant integration with Subversion guide

ant-builds-and-subversion

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

Tagged : / / / / / / / / / / / / / / / / / / /

How to run Remote Desktop Console by using command line?

by scmgalaxy KGeneralLeave a Comment on How to run Remote Desktop Console by using command line?

How to run Remote Desktop Console using command line
If you may want to run Desktop Console from a batch file, for example RDC over VPN, you can use mstsc /v:servername /console command.

Mstsc

Creates connections to terminal servers or other remote computers, edits an existing Remote Desktop Connection (.rdp) configuration file, and migrates legacy connection files that were created with Client Connection Manager to new .rdp connection files.

Syntax

mstsc.exe {ConnectionFile | /v:ServerName[:Port]} [/console] [/f] [/w:Width /h:Height]
mstsc.exe /edit”ConnectionFile”
mstsc.exe /migrate
Parameters

ConnectionFile

Specifies the name of an .rdp file for the connection.
/v:ServerName[:Port]
Specifies the remote computer and, optionally, the port number to which you want to connect.

/console
Connects to the console session of the specified Windows Server 2003 family operating system.

/f
Starts Remote Desktop connection in full-screen mode.

/w:Width /h:Height
Specifies the dimensions of the Remote Desktop screen.

/edit”ConnectionFile”
Opens the specified .rdp file for editing.

/migrate
Migrates legacy connection files that were created with Client Connection Manager to new .rdp connection files.

Remarks
* You must be an administrator on the server to which you are connecting to create a remote console connection.
* default.rdp is stored for each user as a hidden file in My Documents. User created .rdp files are stored by default in My Documents but can be moved anywhere.
Examples

To connect to the console session of a server, type:
mstsc /console

To open a file called filename.rdp for editing, type:
mstsc /edit filename.rdp
Tagged : / / / / / / / / / / / / / / / / / / / /