Log In
Register
Forum
Topic RSS
14:28, EET
June 8, 2016
Offline
With SDK 4 I used to have code generation like this:
1. Client Code generates with target common,client_base,client_impl
2. Server Code generates with target server_base,server_impl
When I try this with SDK 5 – I get the problem:
1. com.prosysopc.ua.types.di.server.BlockTypeNodeBase tries to import com.prosysopc.ua.types.di.BlockType (missing out the “objecttypes” sub-package)
2. but under #1, the FQCN is com.prosysopc.ua.types.di.objecttypes.BlockType
3. also the namespaceMapping was somehow required, so I declared mapping from http://opcfoundation.org/UA/DI/ to com.prosysopc.ua.types.di
When I try the the following with SDK 5 – it works:
Use target “all”:
1. com.prosysopc.ua.types.di.objecttypes.server.BlockTypeNodeBase imports com.prosysopc.ua.types.di.objecttypes.BlockType
2. as before,the FQCN is com.prosysopc.ua.types.di.objecttypes.BlockType, so this import works
Could not find anything related under https://downloads.prosysopc.com/opcua/Prosys_OPC_UA_SDK_for_Java_4_To_5_Migration_Guide.html#code-generator
Also looked into prosys-opc-ua-sdk-for-java-5.2.6-151-client-server-binary/codegen/Prosys_OPC_UA_SDK_for_Java_Codegen_Manual.html#generation-targets
As for now, I will probably move to generating all code at once using targets “all”.
15:22, EET
April 3, 2012
Offline
Hi,
Can you doublecheck that the namespaceMappings configuration is exactly identical in both 1&2 (other than the targets part)?
Hmm.. seems the migration guide misses this part (we might add in the future), but the Codegen Manual section 4.3.2. ‘Namespace Mapping Parameters’ at least does mention
“
Starting from 5.0.0, a separate subpackage is used for each NodeClass, by default. This can be disabled by setting nodeClassSpecificPackageNames as false. For example, for the Device Information (DI) model, the configuration could look like:
<namespaceMappings>
…
<namespaceMapping>
<uri>http://opcfoundation.org/UA/DI…..ri>
<packageName>com.prosysopc.ua.types.di</packageName>
<prefix>Di</prefix>
<nodeClassSpecificPackageNames>false</nodeClassSpecificPackageNames>
</namespaceMapping>
…
…
“
(EDIT: we really need a better tool for code snippets here… anyway while the ‘uri’ above looks a bit funny I think the example is still somewhat clear)
That fixed some issues with some information models using the same BrowseName for DataTypes and VariableTypes, which caused generation issues in the past (thus enabled by default).
If you happened to have different values for nodeClassSpecificPackageNames in 1 and 2 it would have caused that. If they are identical then it is most likely a bug.
P.S.
I think (but cannot fully remember) we did require the namespaceMapping already before 5.x since the DI, ADI, PLCOpen internal hardcodings were removed. In practice since applications should generate them, since those move faster than the SDK and/or they do not contain UA Method implementations they also kinda should be in your applications namespaces, not something we hardcode.
Most Users Ever Online: 1919
Currently Online:
13 Guest(s)
Currently Browsing this Page:
1 Guest(s)
Top Posters:
Heikki Tahvanainen: 402
hbrackel: 144
rocket science: 88
pramanj: 86
Francesco Zambon: 83
Ibrahim: 78
Sabari: 62
kapsl: 57
gjevremovic: 49
Xavier: 43
Member Stats:
Guest Posters: 0
Members: 726
Moderators: 7
Admins: 1
Forum Stats:
Groups: 3
Forums: 15
Topics: 1529
Posts: 6471
Newest Members:
gabriellabachus, Deakin, KTP25Zof, Wojciech Kubala, efrennowell431, wilfredostuart, caitlynfajardo, jeromechubb7, franciscagrimwad, adult_galleryModerators: Jouni Aro: 1026, Pyry: 1, Petri: 0, Bjarne Boström: 1032, Jimmy Ni: 26, Matti Siponen: 349, Lusetti: 0
Administrators: admin: 1
