On 27/05/11 09:57, Jens Grivolla wrote: > On 05/26/2011 08:37 PM, Greg Holmberg wrote: > >> [...] What I want may simply be outside the design target of PEAR files. My >> expectations of PEAR files were based on how other archive formats in >> Java work. JAR files, WAR files, etc. These can all be use in-place, >> without any re-writing of their contents. You can just refer to them, >> and the system can locate the things in them at run-time through >> relative paths, regardless of what directory they've been dropped into. >> In other words, there's no installation process for JAR files or WAR files. >> [...] > > At least in Tomcat, WAR files actually get unzipped before use, and the UIMA > SimpleRestServer also installs PEAR files on the fly. Using SimpleRestServer > you actually have one WAR file which contains a PEAR file, and when you deploy > it in Tomcat, it automatically unzips the WAR and then (I believe on first > call > to the service) installs the PEAR. The descriptor used in the WAR references > the > PEAR file directly. > > I believe that WARs only get installed when they haven't been installed yet, > and > I would hope the same is true for the PEAR installation, so there's no > overhead > from installing on each run of the pipeline. > > It still rewrites $main_root, etc., but it gets pretty close to a transparent > use of PEARs. At least for UIMA-AS a similar deployment scheme would make > sense, and one could substitute "install pear, adjust classpath, deploy > pointing > to pear descriptor" with simply "deploy pointing to pear file" which would be > much nicer, as we could skip all the launch scripts we are currently > creating. > For other uses one might have to think more about automatically cleaning up > the > unzipped directory, etc. > > Bye, > Jens >
It is also worth pointing out that if you control the code, you can write/package your annotators so they just run out of a jar file. The resource loading mechanism of UIMA can load resources from the classpath, i.e., from a jar file. I always package my annotators that way. Then even if you package them in a pear (which you don't have to), the pear install doesn't have to do any of the error prone file rewriting magic. It has been put forward that if you have resources like dictionaries as separate files on disk, they are easier to maintain. That's an argument I only buy for a very limited set of circumstances (e.g., you have a web app and you let users edit the dictionary on the fly or something). Generally, if we're talking about a real deployment, you don't want to do that anyway. It's just as easy to replace a jar. --Thilo
