Backport DataObjectRepository.getUuids() from v2.x to v1.2.x

FESAPI
1

Hello,

We were using FESAPI 1.2+ version to export/import RESQML 2.0.1 files to be consumed by other software.
When we moved to FESAPI 2.0 we realized that due to newly introduced namespaces in the .epc files other softwares are not accepting these files.
In future these softwares will probably adapt and accept the .epc files with namespaces, but in the meantime we are forced to revert back to using FESAPI 1.2+.

We noticed that in v 1.2+ DataObjectRepository.getUuids() method is missing, this method gives us ability to write generic code to deal with number of objects types.
Is there a way you could backport this method to v 1.2+ ?

If not possible, would you be able to help us with logic to get all the UUIDs from .epc file (using java) that we can use ?

We are using java wrapper, not C++.

Thanks,
Shakir

2

Hi @shakirhusain

What a pity that namespaces (or probably more likely directories) in EPC cause a problem. If this is cause of FESAPI, please just detail the problem and I will fix it in next 2.1 version.

Backporting DataObjectRepository.getUuids() in v1.2.* looks quite easy at a first glance.
We probably just have to copy all getUuids method definitions and implementations from master branch to 1.2.2 branch in these 3 files :

  • src\common\DataObjectRepository.h
  • src\common\DataObjectRepository.cpp
  • swig\swigModule.i

Once copied, a CMake generation is needed to take into account the JAVA wrapping and then a build is required as well to create the dll and the jar.

I’ll give a try when I’ll have time.
You can also give a try by yourself and if succesful push a PR on Github in order to share this new 1.2 version with the community if you want to.

1 Like
3

Thanks for your response Philippe!

A follow-up:
As far as I see both FESAPI 1.2+ and 2.0 can consume the RESQML file produced by each other.
Could you please confirm this understanding ?

Thanks,
Shakir

4

Yes, the EPC files produced by FESAPI V1.* and/or FESAPI V2.* (and even future versions) are all valid from a standard point of view.
Thus, they must be readable by all FESAPI versions. If it is not the case, this is a critical bug and I would fix it asap. As far as I know, such a bug have never been reported to me and I personally exchange between FESAPI2 and FESAPI1 quite often.

The only bug which has been reported to me is cause of the PRODML namespace in FESAPI2. If you export PRODML data with FESAPI2, some softwares cannot read them cause of a FESAPI2 bug. It is only on PRODML data (not RESQML, WITSML, EML data).
The fix is done in master branch and will be part of FESAPI 2.1 version.

1 Like
5

Hello Philippe,

We made changes in the files you mentioned above on 1.2.2 (in line with the revision done by mpoudret on 30th Sept 2020) but noticed that the .jar file does not contain the new method getUuids().
The generated DataObjectRepository.java file has the getUuids() method though.

We also open the generated .dll in DLL Export Viewer tool and did not find getUuids method there as well.
Could you please comment, if we are missing any other changes ?

Thanks,
Shakir

6

Hi Shakir,

My mistake, sorry.
In v1., swig\swigModule.i is actually generated by cmake and cannot be modified by hand. This has only been modified in v2..
Instead of modifying swig\swigModule.i, you would have had to change cmake/swigModule.i (and cmake/swigModule_experimental.i if needed)

I created a branch for a v1.2.3.0 release : GitHub - F2I-Consulting/fesapi at v1.2.3.0
This branch already contains the modifications. If you can try it, that would be perfect and if it is OK, I will release it.

7

Hello Philippe,

We built and tested for windows and it looks good.
We will do the same for linux tomorrow.
Could you please go ahead and release it ?

Thanks,
Shakir

8

Thanks Shakir for the test.
I just released it : Release v1.2.3.0 · F2I-Consulting/fesapi · GitHub