I need to run a kettle(ktr) file from the orbeon or more specifically from the xpl file. I was thinking of running a batch file but i cant find any step to do it. How can i run the batch/ktr file from within the xpl file?
To run external commands from XPL you van use the undocumented oxf:execute-processor, for instance (borrowed to XForms Unit):
<p:processor name="oxf:execute-processor">
<p:input name="config" href="#control" transform="oxf:xslt">
<exec executable="/home/vdv/projects/xformsunit/resources/apps/xformsunit/browser-run.sh"
xsl:version="2.0">
<arg
line=" http://localhost:8080/orbeon/xformsunit/suite/{/*/name}/results?implementation=xsltforms&uid={/*/uid}"
/>
</exec>
</p:input>
<p:output name="stdout" id="stdout" debug="stdout"/>
<p:output name="stderr" id="stderr" debug="stderr"/>
<p:output name="result" id="result" debug="result"/>
</p:processor>
AFAIK this processor hasn't been documented but you should be able to find more examples on the mailing list.
Related
I have one VB script in the package itself. I need to call it using CMD, the default way of calling the script taking too much time, so I am trying to call it with CMD and CSCRIPT but the installer raises the error while installation.
I am using the following code which is not working as expected. I searched a lot but didn't find the solution.
<Binary Id="ServiceInstall" SourceFile="..\..\..\AddVirDir.vbs" />
<CustomAction Id="InstallService" BinaryKey ="ServiceInstall"
ExeCommand="CMD /C "[#ServiceInstall]""
Execute="immediate" Return="check" HideTarget="no" Impersonate="no"/>
WiX IIS Elements: If this is all IIS, I would avoid scripting and custom actions whenever possible and use WiX's built-in IIS elements. Here is a Web-installer sample from Rainer Stropek available on github.com.
Look for <iis:WebVirtualDir ... /> et al. Find the WiX Documentation here. I believe you should be able to accomplish what you need without too many custom actions.
DISM.exe: Stropek himself uses custom actions in another sample source to set up IIS using DISM.exe. Not sure I would do it like this (no other suggestions though), but it is a sample of custom actions and IIS.
Need-For-Speed: As to your installation performance issues. Maybe you need to suppress the creation of a restore point and limit file costing? The Windows Installer engine allows this - see link below. I doubt it will be very effective though. I think there must be something else wrong in your installer. Some timeout issue? It could relate to other custom actions, slow network, or some other issue. Can you elaborate on your deployment scenario?
In any case, here is some documentation on speeding up MSI installations in general. Essentially the MSIFASTINSTALL property is the only one I would recommend. DISABLEROLLBACK can cause genuine problems.
Logging: I normally recommend that setup developers enable default verbose MSI logging - as described in the "Globally for all setups on a machine" section, to always have a log file ready when you need one. It is created with a random name for every MSI operation in the TEMP folder and you sort by modify to get the latest one. The log file might give clues as to why the installation is slow - just determine what is really going on. Apologies if this is just obvious trifles and you have this set up already.
Manual log file creation:
msiexec.exe /i C:\Path\Your.msi /L*v C:\Your.log
Interpreting an MSI log: interpreting a log file can be challenging sometimes. Here is an answer with some links to help with this.
Service Installation & Control: You should not install services with scripts. There are built-in mechanisms in MSI that are vastly superior. You simply use the ServiceInstall and ServiceControl WiX XML Elements and "declare" how the service should be registered and when and how the service should be started and stopped:
<Component>
<File Source="$(var.SourceDir)\WindowsService.exe" />
<ServiceInstall Name="MyService" ErrorControl="normal" Start="auto" Type="ownProcess" />
<ServiceControl Id="MyService" Name="MyService" Start="install" Stop="both" Remove="uninstall" Wait="yes" />
</Component>
Look! No custom actions! :-) - Just MSI auto-magic. There is no need to use any custom actions for this. MSI is full-featured and reliable provided your service executable behaves as it is supposed to.
Let me link to a similar sample on github in case the above is not clear. It is more complete and elaborate.
VBScript: I wrote this before I saw you dealt with services. I'll just throw it in: to call a script that doesn't have a function you can try something like this:
<!-- The VBScript file -->
<Binary Id='Sample.vbs' SourceFile='Sample.vbs' />
<!-- The Custom Action -->
<CustomAction Id='Sample.vbs' VBScriptCall='' BinaryKey='Sample.vbs'
Execute='immediate' Return='ignore'/>
<!-- And Insert Into Installation Sequence -->
<InstallExecuteSequence>
<Custom Action='Sample.vbs' After='AppSearch'/>
</InstallExecuteSequence>
That should work for a script like this (Sample.vbs - no funtions, just an implicit main function):
MsgBox(Session.Property("ProductName"))
There is an answer on the topic of VBScript custom actions here: WIX installer execute vbscript from CustomAction.
I'm trying to get Jenkins figured out. I have a suite of selenium tests that I can build and run via Eclipse or build and run via the command line with ant, but whenever I try Jenkins, they fail.
The console out from Jenkins reports that the value for ws.jars, defined in my build.xml file, doesn't exist; however that directory does exist! Again, no problem building from the command line.
Any suggestions would be greatly appreciated as I've been trying to get this solved now for a couple of days.
Thanks.
My build.xml file:
<property environment="env"/>
<property name="ws.home" value="${basedir}"/>
<property name="ws.jars" value="/Users/username/Documents/All JAR Files/All in one place"/>
<property name="test.dest" value="${ws.home}/build"/>
<property name="test.src" value="${ws.home}/src"/>
<property name="ng.result" value="test-output"/>
I created a new target in my build.xml file called path. Here is the output when I run with Jenkins.
Started by user anonymous
Building in workspace /Users/<user>/local_repo/qa-automation/selenium-java/my-projects
[my-projects] $ /Users/Shared/Jenkins/Home/tools/hudson.tasks.Ant_AntInstallation/Install_automatically/bin/ant path
Buildfile: /Users/<user>/local_repo/qa-automation/selenium-java/my-projects/build.xml
path:
[echo]
[echo] My path - /Library/Java/JavaVirtualMachines/jdk1.7.0_55.jdk/Contents/Home/bin:/Library/Java/JavaVirtualMachines/jdk1.7.0_55.jdk/Contents/Home/bin:/usr/bin:/bin:/usr/sbin:/sbin
[echo]
BUILD SUCCESSFUL
Total time: 0 seconds
Finished: SUCCESS
I suspect this is caused by the spaces within your path of ws.jars. You should escape these spaces by adding \, try change the path :
<property name="ws.jars" value="/Users/username/Documents/All JAR Files/All in one place"/>
with this one:
<property name="ws.jars" value="/Users/username/Documents/All\ JAR\ Files/All\ in\ one\ place/"/>
Thanks everybody for your suggestions. I hadn't thought about this in awhile but last night I had some time and was able to work on this issue again. Turns out it was related to the Jenkins job being executed in the non-interactive shell, just as 'rgulia' pointed out. So finally, I tried copying my ws.jars directory to /Users/Shared/Jenkins, changed the owner to 'jenkins', and boom, my build was able to proceed.
The original error message was just so misleading. It wasn't that the directory didn't exist, but that 'jenkins' didn't have access and/or permissions to it.
I hope this information can help others.
I am trying to access the osgi console of eclipse container in remote machine which is used to run automated test suites. We use ant to run the unit tests in test agents. Below is the ant taks we are using.
I found out that i need to add this command line argument to make the remote agent listen to the port specified."-Dosgi.console=8005". I ran the script but it is not stopping saying"listening to 8005". i was able to successfully remote debug this agent but i need osgi console view to debug the bundles that got installed in the agent.
Did i place the argument in the correct position? Does it have to be in any order?
Any help is appreciated. i do not understand why it never worked.
<java dir="${basedir}" classname="org.eclipse.equinox.launcher.Main" fork="true" classpathref="equinox.launcher.class.path">
<arg line="-application org.eclipse.pde.junit.runtime.uitestapplication -data ${tempWorkspace} -dev bin -testlistener org.eclipse.test.XMLTestListener -clean -port ${pde.test.port} -testpluginname ${testrunner.plugin.name} -classnames ${master.testsuite.name}"/>
<jvmarg value="-Xbootclasspath/a:${project.root}/lib/External/Clover/clover.jar"/>
<jvmarg value="-XX:MaxPermSize=256m" />
<jvmarg value="-Xms512m"/>
<jvmarg value="-Xmx1280m"/>
<jvmarg value="-Dorg.eclipse.equinox.http.jetty.http.port=2910"/>
<jvmarg value="-Dxcp.builder.testsuite.testplugins=xxxx.tests"/>
<jvmarg value="-Dosgi.console=8005"/>
<jvmarg value="-Xdebug"/>
<jvmarg value="-Xnoagent"/>
<jvmarg value="-Djava.compiler=NONE"/>
<jvmarg value="-agentlib:jdwp=transport=dt_socket,server=y,suspend=y,address=8000"/>
If you use Equinox 3.8 or newer, you must use the -Dosgi.console.enable.builtin=true system property as well. See http://hwellmann.blogspot.hu/2012/08/new-osgi-console-in-equinox-380.html
To launch the new OSGi console in Eclipse, you need to ensure that the console bundle and its dependencies are available. These include:
org.eclipse.equinox.console
org.apache.felix.gogo.shell
org.apache.felix.gogo.command
org.apache.felix.gogo.shell
Since it's unlikely your code has any dependencies on these they won't be installed into your test runtime, and therefore won't be available for starting the console.
Setting LaunchTarget e.g. to "cmd.exe" works fine, after the installation of the burn package, the desired command line window pops up. However, setting LaunchTarget to for example "[InstallFolder]\Path\To\Postinstallexecutable.exe" yields an error:
Error 0x80070002: Failed to launch target: C:\Program Files (x86)\Path\To\Postinstallexecutable.exe
The path is correct, executing "C:\Program Files (x86)\Path\To\Postinstallexecutable.exe" at the command line works fine. Is this a bug or am I missing something? WiX toolset version is 3.8.309.0.
Update: After a little more testing, the problem seems to occur only when you try to pass a parameter to the command in LaunchTarget. So for example using
<Variable Name="LaunchTarget" Value="[InstallFolder]\Basiskomponenten\Allgemein\test.cmd" />
works, while
<Variable Name="LaunchTarget" Value="[InstallFolder]\Basiskomponenten\Allgemein\test.cmd Test123" />
results in an 0x80070002 error.
The LaunchTarget variable points only to the executable that should be launched, it cannot be provided the command-line arguments. It wasn't until a very recent build of WiX v3.8 that you could set a second variable called LaunchArguments that provides the arguments. So, try upgrading to yesterday's WiX v3.8 build (or newer) and do:
<Variable Name="LaunchTarget" Value="[InstallFolder]\Basiskomponenten\Allgemein\test.cmd" />
<Variable Name="LaunchArguments" Value="Test123" />
I'm trying to decide which side I'm on in the MsBuild vs. Nant war. I'm starting with: stop a service, deploy some files, restart the service. Just from looking at these two links, that is much easier to do in Nant.
MSBuild: Example of using Service Exists MSBuild task in Microsoft.Sdc.Tasks?
<target name="service_exists">
<script language="C#">
<references>
<include name="System.ServiceProcess.dll" />
</references>
<code><![CDATA[
public static void ScriptMain(Project project) {
String serviceName = project.Properties["service.name"];
project.Properties["service.exists"] = "false";
project.Properties["service.running"] = "false";
System.ServiceProcess.ServiceController[] scServices;
scServices = System.ServiceProcess.ServiceController.GetServices();
foreach (System.ServiceProcess.ServiceController scTemp in scServices)
{
etc...
Nant: http://ryepup.unwashedmeme.com/blog/2007/01/04/restart-a-windows-service-remotely/
<!-- Send the stop request -->
<exec program="sc.exe">
<arg line="\\server stop shibd_Default"/>
</exec>
<!-- Sleep a little bit, to give the service a chance to stop -->
<sleep seconds="5"/>
<!-- Send the start request -->
<exec program="sc.exe">
<arg line="\\server start shibd_Default"/>
</exec>
I wonder if the SO community agrees with me. Is it much easier to get basic things like this done in Nant? Sure looks that way. C# code in a CDATA block? WTF?
Our current build process is a) lots of bat files b) lots of cursing. I'd really like to find a good replacement, but that MsBuild stuff looks like a world of pain to my eyes. I'm thinking the way to go is to build scripts in Nant, then use MsBuild to do any .NET builds that need to be done.
One important question: which one is better at catching errors in the script before the script is run? I was thinking of rolling my own here and that was very important part of it: line up all your data and make sure that it makes sense before attempting to run.
In msbuild you could also use the ServiceController task that is packaged in the msbuild community tasks.
You can execute sc.exe using MSBuild every bit as easily ...
<Exec Command="sc.exe \\server stop shibd_Default" />
By default this will "fail" if the exit code (of sc.exe) is non-zero, but that can be customized.
With Nant, there are 2 other ways to stop a service, and one is able to track an error.
First one (using Net Stop):
<exec program="net" failonerror="false"><arg value="stop"/><arg value="${serviceName}"/></exec>
Second one (much cleaner):
<servicecontroller action="Stop" service="${serviceName}" if="${service::is-installed(serviceName,'.') and service::is-running(serviceName,'.')}" />
Note that the second line verifies that the service already exists and is running, which allows to track any weird error.
In addition to #nulpptr's answer for MSBuild, if you don't have the option of using the community tasks, you might have to resort to a hack to wait for your service to stop before moving on. If you have the resource kit you can use the EXEC task with the sleep command.
No resource kit? Use the ping trick...
However, if you don't have the resource kit, you can use the ping trick to force a delay. For instance, the following will stop your service using the sc command, and then pause for about 5 seconds:
<Exec Command="sc.exe \\server stop shibd_Default" ContinueOnError="true" />
<Exec Command="ping 127.0.0.1 -n 5 > nul" ContinueOnError="true" />