Git clones git

Good morning folks,
And I hope that your morning as beautiful as mine, down there in Naples, Florida. I have found a plausible excuse to skip landscaping: share mine small findings with you.

I'm playing with the Bamboo server for another good story or rather few stories (main characters: SOA 12c, Bamboo, Maven, and Ant) and the very first built has failed with the error:

simple 18-Nov-2017 16:38:24 error: unknown switch 'c'
simple 18-Nov-2017 16:38:24 usage: git clone [options] [--] <repo> [<dir>]
simple 18-Nov-2017 16:38:24 
simple 18-Nov-2017 16:38:24     -v, --verbose         be more verbose
simple 18-Nov-2017 16:38:24     -q, --quiet           be more quiet
simple 18-Nov-2017 16:38:24     --progress            force progress reporting
simple 18-Nov-2017 16:38:24     -n, --no-checkout     don't create a checkout
simple 18-Nov-2017 16:38:24     --bare                create a bare repository
simple 18-Nov-2017 16:38:24     --mirror              create a mirror repository (implies bare)
simple 18-Nov-2017 16:38:24     -l, --local           to clone from a local repository
simple 18-Nov-2017 16:38:24     --no-hardlinks        don't use local hardlinks, always copy
simple 18-Nov-2017 16:38:24     -s, --shared          setup as shared repository
simple 18-Nov-2017 16:38:24     --recursive           initialize submodules in the clone
simple 18-Nov-2017 16:38:24     --template <path>     path the template repository
simple 18-Nov-2017 16:38:24     --reference <repo>    reference repository
simple 18-Nov-2017 16:38:24     -o, --origin <branch>
simple 18-Nov-2017 16:38:24                           use <branch> instead of 'origin' to track upstream
simple 18-Nov-2017 16:38:24     -b, --branch <branch>
simple 18-Nov-2017 16:38:24                           checkout <branch> instead of the remote's HEAD
simple 18-Nov-2017 16:38:24     -u, --upload-pack <path>
simple 18-Nov-2017 16:38:24                           path to git-upload-pack on the remote
simple 18-Nov-2017 16:38:24     --depth <depth>       create a shallow clone of that depth
simple 18-Nov-2017 16:38:24 
error 18-Nov-2017 16:38:24 Checkout to revision 1d00aad94cb91435c7099197965c3ef52828e80d has failed.

Obviously, Bamboo is not happy with the installed git command. So my the first thought was:

Ant: instant property file

Good time of the day my patient readers. Yesterday among the millions I saw the second big solar eclipse in my life. The first one I've watched through the soot-covered glass, this one I observed one through the DVR-R disk. The benefits of the progress as they are, aren't they?

Today I'm going show you a little workaround for the situation when you need a property file, but you can't afford it or don't want to keep sensitive information in the plain-text file on the file system. I have run into such issue with the SOA test automation. Oracle offers a set of the Ant tasks for the build, deploy, and test composites. Although, test task requires JNDI properties in form of the property file.

You could create such files one for every target environment, but I foresee without a crystal ball your administrators and security team will be quite unhappy with that. I have tried to substitute the properties from the file, but it doesn't work at all. Test task still wants to read property file.
The next my thought was: if I can't store the file, but I need one, what if I create one at run-time and drop it when the task is completed. So there are such Ant commands and it works with the SOA automation just fine.

<!-- create temporary file for the JNDI propeties -->
<tempfile property="jndi.properties" prefix="jndi" 
                  suffix=".properties" deleteonexit="true"/>
      
<!-- Add properties to the temporary file -->      
<propertyfile file="${jndi.properties}">
 <entry key="java.naming.factory.initial"
                   value="weblogic.jndi.WLInitialContextFactory"/>
 <entry key="java.naming.provider.url"
                   value='${test.target.url}/soa-infra'/>
 <entry key="java.naming.security.principal" value="${user}"/>
 <entry key="java.naming.security.credentials" value="${password}"/>
 <entry key="dedicated.connection" value="true"/>
 <entry key="dedicated.rmicontext" value="true"/>
</propertyfile>  

The task tempfile creates a new empty file. You can specify prefix and suffix and some other attributes, Task updates or creates the specified property (jndi.property in the example) with the file name and path as a value. The attribute deleteonexit helps you with the temporary file elimination.Temporary file disappears when the task is done.

The propertyfile task populates our temporary file with the properties. Task writes all its' children entries to the file. Don't forget to check task documentation, it can do country mile more than just store properties in the files.

Now you can use your temporary property file as a parameter for the SOA test tasks or for any other purposes where you need one.