Our company used Pentaho Data Integration Community Edition (PDI-CE) 8.0 (Linux). We are upgrading to the PDI-CE 9.4. In the process, we met an issue.
To reproduce the issue, clone the project https://github.com/albertwangnz/reproduce-shared-objects-file-issue-pdice-9.4.
When we used PDI-CE 8.0, we used the feature Shared objects file in the transformation Miscellaneous tab. We defined database connections in different files to support different database engines. We set up a variable DB_CONN_SHARED_FILE in a previous transformation step. The value of the variable is the location of a shared object file (XML), like sharefiles/database-connections-mysql.xml. Then we used the variable as the value of the Shared objects file field as shown below. So, we could dynamically support various database engines, like MySQL, SQL Server, with the same *.ktr files.
It used to work in PDI-CE 8.0. But after we upgraded to PDI-CE 9.4, it does not work anymore. If we hard-code the value in the Shared objects file field, as shown below, like sharefiles/database-connections-mysql.xml, it works. But the variable does not work anymore.
I wonder if anyone met the same problem and knows how to fix it.
Thank you.
Regards,
Albert
The version of PDI-CE is 9.4.0.0-343
** The version of Linux is Ubuntu 18.04.6 LTS
Related
I'm writing my first KDE plasmoid using QML. The hello world example uses a metadata.desktop file, while this KDE Plasmoid tutorial talks about a metadata.json instead and says that the metadata.desktop is 'discouraged' now and a desktop file should be converted to json using desktoptojson.
However, when I browse the globally installed plasmoids under /usr/share/plasma/plasmoids/ they all have both the metadata.desktop and metadata.json.
First question: So, what is really recommended? Just the metadata.json? Or both?
And, I wasn't able to find the desktoptojson tool. I'm using Linux Mint and the ./kdesrc-build --initial-setup for debian based systems says that it's "This is woefully incomplete and not very useful" ... I read that "most users of this [i.e. desktoptojson] utility will use the CMake macro kservice_desktop_to_json as part of the process of building a plugin.". However, I haven't found the documentation yet how to use this.
Second question: In case one should maintain both files (for whatever reason), should I use desktoptojson to keep them in sync? And if yes, how?
Thanks!
First question: So, what is really recommended? Just the metadata.json? Or both?
In the current source code, most stock KDE applets such as the task manager use metadata.json's and have dropped the metadata.desktop's. It may be that the desktop files you have locally are left over from old versions, the new format was installed but the old one was never deleted.
Second question: In case one should maintain both files (for whatever reason), should I use desktoptojson to keep them in sync? And if yes, how?
The man page on Arch you linked to has all the information. The tool is part of the package kservice. Find the equivalent in the repository for your distribution. Then, to use it
as part of a CMake macro:
add_library(myplugin MODULE ${myplugin_SRCS})
kservice_desktop_to_json(myplugin myplugin.desktop)
directly on the command-line:
desktoptojson -i myplugin.desktop -o myplugin.json
When I register a .NET assembly enabled for COM interop using the REGASM tool, the tool creates a separate registry key for each component version. For example, I get:
HKEY_CLASSES_ROOT\CLSID\{myCLSID}\InprocServer32\1.0.0.0
HKEY_CLASSES_ROOT\CLSID\{myCLSID}\InprocServer32\1.1.0.0
etc.
Each of these registry contains roughly the same structure values as it is under HKEY_CLASSES_ROOT\CLSID{}\InprocServer32, except that the entries point to different locations, depending on the component version. The HKEY_CLASSES_ROOT\CLSID{myCLSID}\InprocServer32 apparently contains the latest registered version, and that's what COM consumers will normally use, of course, and they ignore the rest.
This structure apparently allows different versions of the component coexist on the same computer (I know it is against the originally specified COM rules). I would like to use it, but I could not find any documentation about it anywhere in the Microsoft documentation or Googling for it. Does anybody know? I am looking for something like CoCreateInstance/CoCreateInstanceEx with the version specifier.
Thanks
I have already built pypi package stored on pypi server few days back. Now I want to compare source code diff between already built pypi package and recent code built today. Is there any way to this?
I want to compare already built pypi package and newly build code. And If there is any difference in source code then only create a new package and upload it to pypi server
If you have only Python bytecodes, you cannot get the corresponding source code (that hypothetical transformation is called decompilation, and is not possible in general; read e.g. about Rice's theorem). Since any translation (such as the one done by the python program) from source code to bytecode is losing some information (e.g. name of local variables, comments explaining the intent of the code).
Equality of the behavior of functions by static analysis of their source code (and the observable behavior of your code is what you really care about) is an undecidable problem. Learn more about λ-calculus, it is deeply related to that question.
The source code (by definition, the preferred form of code on which developers work) is not only for computers, but mostly for fellow developers: in other words, most of its value and its meaning is a social one (and that is what free software is about). Read more about the semantics of programs.
For example, renaming a variable from i to x may convey the implicit hypothesis that the intended dynamic runtime type of the value of that variable was an integer, and becomes a floating point.
Maybe you want some kind of package manager (or some version control system, if you deal with source code, or some build automation tool, if you build then install software out of it). Python has something to manage packages. The scons build automation uses Python, but there are many other build automation tools, GNU make being a common one (that you could use to drive compilation from .py source files to .pyc bytecode files and their installation). For version control, I recommend git.
PS. Your question is very unclear and smells like some XY problem.
Once upon a time Windows SDK (or it was Visual Studio) had a tool named IROTVIEW which enumerated the Running Object Table (ROT).
Where can I get this tool now?
This site has a pretty good viewer for download in 32 bit and 64 bit versions.
This site has a simple enumeration class, but it needs some improvement since if you have two objects running with the same name (like two instances of Excel), it cannot populate the dictionary with the duplicate key.
Need To Set Version Information on the existing .dll
I need to add these to dll
1.File Version
2.Product Version
Tried this free version.
does not work
any Idea ?
There is a tool named verpatch that does exactly that.
After you download it you can run it from command line as below:
verpatch your.dll /pv "product.version" /va "file.version"
There are many other flags that can be used to add extra information.
Try:
verpatch /?
There is Resource Tuner Console from Heaventools Software.
Resource Tuner Console is a command-line tool that enables developers to automate editing of different resource types in large numbers of Windows 32- and 64-bit executable files.
See specifically the Changing Version Variables And Updating The Version Information page for greater details.
I've created a tool for this purpose because didn't find anything that is enough easy to use and easy to automate. Developers find it useful.
I'm sorry if that might seem as a self-ad but I know how annoying is to sync versions...