Maveen Central Repository & Download from Reposotoriy

When you build a Maven’s project, Maven will check your pom.xml file, to identify which dependency to download. First, Maven will get the dependency from your local repository Maven local repository, if not found, then get it from the default Maven central repository – http://repo1.maven.org/maven2/
This is how the Maven central repository website looks like


According to Apache Maven :

Downloading in Maven is triggered by a project declaring a dependency that is not present in the local repository (or for a SNAPSHOT, when the remote repository contains one that is newer). By default, Maven will download from the central repository.

In Maven, when you’re declared library does not exist either inlocal repository nor Maven center repository, the process will stop and output error messages to your Maven console.

1. Example

The org.jvnet.localizer is only available at Java.net repository.
pom.xml

    <dependency>
        <groupId>org.jvnet.localizer</groupId>
        <artifactId>localizer</artifactId>
        <version>1.8</version>
    </dependency>

When you build this Maven project, it will fail and output dependency not found error message.
Updated 12/12/2012
The org.jvnet.localizer is now available in Maven center repository.

2. Declare Java.net repository

To tell Maven to get the dependency from Java.net, you need to declared a remote repository in your pom.xml file like this :
pom.xml

    <repositories>
        <repository>
            <id>java.net</id>
            <url>https://maven.java.net/content/repositories/public/</url>
        </repository>
    </repositories>

Now, Maven’s dependency library look-up sequences is changed to :

1. Search in Maven local repository, if not found, go step 2, else exit.
2. Search in Maven central repository, if not found, go step 3, else exit.
3. Search in java.net Maven remote repository, if not found, prompt error message, else exit.
   

Maven’s dependency mechanism help to download all the necessary dependency libraries automatically, and maintain the version upgrade as well.

Changing the Maven Local Repository

The maven local repository is a local folder that is used to store all your project’s dependencies (plugin jars and other files which are downloaded by Maven). In simple, when you build a Maven project, all dependency files will be stored in your Maven local repository.
By default, Maven local repository is default to .m2 folder :

1. Unix/Mac OS X – ~/.m2
2. Windows – C:\Documents and Settings\{your-username}\.m2
   

1. Update Maven Local Repository

Normally, I will change the default local repository folder from default .m2 to another more meaningful name, for example, maven-repo.
Find {M2_HOME}\conf\setting.xml, update localRepository to something else.

{M2_HOME}\conf\setting.xml

<settings>
  <!-- localRepository
   | The path to the local repository maven will use to store artifacts.
   |
   | Default: ~/.m2/repository
  <localRepository>/path/to/local/repo</localRepository>
  -->
 
<localRepository>D:/maven_repo</localRepository>

2. Saved it

Done, your new Maven local repository is now changed to D:/maven_repo.

2. Saved it

Done, your new Maven local repository is now changed to D:/maven_repo.

Four simple reasons why Automation projects fail

Automated testing tools were supposed to make things easier. Getting them to execute pre-scripted tests — instead of relying on QA pros to carry out tests by hand — saves time and money. Moving to automated testing is a no-brainer, right?
In theory, the case for automated testing tools makes sense. And yet, in years of writing about software testing, I haven’t heard a single test manager say that automation saves time and money and boosts software quality.
What I hear over and over again are variants on the same theme: Test automation projects are far more challenging than they initially appear. They require scripting skills, which some testers lack. And while the initial stage of setting up tools and writing test scripts is the most demanding phase of an automation project, the most successful projects never really go on autopilot. They are never done.
Don’t get me wrong, I am not building a case against automated testing. Nor am I saying that automation doesn’t make sense for the long run. Virtually all QA pros I talk to believe it does, and they also say there is a certain inevitability about making the move to automation. Certain tests are better left to computers rather than to human testers.
In this installment of Quality Time, I discuss four reasons why automated testing projects are challenging. Understanding these challenges can help QA managers avoid some common pitfalls, accurately assess their readiness for automated testing and set more realistic expectations for upcoming projects.

Reason 1: Test automation projects are software development projects.
 Failure to fully grasp this notion is a recipe for disaster. You can’t set up automated testing tools without team members who can write code. As Lisa Crispin, a resident SearchSoftwareQuality expert, explained in her tip on devising a test automation strategy, “automating tests is software development. It must be done with the same care and thought that goes into writing production code.”
This poses a significant hurdle for testers who lack coding skills. That challenge is best met by mastering those skills, not by shying away from projects that demand them. “Learn how to script tests — learn a scripting language like Ruby,” Coveros CEO Jeff Payne said, addressing an audience of software testers at STAREAST 2013 earlier this year. Companies are looking for testers who can automate, and those without coding skills will ultimately be left behind, he said.

