HAPI 3.2, Tinder and DSTU3 resources

[lukasz....@gmail.com]

Hey,
I would like to ask for pointers on how to get DSTU3 stubs generated with tinder or any other tool. James claimed under github issue #698, that it is not needed any longer because resource generation have been moved to HL7.

In the same topic there is information that tinder plugin is used to generate JPA stubs, however I can not find working configuration anywhere. Have anyone used tinder and STU3 together? If you did not, then maybe it would be worth to share information with community how you did it. :-)

Kind regards,
Lukasz

[James Agnew]

Hi Lukasz,

What kind of stubs are you looking to create?

The tinder plugin creates the JPA resource providers for STU3+ but not currently any data model classes. This is an example of the generated classes (it's the DSTU2 one, but the equivalent STU3/4 ones are also generated): http://hapifhir.io/xref-jpaserver/ca/uhn/fhir/jpa/rp/dstu2/PatientResourceProvider.html

You can see an example of how the plugin is used in the hapi-fhir-jpaserver-base/pom.xml file.

Cheers,

James

--
You received this message because you are subscribed to the Google Groups "HAPI FHIR" group.
To unsubscribe from this group and stop receiving emails from it, send an email to hapi-fhir+unsubscribe@googlegroups.com.
To post to this group, send email to hapi...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/hapi-fhir/d5e5b4f3-4e4a-49f5-ae2c-a1ddcad9b32d%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[lukasz....@gmail.com]

Hey James,
Thank you for picking it up so fast. I am building resource providers on top of different mechanism than JPA and I don't want to maintain something which might be generated. So far tinder worked fine for me with DSTU2 mode, however I need to include a Task resource which is missing there. When I switch tinder to use dstu3 it fails with following stack trace:

Caused by: org.apache.maven.plugin.MojoFailureException: Failed to load valuesets
    at ca.uhn.fhir.tinder.TinderGenericMultiFileMojo.execute(TinderGenericMultiFileMojo.java:271)
    at org.apache.maven.plugin.DefaultBuildPluginManager.executeMojo(DefaultBuildPluginManager.java:134)
    at org.apache.maven.lifecycle.internal.MojoExecutor.execute(MojoExecutor.java:208)
    ... 20 more
Caused by: java.lang.IllegalStateException: Fhir version not supported
    at ca.uhn.fhir.tinder.ValueSetGenerator.parse(ValueSetGenerator.java:103)
    at ca.uhn.fhir.tinder.AbstractGenerator.prepare(AbstractGenerator.java:114)
    at ca.uhn.fhir.tinder.TinderGenericMultiFileMojo.execute(TinderGenericMultiFileMojo.java:267)

Since I do not need JPA I am using "generate-multi-files" goal instead of "generate-jparest-server" used in jpa-base module. Now when I think about it, I could just try to override velocity templates to make it work with my base classes.

Best regards,
Lukasz

W dniu piątek, 16 lutego 2018 16:52:59 UTC+1 użytkownik James Agnew napisał:

Hi Lukasz,

What kind of stubs are you looking to create?

The tinder plugin creates the JPA resource providers for STU3+ but not currently any data model classes. This is an example of the generated classes (it's the DSTU2 one, but the equivalent STU3/4 ones are also generated): http://hapifhir.io/xref-jpaserver/ca/uhn/fhir/jpa/rp/dstu2/PatientResourceProvider.html

You can see an example of how the plugin is used in the hapi-fhir-jpaserver-base/pom.xml file.

Cheers,

James

On Fri, Feb 16, 2018 at 10:46 AM, <lukasz....@gmail.com> wrote:

Hey,
I would like to ask for pointers on how to get DSTU3 stubs generated with tinder or any other tool. James claimed under github issue #698, that it is not needed any longer because resource generation have been moved to HL7.

In the same topic there is information that tinder plugin is used to generate JPA stubs, however I can not find working configuration anywhere. Have anyone used tinder and STU3 together? If you did not, then maybe it would be worth to share information with community how you did it. :-)

Kind regards,
Lukasz

--
You received this message because you are subscribed to the Google Groups "HAPI FHIR" group.

To unsubscribe from this group and stop receiving emails from it, send an email to hapi-fhir+...@googlegroups.com.

[James Agnew]

Hi Lukasz,

Yeah, the multifiles thing hasn't been maintained, I doubt it works at this point. I would definitely recommend adjusting the generate-jparest-server task. It shouldn't be too hard to make the templates configurable.

Cheers,

James

To unsubscribe from this group and stop receiving emails from it, send an email to hapi-fhir+unsubscribe@googlegroups.com.

To post to this group, send email to hapi...@googlegroups.com.

To view this discussion on the web visit https://groups.google.com/d/msgid/hapi-fhir/08fec42f-90d3-4b73-b52e-e81b13693e75%40googlegroups.com.

[lukasz....@gmail.com]

I've managed to create a new goal which generates just resource provider classes, without Spring config (I'm not sure if I want it).

