How to access all Java system properties directly?

java-system-properties

You could access all Java system properties directly via ${name}, e.g.

${user.name}, ${user.dir}, ${user.home}, …

You could read environment properties and use them

  <properties environment=”env”/>

  ${env.ENVIRONMENT_VARIABLE}

e.g.

  ${env.USERPROFILE}, ${env.USERNAME}, ${env.PATH}

You could pass properties during Ants start

  ant -Dname=value -Danothername=anothervalue

Also you Ant could ask for input

  <input addproperty=”foo”/>

  ${foo}

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

SET UNIX HOME DIR PROPERTY using ANT

set-unix-home-dir-property-using-ant

Set properties HOMEDIR in build.xml which will be set through user logged in the current system..

Example:

<project name=”test” default=”myhome”>

    <property environment=”env”/>

    <target name=”myhome”>

        <echo message=”My home is ${env.HOME}”/>

    </target>

</project>

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

How to use ant Script to Reset BuildNumber?

To use this code, you need to have the file build.number containging:

major.number=1

minor.number=0
hotfix.number=0

revision.number=0
continuous.number=0

Then the following 3 targets:

  <taskdef resource=”net/sf/antcontrib/antlib.xml”/>
<taskdef name=”unset” classname=”ise.antelope.tasks.Unset”/>

    <target name=”initBuildNum” description=”Get current build number properties”>
<property file=”build.number”/>
<var name=”next.major” value=”${major.number}”/>
<var name=”next.minor” value=”${minor.number}”/>
<var name=”next.hotfix” value=”${hotfix.number}”/>
<var name=”next.revision” value=”${revision.number}”/>
<var name=”next.continuous” value=”${continuous.number}”/>
</target>

    <target name=”getBuildNum”>
<switch value=”${increment}”>
<case value=”rebuild”/>
<case value=”major”>
<!–Increment major, minor to 1, hotfix to 0, revision to 1–>
<math result=”next.major” operand1=”${next.major}” operation=”+” operand2=”1″ datatype=”int”/>
<var name=”next.minor” value=”1″ />
<var name=”next.hotfix” value=”0″ />
<var name=”next.revision” value=”1″ />
</case>
<case value=”minor”>
<!–Major stays the same, minor increments, hotfix goes to 0, revision to 1–>
<math result=”next.minor” operand1=”${next.minor}” operation=”+” operand2=”1″ datatype=”int”/>
<var name=”next.hotfix” value=”0″ />
<var name=”next.revision” value=”1″ />
</case>
<case value=”hotfix”>
<!–Major stays the same, minor stays the same, hotfix increments, revision goes to 1–>
<math result=”next.hotfix” operand1=”${next.hotfix}” operation=”+” operand2=”1″ datatype=”int”/>
<var name=”next.revision” value=”1″ />
</case>
<case value=”continuous”>
<!–For continuous integration don’t change anything but 5th build digit–>
<math result=”next.continuous” operand1=”${next.continuous}” operation=”+” operand2=”1″ datatype=”int”/>
</case>
<case value=”contReset”>
<!–Continuous build, but they want the 5th digit reset (i.e. new week)–>
<var name=”next.continuous” value=”1″/>
</case>
<default>
<!–Update revision number only, they didn’t ask for anything special–>
<math result=”next.revision” operand1=”${next.revision}” operation=”+” operand2=”1″ datatype=”int”/>
</default>
</switch>
</target>

    <target name=”setBuildNumber” depends=”initBuildNum,getBuildNum”>
