What are the steps needed in DITA-OT to pass ANT command line parameters to custom plugin's override XSLT-script - plugins

This question follows this: Is it possible to pass custom ANT parameters into custom plugin with DITA-OT?
I have plugin folder called: com.mymods.pdf under DITA-OT/plugins folder. Under is explained the structure and files shortly (follows this example closely http://dita-ot.github.io/1.8/readme/dita2pdf-customization.html). Plugin works but now I want to pass ANT command line parameters into mycustom.xsl:
com.mymods.pdf/
cfg/
common/
vars/
en.xml
fo/
attrs/
mycustom.xsl
xsl/
mycustom.xsl
catalog.xml
integrator.xml
plugin.xml
build_mymods_pdf_template.xml (dita2com.mymods.pdf.init target is here and it depends on dita2pdf2)
build.xml (<project><import file="build_mymods_pdf.xml"/></project>)
insertParameters.xml (see the linked question for contents)
So where I need to apply changes and/or add new files?
I use the plugin from other location with "mainANT.xml" which has target and transtype for using "dita2mymodsPDF".
plugin.xml code:
<?xml version='1.0' encoding='UTF-8'?>
<plugin id="com.mymods.pdf">
<require plugin="org.dita.pdf2" />
<feature extension="dita.conductor.transtype.check" value="com.mymods.pdf" />
<feature extension="dita.transtype.print" value="com.mymods.pdf" />
<feature extension="dita.conductor.target.relative" file="integrator.xml" />
<feature extension="dita.conductor.com.mymods.pdf.param" file="insertParameters.xml"/>
<extension-point id="dita.conductor.com.mymods.pdf.param" name="PDF XSLT parameters"/>
</plugin>
build_mymods_pdf_template.xml code:
<?xml version='1.0' encoding='UTF-8'?>
<project name="com.mymods.pdf" default="com.mymods.pdf">
<property name="transtype" value="com.mymods.pdf"/>
<target name="dita2com.mymods.pdf.init">
<property location="${dita.plugin.com.mymods.pdf.dir}/cfg" name="customization.dir" />
<property location="${dita.plugin.com.mymods.pdf.dir}/xsl/fo/topic2fo_shell_fop.xsl" name="args.xsl.pdf" />
<property name="args.chapter.layout" value="BASIC" />
<property name="args.bookmark.style" value="COLLAPSED" />
<!--property name="args.fo.include.rellinks" value="nofamily" /-->
</target>
<target depends="dita2com.mymods.pdf.init, dita2pdf2" name="dita2com.mymods.pdf" />
</project>
Also integrator.xml code:
<?xml version='1.0' encoding='UTF-8'?>
<project name="com.mymods.pdf">
<target name="dita2com.mymods.pdf.init">
<property location="${dita.plugin.com.mymods.pdf.dir}/cfg" name="customization.dir" />
<property location="${dita.plugin.com.mymods.pdf.dir}/xsl/fo/topic2fo_shell_fop.xsl" name="args.xsl.pdf" />
<property name="args.chapter.layout" value="BASIC" />
<property name="args.bookmark.style" value="COLLAPSED" />
<!--property name="args.fo.include.rellinks" value="nofamily" /-->
</target>
<target depends="dita2com.mymods.pdf.init, dita2pdf2" name="dita2com.mymods.pdf" />
</project>
Not totally sure whether integrator.xml or build_mymods_pdf_template.xml is like it actually should. But this fileset works and uses mycustom.xsl (other for attributes and other for XSLT overrides). Now the problem is that how to get my own custom ANT parameters so the plugin can see its value.
This is really easy for pdf2 plugin but still can't yet get it working inside my com.mymods.pdf . I think I don't need to post catalog.xml because it just tells where are "mycustom.xsl" files that are working properly.

Really easy way, not the cleanest way to do this is:
Note: This applies for DITA-OT 1.8.4 check suitability for other versions.
Create your custom PDF plugin as told in: http://dita-ot.github.io/1.8/readme/dita2pdf-customization.html
Create "insertParameters.xml" as in: http://dita-ot.github.io/1.8/dev_ref/plugin-xsltparams.html
In my case with following custom parameters:
<?xml version='1.0' encoding='UTF-8'?>
<dummy>
<!-- EXAMPLE: <param name="paramNameinXSLT" expression="${antProperty}" if="antProperty"/> -->
<param name="custom.data1" expression="${custom.data1}" if="custom.data1"/>
<param name="custom.data2" expression="${custom.data2}" if="custom.data2"/>
</dummy>
Now drop this "insertParameters.xml" into DITA-OT\plugins\org.dita.pdf2
Create processing to custom.xsl under xsl\custom.xsl.
Here is an example code snippet for custom.xsl
<?xml version='1.0' encoding='UTF-8'?>
<snippet>
<xsl:param name="custom.data1"/>
<xsl:param name="custom.data2"/>
<fo:block><xsl:value-of select="$custom.data1"/></fo:block>
<fo:block><xsl:value-of select="$custom.data2"/></fo:block>
</snippet>
Run integrator.xml to integrate changes into your DITA-OT.
Give in command line commands for running your PDF scenario like: "ant dita2mypdf -f -Dcustom.data1="myCustomParameter1value" -Dcustom.data2="myCustomParameter2value"
Run the process to create PDF and your parameters should be visible!
What this question was really intended to achieve to get a step by step instruction to set all these things to work 100% in the custom plugin that not a single thing needs to be added into DITA-OT default plugins (not even single file into pdf2 folder as in this solution). This could make updating DITA-OT remarkably easier for future.

The cleaner? alternative to this approach is
add a placeholder insertParameters.xml to the root of the DITA-OT 1.8.5. The file does not exist in the standard DITA-OT 1.8.5
<?xml version='1.0' encoding='UTF-8'?>
<dummy>
<param name="dummy" expression="{$dummy} if="dummy"/>
</dummy>
add the override insertParameters.xml to the root of your plugin
<?xml version='1.0' encoding='UTF-8'?>
<dummy>
<param name="my.runtime.parameter" expression="{$my.runtime.parameter} if="my.runtime.parameter"/>
</dummy>
Then run ant -f integrator.xml

Without knowing precisely which parameters you need to pass, it's difficult to answer this question. However, let's assume you're invoking this from the command line and you've defined a transtype of mymodspdf. The command would look like this:
ant -f build.xml -Dtranstype mymodspdf -Dmyparameter1 paramval1 -Dmyparameter2 paramval2
HTH,
Julio J. Vazquez
Write Spirit
http://www.writespiritservices.com

Related

In dita-ot is it possible to integrate into a feature extension for a specific transtype only?

Specifically, I have a custom dita-ot xhtml plugin which uses the <feature extension="dita.xsl.xhtml" file="xsl/header.xsl"/> to integrate into the xhtml pipeline. But this extension is used by the default xhtml output as well. I don't want this. Is there a way to run my extensions only for my own plugin?
A small example (brandheader example from the dita-ot documentation) which demonstrates the described behavior:
plugin.xml:
<?xml version="1.0" encoding="UTF-8"?>
<plugin id="com.example.brandheader">
<feature extension="ant.import" file="build.xml" />
<feature extension="dita.xsl.xhtml" file="xsl/header.xsl"/>
<transtype name="xhtml-extension" />
</plugin>
build.xml:
<?xml version="1.0" encoding="UTF-8"?>
<project name="com.example.xhtml.extension" basedir=".">
<target name="dita2xhtml-extension" depends="dita2xhtml"/>
</project>
header.xsl:
<?xml version="1.0" encoding="UTF-8"?>
<xsl:stylesheet version="1.0" xmlns:xsl="http://www.w3.org/1999/XSL/Transform">
<xsl:template name="gen-user-header">
<div>
<img src="https://www.dita-ot.org/images/dita-ot-logo.svg" alt="Example Company Banner"/>
</div>
</xsl:template>
</xsl:stylesheet>
The customized header appears for the xhtml transtype as well as for the xhtml-extension transtype.
I searched on stackoverflow for a similar question and I read the dita-ot developer documentation. But I couldn't find an option to enable the extension only for my plugin.
I am happy about any input.
Another option is to override the main XSLT used for processing in your custom XHTML plugin's build file:
<target name="dita2xhtml-custom"
depends="dita2xhtml-custom.init,
dita2xhtml"/>
<target name="dita2xhtml-custom.init">
<property name="args.xsl"
location="${dita.plugin.com.example.xhtml-custom.dir}/custom-main.xsl"/>
</target>
and your custom-main.xsl would import the xhtml XSLT stylesheet like:
<xsl:import href="plugin:org.dita.xhtml:xsl/dita2xhtml.xsl"/>
and add your own templates to the custom-main.xsl to override templates in the dita2xhtml.xsl.
Your "header.xsl" XSLT stylesheet will indeed be taken into account for any transformation type extended from the base XHTML one.
But what you could do would be to define in your plugin.xml an extension point with the name dita.conductor.xhtml.param:
https://www.dita-ot.org/dev/extension-points/all-extension-points.html#all-extension-points__dita.conductor.xhtml.param
Something like this:
<feature extension="dita.conductor.xhtml.param" value="params.xml" type="file"/>
and the params.xml file could contain:
Then in your XSLT stylesheet you define a global xsl:param named "TRANSTYPE" and you should receive on it the value of the transtype from the DITA OT build files, making it possible to take decisions in the custom XSLT templates based on the current transformation type.

Phing update version number in XML manifest

I need to add the ability to a phing build to:
Parse an existing xml file within the project area to get an existing build number (in format 1.2.3)
Ask the user what type of 'change' this is (i.e. major, minor, fix)
Based on the response of the user at the time of run, upgrade the respective digit from the build number (if major increase 1 by 1; if minor increase 2 by 1; if fix increase 3 by 1)
Store the build number back into the original xml file
Have the new build number available for use when naming a zip file (later in the build).
Wondering if anyone already has a phing build file that does something like this or if you happen to know what phing tasks might help with these steps?
As a starting point you could do it without overhead using the version task (it uses a property file to store the version information) or with some more effort from a xml file.
The following example build script (documentation links can be found in the description attributes) contains both ways.
<?xml version="1.0" encoding="UTF-8" ?>
<project name="version test"
default="help"
phingVersion="3.0"
description="https://stackoverflow.com/questions/68584221/phing-update-version-number-in-xml-manifest"
>
<target name="help" description="usage help">
<echo>Usage:</echo>
<echo>bin/phing xml-file-based-workflow</echo>
<echo>bin/phing property-file-based-workflow</echo>
</target>
<target name="xml-file-based-workflow"
description="version handling with xml file"
depends="user-input,handle-xml-version,use-version"
/>
<target name="property-file-based-workflow"
description="version handling with property file"
depends="user-input,handle-property-version,use-version"
/>
<target name="user-input"
description="https://www.phing.info/guide/hlhtml/#InputTask"
hidden="true"
>
<input message="what is your release type?" propertyName="release.type" defaultValue="Bugfix"/>
</target>
<target name="handle-property-version"
description="https://www.phing.info/guide/hlhtml/#VersionTask"
hidden="true"
>
<version releasetype="${release.type}" file="VERSION.txt" property="version.number"/>
</target>
<target name="handle-xml-version"
description="
https://www.phing.info/guide/hlhtml/#XmlPropertyTask
https://www.phing.info/guide/hlhtml/#EchoPropertiesTask
https://www.phing.info/guide/hlhtml/#VersionTask
https://www.phing.info/guide/hlhtml/#DeleteTask
https://www.phing.info/guide/hlhtml/#EchoXMLTask
"
hidden="true"
>
<xmlproperty file="VERSION.xml" />
<echoproperties destfile="VERSION.txt" regex="/version\.number/"/>
<version releasetype="${release.type}" file="VERSION.txt" property="version.number"/>
<delete file="VERSION.txt"/>
<echoxml file="VERSION.xml">
<version>
<number>${version.number}</number>
</version>
</echoxml>
</target>
<target name="use-version"
description="https://www.phing.info/guide/hlhtml/#EchoTask"
hidden="true"
>
<echo message="${version.number}" />
</target>
</project>

sun_checks.xml location in checkstyle-idea.xml

My checkstyle-idea.xml looks like:
<?xml version="1.0" encoding="UTF-8"?>
<project version="4">
<component name="CheckStyle-IDEA">
<option name="configuration">
<map>
<entry key="active-configuration" value="CLASSPATH:/sun_checks.xml:The default CheckStyle rules" />
<entry key="check-nonjava-files" value="false" />
<entry key="check-test-classes" value="false" />
<entry key="location-0" value="CLASSPATH:/sun_checks.xml:The default CheckStyle rules" />
<entry key="suppress-errors" value="false" />
<entry key="thirdparty-classpath" value="" />
</map>
</option>
</component>
</project>
And i can't seem to find this file in my Ubuntu 14.04. Searched everywhere. The only solution i see is to download it and replace that location.
But is there a way to understand where it is located now?
My /etc/environment doesn't contain it also. So where is it? Because CheckStyle works and checks the code in Idea.
The Checkstyle-IDEA plugin contains a copy of the Sun Checks (sun_checks.xml). It is contained in the root of the plugin's JAR file. The plugin JAR is usually located at:
Linux: ~/.<PRODUCT><VERSION>/config/plugins/CheckStyle-IDEA/lib/checkstyle-idea-4.5.2.jar
Windows: C:\Users\<YourUserName>\.<PRODUCT><VERSION>\config\plugins\CheckStyle-IDEA\lib\checkstyle-idea-4.5.2.jar
Version numbers may differ in your case. The part .<PRODUCT><VERSION> should appear as something like .IdeaIC13 (for IntelliJ IDEA version 13).
Note that you should not need to find this file. You should never change it or touch it in any way. If you need to change the rules configuration, create your own rule set and use that. You may of course create your own rule set based on a copy of sun_checks.xml.
For mac I located it by typing:
sudo find / -iname Checkstyle-IDEA
Which lead me to
~/Library/Application Support/IntelliJIdea15/CheckStyle-IDEA/lib
I was then able to open the jar with an archive program and make a copy of the sun_checks.xml for my own customization.

How can I let CruiseControl.NET/nant run all Unittest projects postfixed with .Test?

In our continuous integration setup, I would like to set up CruisControl.NET to automatically run all our unittests. However, I don't want to have to specify every unittest dll seperately in the configuration.
All the unittest projects are all postfixed with .Test (and all non-unittest projects are not). How can I configure CruiseControl.NET to run all the unittests from these projects (I am using v1.5.7256.1 of CruiseControl.NET)?
My current config attempt:
<nunit>
<path>$(nunit.path)</path>
<assemblies>
<assembly>$(working.dir)\**\*.Test.dll</assembly>
</assemblies>
</nunit>
I'm finding it very difficult to find documentation on this specific nunit element. Most pages I can find talk about using exec, nunit2 or another nunit element or the nunit-console commandline options.
I don't have much experience with managing the build environment and am working on an existing configuration where every assembly was specified separately in the following manner.
<nunit>
<path>$(nunit.path)</path>
<assemblies>
<assembly>$(artifact.dir)\test1.dll</assembly>
<assembly>$(artifact.dir)\test2.dll</assembly>
</assemblies>
</nunit>
Hence my failed attempt using wild cards.
EDIT:
Here is some extra xml of my configuration file to show the context a little bit:
<cruisecontrol xmlns:cb="urn:ccnet.config.builder">
<project name="MyProject">
<!-- whole bunch of other elements -->
<tasks>
<nunit>
<!-- see above -->
</nunit>
</tasks>
</project>
</cruiscontrol>
After Mightmuke's suggestion, I tried replacing the <nunit> element with his suggestion, but got the following exception: Unable to instantiate CruiseControl projects from configuration document. Configuration document is likely missing Xml nodes required for properly populating CruiseControl configuration. Unable to load array item 'property' - Cannot convert from type System.String to ThoughtWorks.CruiseControl.Core.ITask for object with value: ""
Then I tried to move the <property> and <foreach> element outside the element. Then I get the exception: Unused node detected: <property name="nunit.filelist" value="" />
I'm now trying to find out more about the <foreach> element and where I can put that, but somehow I find it hard to find any documentation about it.
EDIT2:
I found the documentation of the nunit task I'm using: http://ccnet.sourceforge.net/CCNET/NUnit%20Task.html
I specifies the element to be of type String[]. I'm not sure what that means... but it seems from the example that it just means that it must contain a list of child elements of the same name in Singular form.
PS: I realize this question is getting a bit out of hand... When the whole thing is solved, I'll try to edit it in such a format so that it might be useful to someone else later.
This is an example configuration if you were to use the nunit console.
<property name="nunit.filelist" value="" />
<foreach item="File" property="testfile" verbose="true">
<in>
<items basedir=".">
<include name="${working.dir}\**\*.Test.dll" />
</items>
</in>
<do>
<property name="nunit.filelist" value="${nunitfile.list + ' ' + testfile}" />
</do>
</foreach>
<exec program="nunit-console-x86.exe" failonerror="true" verbose="true">
<arg value="${nunit.filelist}" />
<arg value="/xml=nunit-results.xml" />
<arg value="/nologo" />
<arg value="/nodots" />
</exec>
This hasn't been tested, and there are likely better ways to skin it, but it will hopefully provide a starting point for you.

Publishing my asp.net mvc application via script and not Visual Studio

I dont really know much about this to be honest with you...
I have managed to download mscommunity build and I have managed to use the script below to successfully compile and build my application, however I want to get my asp.net mvc application "published" so I want the same files that you when clicking "publish" inside visual studio. My current build file looks like this:
<?xml version="1.0" encoding="utf-8"?>
<Project DefaultTargets="Build" xmlns="http://schemas.microsoft.com/developer/msbuild/2003">
<!-- Import the MSBuild Tasks -->
<Import Project="$(MSBuildExtensionsPath)\MSBuildCommunityTasks\MSBuild.Community.Tasks.Targets" />
<PropertyGroup>
<Configuration Condition=" '$(Configuration)' == '' ">Release</Configuration>
<ClassLibraryOutputDirectory>c:\publish\</ClassLibraryOutputDirectory>
<ProjectDir>..\PetProject\</ProjectDir >
<ProjectTestDir>$(ProjectDir)PetProject.WebUI\</ProjectTestDir >
<ProjectFile>$(ProjectDir)PetProject.sln</ProjectFile >
<TestProjectFile>$(ProjectTestDir)PetProject.WebUI.csproj</TestProjectFile >
</PropertyGroup>
<!-- Build projects by calling the Project files generated by VS -->
<Target Name="Build">
<MSBuild Projects="$(ProjectFile)" />
<MSBuild Projects="$(TestProjectFile)" />
</Target>
</Project>
I call this in command line using:
C:\Windows\Microsoft.NET\Framework\v3.5>msbuild.exe C:\Projects\PetProject\build
\PetProject.build
Help is greatly appreciated...
NOTE: I want to avoid CI, Nant etc. because I dont really know what they are and I ideally want to get the above working as First Base, then move onto other things like CI or whatever else, I dont want to confuse myself too much...
This should give you the same result as publishing from within Visual Studio:
<Project DefaultTargets="BuildAndPublish" xmlns="http://schemas.microsoft.com/developer/msbuild/2003">
<Import Project="$(MSBuildExtensionsPath)\Microsoft\VisualStudio\v10.0\Web\Microsoft.Web.Publishing.targets" />
<PropertyGroup>
<ProjectFile>C:\PetProject\PetProject.csproj</ProjectFile >
<OutDir>C:\PetProject\MyPublish</OutDir>
</PropertyGroup>
<Target Name="BuildAndPublish">
<MSBuild Projects="$(ProjectFile)" Targets="Package" Properties="Configuration=Release;PackageLocation=$(OutDir)\MSDeploy\Package.zip;_PackageTempDir=$(OutDir)\Temp" />
</Target>
</Project>
for your project.
Don't forget to import Microsoft.Web.Publishing.targets which contains the Package target (which I mixed up with Publish in my inital answer).
If you want to build your solution your script should look something like this:
<Project DefaultTargets="BuildAndPublish" xmlns="http://schemas.microsoft.com/developer/msbuild/2003">
<Import Project="$(MSBuildExtensionsPath)\Microsoft\VisualStudio\v10.0\Web\Microsoft.Web.Publishing.targets" />
<PropertyGroup>
<OutDir>C:\PetProject\MyPublish\</OutDir>
</PropertyGroup>
<ItemGroup>
<Solution Include="C:\PetProject\PetProject.sln">
<Properties>
OutDir=$(OutDir);
Platform=Any CPU;
Configuration=Release;
DeployOnBuild=True;
DeployTarget=Package;
PackageLocation=$(OutDir)\MSDeploy\Package.zip;
_PackageTempDir=$(OutDir)\Temp
</Properties>
</Solution>
</ItemGroup>
<Target Name="BuildAndPublish">
<MSBuild Projects="#(Solution)" />
</Target>
</Project>
There's a blog post by Code Inside which describes basically the same approach but didn't work when I tried it in my environment.