Stream: committers
Topic: java.lang.Error: The expansion for UnitsOfTime is null
Simone Heckmann (Feb 07 2017 at 10:23):
Does anyone else currently have this issue when running the build locally?
[java] Terminology server: Check for supported code systems for urn:iso:std:iso:3166
[java] ==============!! Running without terminology server !!==============
[java] ...code systems 6.916 40sec 750MB
[java] ...value sets 0.002 40sec 750MB
[java] Validating 0.371 41sec 1086MB
[java] Proposed order for DataElement: build order ok
[java] Proposed order for Device: build order ok
[java] Proposed order for NutritionOrder: build order ok
[java] Proposed order for Specimen: build order ok
[java] Proposed order for Substance: build order ok
[java] ...process profiles (base) 2.388 43sec 575MB
[java] ...process profiles (resources) 0.174 43sec 605MB
[java] ...process profiles (extensions) 1.468 45sec 1003MB
[java] ...process profiles (packs) 0.277 45sec 1064MB
[java] ...process logical models 0.009 45sec 1064MB
[java] ...process logical model definition 0.0 45sec 1064MB
[java] ...process logical model event 0.002 45sec 1064MB
[java] ...process logical model request 0.002 45sec 1064MB
[java] ...Check FHIR Path Expressions 1.011 46sec 1279MB
[java] Produce Schemas 3.014 49sec 1560MB
[java] Exception in thread "main" java.lang.Error: The expansion for UnitsOfTime is null
[java] at org.hl7.fhir.definitions.generators.xsd.XSDBaseGenerator.generateEnum(XSDBaseGenerator.java:549)
[java] at org.hl7.fhir.definitions.generators.xsd.XSDBaseGenerator.genStructure(XSDBaseGenerator.java:533)
[java] at org.hl7.fhir.definitions.generators.xsd.XSDBaseGenerator.generate(XSDBaseGenerator.java:126)
[java] at org.hl7.fhir.definitions.generators.xsd.SchemaGenerator.generate(SchemaGenerator.java:72)
[java] at org.hl7.fhir.tools.publisher.Publisher.produceSpecification(Publisher.java:1908)
[java] at org.hl7.fhir.tools.publisher.Publisher.execute(Publisher.java:585)
[java] at org.hl7.fhir.tools.publisher.Publisher.main(Publisher.java:434)
[java] Picked up JAVA_TOOL_OPTIONS: -Dfile.encoding=UTF-8
BUILD FAILED
C:\FHIRRepos\build.xml:30: The following error occurred while executing this line:
C:\FHIRRepos\tools\java\org.hl7.fhir.tools.core\build.xml:145: Java returned: 1
Vadim Peretokin (Feb 07 2017 at 10:24):
Yeah, it's why I started looking at the buildbot notifications this morn
Vadim Peretokin (Feb 07 2017 at 10:25):
I think we can blame it on https://chat.fhir.org/#narrow/near/59697/stream/implementers/topic/ValueSet.20UnitsOfTime
Simone Heckmann (Feb 07 2017 at 10:35):
Makes sense. Nobody commited since the last successful build on the server.
Rob Hausam (Feb 07 2017 at 10:49):
I'm not seeing this error. I just did a succesful build with the latest update (11049).
Vadim Peretokin (Feb 07 2017 at 10:50):
So "[#11105]-[#11109], [11050], [11049] (part 3)" is the latest commit for you?
Rob Hausam (Feb 07 2017 at 10:51):
yes
Vadim Peretokin (Feb 07 2017 at 10:51):
Huh. Computers like you today and they don't like me then
Simone Heckmann (Feb 07 2017 at 10:52):
Still failing for me...
Rob Hausam (Feb 07 2017 at 10:57):
Hmm. Just ran it again for good measure. Still good - with revision 11049.
Vadim Peretokin (Feb 07 2017 at 10:58):
Does svn diff show any files that are different? I just got a clean build today - maybe yours still has something that keeps it working.
Grahame Grieve (Feb 07 2017 at 10:58):
look for uncommitted files in vscache
Simone Heckmann (Feb 07 2017 at 10:59):
Deleted my local copy and currently restoring the whole project...
Simone Heckmann (Feb 07 2017 at 11:02):
Nope. Still the same! How's that possible!? I deleted the whole project and replaced it with the current build!
Simone Heckmann (Feb 07 2017 at 11:03):
So, Vadim: you had the error this morning, but now it's gone? And you didn't change anything?
Simone Heckmann (Feb 07 2017 at 11:06):
Oh wait: has that something to do with the java version update?
Simone Heckmann (Feb 07 2017 at 11:09):
No, I'm already running Java 8 :(
Rob Hausam (Feb 07 2017 at 11:12):
yes - I think it's due to vscache - I still have some prior vscache files
at least one of which is apparently making it work
Simone Heckmann (Feb 07 2017 at 11:14):
so...what do I do? Delete the whole directory?
Brian Postlethwaite (Feb 07 2017 at 11:15):
p.s. if you delete the whole directory on windows, clean out the recycle bin afterwards.
There is a tonne in there, and also the temp folder too, heaps of files created.
Grahame Grieve (Feb 07 2017 at 11:16):
update and try again
Simone Heckmann (Feb 07 2017 at 11:30):
Deleted the whole project, emptied the recycle bin, updated, ran the build.
It's still running, but I think I'm past the point where it previously crashed.
Strangely, this time around the Update found a handful of additional files in vscache, that were not added before...
Grahame Grieve (Feb 07 2017 at 11:32):
I just added them
Simone Heckmann (Feb 07 2017 at 11:32):
oh right, we're at 11050 now!
Vadim Peretokin (Feb 07 2017 at 11:49):
Got past the error as well now. Thanks Grahame
Simone Heckmann (Feb 07 2017 at 18:11):
A general question: Should I also commit the vscache files, when I commit changes? I always excluded them because I expected the server to create it's own files during the build process. But now that I saw Grahame committing such files, I'm not sure if that's right...
Simone Heckmann (Feb 07 2017 at 18:14):
e.g. this:
pasted image
Usually, I only commit the stuff I changed *on purpose* :)
That excludes everything in vscache...
Grahame Grieve (Feb 08 2017 at 02:07):
yes you should always commit; it saves my server doing the same work for everyone else, and makes everyone else's build faster
John Moehrke (Feb 08 2017 at 13:39):
@Grahame Grieve I would commit the vscache files from the changes I make... but I can't figure out which ones were created because of my changes, and which ones were built because of some other reason. Where this 'unknown' is driven far more by the fact that the vscache files are all numeric with no relationship to what I edit... Better guidance would be helpful. Otherwise I will continue to not commit any vscache files.
Grahame Grieve (Feb 09 2017 at 03:54):
just commit them all
Grahame Grieve (Feb 09 2017 at 03:54):
there's no reason for you *not to commit* them
Grahame Grieve (Feb 09 2017 at 03:55):
except that you want to cost me money and other people time
John Moehrke (Feb 09 2017 at 10:14):
okay.. so you are saying that when anyone commits, their vscache files would be just as good as anyones... I didn't know that. So, we all should trust our SVN.... This is knowledge. knowledge is powerful. thanks.
Grahame Grieve (Feb 09 2017 at 11:24):
yes, everyone's vscache is the same as everyone else's - that's why it's in svn
Last updated: Apr 12 2022 at 19:14 UTC