<!–First save the build number properties–>
<propertyfile file=”build.number”>
<entry key=”major.number” value=”${next.major}”/>
<entry key=”minor.number” value=”${next.minor}”/>
<entry key=”hotfix.number” value=”${next.hotfix}”/>
<entry key=”revision.number” value=”${next.revision}”/>
<entry key=”continuous.number” value=”${next.continuous}”/>
</propertyfile>
<!–Unset the properties so that we can change their values–>
<unset name=”major.number”/>
<unset name=”minor.number”/>
<unset name=”hotfix.number”/>
<unset name=”revision.number”/>
<unset name=”continuous.number”/>
<property file=”build.number”/>
<!–set the full.buildnumber property to be used by the build–>
<if>
<or>
<equals arg1=”${increment}” arg2=”continuous”/>
<equals arg1=”${increment}” arg2=”contReset”/>
</or>
<then>
<property name=”full.buildnumber” value=”${major.number}.${minor.number}.${hotfix.number}.${revision.number}.${continuous.number}”/>
</then>
<else>
<property name=”full.buildnumber” value=”${major.number}.${minor.number}.${hotfix.number}.${revision.number}”/>
</else>
</if>
<echo>${full.buildnumber}</echo>
</target>

Add these three targets to your ant script.  Put a “depends” to “setBuildNumber” at invocation of your ant script.  Depending on what you want to do, you’ll set different vars on the way in as follows:

Usage:
To build and increment revision number only:
>Ant
To move to the next major build number:
>Ant -Dincrement=major
To move to the next minor build number:
>Ant -Dincrement=minor
To move to the next hotfix build number:
>Ant -Dincrement=hotfix

  To do a continuous integration build incrementing 5th digit:
>Ant -Dincrement=continuous
To do a continuous integration build resetting 5th digit to 1:
>Ant -Dincrement=contReset

Note that if you don’t set the value of increment, the build number will only have 4 digits.  The var that holds the build number after this is called is ${full.buildnumber}.

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

WinZip Command Line | WinZip Command line CheatSheet – Reference

winzip-command-line

The default action is to add or replace zipfile entries from list, which can include the special name – to compress standard input. If zipfile and list are omitted, zip compresses stdin to stdout.

 -f   freshen: only changed files                   -u   update: only changed or new files

 -d   delete entries in zipfile                         -m   move into zipfile (delete files)

 -k   force MSDOS (8+3) file names           -g   allow growing existing zipfile

 -r   recurse into directories                          -j   junk (don’t record) directory names

 -0   store only                                                   -l   convert LF to CR LF (-ll CR LF to LF)

 -1   compress faster                                       -9   compress better

 -q   quiet operation                                        -v   verbose operation/print version info

 -c   add one-line comments                        -z   add zipfile comment

 -b   use “path” for temp file                        -t   only do files after “mmddyy”

 -@   read names from stdin                        -o   make zipfile as old as latest entry

 -x   exclude the following names              -i   include only the following names

 -F   fix zipfile (-FF try harder)                      -D   do not add directory entries

 -A   adjust self-extracting exe                    -J   junk zip file prefix (unzipsfx)

 -T   test zipfile integrity                                 -X   eXclude eXtra file attributes

 -$   include volume label                              -S   include system and hidden files

 -h   show this help                                          -n   don’t compress these suffixes

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

Ant : Ant-Contrib – Introduction and Installation Process/Guide

ant-ant-contrib

What is Ant-Contrib Tasks?

The Ant-Contrib project provides a collection of tasks and types that extend Ant to work as a scripting language as well as a build tool.

Many developers want more from Ant than the ability to define dependencies. Ant-Contrib adds extra functionality to let Ant act more like a programming lanuage. Most tasks require Ant 1.5 or higher to work properly.

“Ant-Contrib Tasks” is an “independent third party” library of useful additional procedural and utility ApacheAnt Tasks.

 

Pre-Requisite:

First you must install Apache Ant itself, most of the Ant-Contrib tasks require Ant 1.5 or higher to work properly. You can download Ant from Apache.

Download Link: http://sourceforge.net/project/showfiles.php?group_id=36177

“Ant-Contrib Tasks” is also TWO independent ant task libraries:

Installation

See the cc tasks for installation instructions for cpptasks. To install ant-contrib:

  1. Copy ant-contrib-0.3.jar to the lib directory of your Ant installation. If you want to use one of the tasks in your own project, add the lines
