google-code-export / uimafit

Automatically exported from code.google.com/p/uimafit
2 stars 1 forks source link

upgrade UIMA to version 2.3.0 #12

Closed GoogleCodeExporter closed 9 years ago

GoogleCodeExporter commented 9 years ago
Philip:
a ticket for discussing the move to UIMA 2.3.0.

Richard:
We are using UUTUC with UIMA 2.3.0 already. Works fine. The only issue here
may be to remove the warnings. 
Actually I would suggest to leave the dependencies at 2.2.2 until we see a
need to upgrade them to 2.3.0.

Original issue reported on code.google.com by pvogren@gmail.com on 1 May 2010 at 3:10

GoogleCodeExporter commented 9 years ago
I have three reasons for moving to 2.3.0 for the 1.0 release:

- there is now generically typed FSIterator which can replace 
org.uimafit.util.AnnotationRetrieval.get(JCas, Class<T>).  I don't want to 
introduce this method in the 1.0 release if its already obsolete
- If you saw my recent posts to the uima users list there are serious 
performance gains in JCas.reset()
- I had some really weird compilation problems (so to speak) when I tried to 
upgrade to 2.3.0 piecemeal.  Specifically, I tried just changing the dependency 
version in ClearTK and Eclipse disappeard - i.e. crashed without a noise.  It 
was really weird and would go away when I reverted my pom files.  I couldn't 
believe what happened and so I tried it again several times and I got the same 
behavior.  I suppose if I tried changing the pom files in a text editor and 
built the projects from the command line, then the two versions could live 
together.  However, when I changed all my projects (including uimaFIT) to 2.3.0 
at the same moment everything worked just fine - so I would prefer to change 
all of my projects at once.

I realize this last point is only feeding into my paranoia and superstition - 
but are the first two items reason enough?

Original comment by pvogren@gmail.com on 18 Jun 2010 at 3:23

GoogleCodeExporter commented 9 years ago
I am using uimaFIT in projects that depend on UIMA 2.3.0 without any problem. 
For me it doesn't make any difference if uimaFIT is depending on 2.3.0 or 
2.2.2. I'm fine with an upgrade.

Original comment by richard.eckart on 18 Jun 2010 at 3:50

GoogleCodeExporter commented 9 years ago
Afaik the FSIterator is only used by UIMA to be a FSIterator<AnnotationFS> or 
FSIterator<Annotation> but not going to specific JCas classes - please correct 
me if I am wrong. I have some code which we use here that I wish to contribute 
which takes care of this issue and could replace the AnnotationRetrieval stuff. 
This is one of the reasons that I asked when you wish to release 1.0, because I 
would like to get this it in, but I have to prioritize this with other tasks I 
am working on.

Original comment by richard.eckart on 18 Jun 2010 at 3:57

GoogleCodeExporter commented 9 years ago
Good!  I will commit changes to the pom files shortly.  

I didn't realize this limitation to the 
jCas.getAnnotationIndex(type).iterator() method - but I guess that makes sense. 
 There are currently only a couple of places in the examples project where  
AnnotationRetrieval.get(JCas, Class<T>) is being used.  So, I could simply move 
the method into that project and then replace it with your code contribution 
later.  This would avoid introducing a soon-to-be-deprecated method in the 1.0 
release and relaxes the need to get the code you mentioned into 1.0 (I think.)  

I would like to leave in the method 
org.uimafit.util.AnnotationRetrieval.get(JCas, Class<T>, int) as it is useful 
for concise unit tests - but it occurs to me that it should probably be moved 
to the testing.util package so no one gets the wrong idea about its usefulness. 

I think our main priority for a 1.0 release should be avoiding putting stuff in 
there that we need to rearrange or remove later along with documentation.  As 
for new features - we can always add those later without penalty.  

Original comment by pvogren@gmail.com on 18 Jun 2010 at 4:43

GoogleCodeExporter commented 9 years ago
So, I am having troubles running the tests with maven after updating the 
version number.  When I run "mvn test" I get the following output.  It seems to 
be running Jg to generate the java type files and then exits without running 
the tests.  Any thoughts on how to proceed? 

[INFO] Scanning for projects...
[INFO] ------------------------------------------------------------------------
[INFO] Building uimaFIT
[INFO]    task-segment: [test]
[INFO] ------------------------------------------------------------------------
[INFO] [resources:resources {execution: default-resources}]
[INFO] Using 'UTF-8' encoding to copy filtered resources.
[INFO] Copying 1 resource
[INFO] [compiler:compile {execution: default-compile}]
[INFO] Nothing to compile - all classes are up to date
[INFO] [resources:testResources {execution: default-testResources}]
[INFO] Using 'UTF-8' encoding to copy filtered resources.
[INFO] Copying 16 resources
[INFO] Preparing exec:java
[WARNING] Removing: java from forked lifecycle, to prevent recursive invocation.

