Insert a source file in programlisting with xinclude in docbook - relative-path

I've the following file tree
mainfolder
|-assembly.xml
|
|-chapters
| |-introduction.xml
|
|-source
|-example01
|-main.cpp
assembly.xml is the assembly file of my docbook. It contains a reference to introduction.xml.
This is the assembly:
<?xml version="1.0" encoding="UTF-8"?>
<assembly version="5.1"
xmlns="http://docbook.org/ns/docbook">
<resources xml:base="chapters/">
<resource href="introduction.xml" xml:id="introduction" />
</resources>
<structure xml:id="main-book">
<info>
<description>Book chapters</description>
</info>
<output renderas="book"/>
<module resourceref="introduction"/>
</structure>
</assembly>
introduction.xml is docbook chapter. I want to insert in it an example including the main.cpp.
<?xml version="1.0" encoding="UTF-8"?>
<chapter version="5.1"
xmlns="http://docbook.org/ns/docbook"
xmlns:xlink="http://www.w3.org/1999/xlink"
xmlns:xila="http://www.w3.org/2001/XInclude/local-attributes"
xmlns:xi="http://www.w3.org/2001/XInclude"
xmlns:trans="http://docbook.org/ns/transclusion"
xmlns:svg="http://www.w3.org/2000/svg"
xmlns:m="http://www.w3.org/1998/Math/MathML"
xmlns:html="http://www.w3.org/1999/xhtml"
xmlns:db="http://docbook.org/ns/docbook">
<info>
<title>Introduction</title>
</info>
<section>
<info>
<title>Chapter title</title>
</info>
<para>
You can see an example:
</para>
<example>
<title>main example</title>
<programlisting language="c++">
<xi:include href="./../source/example01/maiin.cpp" parse="text" />
</programlisting>
</example>
</section>
</chapter>
Anyway, when I build the book (I'm using personal edition of XMLMind), I don't see anything. In the PDF the example is printed, but instead of the source code inside the main.cpp I see
<xi:include></xi:include>
What I'm doing wrong? How can I include the source code from the file?

I've reproduced your situation in a different ways and got things working in a both cases.
You didn't mention the exact steps you make to build a book using XMLMind XML Editor (XXE for short), but the following steps certainly worked well.
None 1: I've used XXE Professional Edition, but as I know the difference between versions is only in putting random character within text if generating PDF from Personal Edition.
Note 2: XXE says that <description>Book chapters</description> element is not allowed within you context. Despite that fact, the assembly can be generated successfully.
1. Getting things working within XXE
Open an assembly file in XXE.
Select Convert > Convert document > Convert to PDF.
Select a path to save pdf file and press OK button.
2. Getting things working manually in command line
Use your exact files and DIR structure (I included my own .c file sample for my own test).
Use XXE assembly processor: http://www.xmlmind.com/xmleditor/assembly.shtml - it has the same codebase that XXE used for working with assemblies from XXE GUI.
Get docbook book file from assembly:assembly-1_0_2_01/bin/assembly -v assembly.xml docbook_book.xml In my test I've got the .c sample file included - that proves that assembly utility works well with XInclude.
Get .pdf manually: fop -c <config_file> -xsl <path_to_docbook_ns_stylesheets>/fo/docbook.xsl -xml docbook_book.xml -pdf docbook_book.pdf
I've got the final result with .c sample included in both cases.

Related

How to add xml file during installation using wix

I want to create the following xml during the installation created by wix 3.9.
<?xml version="1.0" encoding="utf-8"?>
<MappedUsers xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xmlns:xsd="http://www.w3.org/2001/XMLSchema">
<UsersList>
<LyncUserID>
<CustomUserName>John.Smith</UcaUserName>
</LyncUcaUserID>
</UsersList>
</MappedUsers>
Tried creating the file using following code but got the error message during installtion that file doesn't exists.
<?define UserNameFile="[AppDataFolder]ThirdParty\LyncUcaUserMapping.XML" ?>
<util:XmlFile Id="UserMapping" Value="[USER_NAME]" ElementPath="/UsersList/LyncUserID/add[\[]#key='UcaUserName'[\]]" Action="setValue" File="$(var.UserNameFile)" Name="value" Sequence="7" />
Since I could not create the file during the installation I created the file manually and placed in my appdata folder. But then above code didn't work either as it says "failed to find the following node".
What am I missing?
Best method to do this is first you copy a sample xml file as below.
<?xml version="1.0" encoding="utf-8"?>
<MappedUsers xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xmlns:xsd="http://www.w3.org/2001/XMLSchema">
</MappedUsers>
Then edit it using a custom action.
Here is a link which shows how to edit xml files using c#
http://support.microsoft.com/kb/301233
Following link shows how to add custom actions to a wix project.
http://wixtoolset.org/documentation/manual/v3/wixdev/extensions/authoring_custom_actions.html

WiX Compile Time Directory Harvesting And Variables

I'm a bit confused about the interaction of these tools at the moment and I need a little helping ironing out my appraoch (or being told I'm being daft).
I have a VS2010 solution with two WiX projects. I have a a .WXI file in a solution folder that contains a number of global variables that I would like to use in multiple projects (more will be added in the future).
I include the .WXI file in my main Product.wxs project using the standard syntax like this:
<?include ..\Shared\Common.wxi?>
This is working great and all the variables are available. However as part of this build process I also need to run heat.exe in order to generate a large fragment automatically on each rebuild.
I use a command like this:
"Heat.exe" dir %sourcedir% -sfrag -sreg -suid -gg -ke -template fragment -out %wixfile% -dr INSTALLFOLDER -cg MyInstall -var var.MyFileSource
In my included variables file I have this:
<?define MyFileSource= "$(var.SolutionDir)..\..\..\..\mydir\bindist" ?>
However I get an error like this:
Undefined preprocessor variable '$(var.MyFileSource)'.
As you would expect as the fragment file does not contain a line that references the file Common.wxi but the problem is this fragment file is going to be replaced each build prior to compilation so it's completely inpractical to hand edit this fragment in order to add it each time (not to mention impossible anyway).
My question is am I approaching this completely incorrectly? If not, what is the best way to get this working correctly?
What is confusing is that there is the -var switch to create a variable reference in the fragment file but no way to then enable the variable referencing from an include file (unless I've missed that somewhere in the docs).
Instead of placing the variables in a separate wxi file and include it in all possible places, you can supply candle.exe with the variables you need. You can do this either from command line (using -dVarName=VarValue syntax), or with any of the supported build tools, NAnt or MSBuild.
I can see the following advantages:
the WiX authoring are not polluted with <?include?> stuff here and there
you don't have to mess the heat harvested authoring
variables defined once from the command line are available in any wxs file of your project
I also have such an include-file that centralizes my configuration during the build. As I also use variables in the files produced by heat this is very convenient, as I have to define them just once.
To be able to use these variables also in the heat-output you can transform the output created by heat using a xslt-transformation. Just add -t myTransformFile.xslt to the command-line of heat, so the output will be transformed according to the stylesheet defined in myTransformFile.xslt.
In the myTransformFile.xslt-file just add the following, which will basically copy everything and also add the Include-directive:
<?xml version="1.0" encoding="UTF-8"?>
<xsl:stylesheet version="1.0" xmlns:xsl="http://www.w3.org/1999/XSL/Transform"
xmlns:wix="http://schemas.microsoft.com/wix/2006/wi"
xmlns="http://schemas.microsoft.com/wix/2006/wi"
exclude-result-prefixes="wix">
<xsl:template match="wix:Wix">
<xsl:copy>
<!-- The following enters the directive for adding the Common.wxi include file to the dynamically generated file -->
<xsl:processing-instruction name="include">$(sys.CURRENTDIR)..\Shared\Common.wxi</xsl:processing-instruction>
<xsl:apply-templates select="#*" />
<xsl:apply-templates />
</xsl:copy>
</xsl:template>
<xsl:template match="#*|node()">
<xsl:copy>
<xsl:apply-templates select="#*|node()" />
</xsl:copy>
</xsl:template>
</xsl:stylesheet>
You have to adjust the path to your Common.wxi of course so that it can be found at build-time.
Edit: forgot a part of the XSLT-file that copied also other elements.

Octopus Deploy cannot find namespace in transform file

Have been trying to apply a transformation to one of my config files in Visual Studio 2010
The target file starts like this:
forms.config
<configuration xmlns:patch="http://www.sitecore.net/xmlconfig/" xmlns:x="http://www.sitecore.net/xmlconfig/">
<sitecore>
<formsDataProvider type="Sitecore.Forms.Data.DataProviders.WFMDataProvider,Sitecore.Forms.Core">
<param desc="connection string">connection string goes here</param>
</formsDataProvider>
...
The transformation file is as follows:
forms.Staging.config
<?xml version="1.0" encoding="utf-8" ?>
<!-- For more information on using transformations
see the web.config examples at http://go.microsoft.com/fwlink/?LinkId=214134. -->
<configuration xmlns:patch="http://www.sitecore.net/xmlconfig/" xmlns:x="http://www.sitecore.net/xmlconfig/" xmlns:xdt="http://schemas.microsoft.com/XML-Document-Transform">
<sitecore>
<formsDataProvider type="Sitecore.Forms.Data.DataProviders.WFMDataProvider,Sitecore.Forms.Core">
<param desc="connection string" xdt:Transform="Replace" xdt:Locator="Match(desc)">connection string for staging goes here</param>
</formsDataProvider>
</sitecore>
</configuration>
When the staging build runs on Octopus this is what's in the log:
DEBUG [XML Transformation] The expected namespace http://schemas.microsoft.com/XML-Document-Transform was not found in the transform file.
Have tried to remove the other xmlns attributes to no avail.
Said namespace is clearly on the transform file as an attribute in the configuration node. We have numerous other such files and transformations are applied fine. The Build Action for all transform files is set to Content.
Not sure if we can make Octopus log such messages as errors instead of Debug though.
Has anyone else had a similar problem?
Thanks in advance.
It looks like it might be trying to apply your forms.config as a transformation file instead of a target.
What do you have specified in the deployment step's Additional Transforms? Did you accidentally include forms.config itself?

Getting Project Version Information During MSbuild build

I'm attempting to automate the building of our installers through MSBuild. The problem that I have come up against is getting the Version information of the C# project which is calling the custom MSBuild script, which would then pass the version number into Wix during the build process.
What I would like to do is to set the version into some properties like this:
<ProductVersion>$(MajorVersion).$(MinorVersion).$(PatchVersion).$(BuildVersion)</ProductVersion>
<InstallerName>"$(ProductName)-$(ProductVersion).msi"</InstallerName>
The version is updated as part of our continuous integration build and incorporating the version number into each installer that is built on our continuous integration server helps us in producing an application that is Continuously Deployable.
Any help would be greatly appreciated.
The way I have solved this problem is by creating a 'version.xml' file in my code repository. This file contains the following data
<?xml version="1.0" encoding="utf-8"?>
<Project ToolsVersion="3.5"
DefaultTargets="Build"
xmlns="http://schemas.microsoft.com/developer/msbuild/2003">
<PropertyGroup>
<VersionMajor>0</VersionMajor>
<VersionMinor>1</VersionMinor>
<VersionBuild>1</VersionBuild>
<VersionRevision>0</VersionRevision>
</PropertyGroup>
</Project>
In my case this file is checked in but it should not be too hard to generate this file with information from the build server or whatever is desired.
During the build a custom MsBuild taks (similar to the TemplateFile task) creates an assembly info file and a Wix include file from their respective template files. The 'version.xml' file is accessed by including it in the MsBuild script. For example like this:
<?xml version="1.0" encoding="utf-8"?>
<Project
ToolsVersion="4.0"
DefaultTargets="Build"
xmlns="http://schemas.microsoft.com/developer/msbuild/2003">
<!-- Include the version info file so that we can pull the version info from it -->
<Import
Project="$(DirWorkspace)\version.xml"
Condition="Exists('$(DirWorkspace)\version.xml')" />
<!-- Generate a file with the version information -->
<Target Name="GenerateAssemblyInfoVersionNumber">
<ItemGroup>
<VersionTokens Include="Major">
<ReplacementValue>$(VersionMajor)</ReplacementValue>
</VersionTokens>
<VersionTokens Include="Minor">
<ReplacementValue>$(VersionMinor)</ReplacementValue>
</VersionTokens>
<VersionTokens Include="Build">
<ReplacementValue>$(VersionBuild)</ReplacementValue>
</VersionTokens>
<VersionTokens Include="Revision">
<ReplacementValue>$(VersionRevision)</ReplacementValue>
</VersionTokens>
</ItemGroup>
<TemplateFile
Template="$(FileTemplateAssemblyVersion)"
OutputFileName="$(FileGeneratedAssemblyVersion)"
Tokens="#(VersionTokens)" />
</Target>
</Project>
The AssemblyInfo.VersionNumber.cs file which is included in the C# projects is generated from a template file that looks like:
//-----------------------------------------------------------------------
// <auto-generated>
// This code was generated by a tool.
//
// Changes to this file may cause incorrect behavior and will be lost
// if the code is regenerated.
// </auto-generated>
//-----------------------------------------------------------------------
using System.Reflection;
[assembly: AssemblyVersion("${Major}.${Minor}.${Build}.${Revision}")]
[assembly: AssemblyFileVersion("${Major}.${Minor}.${Build}.${Revision}")]
// The AssemblyInformationalVersion stores the version that will be displayed in
// Windows explorer.
[assembly: AssemblyInformationalVersion("${Major}.${Minor}.${Build}.${Revision}")]
During the replacement process the ${TEXT_HERE} sections are replaced with their respective values.
The Wix include template file looks like this:
<?xml version="1.0" encoding="utf-8"?>
<Include xmlns="http://schemas.microsoft.com/wix/2006/wi">
<!--
This is a generated file.
Do NOT make changes to this file.
They will be undone next time the file is generated.
-->
<!-- The current version -->
<?define CurrentVersion = "${Major}.${Minor}.${Build}"?>
<!-- The install version string -->
<?define ProductVersionFolder = "${Major}.${Minor}"?>
</Include>
After including this file it is possible to refer to the CurrentVersion and the ProductVersionFolder variables in the Wix installer where ever it is needed.
By using this method the version information is stored in a single location and can be accessed by all parts of the build.

how to import osgi blueprint xml

I am trying to import an OSGI blueprint XML file in to another OSGi blueprint XML file.
e.g.:
blueprint1.xml:
<?xml version="1.0" encoding="UTF-8"?>
<blueprint ....>
<bean id="myBean1" class="com.company.Class1"/>
<bean id="myBean2" class="com.company.Class2"/>
</blueprint>
</xml>
blueprint2.xml:
<?xml version="1.0" encoding="UTF-8"?>
<blueprint ....>
<!-- DOES NOT WORK -->
<import resource="blueprint1.xml" />
</blueprint>
The <import> works for spring but not for blueprint.
Does anybody know a way of doing this in OSGi blueprint XML files?
Apparently, Spring like imports are not currently possible in blueprint.
However, if the files are in the same OSGi bundle then they are in the same context and can be used from other blueprint files.
Also, see here: http://fusesource.com/forums/message.jspa?messageID=15091#15091
If you're using Gemini Blueprint (formerly Spring DM) you can simply tell it to load both files, and basically treat them as if they were one big file:
In the absence of the Spring-Context header the extender expects every
".xml" file in the META-INF/spring folder to be a valid Spring
configuration file [...].
It also treats any xml files in /OSGI-INF in the same way.