2.  <taskdef resource="net/sf/antcontrib/antcontrib.properties"/>

to your build file.

  1. Keep ant-contrib-0.3.jar in a separate location. You now have to tell Ant explicitly where to find it (say in /usr/share/java/lib):
4.  <taskdef resource="net/sf/antcontrib/antcontrib.properties">
5.    <classpath>
6.      <pathelement location="/usr/share/java/lib/ant-contrib-0.3.jar"/>
7.    </classpath>
8.  </taskdef>
 
 
Manual and weblinks:
http://ant-contrib.sourceforge.net/ant-contrib/manual/tasks/index.html
http://sourceforge.net/projects/ant-contrib
http://sourceforge.net/project/showfiles.php?group_id=36177
 
Tagged : / / / / / / / / / / / / / /

Graphical Representation of ANT | Ant Flow Chart | Visual representation

1.      

ant-graphical-representation

Grand: Graphical Representation of ANT Dependencies:

Grand is a tool to create visual representation of ant target dependencies. It differs from tools like Vizant or AntGraph by a totally different approach, relying on the Ant API rather than parsing directly the XML files. This enables Grand to provide some nifty features such as the support of the ant 1.6.x tasks like import or subant.

 

From a user point of view, Grand can be used either as a standalone application with a nice GUI or as an Ant task generated a dot” file. In this latter case a post processing using Graphviz is required to get the actual graph.

 

Features

finds both static (using the depends attribute) and dynamic (created by tasks like ant or antcall) dependencies,

supports ant 1.6 import statement,

supports most dependencies generating tasks: ant, antcall, subant and foreach, runtarget from antcontrib,

available as both as an easy to install (one single jar, no extra dependency) ant task or a stand alone application with a nice SWT GUI,

the GUI can open several files simultaneously and includes some inter files navigation features.

 

Link: http://www.ggtools.net/grand/

 

2.       Vizant – Ant task to visualize buildfile

Vizant is an Apache Ant task to create Graphviz DOT source code from an Ant buildfile. The image created from the DOT source code shows the targets dependency.

Link: http://vizant.sourceforge.net/

 

3.       giant

giANT allows existing ant build scripts to be read and displayed as a connected graph of target nodes connected by dependency nodes.

Currently giANT can only read and display ANT scripts. The next stage of development will be to allow creation and deletion of targets through interaction with the diagram and editing of the selected target.

 

Main development tasks are –

 

·         Improve initial layout algorithm

·         Embed a simple syntax highlighter for editing target text

·         Allow amendment of target name via diagram.

·         Allow save of modified ant file

·         giANT makes use of the GEF project for rendering diagrams

Link: http://giant.tigris.org/

 

More can be found in http://ant.apache.org/external.html

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

Ant’s built-in properties – Ant Properties Guide

ants-built-in-properties

This is a simple example that illustrates how to find the basedir name, file name, project name, ant version, java version, operating system name, ant home directory name, java home directory name, user home directory name and user name. Ant provides you with certain built-in properties that you may find useful during your build process. The following table shows the property name and it’s description.

 

Ant’s built-in properties:

Property                                                              Description

 

ant.file                                                                  The absolute path of the build file

 

ant.project.name                                            The name of the project as set in the <project> element’s name attribute.

 

ant.home                                                            The root directory of ant

 

ant.version                                                         The version of this ant installation. This is not just the version number and includes information such as the compilation date.

 

ant.java.version                                               The version of the java that ant uses

 

basedir                                                                 The absolute path of the project

 

os.name                                                              Operating system name

 

java.home                                                          Java home directory name

 

user.home                                                          User directory name

 

user.name                                                          User name                         

 

 

Example Program:

<?xml version=”1.0″?>

 

