[oXygen-user] configuring a custom calabash

[George Cristian Bina]

Hi Gerrit,

If setting a Calabash configuration and a Saxon configuration file is 
not enough then we can also provide you the source code for the Calabash 
connector so you can perform other additional customizations to the 
XProc engine.

As XProc was added more recently to oXygen, we developed this pluggable 
engine support that deprecated the external custom engines for XProc, 
because any engine can be integrated through this support (Calumet also 
has support for this) and it benefits of full integration supporting 
transformations, validation and passing parameters.

Best Regards,
George
--
George Cristian Bina
<oXygen/> XML Editor, Schema Editor and XSLT Editor/Debugger
http://www.oxygenxml.com

On 3/19/13 4:38 PM, Oxygen XML Editor Support wrote:
> Hi,
>
> I'd like to mention a few additional things for clarification.
> Oxygen provides a connector for Calabash that implements the interface
> XProcTransformerInterface:
> ro.sync.xml.transformer.xproc.calabash.XProcTransformerImpl. This is
> used with the default Calabash engine that is bundled with Oxygen:
> Oxygen/lib/xproc/calabash.
>
> You can actually duplicate the "calabash" folder from Oxygen/lib/xproc
> in the same folder (e.g. Oxygen/lib/xproc/calabashCustom) and you can
> then customize the duplicate in any way you want. Just make sure it has
> a different name specified in the engine.xml file. Oxygen will detect
> all the custom engines from the Oxygen/lib/xproc and list them (by name)
> when configuring an XProc transformation. I was under the impression
> that only one engine works, but I see that it correctly detects multiple
> engines in v14.2.
>
> If you want to use a Calabash config file, simply copy it to the folder
> of the calabash engine (Oxygen/lib/xproc/<engine>) and make sure it is
> named: "calabash.config". Similarly a "saxon.config" file is supported
> for the configuration of Saxon when invoked from Calabash. The support
> for these configuration files is implemented in the Oxygen Calabash
> connector in case you're wondering.
>
> Let me know if you need additional assistance.
>
> Regards,
> Adrian
>
> Oxygen XML Editor Support wrote:
>> Hello,
>>
>>
>>> The first problem that I ran into was that Windows gave an access
>>> denied error. I knew that it was Windows because it was in German
>>> while my oXygen installation is in English.
>>>
>>> This will become important to overcome later because the custom
>>> Calabash needs to run on users’ computers. They don’t have admin
>>> privileges.
>> Regarding the first problem, that shouldn't have happened unless it's
>> trying to write to a folder with no write access (maybe the Oxygen
>> installation folder from "Program Files").
>>
>>> So I ran oXygen as admin. Then it ran in principle, but the (command
>>> line?) options – input and output ports, the pipeline, and options –
>>> that I configured in the transformation scenario apparently weren’t
>>> passed to the script. The output was only the usage information of my
>>> custom calabash.
>> Unfortunately, none of the options/parameters from the XProc scenario
>> can currently be passed to the custom engines. If the command line
>> allows it, you will have to do manually do this in the custom engine
>> configuration. Only the XProc document is passed: ${xproc}
>>
>>
>>> In the help I read an entry called “Integration of an External XProc
>>> Engine”. I don’t know whether that is relevant to my problem. Do I
>>> really have to implement
>>> ro.sync.xml.transformer.xproc.api.XProcTransformerInterface myself?
>>> What’s the purpose of being able to configure an external script /
>>> Java invocation as XProc engine?
>> That's meant for developers who would want to integrate their XProc
>> engine into Oxygen. AFAIK, Calabash doesn't implement this interface
>> (XProcTransformerInterface).
>>
>>
>>> When I think about configuring an engine.xml file for my purposes,
>>> I’m unsure how to map Calabash’s -c option, where I specify an option
>>> to use our configuration file that maps a step name to a class that
>>> implements an extension.
>>>
>>> The config file is here:
>>> https://subversion.le-tex.de/common/calabash/lib/ltx-unzip/ltx-config.xml
>>>
>>>
>>> If someone at syncro soft wants to play around with the custom
>>> Calabash, just check it out with svn.
>> That's only meant to work together with the implemented interface.
>>
>>
>> I believe you should rather try to use the custom calabash in place of
>> the built-in one that Oxygen provides in: Oxygen/lib/xproc/calabash
>> Make a copy of that folder (place it somewhere else, NOT in
>> Oxygen/lib/xproc) and customize the existing engine.xml with what you
>> need, update the jars, etc.
>>
>> Regards,
>> Adrian
>>
>> Adrian Buza
>> oXygen XML Editor and Author Support
>>
>> Tel: +1-650-352-1250 ext.202
>> Fax: +40-251-461482
>> support at oxygenxml.com
>> http://www.oxygenxml.com
>>
>>
>> Imsieke, Gerrit, le-tex wrote:
>>> I’m running oXygen 14.2 on Windows 7 64bit.
>>>
>>> I tried to configure a customized calabash. There’s a calabash.bat
>>> file, https://subversion.le-tex.de/common/calabash/calabash.bat, that
>>> I checked out locally and specified as a custom processor, but I also
>>> tried to give the Java invocation explicitly, as seen in my project
>>> configuration:
>>>
>>>                                   <field name="cmd">
>>>                                       <String>java -cp
>>> ${pd}/calabash/resolver/resolver.jar;${pd}/calabash/resolver;${pd}/calabash/calabash.jar;${pd}/calabash/lib;${pd}/calabash/lib/ltx-unzip
>>> -Dfile.encoding=UTF8
>>> -Dxml.catalog.files=${pdu}/calabash/resolver/catalog.xml
>>> -Dxml.catalog.catalog-class-name=org.apache.xml.resolver.Resolver
>>> com.xmlcalabash.drivers.Main -E
>>> org.apache.xml.resolver.tools.CatalogResolver -U
>>> org.apache.xml.resolver.tools.CatalogResolver -c
>>> ${pdu}/calabash/lib/ltx-unzip/ltx-config.xml </String>
>>>                                   </field>
>>>
>>> The first problem that I ran into was that Windows gave an access
>>> denied error. I knew that it was Windows because it was in German
>>> while my oXygen installation is in English.
>>>
>>> This will become important to overcome later because the custom
>>> Calabash needs to run on users’ computers. They don’t have admin
>>> privileges.
>>>
>>> So I ran oXygen as admin. Then it ran in principle, but the (command
>>> line?) options – input and output ports, the pipeline, and options –
>>> that I configured in the transformation scenario apparently weren’t
>>> passed to the script. The output was only the usage information of my
>>> custom calabash.
>>>
>>> In the help I read an entry called “Integration of an External XProc
>>> Engine”. I don’t know whether that is relevant to my problem. Do I
>>> really have to implement
>>> ro.sync.xml.transformer.xproc.api.XProcTransformerInterface myself?
>>> What’s the purpose of being able to configure an external script /
>>> Java invocation as XProc engine?
>>>
>>> When I think about configuring an engine.xml file for my purposes,
>>> I’m unsure how to map Calabash’s -c option, where I specify an option
>>> to use our configuration file that maps a step name to a class that
>>> implements an extension.
>>>
>>> The config file is here:
>>> https://subversion.le-tex.de/common/calabash/lib/ltx-unzip/ltx-config.xml
>>>
>>>
>>> If someone at syncro soft wants to play around with the custom
>>> Calabash, just check it out with svn.
>>>
>>> Thanks for your help.
>>>
>>> Gerrit
>>>
>>> _______________________________________________
>>> oXygen-user mailing list
>>> oXygen-user at oxygenxml.com
>>> http://www.oxygenxml.com/mailman/listinfo/oxygen-user
>>>
>>>
>>
>>
>