FHIR Chat · IG publisher tool v3

Stream: IG creation

Topic: IG publisher tool v3

Grahame Grieve (Apr 25 2018 at 06:58):

I've added 3 new pages to the wiki about implementation guide authoring:

Grahame Grieve (Apr 25 2018 at 06:58):

These will drive my work over the next few weeks re-writing the IG publisher tool to be driven by the new implementation guide resource, and by templates

Eric Haas (Apr 25 2018 at 14:52):

active scripts: http://wiki.hl7.org/index.php?title=FHIR_IG_publisher_templates#Active_Scripts - js, xslt, ant what are these? preprocessing script like my python scripts to build ig.json and ig.xml or run time scripts?

Eric Haas (Apr 25 2018 at 15:21):

"fhirVersion (required): the FHIR version of the IG. The only valid values are: 1.0.2, 1.4.0, 3.0.1 and 3.4.0" What about the latest current version ... that value will change over time.
for Dependencies the option of a local source file is not there - that is problematic when working on unpublished IG or last build of an IG.
Set up version control for your IG - most editors won't even know what this means so need a whole section on this...
If the github repository is public, set up auto-publishing so that the latest version of the guide is always found on build.fhir.org - I think this should say " If you want to share the ig output publicly there are several options including: 1) set up auto-publishing so that the latest version of the guide is always found on build.fhir.org - this is required for HL7 sanctioned IGs blah, blah 2) using some other online publishing tool such as GitHub Pages. "
Narrative: Use Cases, Context and Work Flow to provide guidance on how to use the technical artifacts in the IG. ( I would put the Narrative piece first and the technical artifacts second. )

Eric Haas (Apr 25 2018 at 15:22):

Its a very nice start by the way... I would also like to see a standard file tree defined as well. ( preferably mine ) :-)

Jose Costa Teixeira (Apr 25 2018 at 15:30):

WRT standard tree, i assume that is not coupled to the structure of the content itself, right? We are looking in IHE for a content structure. But the file structure as "where do images, and narratives etc go" that i agree could be useful.

Jose Costa Teixeira (Apr 25 2018 at 15:31):

and I don't know how this will link to cascading profiles.
Say you have a couple of profiles, some of them depending on others. The structure should support some sensible isolation of ownership (read: something we can github) while supporting inheritance

Grahame Grieve (Apr 25 2018 at 21:47):

yes the idea is to allow templates to do pre-processing. I'd like to minimise these
3.4.0 is the latest version and will change over time, but I should be explicit about that
there must be an option for specifying where the IG actually is, but the intent is to do through npm package mgmt, and not in the ig itself
version control: I have a bunch of references to fill out like this.
I don't mind changing it, but we should figure out why you use the horrible gitub pages workflow and resolve that
standard file tree - why? do we need to argue about this to what benefit?

Grahame Grieve (Apr 25 2018 at 21:47):

Jose I think that we already have sensible isolation of ownership

Jose Costa Teixeira (Apr 25 2018 at 22:08):

By ownership I mean things that IHE may have to check, like where to store the conformance resources when several people from different groups are working in different profiles/IGs - will we store all the conformance resources for all IHE profiles in one single folder/repository (which may be harder to maintain), or will we have one dedicated folder per IG/profile...

Lloyd McKenzie (Apr 25 2018 at 22:15):

I think HL7 IGs should have a semi-consistent file tree - makes things much easier for implementers if they don't need to learn a new organization with every IG. I think Eric and I will end up hashing out our respective organizations as part of daVinci

Grahame Grieve (Apr 25 2018 at 22:17):

which file tree are we talking about?

Grahame Grieve (Apr 25 2018 at 22:18):

will IHE use simplifier, or just github?

Jose Costa Teixeira (Apr 25 2018 at 22:18):

no idea yet. Hasn't been decided yet

Grahame Grieve (Apr 25 2018 at 22:20):

well, mostly it's a policy question. my general advice would be to have an ihe common IG where general things shared across all IGs live, and and then a repository for each named IG

Lloyd McKenzie (Apr 25 2018 at 22:20):