<project name=”AntProperties” default=”echo” basedir=”.”>

 

  <target name=”echo”>

  <echo message=”The operating system is: ${os.name}”/> 

 

  <!– absolute path of the project. –>

  <echo message=”The home path is: ${basedir}”/>

 

  <!– absolute path of the build file. –>

  <echo message=”The file name is: ${ant.file}”/>

 

  <!– root directory of ant. –>

  <echo message=”The Project name is: ${ant.project.name}”/>

  <echo message=”The Ant home directory is: ${ant.home}”/>

  <echo message=”The Ant version is: ${ant.version}”/>

  <echo message=”The Java version is: ${ant.java.version}”/>

 

  <!– System properties. –>

  <echo message=”The Java home directory is: ${java.home}”/>

  <echo message=”The User home directory is: ${user.home}”/>

  <echo message=”The User name is: ${user.name}”/>

  </target>

 

</project>

 

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

How to Resolve Apache Ant Copy and Include Issues – Ant Guide

issues-in-apache-ant

Question: Why Copy in ant is not working if I am putting includes separately?
Ant version: Apache Ant version 1.5.4 compiled on January 8 2005.

Program 1 is not working and Program 2 is working.  I guess both programs are correct..
Program1:
<copy todir=”${Temp}/uaw/Uaw_compilescripts”>
<fileset dir=”${SVNCheckout}/scripts/compilescripts” >
<include name=”BuildSh,Compsh,vsamc,buildc.sh,script,compl2,main.sh,makefile,makepl1,script”/>

</fileset>
</copy>

Program2:

<copy todir=”${Temp}/uaw/Uaw_compilescripts”>
<fileset dir=”${SVNCheckout}/scripts/compilescripts” includes=”BuildSh,Compsh,vsamc,buildc.sh,script,compl2,main.sh,makefile,makepl1,script” />
</copy>

ANSWER

Because <include name=”> does not split up the name using ‘,’
You need to have :
<include name=”BuildSh”/>
<include name=”Compsh”/>
<include name=”vsamc”/>

etc..

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

Copy and Include Issues in Apache Ant | Ant Troubleshooting Guide

copy-issue-in-apache-ant

Question: Why Copy in ant is not working if I am putting includes separately?

Ant version: Apache Ant version 1.5.4 compiled on January 8 2005.

Program 1 is not working and Program 2 is working.  I guess both programs are correct..

Program1:

      <copy todir=”${Temp}/uaw/Uaw_compilescripts”>

            <fileset dir=”${SVNCheckout}/scripts/compilescripts” >

                  <include name=”BuildSh,Compsh,vsamc,buildc.sh,script,compl2,main.sh,makefile,makepl1,script”/>

                 

            </fileset>

      </copy>

Program2:

     

      <copy todir=“${Temp}/uaw/Uaw_compilescripts”>

            <fileset dir=“${SVNCheckout}/scripts/compilescripts” includes=“BuildSh,Compsh,vsamc,buildc.sh,script,compl2,main.sh,makefile,makepl1,script” />

      </copy>

 

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

“Cheat Sheet” of Perforce command-line | Perforce command-line Guide

perforce-command-line-cheatsheet

A way to remember data-mining commands
The following is a set of questions that will be used during the Perforce training to remind students which “data-mining” commands to use for specific situations. Perforce is a terrific tool, but it’s easy to get lost in the choices between “p4 files” and “p4 changes” and “p4 filelog” and so on. This list can help a great deal.

the question starts with…
the answer starts with…
Examples
“What are the filenames that…?” “p4 files….” p4 files //depot/…#have
p4 have
p4 files //depot/…
(which is the same as)
p4 files //depot/…#head
p4 files //depot/…@label
p4 files //depot/…@client
p4 files //depot/…@2001/02/12
p4 files //depot/…@1541
“What are the differences between the
workspace copy of XXX and the depot
copy of XXX?”
“p4 diff …” • p4 diff file.c
• p4 diff file.c#2
• p4 diff file.c#head
• p4 diff //… or “p4 diff”
• p4 diff –se
“What are the differences the depot copy
of ______ and the depot copy of ______?”
“p4 diff2 ….” • p4 diff2 file1.c file2.c
• p4 diff2 file1.c#1 file.c#2
• p4 diff2 dir1/… dir2/…
• p4 diff2 dir1/…@now dir1/…@2000/01/02
“Tell me everything about changelist #___.” “p4 describe” • p4 describe 1231
“What’s a list of changelists that….?” “p4 changes….” • p4 changes
(which is the same as)
p4 changes //…
• p4 changes file.c
• p4 changes –i file.c | grep 1255
• p4 changes //depot/…@label1,@label2

 

