Modify SCAN IP address

Let us say the scan IP address is modified (without change in subnet mask) then follow these simple steps to reconfigure the scan

1. Add the additional ips to the /etc/hosts (of all hosts) (Optional only when DNS is not configured)
2. $ORACLE_HOME/bin/srvctl modify scan -scanname <scan-name>
   1. This command need to be run as ‘root‘
3. As grid user run:
   1. srvctl modify scan_listener -update
   2. srvctl stop scan_listener
   3. srvctl start scan_listener
   4. srvctl status scan_listener

lsnrctl start fails with TNS-00525: Insufficient privilege for operation

Oracle’s lsnrctl start command failed with below error:

TNS-12555: TNS:permission denied
TNS-12560: TNS:protocol adapter error
TNS-00525: Insufficient privilege for operation
Linux Error: 1: Operation not permitted

Solution is to remove files (socket files) under /var/tmp/.oracle; and retry

More Info: These are the socket files created by the lsnrctl when it runs. To find out what files are used by the failing command run :

> strace -aef lsnrctl status LISTENER 

access("/etc/ld.so.preload", R_OK)      = -1 ENOENT (No such file or directory)
access("/etc/listener.ora", F_OK)       = -1 ENOENT (No such file or directory)
access("/u02/app/oracle/product/12.1.0/dbhome_1/network/admin/listener.ora", F_OK) = -1 ENOENT (No such file or directory)
access("/u02/app/oracle/product/12.1.0/dbhome_1/network/admin/sqlnet.ora", F_OK) = -1 ENOENT (No such file or directory)
access("/var/tmp/.oracle", F_OK)        = 0
access("/var/tmp/.oracle/s#9102.2", F_OK) = 0

How to enable proxy in Atom editor

You can configure the proxy for the Atom editor on Windows by modifying the file C:\Users\<your user>\.atom\.apmrc file.

1. Add the below content to this file

   https-proxy = http://server:port

   http-proxy = http://server:port

2. Exit Atom editor
3. Open Atom editor again.

NOTE that you should not modify C:\Users\<your user>\.atom\.apm\.apmrc file as this file is auto-generated and any changes to this file will be lost upon re-opening the Atom.

How to solve maven-publish error “… not yet able to resolve a dependency on a project with multiple different publications”

In a multi-project gradle build, it is obvious to define dependencies between projects as :

dependencies {
    compile project(':foo:bar')
}

However if you are using maven-publish plugin for publishing the artifacts and you are publishing more than one artifacts (i.e., have more than one MavenPublication defined) in a project, then you cannot mark that project as dependency for other subproject. This means if in above example, subproject ‘:foo:bar’ defines two MavenPublication (as below) then gradle fails to configure the project and fails with error as :

// This publication publishes artifacts generated by 'integTest' sourceSet and 'main' sourceSet.
publishing {
    publications {
        publishTestCode(MavenPublication) {
            artifactId project.name + '-' + integTestJar.appendix
            artifact integTestJar
        }
        publishMainCode(MavenPublication) {
            from components.java
        }
    }
 }

Publishing is not yet able to resolve a dependency on a project with multiple different publications

This is a known issue with gradle tracked in GRADLE-2966
The solution (or workaround) is to modify the publications in foo/bar/build.gradle as

// This publication publishes artifacts generated by 'integTest' sourceSet and 'main' sourceSet.
publishing {
    publications {
        publishTestCode(MavenPublication) {
            artifactId project.name + '-' + integTestJar.appendix
            artifact integTestJar
        }
        publishMainCode(MavenPublication) {
            artifactId project.name
            artifact jar
        }
    }
 }

Different ways to set gradle properties and its precedence

There are multiple ways to set a property (project property) in gradle.

The first and the very easy way to set is use the –project-property (or -P) option of the gradle command. Let us try that with a simple example. Create a build.gradle file with the below print statement.

println myprop

Run the below command and you should be getting output similar as seen below :

gradle  -Pmyprop=learning_gradle

learning_gradle
:help

Welcome to Gradle 1.11.

To run a build, run gradle <task> ...

To see a list of available tasks, run gradle tasks

To see a list of command-line options, run gradle --help

BUILD SUCCESSFUL

Total time: 4.87 secs

Now this is fairly simple and easy. But what if someone runs the build and forgets to set the property. What happens is shown below :

gradle

FAILURE: Build failed with an exception.

* Where:
Build file '/scratch/skgupta/git_storage/emdi/try.gradle' line: 2

* What went wrong:
A problem occurred evaluating root project 'emdi'.
> Could not find property 'myprop' on root project 'emdi'.

* Try:
Run with --stacktrace option to get the stack trace. Run with --info or --debug option to get more log output.

