uimaFit Exception: JCas type used in Java code, but was not declared in the XML type descriptor.

The toolkit uimaFIT allows you to design annotation types in the so-called Component Descriptor Editor, save the descriptor as XML and generate the corresponding Java classes. When you run an analysis engine that makes use of these annotations uimaFit checks whether it finds the type system descriptor XML file on the classpath. In certain circumstances, it may happen that it falls short of finding this file and will abort with the following error message:

Caused by: org.apache.uima.cas.CASRuntimeException: 
JCas type "de.tudarmstadt.ukp.teaching.nlp4web.ml.type.NamedEntity" used in Java code, but was not declared in the XML type descriptor.
    at org.apache.uima.jcas.impl.JCasImpl.getType(JCasImpl.java:412)
    at org.apache.uima.jcas.cas.TOP.<init>(TOP.java:92)
    at org.apache.uima.jcas.cas.AnnotationBase.<init>(AnnotationBase.java:53)
    at org.apache.uima.jcas.tcas.Annotation.<init>(Annotation.java:54)

In this case you need to explicitly point uimaFIT to the location of your type descriptor file. For this to be done, there exist two different ways.

Solution via VM argument

As a quick and dirty solution you add the following VM argument which in Eclipse is configured in the Launch Configuration dialog


In my case, I stored the XML file in src/main/resources/desc/types/TypeSystem.xml where src/main/resources is set to be a source folder in Eclipse (Maven project layout).

Solution via types.txt (suggested)

The issue with the solution above is that your code will break if other people try to execute it without knowing about the VM parameter. There exists a more stable way to solve this issue. uimaFIT looks into the file

  • <classpath>/META-INF/org.uimafit/types.txt  (for uimaFit until 1.4.x, still supported by the uimafit-legacy-support package)
  • <classpath>/META-INF/org.apache.uima.fit/types.txt (for uimaFit 2.0.0 and above)

in order to find out where to search for the XML type descriptor files (In a Maven context META-INF should be located in src/main/resources). Each line in this types.txt file describes one search pattern. In our example, types.txt should contain one line:



  • [1] uimaFit Guide and Reference – 8.1. Making types auto-detectable
  • [2] DKPro tutorial (UIMA part): Type System Auto-Discovery (Slide 37)
  • [3] TypeDescriptorDetection


  1. Hello, i have a questio about the type system descriptors in uimafit. I’m developing a web service that use uimafit, but i don’t know where i have to put the TypeSystem.xml and the descriptors asociated. All that i read said that i’ve to put the typesystems folder in the META-INF folder. But the system doesn’t find nothing. That is the error that appears:

    org.apache.uima.resource.ResourceInitializationException: Undefined type “edu.isistan.uima.unified.typesystems.srs.Project” in type priority list. (Descriptor: )

    I appreciate your help. Sorry about my english.

    1. Hi Juan,
      Just to make sure: Have you generated the Java classes from the type system descriptor (using JCasGen)?
      If you did, please post your directory structure: Where did you place types.txt, what is its content, where did you place TypeSystem.xml? Did you use the type system editor inside Eclipse?

      1. Hi Roland, the Java classes are generated. I don’t know how this are created because it’s another project part.

        The file types.txt is located in: /META-INF/org.unimafit/types.txt

        The content of this file is:


        The TypeSystem.xml file is located in /META-INF/ folder. I generate this file doing right click on the “Deployment Descriptor” inside the project. This appears because it’s a “Dynamic Web Project”.

        1. There may be two problems in your setup:
          (1) Which version of uimaFit are you using?
          uimaFit <=1.4 looks for /META-INF/org.unimafit/types.txt uimaFit >=2.0 looks for /META-INF/org.apache.uima.fit/types.txt

          (2) The equals sign in “classpath*=” seems weird to me, normally it should look like this:


          If I understood you correctly, the TypeSystem.xml is located directly below /META-INF, right? But it should be somewhere below /META-INF/edu/isistan/uima/unified/typesystems .

          If the Java classes had already been generated by somebody else, the corresponding TypeSystem.xml should already have been there and you should not have had to create it, I guess.

          1. Sorry, the declaration don’t have “=”, it’s “:”. About the uimaFit version it’s 1.4.0. It seems that the folder /META-INF/org.unimafit/types.txt it’s ok.

            I move the typesystems.xml to the folder that you said, but nothing happend. This file have the imports of the descriptors that the project use. This is a line of it:


            Alejandro Rago

  2. Sorry, the declaration don\’t have \”=\”, it\’s \”:\”. About the uimaFit version it\’s 1.4.0. It seems that the folder /META-INF/org.unimafit/types.txt it\’s ok. I move the typesystems.xml to the folder that you said, but nothing happend. This file have the imports of the descriptors that the project use. This is a line of it:import location=\”http://localhost:8080/edu/isistan/uima/unified/typesystems/IdentifiableTypeDescriptor.xml\”/inside the label .

    1. Hm, I have to confess that I have not worked with imports very much, but I tried it out now to reproduce your situation. I my case, it inserted an absolute path name instead of a URL.

      I guess the problem could be that your import location
      is not reachable/readable at runtime? What happens if you enter this URL in the address bar of your browser? Does the exception occur during server operation? If yes, I suggest to write a small unit test first, which tests whether uimaFit is actually set up properly. You only need code similar to the following:

      JCas jCas = JCasFactory.createJCas();
      new edu.isistan.uima.unified.typesystems.srs.Project(jCas);

      uimaFit will check whether the (imported) type system descriptor can be found at runtime.

      1. When i put that URL in a browser, the xml file appears. If i want to instanciate the location of the descriptor with the eclipse, have an error that say that the file it’s not reacheable/readable. I’ll try to do a unit test.

        Thanks a lot!

  3. Hi, i have the same problem in the test project. The fail occurs in the declaration of the descriptors. The error is about the location of the xml files of descriptors. Eclipse show that the files could not be read. I\’m creating the analisisEngine descriptors, and the types descriptors with eclipse.I\’m using Jersey(REST-Web Service). Maybe thats the problem.

  4. Hm, it is possible that you cannot import type systems from arbitrary URLs, but only from absolute paths.

    Is the import actually necessary? Does one of the types in the importing type system inherit from or use one of the imported types? Perhaps it suffices to have the currently imported type system on the classpath during runtime…

    Maybe, importing by name is an option, as illustrated under “Import the type systems by name” here: http://textjuicer.com/blog/2013/09/08/using-ruta-in-a-maven-project/

  5. Dear Roland,I am trying to write an XML reader whose content should then be processed with DKpro. I installed eclipse with the necessary plugins as described in the tutorial. However I still get the error message : Exception in thread \\”main\\” org.apache.uima.cas.CASRuntimeException: JCas type \\”de.unituebingen.sfs.ma.hc.clefprocessor.types.Metadata\\” used in Java code, but was not declared in the XML type descriptor.The type descriptor file was generated and lies in src/main/resources/clefprocessorTypes.xmltypes is in the specified directory and contains classpath*:main/resources/*.xml I tried the fixes you mentioned, but nothing changed. Do you have any other suggestions?

    1. Hi Heike,
      Just to make sure: Have you followed the instructions above (“Solution via types.txt”) in the exact same way? Your file containing the path information seems to be located in main/resources and seems to contain the instructions where to find itself!? Has the dependency to uimaFit been resolved correctly as well?
      Best, Roland

Leave a Reply