Filetree (in my mind) = Semi-standard organization of source as well as semi-standard organization of published TOC

Jose Costa Teixeira (Apr 25 2018 at 22:22):

Organization of source i relate to. Shouldn't we be somewhat liberal on TOC structure?

Grahame Grieve (Apr 25 2018 at 22:22):

well, those are 2 very different things. One of the things i didn't document yet is that removing the json config file makes mananging the output location more fragile

Grahame Grieve (Apr 25 2018 at 22:22):

HL7 will probably want a standard approach in the HL7 template. But we wouldn't want to impose that on other orgs

Jose Costa Teixeira (Apr 25 2018 at 22:22):

some reference structures for TOC are great, as long as they are not binding

Jose Costa Teixeira (Apr 25 2018 at 22:24):

Institutions like IHE may want to follow a certain structure, other settings (i am thinking countries with 2 languages) may want to have a specific requirement for structure of output...

Grahame Grieve (Apr 25 2018 at 22:25):

so IHE would clearly have it's own template

Lloyd McKenzie (Apr 25 2018 at 22:50):

I'm not expecting toc stuff to be binding except for HL7 balloted IGs

Eric Haas (Apr 26 2018 at 00:42):

RE 'yes the idea is to allow templates to do pre-processing. I'd like to minimise these' - without a standard filetree like mine can you reliably preprocess? .... and I would like to why limiting the preprocessing options to those three - I'm sure others (me) would like Python or Ruby or Whatever
RE 'I don't mind changing it, but we should figure out why you use the horrible gitub pages workflow and resolve that' - I don't think its horrible is a easy-peasy solution for smallish IGs. It separates the concern of autopublishing from your local build.
'standard file tree - why? do we need to argue about this to what benefit?' - see above, also for maintainance by others people instead of the original authors it would be of great benefit know where the files lived. Case in point is that US-Core and Argonaut are a mess and would be hard for anybody else but Brett and I to know where to look for stuff. Great for job security though.....
*

Grahame Grieve (Apr 26 2018 at 00:47):

template would have to say more about the local file structure.

Grahame Grieve (Apr 26 2018 at 00:47):

I don't know what you mean 'separate the concern of autopublishing from your local build' means

Grahame Grieve (Apr 26 2018 at 00:48):

well, ok. we can talk about a standard file tree. but I defined a nice simple one that everybody started going in all directions for reasons that are sometimes pretty idiosyncratic

Eric Haas (Apr 26 2018 at 01:05):

separate the concern of autopublishing means you don't want to bother with checking if you have the latest build or the caps are all right - you just want to share online.

Eric Haas (Apr 26 2018 at 01:19):

your file structure is simple and easy to remember and use. But as the number of files grow it gets hard to navigate and some files you don't want to mess with. The general idea is to have a set of folders that authors can go to and a set of folders that are for templates only. like in the build there is the source directory for all the editors content. and everything else. if we set up templates and remove all the framework stuff ( mostly _includes and_layouts, assets) the source folders only needs to be:

+-- source
    +-- examples
    +-- pages
    ¦   +-- _includes
    ¦   +-- assets
    +-- resources

Eric Haas (Apr 26 2018 at 01:20):

of course its idiosyncratic too

Grahame Grieve (Apr 26 2018 at 02:16):

why the separation between pages and includes in this case?

Lloyd McKenzie (Apr 26 2018 at 02:42):

My driver for source file-tree is to put files to be manipulated by different people or different tools in different places. So structures are separated from examples from terminology. And all of the templates and build infrastructure are completely partitioned into a "don't mess around in here unless you really know what you're doing" folder.

Lloyd McKenzie (Apr 26 2018 at 02:44):

So page content is completely separated from page headers, footers, templates, etc. Page content is also valid XHTML so that if the user is using a validating editor, it'll yell at them when they break stuff.

Lloyd McKenzie (Apr 26 2018 at 02:45):

I also keep the stuff that Forge manipulates separate from other resources - so search parameters, questionnaires, capabilityStatement go in one folder, while implementationguide and structuredefinitions go in another

Grahame Grieve (Apr 26 2018 at 04:03):

