I am writing a file path to a property file using ant property file task,below is my code snippet of ant
<propertyfile file="WeblogicDomain.properties" comment="Weblogic Properties Below">
<entry key="path" value="C:/bea"/>
</propertyfile>
In the output properties i.e.., WeblogicDomain.properties file the path varies as shown below
path=C\:/bea
i was puzzled with this, is there a solution to resolve this & place the exact path as mentioned in source code
My ant version : 1.6.5
This is how java.util.Properties works. The colon : and equals = characters are used as name value delimiters so colons are escaped when part of the key or value and not the delimiter.
See java.util.Properties.load(Reader) for more.
Related
I have two properties files
File 1 : Template.properties
k1=v1
k2=v2
k3=v3
k4=v4
k5=v5
File 2 : New.properties
k1=v11
k2=v22
k3=v33
k4=v44
k5=v55
k6=v66
k7=v77
I want to overwrite values of Template.properties with the values of New.properties and I don't want k6 and k7 in Template. How can i achieve this using ANT macro?
Please help.
Use a copy task with a filterset. The template file should have # around the replaceable values:
k1=#v1#
k2=#v2#
k3=#v3#
k4=#v4#
k5=#v5#
The use the filterset as follows
<filterset>
<filter token="v1" value="v11"/>
. . .
</filterset>
I need to use variable in WIX localization file WIXUI_en-us.wxl.
I tried use it like this:
<String Id="Message_SomeVersionAlreadyInstalled" Overridable="yes">A another version of product $(var.InstallationVersionForGUI) is already installed</String>
But it doesn't work. And when I declared property and used it this way:
<String Id="Message_SomeVersionAlreadyInstalled" Overridable="yes">A another version of product [InstallationVersionForGUI] is already installed</String>
doesn't work either.
Where was I wrong?
Thanks for help and your time.
Localization strings are processed at link time, so you can't use $(var) preprocessor variables. Using a [property] reference is supported, as long as the place where the localization string is used supports run-time formatting (e.g., using the Formatted field type).
Your second method should work just fine. This is the same method used by the default .wxl files.
For example, in your .wxl file you would declare your string:
<String Id="Message_Foo">Foo blah blah [Property1]</String>
And in your .wxs file, you declare the property. If you wish, you can declare the property to match a WiX variable (which it sounds like you're trying to do)
<Property Id="Property1">$(var.Property1)</Property>
I was trying to get localization file to use variables. Came across this post:
There are different layers of variables in WiX (candle's preprocessor
variables, Light's WixVariables/localization variables/binder
variables, and MSI's properties). Each have different syntax and are
evaluated at different times:
Candle's preprocessor variables "$(var.VariableName)" are evaluated
when candle runs, and can be set from candle's commandline and from
"" statements. Buildtime environment
properties as well as custom variables can also be accessed similarly
(changing the "var." prefix with other values).
Light's variables accessible from the command-line are the
WixVariables, and accessing them is via the "!(wix.VariableName)"
syntax. To access your variable from your commandline, you would need
to change your String to: This build was prepared on
!(wix.BuildMachine)
If you instead need to have the BuildMachine value exist as an MSI
property at installation time (which is the "[VariableName]" syntax)
you would need to add the following to one of your wxs files in a
fragment that is already linked in:
Now, the environment variable COMPUTERNAME always has held the name of
my build machines in the past, and you can access that this way:
$(env.COMPUTERNAME). So, you can get rid of the commandline addition
to light.exe and change your wxs file like this:
<WixProperty Id="BuildMachine" Value="$(env.COMPUTERNAME)"/>
Preprocessor variables $(var.VariableName) are are processed at link time, so ideally you would use [PropertyName] which would be defined on the main Product element.
The issue sometimes is that property is not yet defined, for instance using the product name on the localization file seems not posible.
This solution was done aiming to only type the product name once given "Super product" as product name:
In case of running through visual studio extension:
Project properties -> Build -> Define variables -> "MyProductName=Super product" (No quotes)
In case of runing from cmd or some other place:
On Light.exe, add -d"MyProductName=Super product"
Into the localization .wxl file:
<String Id="Description" Overridable="yes">Description of !(wix.MyProductName)
to make it more interesting</String>
I have an aditional config file .wxi I include on other files to have some vars, for instance, here i had hardcoded the value but now it's harcoded on the variable definition and I use the given value:
<?xml version="1.0" encoding="utf-8"?>
<Include>
<!-- Define the product name preprocesor variable -->
<?define ProductName="!(wix.ProductNameDefVar)" ?>
<!-- From this point, can use the preprocesor var -->
<?define ProductName_x64="$(var.ProductName) (64bit)" ?>
<?define ProductName_x32="$(var.ProductName) (32bit)" ?>
<?define CompanyDirName = "My company name" ?>
</Include>
Finally, the place where the localization value where the localization text was not interpolating, is like this:
<?xml version="1.0" encoding="UTF-8"?>
<Wix xmlns="http://schemas.microsoft.com/wix/2006/wi">
<!-- Include the config file with the preprocesor var -->
<?include $(sys.CURRENTDIR)\Config.wxi?>
<!-- Main product definition -->
<Product Id="$(var.ProductCode)"
Name="$(var.ProductName)"
Language="!(loc.Language)"
Version="$(var.BuildVersion)"
Manufacturer="!(loc.Company)"
UpgradeCode="$(var.UpgradeCode)">
<!-- Package details -->
<!-- Here, Description was not interpolating -->
<Package InstallerVersion="200"
Compressed="yes"
InstallScope="perMachine"
Platform="$(var.Platform)"
Manufacturer="!(loc.Company)"
Description="!(loc.Description)"
Keywords="!(loc.Keywords)"
Comments="!(loc.Comments)"
Languages="!(loc.Language)"
/>
[...]
I'm trying to automize my android build process. For that, I want to change the app name in an XML file. the code is something like this
<resources>
<string name="app_name">Realta Connections</string>
</resources>
Now I want to replace the name 'Realta Connections' by something else at build time, a name which I would give at build time. The name can be 'Realta Connections' or anything else, so I need to detect the name="app_name" and replace the content inside it. I tried looking for how to do it but couldn't find the precise way. How can I do that? Please help.
It is probaly easiest to have a fixed value, which will be replaced. This will allow the use of the replace task:
You need replacetoken/replacevalue and the Strings inside ![CDATA[]] because of the xml characters.
<replace casesensitive="false"
file="../KS.build/ivy.properties">
<replacetoken><![CDATA[<string name="app_name">Realta Connections</string>]]></replacetoken>
<replacevalue><![CDATA[<string name="app_name">Something else</string>]]></replacevalue>
</replace>
Otherwise there is no normal ant solution (repleaceregex doesn't allow nested CDATA replacements).
Links:
Ant replace task
I know this question is quite old, but here is an idea. This seems like it's not really a purely ant solution, but you can embed a script in ant using the <scriptdef> tag.
Here is a function you can use to search for something in an XML file and store the result in a property:
<scriptdef name="xpath-query" language="javascript">
<attribute name="query"/>
<attribute name="xmlfile"/>
<attribute name="property"/>
<![CDATA[
importClass(java.io.FileInputStream);
importClass(javax.xml.xpath.XPath);
importClass(javax.xml.xpath.XPathConstants);
importClass(javax.xml.xpath.XPathFactory);
importClass(org.xml.sax.InputSource);
importClass(java.lang.System);
var exp = attributes.get("query");
var filename = attributes.get("xmlfile");
var xpath = XPathFactory.newInstance().newXPath();
var input = new InputSource(new FileInputStream(filename));
var value = xpath.evaluate(exp, input, XPathConstants.STRING);
self.project.setProperty( attributes.get("property"), value );
System.out.println("Copied this value:" + value + " to this property:" + attributes.get("property"));
]]>
</scriptdef>
Then you could get the current name of the app by using the xpath-query task you just defined:
<xpath-query query='pathToResources\resources\string[#name="app_name"]' xmlFile="app.xml" property="appName" />
Then the app name will be stored in the property appName.
From there you could do regex replace on the xml file using the app name.
<replaceregexp file="app.xml" match="${appName}" replace="${newAppName}" />
The potential down-side of this particular approach is that if you have the same app name string somewhere else in the XML file the regex replace may replace something you didn't intend.
You could probably define the <scriptdef> to do the replacement rather than just storing what was found in a property, but I had this portion of code handy already.
When dealing with XML in ANT I always recommend the xmltask. For your requirement see xml task manual replace
A little Xpath knowledge won't hurt, see:
http://zvon.org/xxl/XPathTutorial/
http://www.w3schools.com/xpath/
try this code, it works for me
<target name="change-app-name">
<replaceregexp file="res/values/strings.xml" match='name="app_name"(.*)'
replace='name="app_name">Something Else<\/string>'/>
</target>
I'm trying to use the native2ascii ant task but it seems that is not doing anything. Here's my ant task:
<target name="-pre-init">
<native2ascii src="src/com/bluecubs/xinco/messages" dest="src/com/bluecubs/xinco/messages/test"
includes="**/_*.properties"/>
<copy todir="src/com/bluecubs/xinco/messages">
<fileset dir="src/com/bluecubs/xinco/messages/test"/>
</copy>
<delete dir="src/com/bluecubs/xinco/messages/test" />
</target>
I did the copy part to see if it was an overwriting issue but the files come out exactly the same.
This is the output I get when running the task:
Converting 12 files from Z:\Netbeans\Xinco\2.01.xx\Xinco\src\com\bluecubs\xinco\messages to Z:\Netbeans\Xinco\2.01.xx\Xinco\src\com\bluecubs\xinco\messages\test
Copying 12 files to Z:\Netbeans\Xinco\2.01.xx\Xinco\src\com\bluecubs\xinco\messages
Deleting directory Z:\Netbeans\Xinco\2.01.xx\Xinco\src\com\bluecubs\xinco\messages\test
Edit:
Additional information:
OS: Windows 7 (but answer should work on any OD)
File encoding: Western (ISO-8859-1) obtained with this article.
Files location
Any idea?
native2ascii converts native characters like áéí to escaped unicode sequences. It means that á will be \u00e1, é -> \u00e9 and í -> \u00ed. After running native2ascii your files will be standard ASCII files which are more portable.
native2ascii does not touch the characters which are already in the escaped unicode form. Your properties files are already in escaped unicode form so it does not change anything. For example _XincoMessages_cz.properties contains this line:
general.accessrights=opr\u00E1vnen\u00ED k pr\u00EDstupu
It's escaped unicode. The nonescaped unicode form is this:
general.accessrights=oprávnení k prístupu
Wordpad vs. Netbans: When you open the properties files with Wordpad it opens it as a simple text file and shows \u00e1 as \u00e1. It does not convert it back to á. Netbeans does this conversion and you see the 'á' character. Furthermore, it writes it back to the disk as \u00e1 (!) when you save the file. To see the raw files use for example a Total or Double Commander which doesn't do any converting. (Note that Netbeans does this conversion just for properties files.)
If you put for example an á character to your _XincoMessages_cz.properties file it will be changed to \u00e1 if your run your ant task. Of course now don't use Netbeans for the editing, a simple notepad will do.
Loading properties files in java converts the escaped unicode characters to real unicode characters. An example:
final Reader inStream = new FileReader("..../_XincoMessages_cz.properties");
final Properties properties = new Properties();
properties.load(inStream);
System.out.println(properties.getProperty("general.accessrights"));
It prints:
oprávnení k prístupu
The ASCII/escaped unicode form in properites files is usually handled well by java applications. Finally, I think your properties files are good in their current format.
It ended being a view issue. Looking the files in a raw editor (i.e. Wordpad) showed that the files were already converted by the task. Viewing them from NetBeans shows them the same.
I get a very confusing reaction from my ant build-file and I'm wondering whether I'm just not clever enough or this might actually be a bug.
I've got the following property set globally in my project:
<property name="lib.dir" location="lib"/>
Then I'll try to add some files out of this directory into a jar file via fileset (more than one resource):
<fileset dir="${basedir}" includes="lib/*filename*"/>
There should be (and exist) 3 different libraries, which are matched that way. However, if I try to use the following, it doesn't work and no files are included:
<fileset dir="${basedir}" includes="${lib.dir}/*filename*"/>
Note that the only differences lies in the usage of the global property. Now the simple question: why does the first version work as advertised, but the second doesn't?
Please check the actual value of "lib.dir" just before and maybe after the task that uses the "fileset" expression. Just to make sure, that it hasn't been changed accidently after you've set it globally. The <echo/> task can help.
Maybe I got the solution. The description of the locationattribute is:
Sets the property to the absolute filename of the given file. If the value of this attribute is an absolute path, it is left unchanged (with / and \ characters converted to the current platforms conventions). Otherwise it is taken as a path relative to the project's basedir and expanded.
Simply use the value attribute instead of location. Here's a test script to show the difference:
<project name="test">
<property name="test1" location="lib"></property>
<property name="test2" value="lib"></property>
<target name="target" description="description">
<echo>${test1}</echo>
<echo>${test2}</echo>
</target>
</project>
The output on my system is as follows:
Buildfile: D:\Develop\workspace-jabber\scrapbook\build.xml
target:
[echo] D:\Develop\workspace-jabber\scrapbook\lib
[echo] lib
BUILD SUCCESSFUL
Total time: 307 milliseconds
I have found a clue to the answer, but not the whole thing yet.
I runned both versions of the fileset with ant -debug and here is what happens.
In the working, not-using-property version, I get the following output:
fileset: Setup scanner in dir [pathToDir] with patternSet{ includes: [lib/*filename*] excludes: [] }
whereas in the should-be-working-but-doesn't version I get:
fileset: Setup scanner in dir [pathToDir] with patternSet{ includes: [ [pathToDir]/lib/*filename*] excludes: [] }
As you can see, ant add's the [pathToDir] in the regexp, thus searching for
[pathToDir]/[pathToDir]/lib/*filename*
which obviously doesn't exist. Problem now: how do I have to modify my version to have it working properly?
When creating the property (is it done global or in a target?), does the directory lib exist? If not, the location attribute does not work - use a value attribute instead or better define the property after creating the directory.
As indicated above, the problem was that ${lib.dir} too contained the whole path, thus searching for [pathToDir]/[pathToDir]/lib/filename.
To clip away the unwanted [pathToDir] in the ${lib.dir} property, I now used the task. I got now the following, but imho not so nice looking solution:
<basename property="lib.dir.rel" file="${lib.dir}"/>
<fileset dir="${basedir}" includes="${lib.dir.rel}/*filename*"/>
P.S.: On a second look, I found that Andreas_D also found the right reason and a good suggestion yesterday, which I must have overlooked :-/