You changed the build.xml file to copy the org.apache.uima.runtime
from
${eclipseLocation}/plugins instead from the uimaj-ep-runtime project.
This change does not help, because the build already
looks at ${eclipseLocation}/plugins which are necessary for the
build.
The build will work without copying it. Here is the story behind it.
The question a while ago was how we can handle the dependence
on the runtime plugin. My first solution to this was that we just
copy it
over from the uimaj-ep-runtime project. But this does not worked for
tagging the release and building the Cas Editor from the source
package.
Then I extended the build script to not necessarily copy the runtime
plugin from the uimaj-ep-runtime project, but if it exists. The build
then works only
if the runtime is only located at ${eclipseLocation}/plugins. If
both ways
of getting the runtime plugin fail the build is halted and an error
message is printed to the console.
Do you think now we should only get the runtime plugin
from ${eclipseLocation}/plugins ?
I think so. Getting it from uimaj-ep-runtime project can't work for
extracting the
CasEditor for a tagged release. If the copying from $
{eclipseLocation}/plugins
isn't necessary we can remove this step. Agreed?
Ok, I committed it already.
For all jars we ship, we have to set the correct manifest. So maybe
it will be easier to package the
CasEditor plugin as jar and add to this jar the correct manifest -
seems to be easier right :-)
But this is just my point of view. Maybe there is no issue with such
jars inside eclipse plugins.
I already planned to ship the plugin as jar file instead of the
folder. There are other good
reasons to do this. I encountered problems with unzipping the Cas
Editor zip file in the
windows desktop folder because of too long paths.
This resulted in a strange error message of the unzip tool.
I just have to find out how to tell the build to package it as a jar
plugin.
Jörn