Reason 2: You can’t succeed at automated testing until you succeed at manual testing.
The success of any test project, manual or automated, ultimately hinges on testing the set of things most likely to deliver the highest-quality software to the user. If you don’t know what to test, you are not ready to automate the testing process, according to expert Mike Kelly, in our story, When to use manual vs. automated software testing tools: “I see a lot of teams focus on automation, as a cost-lowering technique, when what they really need to focus on first is testing the right things.”
Kelly’s commonsense rule reminds me of a rule art students are often asked to follow in painting 101: No abstract paintings until you prove your ability to paint realistically. In other words, don’t tackle the variation on the theme until you have mastered the theme itself.

Reason 3: Test automation does not mean testing with automation added.
A key misconception about test automation is that it’s easy, said test expert Hans Buwalda, addressing an audience of software testers in the “Lightning Strikes the Keynotes” session at STAREAST 2013. “But I am still waiting for my easy project,” said Buwalda, chief technology officer for software testing service firm LogiGear in San Mateo, Calif. He believes automated testing is harder than manual testing. You can’t simply add automated tests to an existing test process. Instead, you have to rethink your entire approach. Which tests are best automated? Which ones should remain manual? Answering those questions requires creative thinking, he said. “Don’t lose your creativity [when you move to automated testing],” he told the audience.

Reason 4: Avoid automated testing autopilot.

When teams successfully complete the initial stage of setting up automated testing, there is a tendency to keep on running the same tests over and over again. Test expert Robert Galen of RGalen Consulting Group in North Carolina, said this is a big mistake. Running more tests faster does not result in higher-quality software. Better software is the result of running the right tests and continually re-evaluating which tests are the right ones, Galen explained in our story, Test automation ROI commoditizes testers, hurts test organizations.
In other words, the most successful automated testing projects are never complete. You keep on asking which tests will help produce the best software, and then script them accordingly. This approach helps ensure success with automated testing tools. But when you start running the same old tests in autopilot mode, trouble lies ahead.

Code to Restart and Shutdown the System in QTP

strComputer = "dscp xxxxx“         ' Mention machine name / IP address

Set objWMIService = GetObject("winmgmts:{impersonationLevel=impersonate,(Shutdown)}!\\" & strComputer & "\root\cimv2")

Set colOperatingSystems = objWMIService.ExecQuery("Select * from Win32_OperatingSystem")

For Each objOperatingSystem In colOperatingSystems

    objOperatingSystem.Reboot()

//objOperatingSystem.Win32Shutdown(1)    ‘ “1” is for Shut Down -->for shudowning

Next

Code To Know Complete System Information In QTP

strComputer = "."

Set objWMIService = GetObject("winmgmts:" _

                        & "{impersonationLevel=impersonate}!\\" & strComputer & "\root\cimv2")

           

Set colSettings = objWMIService.ExecQuery _

                        ("Select * from Win32_OperatingSystem")

           

For Each objOperatingSystem in colSettings

            Msgbox "OS Name: " & objOperatingSystem.Name

            Msgbox "Version: " & objOperatingSystem.Version

            Msgbox "Service Pack: " & _

                                    objOperatingSystem.ServicePackMajorVersion _

                                                & "." & objOperatingSystem.ServicePackMinorVersion

            Msgbox "OS Manufacturer: " & objOperatingSystem.Manufacturer

            Msgbox "Windows Directory: " & _

                                    objOperatingSystem.WindowsDirectory

            Msgbox "Locale: " & objOperatingSystem.Locale

            Msgbox "Available Physical Memory: " & _

                                    objOperatingSystem.FreePhysicalMemory

            Msgbox "Total Virtual Memory: " & _

                                    objOperatingSystem.TotalVirtualMemorySize

            Msgbox "Available Virtual Memory: " & _

                                    objOperatingSystem.FreeVirtualMemory

            Msgbox "Size stored in paging files: " & _

                                    objOperatingSystem.SizeStoredInPagingFiles

Next

           

Set colSettings = objWMIService.ExecQuery _

                        ("Select * from Win32_ComputerSystem")

           

For Each objComputer in colSettings

            Msgbox "System Name: " & objComputer.Name

            Msgbox "System Manufacturer: " & objComputer.Manufacturer

            Msgbox "System Model: " & objComputer.Model

            Msgbox "Time Zone: " & objComputer.CurrentTimeZone

            Msgbox "Total Physical Memory: " & _

                                    objComputer.TotalPhysicalMemory

Next

           

Set colSettings = objWMIService.ExecQuery _

                        ("Select * from Win32_Processor")

           

For Each objProcessor in colSettings

            Msgbox "System Type: " & objProcessor.Architecture

            Msgbox "Processor: " & objProcessor.Description

Next

           

Set colSettings = objWMIService.ExecQuery _

                        ("Select * from Win32_BIOS")

           

For Each objBIOS in colSettings

            Msgbox "BIOS Version: " & objBIOS.Version

Next