BUILD FAILED

Total time: 3.076 secs

Yes! gradle fails to run the build.

Setting the value permanently

Here is the second way to permanently store the variable inside the file itself. So lets modify our build.gradle to look something like :

myprop=learning_gradle
println myprop

Now you can run the gradle build without worry to set the property explicitly.

gradle.properties

Going a step further, gradle allows you to keep the data separate out of your code into a properties file named as gradle.properties. So to make the code look clean, we create gradle.properties under the same directory as build.gradle, and add the property, myprop there. The files would look like below

myprop=learning_gradle

println myprop

Precedence of evaluation

That solved your problem and in a neat way! But a month later, you realize you want to build differently based on the different values of myprop. So your build.gradle has grown like this :

if (myprop.equals("artifactory")) {
println "I will be building and publishing to artifactory."
}
else if (myprop.equals("maven") {
println "I will build and publish to local maven repository."
}

Now you always want to publish to local maven repository unless otherwise your code is tested locally and ready to be published to artifactory.

Manually

What would you do ?  Set the myprop value to maven in the gradle.properties, and when ready to publish to artifactory change it to ‘artifactory’.

And remember to revert back the value to ‘maven’ so that you don’t commit this change to your version control system and make ‘artifactory’ as default.

This is so much human error prone!

Command line option

Why not try the –project-property option we used earlier to override the value in gradle.properties. Let us try. Set the value of myprop to maven and run this command:

[skgupta@slc03psl emdi]$ gradle -b try.gradle -P myprop=artifactory
I will be building and publishing to artifactory.
:help

Welcome to Gradle 1.11.

To run a build, run gradle <task> ...

To see a list of available tasks, run gradle tasks

To see a list of command-line options, run gradle --help

BUILD SUCCESSFUL

Total time: 4.78 secs

Environment variable

Gradle also provides an environment variable template which can be used to override values defined in the gradle.properties. Any environment variable set with prefix ORG_GRADLE_PROJECT_ will be made available as gradle property in the project.

setenv ORG_GRADLE_PROJECT_myprop artifactory

[skgupta@skgupta-lap emdi]$ gradle
I will be building and publishing to artifactory.
:help

Welcome to Gradle 1.11.

To run a build, run gradle <task> ...

To see a list of available tasks, run gradle tasks

To see a list of command-line options, run gradle --help

BUILD SUCCESSFUL

Total time: 4.78 secs

Command line property Vs Environment variable.

That said, what if you set both environment variable and command line, when you also have value set in gradle.properties; The answer is value set in command line will take precedence over both environment variable and the gradle.properties

Evaluation Precedence

So the evaluation of gradle property value goes as :

1. Values in gradle.properties are evaluated first
   1. If this is a multi-project build, the subproject’s gradle.properties are evaluated next.
2. If there is environment variable matching prefix, ORG_GRADLE_PROJECT_, it will be converted to gradle property and overrides any existing property value.
3. Project properties set from command line are evaluated next and if the property exists from step 1 and step 2 their values will be overridden
   1. If same property is set multiple times in command line, then last set value will be used.
4. Lastly and most important, if you are setting the property inside the build.gradle, that will be the final value of the property.

Include exact version of dependency in pom

Gradle’s maven-publish plugin by default generates the pom file with the dependency information exactly as specified in the configuration. Consider the below dependencies{} configuration for compiling a java project.

dependencies {
compile group:'com.yourcompany.group', name:'foo', version: '1.0+'<br />
}

The pom file generated will look like:

<!-- other xml content for pom-default.xml -->
<dependencies>
    <dependency>
        <groupId>com.yourcompany.group</groupId>
        <name>foo</name>
        <version>1.0+</version>
        <scope>runtime</scope>
    </dependency>
</dependencies>

Problem
The above solution works fine as long as my code compiled using 1.0.X version of foo.jar is compatible and works with 1.0.Y version of foo.jar, where Y > X; Note here that the project code is not being compiled again using 1.0.Y version of foo.jar. It is just that because the pom file has version information as ‘1.0+’, gradle would pull 1.0.Y instead of 1.0.X, which MAY result in failure.

Solution
The solution here is to generate the pom file with exact version, instead of dynamic version. So if during build, gradle evaluates the compile dependency to be 1.0.1 version of foo.jar, exactly same must be written in the generated pom file. The pom file published must appear like below:

<!-- other xml content for pom-default.xml -->
<dependencies>
    <dependency>
        <groupId>com.yourcompany.group</groupId>
        <name>foo</name>
        <version>1.0.1</version>
        <scope>runtime</scope>
    </dependency>
</dependencies>

How to specify exact version ?
maven-publish does not provide any configuration to use exact version in the pom xml file. Based on the Gradle API, here is a solution which works :

 

publishing {
    publications {
        myPublicationName(MavenPublication) {
            artifact jar
            /* Adding all depenencies config into the pom.xml */
            pom.withXml { XmlProvider xmlProvider ->
                def dependencies = asNode().appendNode('dependencies')
                Configuration runtimeConfiguration = project.configurations.getByName('compile')
                runtimeConfiguration.getResolvedConfiguration().getFirstLevelModuleDependencies().each {
                    def dependency = dependencies.appendNode('dependency')
                    dependency.appendNode('groupId', it.moduleGroup)
                    dependency.appendNode('artifactId', it.moduleName)
                    dependency.appendNode('version', it.moduleVersion)
               }
           }
        }
    }
}

Solution 2
There is another alternate solution I found later here in nebula plugin

Find the superconfigurations for the gradle configuration

Generally gradle’s configurations are extended from other configurations. For example in gradle’s java, the plugin configuration,  runtime extends the configuration compile. Similarly testRuntime extends both runtime and testCompile.

What is extending of configuration

A configuration can extend from one or more existing configurations. The configurations from which this configuration extends are called super configurations. By extending, a configuration you get all the dependencies of the superconfiguration. For example, when runtime configuration extends compile configuration, it gets all the configurations (dependencies, etc) of compile configuration instance. Thus extending configuration helps in reusing the dependency configuration efficiently.

Find the superconfiguration

Gradle’s Configuration API provides getExtendsFrom API which returns a set of super-configurations of this configuration.Here is a simple gradle task to print the names of the super-configuration of testRuntime configuration.

task printSuperConfigs {
    configurations.testRuntime.extendsFrom.each { 
        println it.name
    }
}

Find if an option exist in select or not

Here is the soluton to determine if the given option exist in the page (select item) or not

public boolean isSelectOptionPresent(WebDriver webdriver, String selectLocator, String optionToCheck) {
    if (webdriver == null) {
        throw new NullPointerException("WebDriver instance is null.");
    }

    if (null == optionToCheck || optionToCheck.isEmpty()) {
        throw new IllegalArgumentException("Invalid value
    }

    String[] availableOptions = webdriver.getSelectOptions(selectLocator);
    for(String option: availableOptions) {
        if (optionToCheck.equals(option) {
            return true;
        }
    }
    return false;
}

 

Validate group names in TestNG

I came across a requirement to validate the group names for the TestNG tests. The validation is required to ensure that the QA engineers tag their tests with only the list of published group names. Since group names in TestNG are Strings, which can accept any value, it becomes difficult to pick all tests belonging to a particular category unless the group names are validated.

For example, if there are 50,000 tests which can be grouped under three buckets, as ‘ui’ and ‘backend’ and ‘cli’, it is common for engineer to write various names for these buckets like ‘gui’, ‘UI’, ‘browser’, etc. To avoid such variations in naming, the validation of group name is required.

Here is the code to validate groups before running tests.

package com.example.testng.listeners;

import java.util.HashMap;
import java.util.List;
import java.util.Map;

import org.testng.IMethodInstance;
import org.testng.IMethodInterceptor;
import org.testng.ITestContext;
import org.testng.ITestNGMethod;

public class GroupValidator implements IMethodInterceptor {
	/**
	 * Checks if the group names of the list of tests being run are valid.
	 */
	@Override
	public List intercept(List methods,
			ITestContext context) {
		/* Put your valid group names in a map so that it is easy to validate
		 * One can also put the list in an external file and read it here.
		 */
		Map validGroupNames = new HashMap();
		validGroupNames.put("ui", true);
                validGroupNames.put("backend", true);
                validGroupNames.put("cli", true);
		for(IMethodInstance mInstance: methods) {
			ITestNGMethod method = mInstance.getMethod();
			if (method.isTest()) {
				System.out.println("Validating: " + method.getMethodName());
				for(String group : method.getGroups()) {
					if (! validGroupNames.containsKey(group)) {
						throw new RuntimeException("Group name validation failed. Cannoot run the tests");
					}
				}
			}
		}
		return methods;
	}
}

Add the above class as listener to your testng and it will validate the group names of the test methods.
NOTE that the code above allows a @Test without any group. The validation is only done when there is a group name specified.

Environment variables in gradle

Read environment variables
The requirement is access environment variable in gradle or any language is very common. To access environment variable value from gradle, you can use System.getenv() api. This is the java’s System class API which gradle allows you to access with script. Here is an example :

task printHome {
    println System.getenv("HOME")
}

gradle -q printHome
/home/skgupta