so the template split will move the build infrastructure much further away.

Grahame Grieve (Apr 26 2018 at 04:03):

why keep forge stuff separate?

Lloyd McKenzie (Apr 26 2018 at 04:09):

Because it's maintained by a different tool - and forge has weird naming conventions that I'd rather not enforce everywhere else

Lloyd McKenzie (Apr 26 2018 at 04:10):

Also, you typically need to hand edit the other files and you don't want someone hand-editing something that's open in Forge. Separate folder makes it less likely to do that by accident

Grahame Grieve (Apr 26 2018 at 08:28):

@Eric Haas back to active content: the actual rule for active content is 'anything that can reliably be run from Java on all platforms on which the builder runs' including the auto-builder platform, which is probably the most restrictive

Michel Rutten (Apr 26 2018 at 09:01):

@Lloyd McKenzie I notice that you mention something about weird naming conventions in Forge. Can you explain, and is there something we can do to improve?

Grahame Grieve (Apr 26 2018 at 09:57):

in this sentence, 'weird' is anything other than what Lloyd wants to do.

Eric Haas (Apr 26 2018 at 14:39):

@Grahame Grieve In the end, I'm not not violently opposed to auto-publishing with the CI build - just bringing up easier and less robust alternatives.
@Lloyd McKenzie explained the rationale behind the tree and splitting the framework files from the editable stuff well. I do that too. But, just like Goldilocks, Grahame's files structure is too simple and LLoyd's too complicated, mine is somewhere in the middle. I think the ig-pub with grab anything in the subfolder in the resources directory anyway. The issue is with the preprocessing script(s). I enforce a file naming convention on the conformance resources so I can pre-process them whereas it looks like Lloyd depends on the file structure.

Eric Haas (Apr 26 2018 at 14:42):

re the question :"why the separation between pages and includes in this case?" That is the Jekyll way.

Lloyd McKenzie (Apr 26 2018 at 17:08):

'weird' was a bit pejorative. Sorry for that. Forge isn't doing anything wrong, it just throws the resource name onto the filename. E.g. myIg.implementationguide.xml. That makes the names a little long, and I don't necessarily want to follow that naming convention with all of my other resoruces.

Lloyd McKenzie (Apr 26 2018 at 17:10):

Eric is right that I do rely on folders a bit for determining pre-processing - or have. Given that I use XML for source pretty much exclusively, it's possible for the transforms to pass things through unchanged, but I'd rather not process things I don't have to.

Eric Haas (Apr 26 2018 at 19:13):

I use the same weird naming convention too! :)

Grahame Grieve (Apr 26 2018 at 23:27):

"why the separation between pages and includes in this case?" That is the Jekyll way."

yes but does it need to be our way? That's what I'm wondering.

Eric Haas (Apr 26 2018 at 23:43):

I think its important to keep them segregated - all my pages are md files and includes are md files, but the include files don't have front matter.

Grahame Grieve (Apr 26 2018 at 23:57):

I'm just wondering whether part of the template infrastructure is to make all narrative includes altogether

Lloyd McKenzie (Apr 27 2018 at 00:15):

To start, I don't want a folder containing narrative content called "includes". That won't make logical sense to the people developing the content

Eric Haas (Apr 27 2018 at 00:20):

make all narratives includes? The pages use the default layouts which are part of the template infrastructure. I use the pages front matter for setting all sorts of page variables, so no i think you keep the pages and includes separate. Includes are important too to split up the narrative and insert into templates and to reuse pieces and simplify stuff like inserting images bootstrap objects using markdown.

Jose Costa Teixeira (Apr 29 2018 at 21:41):

http://wiki.hl7.org/index.php?title=FHIR_IG_publisher_templates
the links to the templates are not ok (gitub? are these public repositories?)

Grahame Grieve (May 07 2018 at 07:12):

@Eric Haas @Lloyd McKenzie I updated the documentation at http://wiki.hl7.org/index.php?title=FHIR_IG_publisher_templates

Grahame Grieve (May 07 2018 at 07:12):

please review

Grahame Grieve (May 07 2018 at 08:43):

