Stream: IG creation
Topic: new build error
Rob Hausam (Jul 26 2018 at 13:45):
After recent IG Publisher updates (not sure exactly which one) I'm now getting this error in my build:
Initialization complete (00:01:58.0413sec)
Load Content (00:01:58.0415sec)
Publishing Content Failed: Unable to determine type for E:\git-repo\fhir-ips\examples\IPS-bundle-01: com.google.gson.JsonPrimitive cannot be cast to com.google.gson.JsonObject (00:02:00.0551sec)
(00:02:00.0554sec)
Use -? to get command line help (00:02:00.0555sec)
(00:02:00.0556sec)
Stack Dump (for debugging): (00:02:00.0556sec)
java.lang.Exception: Unable to determine type for E:\git-repo\fhir-ips\examples\IPS-bundle-01: com.google.gson.JsonPrimitive cannot be cast to com.google.gson.JsonObject
at org.hl7.fhir.igtools.publisher.Publisher.loadAsElementModel(Publisher.java:2182)
at org.hl7.fhir.igtools.publisher.Publisher.load(Publisher.java:1595)
at org.hl7.fhir.igtools.publisher.Publisher.createIg(Publisher.java:498)
at org.hl7.fhir.igtools.publisher.Publisher.execute(Publisher.java:464)
at org.hl7.fhir.igtools.publisher.Publisher.main(Publisher.java:4593)
Caused by: java.lang.ClassCastException: com.google.gson.JsonPrimitive cannot be cast to com.google.gson.JsonObject
at com.google.gson.JsonObject.getAsJsonObject(JsonObject.java:182)
at org.hl7.fhir.r4.formats.JsonParser.parseConditionProperties(JsonParser.java:7023)
at org.hl7.fhir.r4.formats.JsonParser.parseCondition(JsonParser.java:7010)
at org.hl7.fhir.r4.formats.JsonParser.parseResource(JsonParser.java:25035)
at org.hl7.fhir.r4.formats.JsonParser.parseBundleBundleEntryComponentProperties(JsonParser.java:3296)
at org.hl7.fhir.r4.formats.JsonParser.parseBundleBundleEntryComponent(JsonParser.java:3279)
at org.hl7.fhir.r4.formats.JsonParser.parseBundleProperties(JsonParser.java:3252)
at org.hl7.fhir.r4.formats.JsonParser.parseBundle(JsonParser.java:3223)
at org.hl7.fhir.r4.formats.JsonParser.parseResource(JsonParser.java:25005)
at org.hl7.fhir.r4.formats.JsonParserBase.parse(JsonParserBase.java:92)
at org.hl7.fhir.r4.formats.ParserBase.parse(ParserBase.java:58)
at org.hl7.fhir.r4.elementmodel.ObjectConverter.convert(ObjectConverter.java:90)
at org.hl7.fhir.igtools.publisher.Publisher.loadAsElementModel(Publisher.java:2175)
... 4 more
Exception in thread "main" java.lang.NullPointerException
at org.hl7.fhir.igtools.publisher.Publisher.main(Publisher.java:4603)
The example file is xml (IPS-bundle-01.xml), not json. It hasn't been changed, and it was building OK (with some errors) before. Has anyone seen this or have ideas how to fix it?
Rob Hausam (Jul 26 2018 at 13:57):
I recall another issue in the past where an xml file was attempting to be parsed erroneously as json, but I'll have to look up the details - maybe this is similar.
Grahame Grieve (Jul 26 2018 at 14:01):
this is what I get for what's checked in:
Grahame Grieve (Jul 26 2018 at 14:01):
Exception loading http://hl7.org/fhir/uv/ips/StructureDefinition/deviceusestatement-uv-ips: DeviceUseStatement has children for type in profile deviceusestatement-uv-ips, but can't find type
Grahame Grieve (Jul 26 2018 at 14:01):
I don't know what that means - will look at it when I wake up
Rob Hausam (Jul 26 2018 at 14:03):
thanks - I'll look more in the meantime, too
Rob Hausam (Aug 02 2019 at 15:30):
In the IPS IG build I have multiple (>100) instances of a new error:
Internal error in location for message: 'Error in ?? at 1, 1: Found / expecting a token name', loc = '/Users/rhausam/git-repo/fhir-ips/output/StructureDefinition-Composition-uv-ips.html#/html/head/body/', err = 'The image source 'icon_fixed.gif' cannot be resolved'
I'm not seeing those errors in the LIVD IG, so it doesn't appear to be a universal issue. In trying to track this down, I'm not finding any mention of icon_fixed (with or without the .gif) anywhere in the source for either the ig or IG Publisher, so I'm not sure where this is coming from or at this point what to do about it.
Rob Hausam (Aug 02 2019 at 15:31):
Bryn and I are thinking alike. :)
Lloyd McKenzie (Aug 02 2019 at 15:34):
To fix that, for now, I've just added the icon as an image file to propagate. (check out davinci-pas or pcde)
Mark Kramer (Aug 02 2019 at 15:34):
I guess the icon isn't fixed. Chasing these errors is driving me crazy. "Clean build" doesn't happen if you use a code from outside an extensible value set. "Clean build" doesn't happen if you use a code system that is unsupported. "Clean build" doesn't happen because publisher and FHIR bugs (we've got a strange one involving documentreference URI that isn't in our code).
David Pyke (Aug 02 2019 at 15:35):
(deleted)
Rob Hausam (Aug 02 2019 at 15:37):
Thanks, Lloyd. It would still be good to know where this is coming from (and hopefully fix it there).
Lloyd McKenzie (Aug 02 2019 at 15:37):
code systems not supported should be warnings (which you can then suppress). Agree that the tooling issues are frustrating. We're continuously working to up the bar and as the tools change, we need to adjust. The biggest challenge is that it can be hard for most folks to differentiate between "that's a Grahame problem, I can ignore" vs. "that's something I have to fix".
Lloyd McKenzie (Aug 02 2019 at 15:37):
the icon thing is Grahame's new change to improve pattern rendering. It's the little 'lock' icon he showed before. (The one I don't like :))
Mark Kramer (Aug 02 2019 at 15:38):
And it is also the 23:59:59 hour, and Cinderella's coach is about to become a pumpkin. This is not fair to IG authors.
Lloyd McKenzie (Aug 02 2019 at 15:38):
The URL/id errors are because Grahame is now enforcing a convention for ImplementationGuide ids an canonical URLs that breaks my framework (and in at least one way is itself broken).
Lloyd McKenzie (Aug 02 2019 at 15:40):
It has nothing to do with "fair". It has to do with capacity. Changes get made when there is time to make them. Sometimes the change is incremental and things are broken in the mean-time. They'll get fixed. No one is going to yell at you because of the missing gif. It's annoying noise right now, but it's not an actual "problem" you're responsible for fixing.
Lloyd McKenzie (Aug 02 2019 at 15:42):
The id and url stuff is a policy that's been in place for a few months, but it's only now being enforced by the tools (in part because everyone was ignoring the policy). It's unfortunate that it's manifesting now, but Grahame (and I and others) will work with the relevant authors to help them comply.
Rob Hausam (Aug 02 2019 at 15:43):
Well, it sounds as if we might need to relax the deadline? I doubt that all of this will be fixed or approved (or that we will understand if it should be approved or not) for all of us and all of our IGs by Sunday?
Mark Kramer (Aug 02 2019 at 15:43):
It is too late. I'm signing off for the weekend and whatever errors are there -- which by the way are NOT affecting the quality of our IGs -- are just going to have to stay there. Nothing is perfect, but we are close enough to not go through these ridiculous fire drills.
Lloyd McKenzie (Aug 02 2019 at 15:46):
Technically, the errors are affecting the quality of your IGs, albeit in a minor way. The missing GIF means that all of the snapshot and differential diagrams you have for profiles that include patterns will not render quite right. The issues about implementation guide id and canonical URL issues mean that your IG won't load properly into the FHIR registry. However, it's ok for you to sign off. We'll get it figured out and manually patch if need-be.
Mark Kramer (Aug 02 2019 at 15:52):
Thank you, Lloyd. I understand you and Grahame and others are working extremely hard to improve the IG process, and I appreciate it. Excuse my grumpiness. The endless spin cycle of thinking we're done, but then we're not done, and done again, but then @Lynn Laakso communicates new requirements, so we aren't done, etc... That's the way it feels on this end.
Lynn Laakso (Aug 02 2019 at 16:00):
yep, that's how it feels to me too. I am apparently working off a different set of checklists than you. How do I get my checklists incorporated into yours?
Lloyd McKenzie (Aug 02 2019 at 17:23):
I'm on the receiving end too, so I certainly understand. (I just now how things work from the otherside too).
Lloyd McKenzie (Aug 02 2019 at 17:23):
@Lynn Laakso - not quite sure what you mean about different checklists?
Lynn Laakso (Aug 02 2019 at 17:26):
I'm following the criteria given to me at https://wiki.hl7.org/Process_for_Publishing_a_FHIR_IG and apparently folks don't know about the correct package id or path in the package-list.json and where ever else it's meant to go. THe header and footer stuff isn't always right either.
Lynn Laakso (Aug 02 2019 at 17:27):
is this something on the agenda for some training material somewhere?
Lloyd McKenzie (Aug 02 2019 at 17:33):
It's all documented in the wiki on how to create IGs, but a lot of IG Authors don't necessarily read (or at least pay much attention) to that stuff. They only care once the tooling yells at them - which it's now doing. A bunch of those things are driven by templates. Unfortunately we haven't (quite) migrated to a place where everyone uses a consistent template, which means that when one IG makes fixes that address the rules, that doesn't necessarily propagate to everyone. (And a lot of IG authors just copy and paste from other IGs to start.) I'm one of the main template authors and my IGs are currently broken due to what Grahame began enforcing last night. I have to make some significant changes to make my stuff work again. (And some of the rules he's enforcing can only be enforced in the context of HL7 ballot - not everywhere, and one of them will need to be tweaked.)
Grahame Grieve (Aug 02 2019 at 20:59):
@Mark Kramer my apologies for the changes turning up so late. You may not believe it but I didn't set out to change the rules; an author preparing an IG for ballot reported an issue which I fixed, which (unexpectedly) fixed an issue somewhere else where rules were not being enforced
Mark Kramer (Aug 02 2019 at 21:17):
@Grahame Grieve Apologies accepted. I know you are working hard and in good faith. But I have to say, regarding the ballot process for IGs, it is a horrendous shit-show of committees, dates, rules, and requirements that is virtually impossible to navigate. Add to that the last-minute changes, and it is just too much. We have excellent resources at MITRE, but HL7 is killing us. Something has to be done to simplify the process.
Grahame Grieve (Aug 02 2019 at 21:47):
I agree about the process. We are working on that (have you looked at Wayne's proposal to simplify the approval process?)
As for the technical process... we are constantly working to improve it. This round of publishing we moved a lot of the publishing quality work that I had just done in the background to the editors, so that I don't have to do the publishing, and we can scale the process. That hasn't been liked.
We were supposed to have moved to the new HL7 template, which would also have simplified the process a lot, but that missed the boat. Hopefully that'll be sorted out by next time. Otherwise, the IG publisher requires that you dot your i's and cross your ts. I don't apologise for the policy, though I'm constantly trying to make the error messages better
Grahame Grieve (Aug 02 2019 at 21:55):
having said all that, I think it would be a worthwhile investment for Mitre to commit your issues to a document and send it to Austin (TSC chair) and Wayne (CTO)
Mark Kramer (Aug 03 2019 at 17:29):
Where does one find @Wayne Kubick 's proposal? I have a proposal of my own, namely, that this become a project-centered process, not a committee-centered process. Each project should present to HL7 with all required authorities present three times: 1) at the outset of the project, 2) intermediate point, 3) when the project is ready to go to ballot. Let the committees come to the project, not the other way around.
Grahame Grieve (Aug 03 2019 at 21:04):
I do not know where it is documented. It was presented to co-chairs several times but I don't know where things are now. But we desperately need to do something about it
Wayne Kubick (Aug 07 2019 at 18:41):
The proposed process that's closest to being rolled out relates primarily to the PSS https://confluence.hl7.org/display/PSS/Business+Model+of+TSC+Project+Task+Force+%28TPTF%29+for+PSS%27s . Much more needs to be done. I see value in what @Mark Kramer proposes with more of a project0centered focus, but we haven't gotten very far yet. I'm looking at ways to accelerate getting started on other process improvements before Atlanta.
Last updated: Apr 12 2022 at 19:14 UTC
