uima-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Marshall Schor <...@schor.com>
Subject Re: Cas Editor build script
Date Wed, 14 May 2008 12:25:40 GMT
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
>


Mime
View raw message