Hi Greg, The original design of PEARs was partly motivated by use cases involving wrapping legacy code that had all kinds of fairly arbitrary requirements, hence the general solution of allowing replacement of string parts by the "install directory".
I can see the value of your use case, and think it would be a good addition :-). I suggest you put it into Jira, with as much use-case particulars, and then let's see others agree it would be a good addition, and if anyone wants to volunteer to help make it happen. -Marshall On 5/26/2011 2:37 PM, Greg Holmberg wrote: > Hi Marshall-- > > >> To support something like this, I'm thinking it would require that during >> initialization of the pipeline, UIMA would need to "install" the PEAR in some >> temporary location somewhere, and then use that installation. (The >> installation >> is needed because of the possibility that there are resources that are >> referenced by strings in the PEAR configuration, which need to be resolved >> relative to where the PEAR was installed.) >> >> Is this what you have in mind? Though, typically, this is not something >> you'd >> want to do every time a pipeline was run, I think. > > Well, I'm not sure if that would be a solution or not. I'll have to > investigate. > > 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. > > PEAR files break my expectations. The installation process un-archives the > PEAR file and re-writes some of its contents, such that it is then bound to > the directory that it's been dropped into. I can't be moved or used on a > different machine without re-writing some contents again. I find this > surprising and inconsistent with Java conventions. > > I was hoping for a system in which all references made within the PEAR file > (i.e. in the descriptor files) are relative or by name, and then the system > can resolve everything at run-time, without having to un-zip them or modify > them. Intuitively, it seems like that should be possible by managing the > classpath and datapath, but I don't know enough about PEAR files to say for > sure. > > Do you think it would be fruitful for me to pursue a path of enhancing the > PEAR system to do that (avoid the installation process, provide 100% run-time > resolution), or is that just so counter to the design of PEAR files that I > would be wasting my time? > > If I can't achieve this zero-install goal with PEAR files, could I achieve it > with OSGi? > > Thanks for any advice you can offer, > > Greg > > >
