I am new to JavaFX and only have some basic knowledge about Ant. At the moment I am learning how to use the FX Ant tasks to deploy an application. Edit: By using <fx:deploy nativeBundles="exe" ../> Ant automaticly uses Inno Setup to create a setup file with the .exe extension.
Since our company has some affiliated companies, most of our applications need to be deployed once for each of them. This is because some Windows Registry entries are created and they should look like this (not my idea, the management wants it to be like this!):
"HKCU\Software\affiliated company name\AppName\Settings"
Now I would like to know, if it's possible to pass a parameter from my build.xml to the .iss to insert the bold part dynamically.
I found this question , where passing
/DMyParameterName=MyValue to the Inno Setup compiler (ISC) is suggested, but I don't know how to do this from the build.xml since I can't find any direct call to the ISC.
I hope you can understand my problem (English isn't my native language). If you need more information to be able to help me please feel free to ask, I will try to add them as fast as possible.
The Java FX does not allow you to pass any additional arguments to ISCC.exe.
At least according to OpenJFX source code:
//run candle
ProcessBuilder pb = new ProcessBuilder(
TOOL_INNO_SETUP_COMPILER_EXECUTABLE.fetchFrom(params),
"/o"+outdir.getAbsolutePath(),
getConfig_ExeProjectFile(params).getAbsolutePath());
pb = pb.directory(EXE_IMAGE_DIR.fetchFrom(params));
IOUtils.exec(pb, VERBOSE.fetchFrom(params));
You might do with setting an environment variable instead of parameter and consume it using this syntax:
{%VARNAME}
See Inno Setup Constants documentation.
For those looking for a pure Ant solution (no Java FX):
The Inno Setup compiler (ISCC.exe) is a normal console executable.
You run the compiler using a basic Exec Ant task:
<project>
<exec executable="ISCC.exe">
<arg value="Example1.iss"/>
<arg value="/DMyParameterName=MyValue"/>
</exec>
</project>
Related
I have an ant script which has a taskdef and the task creates an https internet connection and somethin with that SSL stuff is wrong. Thus I want to set the system property javax.net.debug=all to get some more information.
In java I would do this using the -D option, but in ant this is used for ant properties which is not the same as a system property.
If this wouldn't be a taskdef but instead a java task, I could use the sysproperty property, but it is no java-task.
Googling for this is frustratingly complicated because ant properties and system properties in ant are so similar that most search results are about the other (or about the java-task).
Obviously I am not the only one with the problem, but other people's questions that I have found (like here) are unanswered or went for hack (like here).
One way to set such a property is the ANT_OPTS system variable. You have to be very carefully to not simply skim over answers on google that state that options can be set that way, because it sounds so much like not what it does:
The documentation says:
ANT_OPTS - command-line arguments that should be passed to the JVM.
For example, you can define system properties or set the maximum Java
heap size here.
Who what have expected that? ANT_OPTS are options for the JVM and not for ant like the name suggests. The var which is used for ant options is called ANT_ARGS.
Now I can launch ant like this: ANT_OPTS="-Djavax.net.debug=all" ant myTarget and can see tons of log output.
(However this leaves the question open whether such a variable can be set using XML).
You can declare system properties in the xml with <sysproperty key="key" value="value"/>.
http://www.java2s.com/Code/Java/Ant/SetsystempropertiesinAntbuildscript.htm
You can use scripting:
<script language="javascript">
java.lang.System.setProperty('myKey', 'myValue');
</script>
When trying to compile a Javadoc taglet, which requires $JAVA_HOME/lib/tools.jar, I discovered that ant (version 1.8.4) sets java.home to $JAVA_HOME/jre rather than just $JAVA_HOME. I verified this thusly:
<echo>${java.home}</echo>
<echo>${env.JAVA_HOME}</echo>
[echo] /usr/java/jdk1.7.0_21/jre
[echo] /usr/java/jdk1.7.0_21
According to ant -diagnostics, there isn't any property like a jdk.home. Thus, to use tools.jar I have to do:
<classpath location="${java.home}/../lib/tools.jar"/>
So, I have two questions:
1) Is there something wrong with my setup of ant that's causing java.home to point to the JRE instead of the JDK?
2) If this is the way ant is supposed to work, is using the .. in my classpath the way I'm supposed to do things? Or should I do ${env.JAVA_HOME}/lib/tools.jar? Or something else entirely?
Here are the answers:
"Is there something wrong with my setup ...?" No. Ant is setting it's internal java.home based on JVM System properties. The code for HotSpot (JVM internals) sets it with "/jre" appended on purpose. In fact, the Java(TM) Tutorials for System Properties describes it exactly that way. The "java.home" variable from inside ant really isn't one-in-the-same as the "JAVA_HOME" that is set in your environment -- different but with similar names.
"(What is) the way I'm supposed to do things?" You can really do whatever you feel is appropriate, but remember that Ant can and usually does run in a separate JVM process. I'd assume that your system environment is probably specifying the JVM that was used to develop the app, so I would just use "${env.JAVA_HOME}" to ensure that development expectations meet build expectations.
For more information, please see another similar answer here.
Also, consider that more info can be collected from ant by running it with the -debug, -diagnostics and/or -verbose flags.
Had the same problem. I found that adding fork="true" to the javac tag solves this issue. So do something like this:
<javac target="1.7" source="1.7" fork="true" ...>
I will thank whoever can explain why this works.
The title might not be the best so let me explain what I am trying to do.
I have made an Ant buildfile that will help me with Maven goals. It's so much easier having to scope to Ant view and choose what I want to do. The biggest benefit with this is that I can use it in almost any project. Whether I deploy to tomcat or jboss or sakai(:deploy) or I handle mutiple instaces of the same server or skip tests... worst case I just change some path properties.
The drawback right now is that I have to keep a copy of this buildfile in every project.
What I am trying to do is have only 1 buildfile, in the workspace, and dinamicaly optain, from eclipse, the current project that I am working on. Be it module or parent I can refine that later.
So basically change the basedir for ant tasks based on the selected project in eclipse.
I have tried Ant Runtime Properties but for some reason properties like
${project_path}
fail to give me what their description say. I get this:
Variable references empty selection: ${project_path}
I hope it is clear what I am trying to do. So my question, I know it's possible, I'm just missing something and I hope some of you can help me with this.
I believe the trouble is in the Ant Runtime properties. I'm not 100% sure how I should use those.
Thank you!
EDIT after comment and further investigation..
Make the projectdir available as basedir property for ant like that :
Window > Preferences > Ant > Runtime > Properties
and create a property named basedir with value either :
${project_loc}
or
${workspace_loc}/${project_name}
and
<project basedir="${basedir}">
<echo>$${basedir} = ${basedir}</echo>
</project>
will work as expected, means echoing eclipse/yourworkspace/projectdir
Maybe there are other ways, i.e. via Ant Addon Ant4Eclipse, which aims to make Eclipse settings available for ant, never used it.
I have an extension-point defined in ant :
<extension-point name="foo"/>
A lot of tasks contribute to this point in several imported ant files :
<bindtargets targets="bar" extensionPoint="foo" />
However I'm kinda lost as to exactly which tasks are contributing. Is there a way to have ant report the tasks that would be triggered by a given extension point ? More generaly, is there a way to display the "call-graph" (or simply the list of dependencies) of an ant task ?
I tried using verbose options for ant (-v and such), with no luck.
Thanks
First of all, you can try to debug the ANT process in your IDE using remote debugging by adding some parameters to ANT_OPTS (mine is set in ~/.profile):
http://blog.dahanne.net/2010/06/03/debugging-any-java-application/
And profiling may help. I found project Antro on ANT Wiki...
http://sourceforge.net/projects/antro
Maybe you can try it out. The project is said to be designed for ANT, which looks promising in solving your problem.
Also you can use Yourkit Java Profiler to do a CPU profiling. YJP can show the call graph of a java application, but I'm not sure if one can find out which are ANT targets.
The following document shows how to start a java application with YJP agent.
http://www.yourkit.com/docs/95/help/agent.jsp
I know of 2 ways to get this information:
You can get the effective target/extension-point invocation sequence from Ant's console logger. To do this, place Ant's logging facility into verbose mode by passing -verbose on the command line to Ant. There are two lines, one after the other, that dump to the console immediately before most targets as they are invoked in your build script:
A line that shows a summary of the targets in the call sequence starting with the text, Build sequence for target(s) 'artifact' is [...].
A line showing the detailed call sequence (nested targets and antcalls included). This line starts with the text, Complete build sequence is [...]. This listing considers, as much as reasonably possible, the evaluation of any if and unless attributes of each target listed at the point the line is logged to the console.
Simply invoke your Ant build as you would normally with the -verbose option and your console should have the information you're looking for.
You can get a pictorial representation of the call sequence using a tool called Grand. However, it hasn't been updated for quite some time and thus doesn't support extension-points (which is what you're concerned with here). It will interpret antcall's, ant, and depend'encies. It doesn't evaluate the if and unless attributes but simply identifies potential execution sequence - more of a dependency hierarchy than an actual call graph. The project is on Github so an update to support extension-points may not be too difficult.
The graphic is rendered using Graphviz.
For an actual call sequence, use option 1.
This is pretty sloppy, but it works. Ant is actually pretty easily scripted, and if you are using at least Java 6 (or it might be Java 7), javascript support is built in and thus can be used right out of the box. This defines a task that will echo the dependencies of any target in call order:
<scriptdef name="listdepends" language="javascript">
<attribute name="target"/>
<![CDATA[
var done = [];
var echo = project.createTask("echo")
function listdepend(t) {
done.push(t.getName());
var depends = t.getDependencies();
while (depends.hasMoreElements()) {
var t2 = depends.nextElement();
if (done.indexOf(t2)==-1) listdepend(project.getTargets().get(t2));
}
echo.setMessage(t.getName());
echo.perform();
}
var t = attributes.get("target");
if (t!=null) {
var targ = project.getTargets().get(t);
listdepend(targ);
}
]]>
</scriptdef>
In your case, you can create a new target (or not) and call it like so:
<target name="listfoo">
<listdepends target="foo"/>
</target>
As I said, this is somewhat sloppy. It probably isn't very fast (although unless your target triggers thousands of others, it probably isn't noticeably slow). It won't handle antcall tasks (although it could be modified to do so easily) or respond to if and unless attributes. If dependencies nest too far, it may hit a recursion depth limit (but I doubt any project nest them deep enough).
The array is used to make sure that each dependency is listed once (ant would only run them once).
I'm currently working with some developers who like to set up Ant tasks that define environment specific variables rather than using properties files. It seems they prefer to do this because it's easier to type:
ant <environment task> dist
Than it is to type:
ant -propertyfile <environment property file> dist
So for example:
<project name="whatever" default="dist">
<target name="local">
<property name="webXml" value="WebContent/WEB-INF/web-local.xml"/>
</target>
<target name="remote">
<property name="webXml" value="WebContent/WEB-INF/web-remote.xml"/>
</target>
<target name="build">
<!-- build tasks here --->
</target>
<target name="dist" depends="build">
<war destfile="/dist/foo.war" webxml="${webXml}">
<!-- rest of war tasks here -->
</war>
</target>
I am finding it hard to convince them that properties files are they right way to go. I believe properties files are better because:
They provides more flexibility - if you need a new environment just add a new properties file
It's clearer what's going on - You have to know about this little "trick" to realize what they're accomplishing
Doesn't provide default values and the ability to use overrides - if they used property files they could provide defaults at the top of the project but have the ability to override them with a file
Script won't break if an environment task isn't supplied on command line
Of course all they hear is that they need to change their Ant script and have to type more on the command line.
Can you provide any additional arguments in favor of properties files over "property tasks"?
Properties tasks tightly couple the build file to environments. If your fellow developers are arguing that they "have to change their ant script" with your suggestions, why aren't they arguing about changing it every time they have to deploy to a new environment? :)
Perhaps you can convince them to allow both properties file and command-line configuration. I set up my Ant builds so that if a build.properties exists in the same directory as the build.xml, it reads it in. Otherwise it uses a set of default properties hard-coded into the build. This is very flexible.
<project name="example">
<property file="build.properties"/>
<property name="foo.property" value="foo"/>
<property name="bar.property" value="bar"/>
...
</project>
I don't provide a build.properties with the project (i.e. build.properties is not versioned in SCM). This way developers aren't forced to use the property file. I do provide a build.properties.example file that developers can reference.
Since Ant properties, once set, are immutable, the build file will use properties defined in this order:
Properties provided with -D or -propertyfile via the command line
Properties loaded from build.properties
Default properties within build.xml
Advantages of this approach:
The build file is smaller and therefore more maintainable, less bug-prone
Developers that just can't get away from setting properties at the command line can still use them.
Properties files can be used, but aren't required
The arguments you have are already pretty compelling. If those arguments haven't worked, then arguing isn't going to solve the problem. In fact, nothing is going to solve the problem. Don't assume that people are rational and will do the most practical thing. Their egos are involved.
Stop arguing. Even if you win, the resentment and irritation you create will not be worth it. Winning an argument can be worse than losing.
Make your case, then let it go. It's possible that after a while they will decide to switch to your way (because it actually is better). If that happens, they will act like it was their own idea. There will be no mention of your having proposed it.
On the other hand, they may never switch.
The only solution is to work towards a position of authority, where you can say how things are to be done.
The problem with the first solution (using ant property) is basically hardcoding.
It can be convenient when you start a project for yourself but quickly you have to remove that bad habit.
I'm using a property file close to what said robhruska except that I have committed the build.properties file directly. This way you have a default one.
In other hand, I understand I could add those default values in the build.xml. (I will probably try that in the next hours/days ;-) ).
Anyway, I really don't like the first approach and I would force those guys to follow the second one ...