the -debug parameter is supported now, so you can see what is produced by the the 2 build points for templates

Lloyd McKenzie (May 07 2018 at 10:24):

Minor edits, mainly to grammar. @Eric Haas, you and I need to spend some time together in Cologne figuring out a common template :)

Grahame Grieve (May 07 2018 at 12:33):

@Eric Haas isn't going to be in Cologne.

Lloyd McKenzie (May 07 2018 at 12:36):

Ah. Missed that. I guess we'll work on it virtually after the meeting then.

Grahame Grieve (May 07 2018 at 12:40):

I plan for the IG publisher to support templates fully by Saturday morning

Lloyd McKenzie (May 07 2018 at 12:50):

What will the options be for projects that don't have the bandwidth to re-architect their publishing approach (and who currently build off tx.fhir.org)?

Eric Haas (May 10 2018 at 22:10):

does IG-pub currently run off of the ci version of the IG resource?

Grahame Grieve (May 11 2018 at 04:45):

yes

Grahame Grieve (May 11 2018 at 04:46):

it produces the correct version, but the input must be in the latest versino

Eric Haas (May 11 2018 at 18:09):

so I looks like the Ig-pub will autopopulate it from folders, Is there a file naming convention ( i.e. [Type]-name.json/xml) and there is no more ig.json? mmmm I just tried and it worked
fine using the old way, I assume there support for both.

Eric Haas (May 11 2018 at 18:16):

I admit I store all my all the configuration data in a csv file ( instead of xml or json) too avoid brackets and curly braces. And then I load into the ig.json.
So I will probably update this to create the ig.xml, but is nice to just have to point to a folder instead.

Grahame Grieve (May 11 2018 at 18:39):

I'm not sure exactly what you are talking about here...

Grahame Grieve (May 11 2018 at 18:40):

so far, the only thing that you have to to do is version the IG and the dependencies, and provide a package name - there's no forgiveness on this anymore

Grahame Grieve (May 11 2018 at 18:40):

and, btw, @Lloyd McKenzie from now on I will be enforcing that all IGs published by HL7 use semver for their version

Grahame Grieve (May 11 2018 at 18:44):

another thing that is changed is that I have withdrawn support for dependency.source - you now have to use the package manager. Or at least, you will once i commit.

Lloyd McKenzie (May 11 2018 at 18:44):

So no more 2018may - I have to go with 0.0.1 or something?

Lloyd McKenzie (May 11 2018 at 18:45):

Dependency.source is a problem

Lloyd McKenzie (May 11 2018 at 18:45):

If I have 3 local IGs that are interdependent, how do I manage that?

Lloyd McKenzie (May 11 2018 at 18:45):

They're not going to be registered anywhere

Grahame Grieve (May 11 2018 at 18:46):

interdependent? I presume you don't mean cyclical

Grahame Grieve (May 11 2018 at 18:46):

you don't need them registered anywhere but in your cache.

Lloyd McKenzie (May 11 2018 at 18:46):

No. B and C each depend on A

Lloyd McKenzie (May 11 2018 at 18:46):

I can't point to them by relative path in my build folder?

Grahame Grieve (May 11 2018 at 18:47):

no. you don't do that anymore. you say that you depend on the dev versions, and then it will automatically sort it self out

Grahame Grieve (May 11 2018 at 18:48):

e.g build A, then build b and c. As long as b and c say they depend on the dev version of A, presto. if you change them to depend on specific versions, then you install those specific versions in the cache (using your package manager of choice - one will be available by the end of the weekend)

Lloyd McKenzie (May 11 2018 at 18:49):

How does that magic work if I can't use relative directories to point from the B IG to the A publish folder?

Grahame Grieve (May 11 2018 at 18:49):

you don't use relative directories at all anymore.

Lloyd McKenzie (May 11 2018 at 18:49):

So I have to install a package manager?

Grahame Grieve (May 11 2018 at 18:49):

you just specify the canonical url and the version

Grahame Grieve (May 11 2018 at 18:49):

yes

Lloyd McKenzie (May 11 2018 at 18:49):

That really sucks

Lloyd McKenzie (May 11 2018 at 18:50):