https://github.com/splatch/hapi-fhir/commit/7dc06b997476857a4a8e6fd6ce96944cde18bfcf

In general I see that current generate-jpareser-server goal is in fact combination of 3 generators - one creating multiple java sources and two other executions which create Java and XML files. Something could be unified there. :-) Since multi-* goals are not actively supported and do not work with DSTU3 they could be marked as deprecated?

Cheers,
Lukasz

[James Agnew]

I think they should just be removed truthfully. I have never heard of anyone using them. (Although if anyone reads this and feels differently please do speak up!)

That patch makes sense to me, feel free to PR it.

Cheers,

James

To unsubscribe from this group and stop receiving emails from it, send an email to hapi-fhir+unsubscribe@googlegroups.com.

To post to this group, send email to hapi...@googlegroups.com.

To view this discussion on the web visit https://groups.google.com/d/msgid/hapi-fhir/6c3944bc-3a68-4d82-83e3-14603ea812e9%40googlegroups.com.

[as...@yahoo.com]

James/Lukasz - I need to re-generate the Consent.java model files for STU3 and R4 (issue #920) and was wondering if your earlier explorations in this thread could give me insight how to do that?

[James Agnew]

Hi Anthony,

The code generator is a bit of a pain in the butt to work with (with good reason- building FHIR is complicated). It lives in the FHIR specification build, in this class: https://github.com/hl7-fhir/fhir-svn/blob/master/tools/java/org.hl7.fhir.tools.core/src/org/hl7/fhir/tools/implementations/java/JavaResourceGenerator.java

To test changes, you need to check out the FHIR spec build and run that build.

There are details on this page about how the spec build works: http://wiki.hl7.org/index.php?title=FHIR_Build_Process

Cheers,

James

To unsubscribe from this group and stop receiving emails from it, send an email to hapi-fhir+unsubscribe@googlegroups.com.

To post to this group, send email to hapi...@googlegroups.com.

To view this discussion on the web visit https://groups.google.com/d/msgid/hapi-fhir/076a7103-2cb7-4273-a904-e290cc8961fc%40googlegroups.com.

[as...@yahoo.com]

Understood - many thanks for the reply.  A few questions if I could:

• I've spent a fair bit of time investigating issue #920 and my initial suspicion for the cause is incorrect parsing of the Path column in the Search tab of the spreadsheets.
• The path for Consent.source is correctly specified in the consent-spreadsheet.xml file as Consent.source[x]
• This leads me to think that the [x] is being interpreted as a regular expression specification and not as a part of the literal path string
• Am I on the right track in thinking that the BaseStructureSpreadsheetParser class in the Tinder plug-in is the one I need to examine for the parsing?
  

Based on the bullets above, I came to the conclusion that I have to re-generate the Consent.java file in order to test any fixes I implement.

- Anthony

[James Agnew]

> Am I on the right track in thinking that the BaseStructureSpreadsheetParser class in the Tinder plug-in is the one I need to examine for the parsing

Unfortunately not. That class was used for HAPI's resource generation up until the HAPI DSTU2 structures, but it is not used by the spec build.

For what it's worth, it's the writeSearchParameterField method that actually creates the SP definitions in the class. This method uses a SearchParameterDefn object, although I actually don't know where that parsing happens.

Cheers,

James

To unsubscribe from this group and stop receiving emails from it, send an email to hapi-fhir+unsubscribe@googlegroups.com.

To post to this group, send email to hapi...@googlegroups.com.

To view this discussion on the web visit https://groups.google.com/d/msgid/hapi-fhir/b0c8eb52-46f5-4efb-bb6a-7c39b0108c98%40googlegroups.com.

[as...@yahoo.com]

Many thanks again for the info - very useful.

If I identify the issue in the JavaResourceGenerator.java file, who do I contact to make the changes?  I noticed Grahame was the last committer.

Is a development VM available that has the "particular java set up" per the Wiki?

- Anthony