[INFO] No goals needed for project - skipping
[INFO] [exec:java {execution: default}]
Jun 18, 2010 11:16:04 AM org.apache.uima.tools.jcasgen.UimaLoggerProgressMonitor
 subTask(35)
INFO:  >>JCasGen Output going to 'C:\Users\Philip\Documents\Academic\workspace\u
imaFIT/src/test/java'
Jun 18, 2010 11:16:04 AM org.apache.uima.tools.jcasgen.UimaLoggerProgressMonitor
 subTask(35)
INFO:  >>JCasGen Reading the XML TAE descriptor, and creating types, for xml inp
ut file 'C:\Users\Philip\Documents\Academic\workspace\uimaFIT/src/test/resources
/org/uimafit/type/TypeSystem.xml'.
Jun 18, 2010 11:16:04 AM org.apache.uima.tools.jcasgen.UimaLoggerProgressMonitor
 subTask(35)
INFO:  >>JCasGen Replacing: 'org.uimafit.type.AnalyzedText'.
Jun 18, 2010 11:16:04 AM org.apache.uima.tools.jcasgen.UimaLoggerProgressMonitor
 subTask(35)
INFO:  >>JCasGen Replacing: 'org.uimafit.type.AnalyzedText_Type'.
Jun 18, 2010 11:16:04 AM org.apache.uima.tools.jcasgen.UimaLoggerProgressMonitor
 subTask(35)
INFO:  >>JCasGen Replacing: 'org.uimafit.type.Sentence'.
Jun 18, 2010 11:16:04 AM org.apache.uima.tools.jcasgen.UimaLoggerProgressMonitor
 subTask(35)
INFO:  >>JCasGen Replacing: 'org.uimafit.type.Sentence_Type'.
Jun 18, 2010 11:16:04 AM org.apache.uima.tools.jcasgen.UimaLoggerProgressMonitor
 subTask(35)
INFO:  >>JCasGen Replacing: 'org.uimafit.type.Token'.
Jun 18, 2010 11:16:04 AM org.apache.uima.tools.jcasgen.UimaLoggerProgressMonitor
 subTask(35)
INFO:  >>JCasGen Replacing: 'org.uimafit.type.Token_Type'.
Jun 18, 2010 11:16:04 AM org.apache.uima.tools.jcasgen.UimaLoggerProgressMonitor
 done(31)
INFO:  ** JCasGen Done.

Original comment by pvogren@gmail.com on 18 Jun 2010 at 5:32

GoogleCodeExporter commented 9 years ago
So, I removed from pom.xml the process-test-resources plugin configuration 
which ran jcasgen - because it isn't working with 2.3.0 for some reason.  I 
removed it and then committed the generated files so that it will compile.  I 
know that committing generated code is generally a bad idea - but I wasn't sure 
what else to do for now.  So, I'm not going to close this issue until we decide 
whether or not it's ok to have the jcasgen java type files in the repository or 
not.  

Original comment by pvogren@gmail.com on 18 Jun 2010 at 8:05

GoogleCodeExporter commented 9 years ago
Actually for running uimaFIT in Eclipse, it is "nicer" to have the JCas stuff 
in svn because first time I import the project, I always seem to have to do a 
Run as ->Maven package before Eclipse will find the generated sources. It would 
be cleaner to find a proper way of not having to check them in, but I am not 
opposed.

Original comment by richard.eckart on 19 Jun 2010 at 9:59

GoogleCodeExporter commented 9 years ago
So, one really annoying thing about checking these files in is that everytime 
the files get generated the data modified in the comments at the top of the 
.java files changes and then the files are shown as modified again.  I think 
this is probably more annoying than the import problem.  I would prefer to fix 
the pom.xml file so that it works like it used to - but I can go either way on 
this.

Original comment by pvogren@gmail.com on 20 Jun 2010 at 3:53

GoogleCodeExporter commented 9 years ago
I usually revert the types before I commit. Having the POM fixed is surely the 
better way.

Original comment by richard.eckart on 20 Jun 2010 at 8:53

GoogleCodeExporter commented 9 years ago
I committed a new class org.uimafit.util.JCasGenPomFriendly which calls 
org.apache.uima.tools.jcasgen.Jg.main0 method without calling system.exit.  
This seems to fix everything.

Original comment by pvogren@gmail.com on 29 Jun 2010 at 3:23