I'm migrating a custom PDF plugin from DITA OT 2.4.4 to 2.5.4. It worked fine in DITA 2.4.4, but in 2.5.4, some elements are missing from the output. I've been able to work around this by adding templates for the missing elements to the custom plugin. The one I haven't been able to fix is for conditions to the body text (such as using the product attribute like ). Conditions are correctly included and excluded in the title, but not in the body of the topic.
I've looked in the provided org.dita.pdf2 plugins, but I can't find where conditions are filtered. Any suggestions on how to fix this? Thanks.
The filtering of DITA elements based on filters specified in the DITAVAL files is not done in the XSLT code, it's done in Java pre-processing steps.
So if your PDF plugin defines a separate transformation type and has ANT build files, maybe you could try to update those, if you copied ANT targets from the base PDF plugin, try to see how they changed. But it depends really on your particular PDF plugin, most PDF plugins which contribute a transformation type only use it to specify a PDF customization folder in the custom ANT build file.
I'm looking at my plugin and build files. I'm using the build_preprocess.xml from org.dita.base. The plugin doesn't have its own build file, but adds some conditions in the integrator.xml file, such as:
<!-- [Kofax] 2016-Apr-14 MAS: Passes through the command-line parameter for selecting the branding and sets
corporate as the default. -->
<condition property="title.branding" value="${title.branding}" else="corporate">
<isset property="title.branding"/>
</condition>
</target>
The plugin also has a root-processing.xsl file that has overrides to update the PDF's metadata.
Is there somewhere else I should look in my plugin?
Thanks,
Matthew
Related
jEdit is great, and I would like to include it in JTabbedPane.
From the API it seems to be possible but I have been unable to achieve this.
By any chance do you have a simple example that works ?
Do you mean just the text area?
Well, you can build the text area as library JAR for you to use with the ant target build-textArea.
But be aware that the standalone textarea is also under GPL like whole rest of jEdit, so if you plan to release your work, you have to release it under GPL too. If it is just for your private use, you can use it like you want of course.
The package also has StandaloneTextArea which demonstrate how to use the text area outside jEdit. You can just run the built JAR, it is an executable JAR that runs this example StandaloneTextArea.
I have found a plugin (EELSTools.gtk from http://www.dmscripting.com) which I want to modify.
The plugin contains nearly every function I need, but I want also to integrate some extra functions.
Does anyone know how to open .gtk files?
You can't and shouldn't.
*.gtk files are packages files with the purpose of encapsulation. This might either be because of convenience, but it might as well be, because the author does not want to make the code open-source. (Note that there are some proprietory plugins as well, they are also .gtk files.)
If you have found a plugin and want to expand on it, the best way forward is to contact the plugin-author.
The *.gtk files get loaded before *.s files. If you install your own script from DM Menu Install Script File or Install Script, you can add it to the menu that the *.gtk file has, e.g. EELSTools. It is added at the end of the list. For example, I put a measure ZLP width script in EELSTools.
I'm developer on a big system (>100 Projects in Solution, >100 000 LOC, > 10 Services, ...) and did the installation of this system in the past with wix and it worked fine. Now I need a way to patch (Minor Upgrade) parts of the system and run into several issues.
My Current Wix Setup is as following:
I have VS2010 and Wix3.6 Toolset and TFS2012 to Build the whole thing and get an installer
I'm using a Setup Library Project Type per Service
I'm using exactly one Setup Project to bundle things together and get one installer for the whole system.
It's not possible to change this setup.
The Setup Library Projects are set up as following:
I use the heat-directory msbuild task to generate the components and files and I'm using preprocessor variables to modify the file paths.
I need to modify the file paths because it must be possible to build an installer on the local developer system and to build the installer on the tfs build system which is different in folder structures.
The TFS uses always the same directory to compile subsequent versions of the software and moves the output after successful compilation to a unique folder structure.
Now I need a patch.
I created the Patch.wxs and called candle and light for it. I called torch to get the difference file. And finally want to create the patch with pyro.
Everything worked fine with a simple testproject, but on the big system
Pyro has the problem that it can't find the files to install.
Through my setup (see above), I must use preprocessor variables and have a full qualified path in my wix output (for example: C:\builds\myproduct\prodct.exe as file source). After moving the TFS output to another location this path is not valid anymore. I tried to use -bt and -bu switches for pyro, but this does only work for relative paths or for named bindpaths.
Now I wanted to change my wix project setup to use named bindpaths rather than preprocessor variables, but it seems that this is not possible.
heat can only use preprocessor variables or wixvariables but it seems not to be possible to use bindpath variables. heat provides a switch -wixvar which should create binder variables instead of preprocessor variables but I does exactly nothing.
Now I tried do use no wix and no preprocessor variables in heat and tell light per -bu -bt switches where to find the files. But if I do not set a preprocessor variable the resulting files look like Sources\product.exe. I can't get rid of this Sources. I know that I can transform all the xml with xslt and remove the Sources but thats a workaround which I would only implement if no other solution is possible. This would also mean that there is a problem in the wix toolchain.
It looks like pyro does only support bindpath variables and heat does only support preprocessor and wix variables. This seems to be really crazy, because how should they work together?
How can I create a patch if I use lit, light, candle, heat, torch and pyro and if the original build paths have changed (which is very common on a build system) and the file paths are created with heat and therefore be fixed or preprocessor or wix variables?
As you've found heat wasn't designed to be used in the patching scenario. It was only in recent versions of the WiX toolset that the generated GUIDs got to a point where there was even a chance that heat could successfully build output that would be patchable. Still need to do work there to make patching where heat is used work well.
Ultimately, I believe the answer is to simplify the "original source" problem. It is challenging to get all the bindpaths set up correctly and that makes patching, which is a hard problem, even harder. We've kicked around a few ideas but nothing has come together yet.
You could always use admin image based patching. It's slower but can be easier to get the "original source" and "target" laid out. That path does lose filtering though.
Basically, we need to do a bit more work in patching scenarios to make it much easier.
PS: "Source" in the path for a File/#Source attribute is an alias for the "default bindpath". You can use bindpaths there.
I am building an eclipse rcp application. For the Drag and Drop functionality of resources I need extraset of validations. Eclipse doesn't suggest to subclass the ResourceDropAdapterAssistant. So I modified the code for ResourceDropAdapterAssistant which is in the package org.eclipse.ui.navigator.resources.
Now what is the best way to put this feature back to my eclipse? I have gone through this link. http://eclipsesource.com/blogs/2012/07/30/patching-your-own-eclipse-ide/
It has helped me to create a feature patch. But I am clear when I create the feature patch should I include only the modified class or all classes and packages under the plug-in?
Regards,
Priyank Thakkar
It should to only copy the .class files for the modified java files. However, I have created several feature patches and just find it easier and less error prone to include all .class files. So, that is what I would recommend doing.
Remember though that by default, a feature patch applies to exactly one version of the released feature. However, you can modify the created p2 metadata to expand the range. See these excellent blog posts for more information:
http://aniefer.blogspot.com/2009/06/patching-features-with-p2.html
http://aniefer.blogspot.com/2009/06/patching-features-part-2.html
Is there any way to create a new text file and write to it using Wix? I have come across elements that will allow me to work with Xml files and Ini files, but nothing for a plain text file.
The root of the problem stems from the fact that we're using a third party library that reads from its own custom configuration file, which really ties my hands as to what the text file can look like. The configuration file is similar to an Ini file, minus the "sections." And I've noticed that Wix handles Ini files by always placing them in the system folder, which won't work for our needs.
The data that needs to be written to the configuration file is gathered at run-time, so there's no opportunity to simply lay down a pre-configured file.
I would be willing to accept a Wix extension to accomplish the same result if one exists, but haven't come across one yet.
There is no built-in feature in Windows Installer for this. You'll have to write code to do it and invoke that code with a custom action.
The IniFile element can write .ini files anywhere; use the #Directory attribute to specify which directory it should go in. If the library ignores [section] lines, you can use anything as the #Section attribute value.
You might want to have a look at this project. It contains the collection of WiX extensions and custom actions, and I suppose it also has CA to read and write text files. Try it out - it is claimed to be tested and proved by using in enterprise installations.