Because it means a bunch of people now need something else installed before their build will run.

Grahame Grieve (May 11 2018 at 18:50):

no, it won't. But you don't have to like change. You just have to deal with it

Eric Haas (May 11 2018 at 18:50):

I not sure how it will work exactly but is sounds painful to me as well

Lloyd McKenzie (May 11 2018 at 18:50):

It's not me. It's the 12+ people at various projects who will now have to do it.

Grahame Grieve (May 11 2018 at 18:50):

well, it will also mean that now there's no need to make hard rules about relative file locations either

Lloyd McKenzie (May 11 2018 at 18:50):

That was easy

Lloyd McKenzie (May 11 2018 at 18:51):

It's directly tied to the publication process

Lloyd McKenzie (May 11 2018 at 18:51):

Put the IGs in parallel folders, dump the output into a common folder with relative paths.

Lloyd McKenzie (May 11 2018 at 18:51):

What's the benefit of this again?

Grahame Grieve (May 11 2018 at 18:52):

because it will be much easier to manage the general scenario where you have dependencies on other IGs that you don't control

Lloyd McKenzie (May 11 2018 at 18:53):

And we can't support both approaches because...?

Eric Haas (May 11 2018 at 18:54):

I think will need a walk through how to use a CI build of USCore as a dependency file.

Grahame Grieve (May 11 2018 at 18:54):

I'm not adding more and more configuration. It just gets harder and harder.

Grahame Grieve (May 11 2018 at 18:54):

I'm stripping out configuration in favor of a much more stable approach

Lloyd McKenzie (May 11 2018 at 18:56):

It's a stable approach that makes things overly complex for the "simple" people - and I thought we were supposed to make things simple for the simple folks and add complexity for the more complicated folks.

Grahame Grieve (May 11 2018 at 18:58):

it's not simple at all. What I hear you saying is that there needs to be a solid workflow for automated builds of multiple IGs that doesn't require human intervention

Lloyd McKenzie (May 11 2018 at 18:58):

Um, no, that's not what I'm saying

Lloyd McKenzie (May 11 2018 at 18:59):

They run a set of batch files. The batch files are numbered 1, 2, 3

Grahame Grieve (May 11 2018 at 18:59):

well, perhaps you could clarify, because that's what I heard

Grahame Grieve (May 12 2018 at 06:44):

there's a manual package manager for windows at http://www.healthintersections.com.au/FhirServer/FhirPackageManager.zip

Grahame Grieve (May 12 2018 at 06:45):

if you want to install packages, there are packages for all the currently supported versions of FHIR (1.0.2, 1.4.0, 3.0.1, and build) and for all the posted implementation guides on hl7.org/fhir and fhir.org/guides (just enter the base URL in the import URL folder)

Eric Haas (May 13 2018 at 23:36):

Do I have to create my own package to use the latest CI or unpublished US-Core as a dependency? If the answer is yes ... any suggestions where should I start reading how to do that for a mac?

Grahame Grieve (May 14 2018 at 04:57):

use "current" as the version if you want to use CI build. use "dev" if you want to use your local build and fall back to CI

Eric Haas (May 15 2018 at 21:19):

I followed the wiki and created an IG resource. However when I try to launch based off of it I get a Null error.

java -jar ${path2} -ig /Users/ehaas/Documents/FHIR/IG-Test3/ig.json

where ig.json is now the IG resources.

here is my file tree:
.
├── ig.json
├── pub3.sh
└── source
├── examples
├── pages
├── resources
└── resources-forge

here is the error:

FHIR Implementation Guide Publisher (v3.4.0-13761, gen-code v3.4.0-13757) @ Tuesday, May 15, 2018 2:06:57 PM
Detected Java version: 1.8.0_65 from /Library/Java/JavaVirtualMachines/jdk1.8.0_65.jdk/Contents/Home/jre on x86_64 (64bit). 1820MB available
Package Cache: /Users/ehaas/.fhir/packages
Load Configuration from /Users/ehaas/Documents/FHIR/IG-Test3/ig.json             (00.0010sec)
Root directory: /Users/ehaas/Documents/FHIR/IG-Test3                             (00.0081sec)
Publishing Content Failed: null                                                  (00.0082sec)
                                                                                 (00.0083sec)