“Cheat Sheet” of Perforce command-line
The following list is a set of helpful commands that anyone can run, but that the person administering the Perforce codelines will
be using a lot. They’re included here for quick reference.

Function
Commands
Create a new workspace…
1. That’s modeled after the
“1.0dev” workspace – same
mappings
2. That’s the Perforce defaults,
Set the workspace name using “p4 set” or in the environment. Then run:
1. p4 client –t 1.0dev
2. p4 client
Retrieve a file as of
1. Now (head revision)
2. April 15, 2000
3. Label “xyz”
4. Changelist 123456
5. the revision that client
“jab.work” has retrieved
6. The revision you had before
accidently bashing your disk
Use “p4 sync” as follows:
1. p4 sync file.java
p4 sync file.java#head
p4 sync file.java@now
2. p4 sync file.java@2000/04/15
3. p4 sync file.java@xyz
4. p4 sync file.java@123456
5. p4 sync file.java@jab.work
6. p4 sync –f file.java#have
See “p4 help revisions” for more examples. Note that anywhere that “file.java” is used in these
examples, a full pathname (“c:\work\projects\file.java”) or depot name
(“//depot/rel_218/base/projects/file.java”) could be used.
Open a file for:
1. add
2. edit
3. delete
And then publish the change to others
.
Use “p4” with the appropriate verb:
• p4 add file.java
• p4 edit file.java
• p4 delete file.java
Then “p4 submit” to publish it
What have I changed in the files I
have opened for edit?
• p4 diff (for all opened files)
• p4 diff file1 file2 (for specific files)
Undo a checkout. If the file hasn’t been submitted yet:
• Use “p4 revert –a” to find all opened files that have no modifications – it’ll revert those.
• Use “p4 revert file.java” to revert an individual file.
• Use “p4 revert //…” to revert all files.
Remember that “p4 revert” is irreversible.
If the file has been submitted, you’ll need to open the file for edit and check in a prior revision.
Use very good change descriptions to say what you did and why.
Interrupt your work to edit a single
file and check it in, without any other
disruptions. (You’re hacking Java and
someone needs a “relnotes.txt”
updated ASAP to issue a release.)
Two ways:
1. Edit the file and submit only that file.
• p4 edit relnotes.txt
• do the modifications
• p4 submit relnotes.txt
2. Make a new changelist to manage just that change.
• p4 change
remove all the files in this change from the Files: section, it’ll create an empty
change.
• p4 edit –c XXX relnotes.txt
where XXX is the change number in the previous step
• p4 submit –c XXX
Publish your work to others “p4 submit”
Compress the data on the net
because you have a slow modem line
between your workspace and the
server.
Run “p4 client” for your workspace, and change the options from “nocompress” to “compress”.
(Read “p4 help client” for details.)
Get the list of…
1. All changelists applied to the
base codeline
2. … to the prodxyz codeline
3. … to the prodxyz codeline,
including those applied
originally to another codeline
and integrated into prodxyz
4. All revisions of file.java
Use “p4 changes” or “p4 filelog” as follows:
1. p4 changes //depot/eng/…
2. p4 changes //depot/eng/prodxyz/…
3. p4 changes –i //depot/eng/prodxyz/…
4. p4 filelog file.java
Push … from the base codeline
(“prodxyz”) to the 1.0.1 codeline
(“prodxyz-1.0.1”):
1. Push change #1232
2. From change #129 to #134
3. all changes in the base
codeline
Use “p4 integrate –b prodxyz-1.0.1” as the place to start, in each case:
1. p4 integ –b prodxyz-1.0.1 //…@=1232
2. p4 integ –b prodxyz-1.0.1 //…@129,@134
3. p4 integ –b prodxyz-1.0.1 (no additional args)
Note that this assumes that the named branch specification “prodxyz-1.0.1” has been created
by your project lead or administrator using “p4 branch”.
Push … from the prodxyz-1.0.1
codeline to the base (“prodxyz”)
codeline:
1. Push change #1235
2. From change #127 to #128
3. all changes in the base
Use “p4 integrate –b prodxyz-1.0.1” as the place to start, in each case:
1. p4 integ –b prodxyz-1.0.1 –r @=1235
2. p4 integ –b prodxyz-1.0.1 –r //…@127,@128
3. p4 integ –b prodxyz-1.0.1 –r (no additional args)
The “-r” reverses the order of source/target in that named branch specification.
Note that for the ‘selective integration’ cases, you’ll want to be VERY CAUTIOUS of ‘accept
theirs’.
Show the ‘diff’ between the
prodxyz-1.0.1 codeline and its
parent
“p4 diff2 –b prodxyz-1.0.1” (This works because “prodxyz” is the name of the branch
specification, not because “prodxyz” is part of “//depot/prodxyz/…”)
What branches do I have? If you use “p4 branch” to create branch specifications and use them consistently, then “p4
branches” provides this info.
How do I make a new codeline
named prodxyz-2.0?
There are several steps:
1. Make a named branch specification. Save it.
• “p4 prodxyz-2.0”
• if you want to exactly imitate another branch (e.g. prodxyz), use
“p4 branch –o prodxyz-1.0.1 > tmp” to capture the output, edit this temporary file
and replace the “1.0.1” references with “2.0”, then run “p4 branch –i < tmp”.
2. Run the “p4 integrate” command to populate this new codeline. Submit the change.
• p4 integrate –b prodxyz-2.0
or, if you want to push content as of a certain label (e.g. “xyz”) from the parent,
p4 integrate –b prodxyz-2.0 //…@xyz
• p4 submit
3. Send e-mail telling everyone about this codeline and what it’s used for.
Put everything onto a laptop, you’re
going to the beach and want to hack.
(This assumes that you won’t be
connected to a net while away.)
There are several steps:
1. Connect the laptop to the net.
2. Run “p4 sync” to populate the source onto the laptop.
3. Leave for the beach.
4. While editing, use “chmod” or “attrib” to make the files writeable. Make your changes.
5. Get back to work, reconnect to the net.
6. Run the following commands to tell you what’s updated and open them for
add/edit/delete:
• p4 diff –se | p4 –x – edit
• p4 diff –sd | p4 –x – delete
• find . –type f –print | p4 –x – add
Then inspect what’s opened (“p4 opened”) and what you’ve changed (“p4 diff”). Submit or
revert as appropriate.
Run a checkpoint “p4 admin checkpoint” – only an administrator can run this. (An administrator has “super”
permissions in the “p4 protect” data.)
Be sure to back up the checkpoint, the current journal, and each of the “depot” directories on
the server machine!
Change the security/permissions “p4 protect” – only an administrator can run this.
Also…
“p4 protects” – used in 2006.1 and later to TELL you your permissions .
Make a label It’s a two-step process:
1. Make the label using “p4 label xxx”
2. Populate it using “p4 labelsync –l xxx”
or if you have a specific list of files,
“p4 labelsync –l xxx file1 file2 …”.
Copy a label’s contents to another
label. Assume that the existing label
is “xxx” and the new label is to be
“abc”.
Again, a two-step process:
1. Make the label using “p4 label –t xxx abc”
2. Populate it using
“p4 labelsync –l abc //…@xxx”
Note that the second step is really identical to the second step in the previous question – we’re
just specifying a very specific list of revisions [of files] to include in the new label.
(Also…
In 2005.1 and later, “p4 tag” will make the label and apply it to a set of files.)

 

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