Re: where to get Jars for builds -
How about getting them from the local Maven Repo, using the maven
version info?
This implies that the builder has run some process which insures the
local repo has
the right tagged build of the particular version of the plugin, and
works even if the
version hasn't yet been uploaded (released) to the official maven repo
but instead
was built locally from a release candidate.
For the Eclipse Update Site, I use this ant macro:
<macrodef name="makePluginJar">
<attribute name="project-name"/>
<attribute name="org-name"/>
<sequential>
<copy
tofile="target/eclipse-update-site/plugins/@{org-name}_${project.full.eclipse.version}.jar"
file="${envVar.HOMEPATH}/.m2/repository/org/apache/uima/@{project-name}/${project.full.eclipse.version}/@{project-name}-${project.full.eclipse.version}.jar"/>
</sequential>
</macrodef>
The line of interest is the one starting with "file=".
-Marshall
Jörn Kottmann wrote:
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