Use -? to get command line help                                                  (00.0083sec)
                                                                                 (00.0083sec)
Stack Dump (for debugging):                                                      (00.0083sec)
java.lang.NullPointerException
    at org.hl7.fhir.igtools.publisher.Publisher.str(Publisher.java:775)
    at org.hl7.fhir.igtools.publisher.Publisher.initialize(Publisher.java:905)
    at org.hl7.fhir.igtools.publisher.Publisher.execute(Publisher.java:474)
    at org.hl7.fhir.igtools.publisher.Publisher.main(Publisher.java:4468)
Exception in thread "main" java.lang.NullPointerException
    at org.hl7.fhir.igtools.publisher.Publisher.main(Publisher.java:4478)

Eric Haas (May 15 2018 at 21:27):

here is ig,json ( I assume its wrong but was hoping for some more helpful error messages)

{
    "resourceType": "ImplementationGuide",
    "id": "1",
    "meta": {
        "versionId": "1",
        "lastUpdated": "2018-05-15T20:45:44Z"
    },
    "url": "http://www.fhir.org/guides/test3",
    "version": "0.0.0",
    "license value": "CC0-1.0",
    "name": "IG-Test3",
    "status": "draft",
    "experimental": false,
    "date": "2018-05-14",
    "publisher": "Health eData Inc",
    "contact": [
        {
            "name": "Eric Haas",
            "telecom": [
                {
                    "system": "url",
                    "value": "ehaas@healthedatainc.com"
                }
            ]
        }
    ],
    "description": "Testing ig.xml with ig-pub",
    "jurisdiction": [
        {
            "coding": [
                {
                    "system": "urn:iso:std:iso:3166",
                    "code": "US"
                }
            ]
        }
    ],
    "copyright": "Published by Health eData Inc under the standard FHIR license (CC0)",
    "fhirVersion": "3.0.1",
    "dependsOn": [
        {
            "uri": "http://hl7.org/fhir/ImplementationGuide/uscore",
            "version": "1.1.0",
            "packageId": "hl7.fhir.us.core"
        }
    ],
    "definition": {
        "extension": [
            {
                "url": "http://fhir.org/ig-publisher/StructureDefinition/scan-folder",
                "valueUrl": "source/resources"
            }, {
                "url": "http://fhir.org/ig-publisher/StructureDefinition/page-content",
                "valueUrl": "source/pages"
            }
        ],
        "resource": [
            {
                "reference": {
                    "reference": "Patient/test"
                },
                "name": "Test Example",
                "description": "A test example to show how a implementation guide works",
                "exampleCanonical": "http://hl7.org/fhir/us/core/StructureDefinition/patient"
            }
        ],
        "parameter": [
            {
                "code": "history-page",
                "value": "source/history/history.md"
            }, {
                "code": "extension-domain",
                "value": "http://example.org/fhir"
            }, {
                "code": "logging",
                "value": "progress"
            }, {
                "code": "npm-template",
                "value": "npm package template file"
            }, {
                "code": "npm-name",
                "value": "healthedata.test3"
            }, {
                "code": "license",
                "value": "CC0-1.0"
            }, {
                "code": "template",
                "value": "../IG-Template2"
            }, {
                "code": "generate-turtle",
                "value": "false"
            }, {
                "code": "generate-json",
                "value": "true"
            }, {
                "code": "generate-xml",
                "value": "true"
            }, {
                "code": "expansion-profile",
                "value": "tx.fhir.org"
            }, {
                "code": "path-tx-cache",
                "value": "generated-output/txCache"
            }, {
                "code": "apply-jurisdiction",
                "value": "true"
            }, {
                "code": "apply-business-version",
                "value": "true"
            }, {
                "code": "rule-broken-links",
                "value": "warning"
            }, {
                "code": "apply-business-version",
                "value": "0.0.0"
            }
        ]
    }
}

Grahame Grieve (May 15 2018 at 21:35):

the IG publisher hasn't made this transition yet

Eric Haas (May 15 2018 at 21:45):

good to know... I've logged a couple of trackers to IG to make it work. and a couple more things I noticed:

the 'license' parameter is not needed since there is IG.license
the 'template' parameter is not needed since there is IG.defintion.template
description.resource is min = 1 so how does one use the extension on definition to populate without having an invalid resource... maybe should be min = 0?
extension for resources doesn't differentiate between examples and conformance artifacts would be nice to have an extension for each.... :-)

Grahame Grieve (May 15 2018 at 21:54):

the json file is going away completely. I've added some things to the IG resource so that I can make it go away. So you'll find duplicate right now, but the IG publisher isn't looking in the IG for those things at the moment

Grahame Grieve (May 15 2018 at 21:54):

what's description.resource?

Eric Haas (May 15 2018 at 22:26):

sorry .definition.resource is min = 1

Eric Haas (May 15 2018 at 22:42):

Yes I realize that ig.json the config file is going to be replaced by ig.json the IG resource. I thought you had made the leap already and the IG-PUB was supporting both :-). anyhow is nice to have an example for the documentation. Hoping I got a head start.

Grahame Grieve (May 22 2018 at 16:43):

ok. templates are working. Not scripts in templates yet, but I just built the first IG with a template

Eric Haas (May 23 2018 at 13:31):

When are we all cutting over to this? Because I imagine I'll have to retool and need to plan for it.

Eric Haas (May 23 2018 at 15:42):

I've reread the templates section. It looks like I will need t an ant script to read all the ig resources and example id to autogenerate the the config.json ( aka ig.json). Is that correct? @Lloyd McKenzie have you done this already? My scripting is limited to Python.

Grahame Grieve (May 23 2018 at 17:14):

well, the ant script is just a launcher for stuff like that

Lloyd McKenzie (May 23 2018 at 17:36):

I haven't tried to do anything with templates yet

Grahame Grieve (May 23 2018 at 17:52):

could't have until 24 hour ago...

Chris Moesel (Jun 27 2018 at 22:19):

I have three questions:
(1) Will IGs balloted in the Fall cycle be required to use the new IG Publishing Tool?
(2) Is the new IG Publishing Tool far enough along to switch over to now?
(3) Is there any documentation about what's changed from the old tool (or even better, steps to migrate an existing IG to the new tooling)?

Grahame Grieve (Jun 28 2018 at 04:07):

which old tool are you referring to?

Chris Moesel (Jun 28 2018 at 11:59):

Sorry @Grahame Grieve -- I should have been more specific! Our IG (the US Breast Cancer IG) is built to work w/ the IG publisher as it was when content froze for the May ballot, but I get the impression a lot may have changed since then. Or perhaps I have the wrong impression?

Lloyd McKenzie (Jun 28 2018 at 18:40):

It's certainly changed some. And more changes are in the works. The expectation is that IGs will publish using the current version of the publisher at the time the ballot opens and will have a working CI Build

Grahame Grieve (Jun 28 2018 at 22:13):

the only genuine changes are the requirements around packaging; these are trivial and have no impact on the IG itself

Chris Moesel (Jul 03 2018 at 18:08):

OK. I must have misunderstood something along the way. Thanks for the clarification!

Last updated: Apr 12 2022 at 19:14 UTC

Main menu

FHIR Chat · IG publisher tool v3 · IG creation

Stream: IG creation

Topic: IG publisher tool v3

Grahame Grieve (Apr 25 2018 at 06:58):

Grahame Grieve (Apr 25 2018 at 06:58):

Eric Haas (Apr 25 2018 at 14:52):

Eric Haas (Apr 25 2018 at 15:21):

Eric Haas (Apr 25 2018 at 15:22):

Jose Costa Teixeira (Apr 25 2018 at 15:30):

Jose Costa Teixeira (Apr 25 2018 at 15:31):

Grahame Grieve (Apr 25 2018 at 21:47):

Grahame Grieve (Apr 25 2018 at 21:47):

Jose Costa Teixeira (Apr 25 2018 at 22:08):

Lloyd McKenzie (Apr 25 2018 at 22:15):

Grahame Grieve (Apr 25 2018 at 22:17):

Grahame Grieve (Apr 25 2018 at 22:18):

Jose Costa Teixeira (Apr 25 2018 at 22:18):

Grahame Grieve (Apr 25 2018 at 22:20):

Lloyd McKenzie (Apr 25 2018 at 22:20):

Jose Costa Teixeira (Apr 25 2018 at 22:22):

Grahame Grieve (Apr 25 2018 at 22:22):

Grahame Grieve (Apr 25 2018 at 22:22):

Jose Costa Teixeira (Apr 25 2018 at 22:22):

Jose Costa Teixeira (Apr 25 2018 at 22:24):

Grahame Grieve (Apr 25 2018 at 22:25):

Lloyd McKenzie (Apr 25 2018 at 22:50):

Eric Haas (Apr 26 2018 at 00:42):

Grahame Grieve (Apr 26 2018 at 00:47):

Grahame Grieve (Apr 26 2018 at 00:47):

Grahame Grieve (Apr 26 2018 at 00:48):

Eric Haas (Apr 26 2018 at 01:05):

Eric Haas (Apr 26 2018 at 01:19):

Eric Haas (Apr 26 2018 at 01:20):

Grahame Grieve (Apr 26 2018 at 02:16):

Lloyd McKenzie (Apr 26 2018 at 02:42):

Lloyd McKenzie (Apr 26 2018 at 02:44):

Lloyd McKenzie (Apr 26 2018 at 02:45):

Grahame Grieve (Apr 26 2018 at 04:03):

Grahame Grieve (Apr 26 2018 at 04:03):

Lloyd McKenzie (Apr 26 2018 at 04:09):

Lloyd McKenzie (Apr 26 2018 at 04:10):

Grahame Grieve (Apr 26 2018 at 08:28):

Michel Rutten (Apr 26 2018 at 09:01):

Grahame Grieve (Apr 26 2018 at 09:57):

Eric Haas (Apr 26 2018 at 14:39):

Eric Haas (Apr 26 2018 at 14:42):

Lloyd McKenzie (Apr 26 2018 at 17:08):

Lloyd McKenzie (Apr 26 2018 at 17:10):

Eric Haas (Apr 26 2018 at 19:13):

Grahame Grieve (Apr 26 2018 at 23:27):

Eric Haas (Apr 26 2018 at 23:43):

Grahame Grieve (Apr 26 2018 at 23:57):

Lloyd McKenzie (Apr 27 2018 at 00:15):

Eric Haas (Apr 27 2018 at 00:20):

Jose Costa Teixeira (Apr 29 2018 at 21:41):

Grahame Grieve (May 07 2018 at 07:12):

Grahame Grieve (May 07 2018 at 07:12):

Grahame Grieve (May 07 2018 at 08:43):

Lloyd McKenzie (May 07 2018 at 10:24):

Grahame Grieve (May 07 2018 at 12:33):

Lloyd McKenzie (May 07 2018 at 12:36):

Grahame Grieve (May 07 2018 at 12:40):

Lloyd McKenzie (May 07 2018 at 12:50):

Eric Haas (May 10 2018 at 22:10):

Grahame Grieve (May 11 2018 at 04:45):

Grahame Grieve (May 11 2018 at 04:46):

Eric Haas (May 11 2018 at 18:09):

Eric Haas (May 11 2018 at 18:16):

Grahame Grieve (May 11 2018 at 18:39):

Grahame Grieve (May 11 2018 at 18:40):

Grahame Grieve (May 11 2018 at 18:40):

Grahame Grieve (May 11 2018 at 18:44):

Lloyd McKenzie (May 11 2018 at 18:44):

Lloyd McKenzie (May 11 2018 at 18:45):

Lloyd McKenzie (May 11 2018 at 18:45):

Lloyd McKenzie (May 11 2018 at 18:45):

Grahame Grieve (May 11 2018 at 18:46):

Grahame Grieve (May 11 2018 at 18:46):

Lloyd McKenzie (May 11 2018 at 18:46):