You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@uima.apache.org by Marshall Schor <ms...@schor.com> on 2008/04/15 20:16:29 UTC
Issues with sandbox annotator distribution
I'm trying to build the sandbox annotator distr from SVN - I started
with an extract from the current level in SVN (trunk). I cd to
SandboxDistr, and did mvn install.
In the reactor it showed two entries for Apache UIMA Java SDK Add-Ons -
this seems wrong. These names are coming from the 2 poms in the
sandbox-distr - the names probably should be changed to be more descriptive.
The mvn install failed with a build error because it couldn't find the
PearPackagingMavenPlugin.
I re-ran mvn install on just that project. It also got a build error,
after compiling/testing/building the jar.
This was due to missing the uima-docbook-tool. I extracted that. and
re-ran.
The various docbook docs in the sandbox need to adopt the fix used in
other uima books to avoid overflowing the footer on even pages (minor).
I think adding this to the src/styles/top/pdf.xsl might do the trick:
<!-- width specifications: inside, center, outside -->
<!-- OVERRIDE: inside is large to accommodate large version strings
without overflowing -->
<xsl:param name="footer.column.widths">6 8 1</xsl:param>
The RegEx docbook has some lines inside <programlisting> elements that
are too long - they go off the page in the pdf. Look at page 12 for
instance.
Running the mvn install gave a build failure in running the test for
Apache UIMA Simple Server:
Running org.apache.uima.simpleserver.test.ServerTest
java.lang.NullPointerException
at
org.apache.uima.simpleserver.util.JettyUtils.getHost(JettyUtils.java:133)
at
org.apache.uima.simpleserver.test.ServerTest.test1(ServerTest.java:118)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at sun.reflect.NativeMethodAccessorImpl.invoke(Unknown Source)
at sun.reflect.DelegatingMethodAccessorImpl.invoke(Unknown Source)
at java.lang.reflect.Method.invoke(Unknown Source)
at
org.apache.maven.surefire.testset.PojoTestSet.executeTestMethod(PojoTestSet.java:150)
. . .
This error occurred twice.
Is there some setup I need to get this test to run?
-Marshall
Re: Issues with sandbox annotator distribution
Posted by Michael Baessler <mb...@michael-baessler.de>.
Marshall Schor wrote:
> Michael Baessler wrote:
>> Marshall Schor wrote:
>>
>>> Here's the next batch of things I've noticed about the annotator
>>> release.
>>>
>>> In the main uima build, doing a mvn install mutliple times doesn't cause
>>> the docbook PDF generation to be re-run (if the source hasn't changed),
>>> but in the sandbox distr, it does. (Haven't investigated why).
>>>
>> We have to investigate why, maybe something related to the PEAR
>> packaging we do, but is this an
>> issue that has to be solved for the current release?
>>
> In my opinion, this doesn't need to be fixed for this release. My guess
> is that the ant builds for these docs have hardcoded an always executed
> "clean" step.
>>> The POM for DictionaryAnnotator (and probably many others) has
>>> <dependency>
>>> <groupId>org.apache.uima</groupId>
>>> <artifactId>PearPackagingMavenPlugin</artifactId>
>>> <version>2.2.2-incubating</version>
>>> <scope>package</scope>
>>> </dependency>
>>>
>>> I couldn't find "package" as a valid scope value. The maven 2 docs at
>>> http://maven.apache.org/guides/introduction/introduction-to-dependency-mechanism.html#Dependency_Scope
>>>
>>>
>>> say there are 5 scopes available, and "package" is not one of them.
>>> Should this be something else? Something is causing the eclipse:eclipse
>>> to put in a bunch entries under "Referenced Libraries" that look like
>>> they don't belong, such as :plexus-utils-1.1.jar.
>>>
>> I choose package since it is just used to create the PEAR package for
>> the component. I think the
>> dependencies are caused by the Maven plugin.
>>
> But "package" doesn't appear to be a valid choice - the only choices
> listed (according to the above documentation) are :
> compile, provided, runtime, test, system and import.
>
> If you found some documentation somewhere which says "package" is a
> valid scope, can you post where, so I can learn about it?
Right, seems I mixed up two things here. I tried to change the scope, but I does not see any
differences. So I also think this is a minor one and should be changed for the next release.
Thanks for figuring out.
>
>>> The Dictionary Annotator has a jar, dict_annot_xml_types.jar. I
>>> couldn't easily find out where / how this jar is built, or
>>> maintained. Is that documented somewhere in the project? I don't
>>> think we want to
>>> ship something that includes a jar that is not buildable from
>>> source... (After some investigation - I'm beginning to think it's
>>> related to
>>> xmlbeans? If so, is there a step that maintainers of this code need to
>>> know about to build things using the xmlbeans package?)
>>> That jar also has package names that start with
>>> "org.apache.incubator" - this seems incorrect - I think the practice
>>> is to have package names
>>> not include "incubator" so that when graduation happens, package names
>>> don't need to change.
>>>
>> The dict_annot_xml_types.jar jar is a generated jar when using XML
>> Beans. Right the package name
>> org.apache.incubator is not perfect, but the packages are only
>> internally used by the
>> DictionaryAnnotator. We could change this easily without any impact
>> for the user.
>>
>> Do you think this must be changed for the current release.
>>
> If this is internal, I don't think this needs fixing for this release.
> Can you also remember to add some documentation for future maintainers
> on how to use/build xmlbeans (unless of course, it's already present,
> and I just missed it...)
I will add some documentation...
-- Michael
Re: Issues with sandbox annotator distribution
Posted by Marshall Schor <ms...@schor.com>.
Michael Baessler wrote:
> Marshall Schor wrote:
>
>> Here's the next batch of things I've noticed about the annotator release.
>>
>> In the main uima build, doing a mvn install mutliple times doesn't cause
>> the docbook PDF generation to be re-run (if the source hasn't changed),
>> but in the sandbox distr, it does. (Haven't investigated why).
>>
> We have to investigate why, maybe something related to the PEAR packaging we do, but is this an
> issue that has to be solved for the current release?
>
In my opinion, this doesn't need to be fixed for this release. My guess
is that the ant builds for these docs have hardcoded an always executed
"clean" step.
>> The POM for DictionaryAnnotator (and probably many others) has
>> <dependency>
>> <groupId>org.apache.uima</groupId>
>> <artifactId>PearPackagingMavenPlugin</artifactId>
>> <version>2.2.2-incubating</version>
>> <scope>package</scope>
>> </dependency>
>>
>> I couldn't find "package" as a valid scope value. The maven 2 docs at
>> http://maven.apache.org/guides/introduction/introduction-to-dependency-mechanism.html#Dependency_Scope
>>
>> say there are 5 scopes available, and "package" is not one of them.
>> Should this be something else? Something is causing the eclipse:eclipse
>> to put in a bunch entries under "Referenced Libraries" that look like
>> they don't belong, such as :plexus-utils-1.1.jar.
>>
> I choose package since it is just used to create the PEAR package for the component. I think the
> dependencies are caused by the Maven plugin.
>
But "package" doesn't appear to be a valid choice - the only choices
listed (according to the above documentation) are :
compile, provided, runtime, test, system and import.
If you found some documentation somewhere which says "package" is a
valid scope, can you post where, so I can learn about it?
>> The Dictionary Annotator has a jar, dict_annot_xml_types.jar. I
>> couldn't easily find out where / how this jar is built, or maintained.
>> Is that documented somewhere in the project? I don't think we want to
>> ship something that includes a jar that is not buildable from source...
>> (After some investigation - I'm beginning to think it's related to
>> xmlbeans? If so, is there a step that maintainers of this code need to
>> know about to build things using the xmlbeans package?)
>> That jar also has package names that start with "org.apache.incubator"
>> - this seems incorrect - I think the practice is to have package names
>> not include "incubator" so that when graduation happens, package names
>> don't need to change.
>>
> The dict_annot_xml_types.jar jar is a generated jar when using XML Beans. Right the package name
> org.apache.incubator is not perfect, but the packages are only internally used by the
> DictionaryAnnotator. We could change this easily without any impact for the user.
>
> Do you think this must be changed for the current release.
>
If this is internal, I don't think this needs fixing for this release.
Can you also remember to add some documentation for future maintainers
on how to use/build xmlbeans (unless of course, it's already present,
and I just missed it...)
-Marshall
Re: Issues with sandbox annotator distribution
Posted by Michael Baessler <mb...@michael-baessler.de>.
Marshall Schor wrote:
> Here's the next batch of things I've noticed about the annotator release.
>
> In the main uima build, doing a mvn install mutliple times doesn't cause
> the docbook PDF generation to be re-run (if the source hasn't changed),
> but in the sandbox distr, it does. (Haven't investigated why).
We have to investigate why, maybe something related to the PEAR packaging we do, but is this an
issue that has to be solved for the current release?
>
> The POM for DictionaryAnnotator (and probably many others) has
> <dependency>
> <groupId>org.apache.uima</groupId>
> <artifactId>PearPackagingMavenPlugin</artifactId>
> <version>2.2.2-incubating</version>
> <scope>package</scope>
> </dependency>
>
> I couldn't find "package" as a valid scope value. The maven 2 docs at
> http://maven.apache.org/guides/introduction/introduction-to-dependency-mechanism.html#Dependency_Scope
>
> say there are 5 scopes available, and "package" is not one of them.
> Should this be something else? Something is causing the eclipse:eclipse
> to put in a bunch entries under "Referenced Libraries" that look like
> they don't belong, such as :plexus-utils-1.1.jar.
I choose package since it is just used to create the PEAR package for the component. I think the
dependencies are caused by the Maven plugin.
>
> The Dictionary Annotator has a jar, dict_annot_xml_types.jar. I
> couldn't easily find out where / how this jar is built, or maintained.
> Is that documented somewhere in the project? I don't think we want to
> ship something that includes a jar that is not buildable from source...
> (After some investigation - I'm beginning to think it's related to
> xmlbeans? If so, is there a step that maintainers of this code need to
> know about to build things using the xmlbeans package?)
> That jar also has package names that start with "org.apache.incubator"
> - this seems incorrect - I think the practice is to have package names
> not include "incubator" so that when graduation happens, package names
> don't need to change.
The dict_annot_xml_types.jar jar is a generated jar when using XML Beans. Right the package name
org.apache.incubator is not perfect, but the packages are only internally used by the
DictionaryAnnotator. We could change this easily without any impact for the user.
Do you think this must be changed for the current release.
-- Michael
Re: Issues with sandbox annotator distribution
Posted by Thilo Goetz <tw...@gmx.de>.
Marshall Schor wrote:
> Here's the next batch of things I've noticed about the annotator release.
[...]
> I see in the POM that several jars are set up to come from our local SVN
> as opposed to getting them from maven repos. For instance, the 2.2.0
> version of org.apache.xmlbeans:xmlbeans is in the maven 2 repo. It
> seems to me we should use those sources, as opposed to putting the jars
> into our SVN. Our biniary distributions can still distribute those
> jars, if that's what's wanted. For the uima-as project, we only have
> local jars for those cases where the jars from maven won't work (e.g.,
> we needed to patch the jars). Is there a reason some jars were copied
> into our SVN?
In the case of the simple server, plain ignorance. If you know how
to change this, go right ahead. Please make sure that the ant script
for building the simple server xbean jar also still works.
>
> The POM for the RegularExpressionAnnotator says it has a dependency on
> the jsr173 jar, but I did a search in the source for that project and
> didn't see any reference to the packages in the jsr173 jar. I think
> this dependency (and perhaps others) are incorrect, not just for this
> project, but perhaps others as well?
That's an xbean dependency. Try running the simple server without that
jar, and you'll see it won't work ;-)
--Thilo
Re: Issues with sandbox annotator distribution
Posted by Marshall Schor <ms...@schor.com>.
Here's the next batch of things I've noticed about the annotator release.
In the main uima build, doing a mvn install mutliple times doesn't cause
the docbook PDF generation to be re-run (if the source hasn't changed),
but in the sandbox distr, it does. (Haven't investigated why).
The POM for DictionaryAnnotator (and probably many others) has
<dependency>
<groupId>org.apache.uima</groupId>
<artifactId>PearPackagingMavenPlugin</artifactId>
<version>2.2.2-incubating</version>
<scope>package</scope>
</dependency>
I couldn't find "package" as a valid scope value. The maven 2 docs at
http://maven.apache.org/guides/introduction/introduction-to-dependency-mechanism.html#Dependency_Scope
say there are 5 scopes available, and "package" is not one of them.
Should this be something else? Something is causing the eclipse:eclipse
to put in a bunch entries under "Referenced Libraries" that look like
they don't belong, such as :plexus-utils-1.1.jar.
The Dictionary Annotator has a jar, dict_annot_xml_types.jar. I
couldn't easily find out where / how this jar is built, or maintained.
Is that documented somewhere in the project? I don't think we want to
ship something that includes a jar that is not buildable from source...
(After some investigation - I'm beginning to think it's related to
xmlbeans? If so, is there a step that maintainers of this code need to
know about to build things using the xmlbeans package?)
That jar also has package names that start with "org.apache.incubator"
- this seems incorrect - I think the practice is to have package names
not include "incubator" so that when graduation happens, package names
don't need to change.
I see in the POM that several jars are set up to come from our local SVN
as opposed to getting them from maven repos. For instance, the 2.2.0
version of org.apache.xmlbeans:xmlbeans is in the maven 2 repo. It
seems to me we should use those sources, as opposed to putting the jars
into our SVN. Our biniary distributions can still distribute those
jars, if that's what's wanted. For the uima-as project, we only have
local jars for those cases where the jars from maven won't work (e.g.,
we needed to patch the jars). Is there a reason some jars were copied
into our SVN?
The POM for the RegularExpressionAnnotator says it has a dependency on
the jsr173 jar, but I did a search in the source for that project and
didn't see any reference to the packages in the jsr173 jar. I think
this dependency (and perhaps others) are incorrect, not just for this
project, but perhaps others as well?
-Marshall
Re: Issues with sandbox annotator distribution
Posted by Marshall Schor <ms...@schor.com>.
Michael Baessler wrote:
> Marshall Schor wrote:
>
>
>> OK - I extracted the source zip file from mbaessler on people.a.o, added
>> the things needed to get docbook to run, and ran mvn install on the
>> sandboxDistr directory. It ran up to the SimpleServer and had the same
>> failure:
>> java.lang.NullPointerException
>> at
>> org.apache.uima.simpleserver.util.JettyUtils.getHost(JettyUtils.java:133)
>>
>>
>
> What do you mean by "added the things needed to get docbook to run" ?
>
You know how docbook, from an initial checkout, goes out to the web and
pulls down the Docbook XSL templates, the Saxon XSLT engine, and the
"jai" java jars to fix up images? To avoid that, I copied those into
the download from another download which already had them there.
-Marshall
> -- Michael
>
>
>
>
Re: Issues with sandbox annotator distribution
Posted by Michael Baessler <mb...@michael-baessler.de>.
Marshall Schor wrote:
> OK - I extracted the source zip file from mbaessler on people.a.o, added
> the things needed to get docbook to run, and ran mvn install on the
> sandboxDistr directory. It ran up to the SimpleServer and had the same
> failure:
> java.lang.NullPointerException
> at
> org.apache.uima.simpleserver.util.JettyUtils.getHost(JettyUtils.java:133)
>
What do you mean by "added the things needed to get docbook to run" ?
-- Michael
Re: Issues with sandbox annotator distribution
Posted by Marshall Schor <ms...@schor.com>.
Thilo Goetz wrote:
> Jörn Kottmann wrote:
>>> Your machine is kaputt :-)
>>
>> His machine is fine, it was able to build the Cas Editor.
>>
>> Jörn
>
> That's probably what broke it ;-)
LOL - Actually, I'm "in the queue" for a new machine. Mine is 3+ years
old, and has this nice feature: If you run code that accesses a Windows
"compressed" disk a lot, the machine at some point instantly re-boots.
What I think happens is that the CPU overheats (the monitor of CPU use
goes way up when accessing a compressed disk), which causes a hard
shut-down (not even a blue screen).
Thanks for the kind words :-) -Marshall
Re: Issues with sandbox annotator distribution
Posted by Thilo Goetz <tw...@gmx.de>.
Michael Baessler wrote:
> Thilo Goetz wrote:
>> Jörn Kottmann wrote:
>>>> Your machine is kaputt :-)
>>> His machine is fine, it was able to build the Cas Editor.
>>>
>>> Jörn
>> That's probably what broke it ;-)
>>
> What going on here... I thought we talk about the SimpleServer tests... not the CasEditor build :-)
>
> -- Michael
We're just kidding. They have nothing to do with
each other (I think).
--Thilo
Re: Issues with sandbox annotator distribution
Posted by Michael Baessler <mb...@michael-baessler.de>.
Thilo Goetz wrote:
> Jörn Kottmann wrote:
>>> Your machine is kaputt :-)
>>
>> His machine is fine, it was able to build the Cas Editor.
>>
>> Jörn
>
> That's probably what broke it ;-)
>
What going on here... I thought we talk about the SimpleServer tests... not the CasEditor build :-)
-- Michael
Re: Issues with sandbox annotator distribution
Posted by Thilo Goetz <tw...@gmx.de>.
Jörn Kottmann wrote:
>> Your machine is kaputt :-)
>
> His machine is fine, it was able to build the Cas Editor.
>
> Jörn
That's probably what broke it ;-)
Re: Issues with sandbox annotator distribution
Posted by Jörn Kottmann <ko...@gmail.com>.
> Your machine is kaputt :-)
His machine is fine, it was able to build the Cas Editor.
Jörn
Re: Issues with sandbox annotator distribution
Posted by Marshall Schor <ms...@schor.com>.
Thilo Goetz wrote:
> Marshall Schor wrote:
> [...]
>> OK - I extracted the source zip file from mbaessler on people.a.o,
>> added the things needed to get docbook to run, and ran mvn install on
>> the sandboxDistr directory. It ran up to the SimpleServer and had
>> the same failure:
>> java.lang.NullPointerException
>> at
>> org.apache.uima.simpleserver.util.JettyUtils.getHost(JettyUtils.java:133)
>>
>>
>> -Marshall
>
> Your machine is kaputt :-)
kaputt - that's a German word, right? :-)
> Seriously, I'm out of ideas what the problem
> could be.
Any ideas of how to start looking for things at this end, including
pointers to docs to read, would be good :-)
-Marshall
>
> --Thilo
>
>
>
>
Re: Issues with sandbox annotator distribution
Posted by Thilo Goetz <tw...@gmx.de>.
Marshall Schor wrote:
[...]
> OK - I extracted the source zip file from mbaessler on people.a.o, added
> the things needed to get docbook to run, and ran mvn install on the
> sandboxDistr directory. It ran up to the SimpleServer and had the same
> failure:
> java.lang.NullPointerException
> at
> org.apache.uima.simpleserver.util.JettyUtils.getHost(JettyUtils.java:133)
>
> -Marshall
Your machine is kaputt :-) Seriously, I'm out of ideas what the problem
could be.
--Thilo
Re: Issues with sandbox annotator distribution
Posted by Marshall Schor <ms...@schor.com>.
Michael Baessler wrote:
> Marshall Schor wrote:
>
>> Thilo Goetz wrote:
>>
>>> Marshall Schor wrote:
>>> [...]
>>>
>>>> Running the mvn install gave a build failure in running the test for
>>>> Apache UIMA Simple Server:
>>>> Running org.apache.uima.simpleserver.test.ServerTest
>>>> java.lang.NullPointerException
>>>> at
>>>> org.apache.uima.simpleserver.util.JettyUtils.getHost(JettyUtils.java:133)
>>>>
>>>> at
>>>> org.apache.uima.simpleserver.test.ServerTest.test1(ServerTest.java:118)
>>>> at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
>>>> at sun.reflect.NativeMethodAccessorImpl.invoke(Unknown Source)
>>>> at sun.reflect.DelegatingMethodAccessorImpl.invoke(Unknown
>>>> Source)
>>>> at java.lang.reflect.Method.invoke(Unknown Source)
>>>> at
>>>> org.apache.maven.surefire.testset.PojoTestSet.executeTestMethod(PojoTestSet.java:150)
>>>>
>>>> . . .
>>>> This error occurred twice.
>>>>
>>>> Is there some setup I need to get this test to run?
>>>>
>>>> -Marshall
>>>>
>>> Works for me. Platform, jdk? I have tested this with various jvms, on
>>> windows and linux.
>>>
>> Platform = Windows XP (my thinkpad). c:\>java -version
>> java version "1.6.0_05"
>> Java(TM) SE Runtime Environment (build 1.6.0_05-b13)
>> Java HotSpot(TM) Client VM (build 10.0-b19, mixed mode, sharing)
>>
>
> This JVM works fine for me.
>
> Please try to build with the provided source package I added to my apache home space.
>
OK - I extracted the source zip file from mbaessler on people.a.o, added
the things needed to get docbook to run, and ran mvn install on the
sandboxDistr directory. It ran up to the SimpleServer and had the same
failure:
java.lang.NullPointerException
at
org.apache.uima.simpleserver.util.JettyUtils.getHost(JettyUtils.java:133)
-Marshall
Re: Issues with sandbox annotator distribution
Posted by Michael Baessler <mb...@michael-baessler.de>.
Marshall Schor wrote:
> Thilo Goetz wrote:
>> Marshall Schor wrote:
>> [...]
>>> Running the mvn install gave a build failure in running the test for
>>> Apache UIMA Simple Server:
>>> Running org.apache.uima.simpleserver.test.ServerTest
>>> java.lang.NullPointerException
>>> at
>>> org.apache.uima.simpleserver.util.JettyUtils.getHost(JettyUtils.java:133)
>>>
>>> at
>>> org.apache.uima.simpleserver.test.ServerTest.test1(ServerTest.java:118)
>>> at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
>>> at sun.reflect.NativeMethodAccessorImpl.invoke(Unknown Source)
>>> at sun.reflect.DelegatingMethodAccessorImpl.invoke(Unknown
>>> Source)
>>> at java.lang.reflect.Method.invoke(Unknown Source)
>>> at
>>> org.apache.maven.surefire.testset.PojoTestSet.executeTestMethod(PojoTestSet.java:150)
>>>
>>> . . .
>>> This error occurred twice.
>>>
>>> Is there some setup I need to get this test to run?
>>>
>>> -Marshall
>>
>> Works for me. Platform, jdk? I have tested this with various jvms, on
>> windows and linux.
> Platform = Windows XP (my thinkpad). c:\>java -version
> java version "1.6.0_05"
> Java(TM) SE Runtime Environment (build 1.6.0_05-b13)
> Java HotSpot(TM) Client VM (build 10.0-b19, mixed mode, sharing)
This JVM works fine for me.
Please try to build with the provided source package I added to my apache home space.
-- Michael
Re: Issues with sandbox annotator distribution
Posted by Marshall Schor <ms...@schor.com>.
Tong Fin wrote:
> Hi Marshall,
>
> ---- Quoted Text ------
>
>> I looked, and saw that my local repository had the 2.2 and 2.3 versions of
>>
> the surfire plugin. I deleted these from my repository, along with
> maven-test and maven-surefire-reports, for good measure, and re-ran.
> -------------------------
>
> If I would like to do the same clean up, what files should I delete (I am
> not familiar with surefile) ?
>
Easiest thing is to delete the entire repository :-) If you wanted to
do that, you go to (windows) Documents and
Settings/the-login-that-you-work-under/.m2/repository and delete the
files under that (leave "repository").
I went to: ...\.m2\repository\org\apache\maven\plugins and deleted the
directories:
maven-surefire-plugin and 2 others - something like maven-test and
maven-surefire-reports.
When maven re-populated my local repo with the surefire plugin version
2.4.2, I see it has been moved up a level ...
-Marshall
> Thanks,
> Tong
>
> On Wed, Apr 16, 2008 at 5:05 PM, Marshall Schor <ms...@schor.com> wrote:
>
>
>> Problem solved !
>>
>> A search of the web using the search string "surefile @beforeclass" turned
>> up a surefire issue:
>> http://jira.codehaus.org/browse/SUREFIRE-448
>> which, in turn, implied that one should be using surefire version 2.4.2.
>>
>> Of course, our POMs don't specify a level for many maven things like this,
>> so they just use whatever level you have in your repository. Those of you
>> who delete the local repository contents from time to time end up
>> downloading upgraded levels.
>>
>> I looked, and saw that my local repository had the 2.2 and 2.3 versions of
>> the surfire plugin. I deleted these from my repository, along with
>> maven-test and maven-surefire-reports, for good measure, and re-ran.
>> This caused maven to download the current (latest = 2.4.2) version of the
>> surefire plugin, so now things are working :-)
>>
>> -Marshall
>>
>>
>> Marshall Schor wrote:
>>
>>
>>> More info: Running the failing test (ServerTest) from Eclipse using
>>> run-as Junit, works reliably...
>>> Time to look at what's different between this and maven's running of
>>> it...
>>>
>>> -Marshall
>>>
>>> Marshall Schor wrote:
>>>
>>>
>>>> Can someone for whom the simple-server tests work, confirm these are
>>>> the right levels of software:
>>>>
>>>> httpcore-4.0-alpha6.jar
>>>> log4j-1.2.8.jar
>>>> commons-logging-1.0.4.jar
>>>> servlet-api-2.5-6.1.8.jar
>>>> junit-4.0.jar
>>>> jetty-util-6.1.8.jar
>>>> commons-codec-1.3.jar
>>>> jetty-6.1.8.jar
>>>> servlet-api-2.4.jar
>>>> httpclient-4.0-alpha2.jar
>>>>
>>>> Note the httpcore and httpclient seem to be at different levels.
>>>> Note that there are 2 servlet-api's in the class path at different
>>>> levels.
>>>>
>>>> The above is the actual classpath order that mvn install uses when
>>>> running the tests (except that I left out some jars in this list that were
>>>> the uima stuff, or came from the simple-server libraries).
>>>>
>>>> If you run the test using --debug in maven, it will show the
>>>> classpath. Please let me know of any discrepencies.
>>>>
>>>> Thanks. -Marshall
>>>>
>>>>
>>>>
>>>>
>>>
>>>
>
>
Re: Issues with sandbox annotator distribution
Posted by Tong Fin <to...@gmail.com>.
Hi Marshall,
---- Quoted Text ------
> I looked, and saw that my local repository had the 2.2 and 2.3 versions of
the surfire plugin. I deleted these from my repository, along with
maven-test and maven-surefire-reports, for good measure, and re-ran.
-------------------------
If I would like to do the same clean up, what files should I delete (I am
not familiar with surefile) ?
Thanks,
Tong
On Wed, Apr 16, 2008 at 5:05 PM, Marshall Schor <ms...@schor.com> wrote:
> Problem solved !
>
> A search of the web using the search string "surefile @beforeclass" turned
> up a surefire issue:
> http://jira.codehaus.org/browse/SUREFIRE-448
> which, in turn, implied that one should be using surefire version 2.4.2.
>
> Of course, our POMs don't specify a level for many maven things like this,
> so they just use whatever level you have in your repository. Those of you
> who delete the local repository contents from time to time end up
> downloading upgraded levels.
>
> I looked, and saw that my local repository had the 2.2 and 2.3 versions of
> the surfire plugin. I deleted these from my repository, along with
> maven-test and maven-surefire-reports, for good measure, and re-ran.
> This caused maven to download the current (latest = 2.4.2) version of the
> surefire plugin, so now things are working :-)
>
> -Marshall
>
>
> Marshall Schor wrote:
>
> > More info: Running the failing test (ServerTest) from Eclipse using
> > run-as Junit, works reliably...
> > Time to look at what's different between this and maven's running of
> > it...
> >
> > -Marshall
> >
> > Marshall Schor wrote:
> >
> > > Can someone for whom the simple-server tests work, confirm these are
> > > the right levels of software:
> > >
> > > httpcore-4.0-alpha6.jar
> > > log4j-1.2.8.jar
> > > commons-logging-1.0.4.jar
> > > servlet-api-2.5-6.1.8.jar
> > > junit-4.0.jar
> > > jetty-util-6.1.8.jar
> > > commons-codec-1.3.jar
> > > jetty-6.1.8.jar
> > > servlet-api-2.4.jar
> > > httpclient-4.0-alpha2.jar
> > >
> > > Note the httpcore and httpclient seem to be at different levels.
> > > Note that there are 2 servlet-api's in the class path at different
> > > levels.
> > >
> > > The above is the actual classpath order that mvn install uses when
> > > running the tests (except that I left out some jars in this list that were
> > > the uima stuff, or came from the simple-server libraries).
> > >
> > > If you run the test using --debug in maven, it will show the
> > > classpath. Please let me know of any discrepencies.
> > >
> > > Thanks. -Marshall
> > >
> > >
> > >
> >
> >
> >
>
Re: Issues with sandbox annotator distribution
Posted by Thilo Goetz <tw...@gmx.de>.
Marshall Schor wrote:
> Problem solved !
>
> A search of the web using the search string "surefile @beforeclass"
> turned up a surefire issue:
> http://jira.codehaus.org/browse/SUREFIRE-448
> which, in turn, implied that one should be using surefire version 2.4.2.
>
> Of course, our POMs don't specify a level for many maven things like
> this, so they just use whatever level you have in your repository.
> Those of you who delete the local repository contents from time to time
> end up downloading upgraded levels.
>
> I looked, and saw that my local repository had the 2.2 and 2.3 versions
> of the surfire plugin. I deleted these from my repository, along with
> maven-test and maven-surefire-reports, for good measure, and re-ran.
> This caused maven to download the current (latest = 2.4.2) version of
> the surefire plugin, so now things are working :-)
>
I thought maven always tried to get the latest stuff? I have 2.3 on
my laptop and the test still works. Oh well, main thing is it works
now.
--Thilo
Re: Issues with sandbox annotator distribution
Posted by Marshall Schor <ms...@schor.com>.
Michael Baessler wrote:
> Marshall Schor wrote:
>
>> Problem solved !
>>
>> A search of the web using the search string "surefile @beforeclass"
>> turned up a surefire issue:
>> http://jira.codehaus.org/browse/SUREFIRE-448
>> which, in turn, implied that one should be using surefire version 2.4.2.
>>
>> Of course, our POMs don't specify a level for many maven things like
>> this, so they just use whatever level you have in your repository.
>> Those of you who delete the local repository contents from time to time
>> end up downloading upgraded levels.
>>
>> I looked, and saw that my local repository had the 2.2 and 2.3 versions
>> of the surfire plugin. I deleted these from my repository, along with
>> maven-test and maven-surefire-reports, for good measure, and re-ran.
>> This caused maven to download the current (latest = 2.4.2) version of
>> the surefire plugin, so now things are working :-)
>>
>> -Marshall
>>
>>
>> Marshall Schor wrote:
>>
>>> More info: Running the failing test (ServerTest) from Eclipse using
>>> run-as Junit, works reliably...
>>> Time to look at what's different between this and maven's running of
>>> it...
>>>
>>> -Marshall
>>>
>>> Marshall Schor wrote:
>>>
>>>> Can someone for whom the simple-server tests work, confirm these are
>>>> the right levels of software:
>>>>
>>>> httpcore-4.0-alpha6.jar
>>>> log4j-1.2.8.jar
>>>> commons-logging-1.0.4.jar
>>>> servlet-api-2.5-6.1.8.jar
>>>> junit-4.0.jar
>>>> jetty-util-6.1.8.jar
>>>> commons-codec-1.3.jar
>>>> jetty-6.1.8.jar
>>>> servlet-api-2.4.jar
>>>> httpclient-4.0-alpha2.jar
>>>>
>>>> Note the httpcore and httpclient seem to be at different levels.
>>>> Note that there are 2 servlet-api's in the class path at different
>>>> levels.
>>>>
>>>> The above is the actual classpath order that mvn install uses when
>>>> running the tests (except that I left out some jars in this list that
>>>> were the uima stuff, or came from the simple-server libraries).
>>>>
>>>> If you run the test using --debug in maven, it will show the
>>>> classpath. Please let me know of any discrepencies.
>>>>
>>>> Thanks. -Marshall
>>>>
>>>>
>>>>
>>>
>>>
> So do you have any remaining open issues for the current release?
>
> I would like to close the vote to go on.
>
> -- Michael
>
>
>
I have no open issues. You may close the vote - in 5 min. I want to
find the vote thread and cast my +1. -Marshall
Re: Issues with sandbox annotator distribution
Posted by Michael Baessler <mb...@michael-baessler.de>.
Marshall Schor wrote:
> Problem solved !
>
> A search of the web using the search string "surefile @beforeclass"
> turned up a surefire issue:
> http://jira.codehaus.org/browse/SUREFIRE-448
> which, in turn, implied that one should be using surefire version 2.4.2.
>
> Of course, our POMs don't specify a level for many maven things like
> this, so they just use whatever level you have in your repository.
> Those of you who delete the local repository contents from time to time
> end up downloading upgraded levels.
>
> I looked, and saw that my local repository had the 2.2 and 2.3 versions
> of the surfire plugin. I deleted these from my repository, along with
> maven-test and maven-surefire-reports, for good measure, and re-ran.
> This caused maven to download the current (latest = 2.4.2) version of
> the surefire plugin, so now things are working :-)
>
> -Marshall
>
>
> Marshall Schor wrote:
>> More info: Running the failing test (ServerTest) from Eclipse using
>> run-as Junit, works reliably...
>> Time to look at what's different between this and maven's running of
>> it...
>>
>> -Marshall
>>
>> Marshall Schor wrote:
>>> Can someone for whom the simple-server tests work, confirm these are
>>> the right levels of software:
>>>
>>> httpcore-4.0-alpha6.jar
>>> log4j-1.2.8.jar
>>> commons-logging-1.0.4.jar
>>> servlet-api-2.5-6.1.8.jar
>>> junit-4.0.jar
>>> jetty-util-6.1.8.jar
>>> commons-codec-1.3.jar
>>> jetty-6.1.8.jar
>>> servlet-api-2.4.jar
>>> httpclient-4.0-alpha2.jar
>>>
>>> Note the httpcore and httpclient seem to be at different levels.
>>> Note that there are 2 servlet-api's in the class path at different
>>> levels.
>>>
>>> The above is the actual classpath order that mvn install uses when
>>> running the tests (except that I left out some jars in this list that
>>> were the uima stuff, or came from the simple-server libraries).
>>>
>>> If you run the test using --debug in maven, it will show the
>>> classpath. Please let me know of any discrepencies.
>>>
>>> Thanks. -Marshall
>>>
>>>
>>
>>
>>
>
So do you have any remaining open issues for the current release?
I would like to close the vote to go on.
-- Michael
Re: Issues with sandbox annotator distribution
Posted by Marshall Schor <ms...@schor.com>.
Problem solved !
A search of the web using the search string "surefile @beforeclass"
turned up a surefire issue:
http://jira.codehaus.org/browse/SUREFIRE-448
which, in turn, implied that one should be using surefire version 2.4.2.
Of course, our POMs don't specify a level for many maven things like
this, so they just use whatever level you have in your repository.
Those of you who delete the local repository contents from time to time
end up downloading upgraded levels.
I looked, and saw that my local repository had the 2.2 and 2.3 versions
of the surfire plugin. I deleted these from my repository, along with
maven-test and maven-surefire-reports, for good measure, and re-ran.
This caused maven to download the current (latest = 2.4.2) version of
the surefire plugin, so now things are working :-)
-Marshall
Marshall Schor wrote:
> More info: Running the failing test (ServerTest) from Eclipse using
> run-as Junit, works reliably...
> Time to look at what's different between this and maven's running of
> it...
>
> -Marshall
>
> Marshall Schor wrote:
>> Can someone for whom the simple-server tests work, confirm these are
>> the right levels of software:
>>
>> httpcore-4.0-alpha6.jar
>> log4j-1.2.8.jar
>> commons-logging-1.0.4.jar
>> servlet-api-2.5-6.1.8.jar
>> junit-4.0.jar
>> jetty-util-6.1.8.jar
>> commons-codec-1.3.jar
>> jetty-6.1.8.jar
>> servlet-api-2.4.jar
>> httpclient-4.0-alpha2.jar
>>
>> Note the httpcore and httpclient seem to be at different levels.
>> Note that there are 2 servlet-api's in the class path at different
>> levels.
>>
>> The above is the actual classpath order that mvn install uses when
>> running the tests (except that I left out some jars in this list that
>> were the uima stuff, or came from the simple-server libraries).
>>
>> If you run the test using --debug in maven, it will show the
>> classpath. Please let me know of any discrepencies.
>>
>> Thanks. -Marshall
>>
>>
>
>
>
Re: Issues with sandbox annotator distribution
Posted by Marshall Schor <ms...@schor.com>.
More info: Running the failing test (ServerTest) from Eclipse using
run-as Junit, works reliably...
Time to look at what's different between this and maven's running of it...
-Marshall
Marshall Schor wrote:
> Can someone for whom the simple-server tests work, confirm these are
> the right levels of software:
>
> httpcore-4.0-alpha6.jar
> log4j-1.2.8.jar
> commons-logging-1.0.4.jar
> servlet-api-2.5-6.1.8.jar
> junit-4.0.jar
> jetty-util-6.1.8.jar
> commons-codec-1.3.jar
> jetty-6.1.8.jar
> servlet-api-2.4.jar
> httpclient-4.0-alpha2.jar
>
> Note the httpcore and httpclient seem to be at different levels.
> Note that there are 2 servlet-api's in the class path at different
> levels.
>
> The above is the actual classpath order that mvn install uses when
> running the tests (except that I left out some jars in this list that
> were the uima stuff, or came from the simple-server libraries).
>
> If you run the test using --debug in maven, it will show the
> classpath. Please let me know of any discrepencies.
>
> Thanks. -Marshall
>
>
Re: Issues with sandbox annotator distribution
Posted by Marshall Schor <ms...@schor.com>.
Can someone for whom the simple-server tests work, confirm these are the
right levels of software:
httpcore-4.0-alpha6.jar
log4j-1.2.8.jar
commons-logging-1.0.4.jar
servlet-api-2.5-6.1.8.jar
junit-4.0.jar
jetty-util-6.1.8.jar
commons-codec-1.3.jar
jetty-6.1.8.jar
servlet-api-2.4.jar
httpclient-4.0-alpha2.jar
Note the httpcore and httpclient seem to be at different levels.
Note that there are 2 servlet-api's in the class path at different levels.
The above is the actual classpath order that mvn install uses when
running the tests (except that I left out some jars in this list that
were the uima stuff, or came from the simple-server libraries).
If you run the test using --debug in maven, it will show the classpath.
Please let me know of any discrepencies.
Thanks. -Marshall
Re: Issues with sandbox annotator distribution
Posted by Marshall Schor <ms...@schor.com>.
Thilo Goetz wrote:
> Marshall Schor wrote:
>> Thilo Goetz wrote:
>>> Marshall Schor wrote:
>>> [...]
>>>> Running the mvn install gave a build failure in running the test
>>>> for Apache UIMA Simple Server:
>>>> Running org.apache.uima.simpleserver.test.ServerTest
>>>> java.lang.NullPointerException
>>>> at
>>>> org.apache.uima.simpleserver.util.JettyUtils.getHost(JettyUtils.java:133)
>>>>
>>>> at
>>>> org.apache.uima.simpleserver.test.ServerTest.test1(ServerTest.java:118)
>>>>
>>>> at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
>>>> at sun.reflect.NativeMethodAccessorImpl.invoke(Unknown Source)
>>>> at sun.reflect.DelegatingMethodAccessorImpl.invoke(Unknown
>>>> Source)
>>>> at java.lang.reflect.Method.invoke(Unknown Source)
>>>> at
>>>> org.apache.maven.surefire.testset.PojoTestSet.executeTestMethod(PojoTestSet.java:150)
>>>>
>>>> . . .
>>>> This error occurred twice.
>
> Looks like the server is null. That can only occur if setUp()
> wasn't called. You're not attempting to run this with junit 3
> by any chance?
I'm running mvn install. Running this with the --debug shows this
classpath for the testing, which seems to have junit-4.0
[DEBUG] Test Classpath :
[DEBUG] C:\a\apache-uima\annotators\SimpleServer\target\classes
[DEBUG] C:\a\apache-uima\annotators\SimpleServer\target\test-classes
[DEBUG] C:\Documents and
Settings\Administrator\.m2\repository\org\apache\httpcomponents\httpcore\4.0-alpha6\httpcore-4.0-alpha6.jar
[DEBUG] C:\Documents and
Settings\Administrator\.m2\repository\log4j\log4j\1.2.8\log4j-1.2.8.jar
[DEBUG] C:\a\apache-uima\annotators\SimpleServer\lib\xbean.jar
[DEBUG] C:\Documents and
Settings\Administrator\.m2\repository\commons-logging\commons-logging\1.0.4\commons-logging-1.0.4.jar
[DEBUG] C:\Documents and
Settings\Administrator\.m2\repository\org\mortbay\jetty\servlet-api-2.5\6.1.8\servlet-api-2.5-6.1.8.jar
[DEBUG] C:\Documents and
Settings\Administrator\.m2\repository\org\apache\uima\uimaj-component-test-util\2.2.2-incubating\uimaj-component-test-util-2.2.2-incu
bating.jar
[DEBUG] C:\Documents and
Settings\Administrator\.m2\repository\org\apache\uima\uimaj-test-util\2.2.2-incubating\uimaj-test-util-2.2.2-incubating.jar
[DEBUG] C:\Documents and
Settings\Administrator\.m2\repository\junit\junit\4.0\junit-4.0.jar
[DEBUG] C:\Documents and
Settings\Administrator\.m2\repository\org\mortbay\jetty\jetty-util\6.1.8\jetty-util-6.1.8.jar
[DEBUG] C:\Documents and
Settings\Administrator\.m2\repository\commons-codec\commons-codec\1.3\commons-codec-1.3.jar
[DEBUG]
C:\a\apache-uima\annotators\SimpleServer\lib\uima-simple-server-xbean.jar
[DEBUG] C:\a\apache-uima\annotators\SimpleServer\lib\jsr173_1.0_api.jar
[DEBUG] C:\Documents and
Settings\Administrator\.m2\repository\org\mortbay\jetty\jetty\6.1.8\jetty-6.1.8.jar
[DEBUG] C:\Documents and
Settings\Administrator\.m2\repository\javax\servlet\servlet-api\2.4\servlet-api-2.4.jar
[DEBUG] C:\Documents and
Settings\Administrator\.m2\repository\org\apache\uima\uimaj-core\2.2.2-incubating\uimaj-core-2.2.2-incubating.jar
[DEBUG] C:\Documents and
Settings\Administrator\.m2\repository\org\apache\httpcomponents\httpclient\4.0-alpha2\httpclient-4.0-alpha2.jar
[DEBUG] Setting system property [localRepository]=[C:\Documents and
Settings\Administrator\.m2\repository]
[DEBUG] Setting system property
[basedir]=[C:\a\apache-uima\annotators\SimpleServer]
-Marshall
>
> --Thilo
>
>
>
Re: Issues with sandbox annotator distribution
Posted by Thilo Goetz <tw...@gmx.de>.
Marshall Schor wrote:
> Thilo Goetz wrote:
>> Marshall Schor wrote:
>> [...]
>>> Running the mvn install gave a build failure in running the test for
>>> Apache UIMA Simple Server:
>>> Running org.apache.uima.simpleserver.test.ServerTest
>>> java.lang.NullPointerException
>>> at
>>> org.apache.uima.simpleserver.util.JettyUtils.getHost(JettyUtils.java:133)
>>>
>>> at
>>> org.apache.uima.simpleserver.test.ServerTest.test1(ServerTest.java:118)
>>> at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
>>> at sun.reflect.NativeMethodAccessorImpl.invoke(Unknown Source)
>>> at sun.reflect.DelegatingMethodAccessorImpl.invoke(Unknown
>>> Source)
>>> at java.lang.reflect.Method.invoke(Unknown Source)
>>> at
>>> org.apache.maven.surefire.testset.PojoTestSet.executeTestMethod(PojoTestSet.java:150)
>>>
>>> . . .
>>> This error occurred twice.
Looks like the server is null. That can only occur if setUp()
wasn't called. You're not attempting to run this with junit 3
by any chance?
--Thilo
Re: Issues with sandbox annotator distribution
Posted by Marshall Schor <ms...@schor.com>.
Thilo Goetz wrote:
> Marshall Schor wrote:
> [...]
>> Running the mvn install gave a build failure in running the test for
>> Apache UIMA Simple Server:
>> Running org.apache.uima.simpleserver.test.ServerTest
>> java.lang.NullPointerException
>> at
>> org.apache.uima.simpleserver.util.JettyUtils.getHost(JettyUtils.java:133)
>>
>> at
>> org.apache.uima.simpleserver.test.ServerTest.test1(ServerTest.java:118)
>> at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
>> at sun.reflect.NativeMethodAccessorImpl.invoke(Unknown Source)
>> at sun.reflect.DelegatingMethodAccessorImpl.invoke(Unknown
>> Source)
>> at java.lang.reflect.Method.invoke(Unknown Source)
>> at
>> org.apache.maven.surefire.testset.PojoTestSet.executeTestMethod(PojoTestSet.java:150)
>>
>> . . .
>> This error occurred twice.
>>
>> Is there some setup I need to get this test to run?
>>
>> -Marshall
>
> Works for me. Platform, jdk? I have tested this with various jvms, on
> windows and linux.
Platform = Windows XP (my thinkpad).
c:\>java -version
java version "1.6.0_05"
Java(TM) SE Runtime Environment (build 1.6.0_05-b13)
Java HotSpot(TM) Client VM (build 10.0-b19, mixed mode, sharing)
>
> --Thilo
>
>
>
>
Re: Issues with sandbox annotator distribution
Posted by Thilo Goetz <tw...@gmx.de>.
Marshall Schor wrote:
[...]
> Running the mvn install gave a build failure in running the test for
> Apache UIMA Simple Server:
> Running org.apache.uima.simpleserver.test.ServerTest
> java.lang.NullPointerException
> at
> org.apache.uima.simpleserver.util.JettyUtils.getHost(JettyUtils.java:133)
> at
> org.apache.uima.simpleserver.test.ServerTest.test1(ServerTest.java:118)
> at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
> at sun.reflect.NativeMethodAccessorImpl.invoke(Unknown Source)
> at sun.reflect.DelegatingMethodAccessorImpl.invoke(Unknown Source)
> at java.lang.reflect.Method.invoke(Unknown Source)
> at
> org.apache.maven.surefire.testset.PojoTestSet.executeTestMethod(PojoTestSet.java:150)
>
> . . .
> This error occurred twice.
>
> Is there some setup I need to get this test to run?
>
> -Marshall
Works for me. Platform, jdk? I have tested this with various jvms, on
windows and linux.
--Thilo
Re: Issues with sandbox annotator distribution
Posted by Thilo Goetz <tw...@gmx.de>.
You need to cd to the annotator-package subdir.
Marshall Schor wrote:
> I'm trying to build the sandbox annotator distr from SVN - I started
> with an extract from the current level in SVN (trunk). I cd to
> SandboxDistr, and did mvn install.
>
> In the reactor it showed two entries for Apache UIMA Java SDK Add-Ons -
> this seems wrong. These names are coming from the 2 poms in the
> sandbox-distr - the names probably should be changed to be more
> descriptive.
>
> The mvn install failed with a build error because it couldn't find the
> PearPackagingMavenPlugin.
>
> I re-ran mvn install on just that project. It also got a build error,
> after compiling/testing/building the jar.
> This was due to missing the uima-docbook-tool. I extracted that. and
> re-ran.
>
> The various docbook docs in the sandbox need to adopt the fix used in
> other uima books to avoid overflowing the footer on even pages (minor).
> I think adding this to the src/styles/top/pdf.xsl might do the trick:
> <!-- width specifications: inside, center, outside -->
> <!-- OVERRIDE: inside is large to accommodate large version strings
> without overflowing -->
> <xsl:param name="footer.column.widths">6 8 1</xsl:param>
>
> The RegEx docbook has some lines inside <programlisting> elements that
> are too long - they go off the page in the pdf. Look at page 12 for
> instance.
>
> Running the mvn install gave a build failure in running the test for
> Apache UIMA Simple Server:
> Running org.apache.uima.simpleserver.test.ServerTest
> java.lang.NullPointerException
> at
> org.apache.uima.simpleserver.util.JettyUtils.getHost(JettyUtils.java:133)
> at
> org.apache.uima.simpleserver.test.ServerTest.test1(ServerTest.java:118)
> at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
> at sun.reflect.NativeMethodAccessorImpl.invoke(Unknown Source)
> at sun.reflect.DelegatingMethodAccessorImpl.invoke(Unknown Source)
> at java.lang.reflect.Method.invoke(Unknown Source)
> at
> org.apache.maven.surefire.testset.PojoTestSet.executeTestMethod(PojoTestSet.java:150)
>
> . . .
> This error occurred twice.
>
> Is there some setup I need to get this test to run?
>
> -Marshall
Cas Editor build
Posted by Jörn Kottmann <ko...@gmail.com>.
> So the only issue with building may be to make the log4j "optional".
I do not have this issues.
Its possible to build the Cas Editor with a fresh
eclipse 3.3.2 + EMF + delta package + uima runtime plugin.
I added the release notes.
I think there is one more issue. During building documentation
there are downloads of binaries which could not be included in
the distribution.
Currently they are copied over into the source distribution.
How do we avoid this in the other build scripts ?
Thanks,
Jörn
Re: Issues with sandbox annotator distribution
Posted by Michael Baessler <mb...@michael-baessler.de>.
Marshall Schor wrote:
> Issues building CasEditor
>
> First I tried "mvn install" - that said this wasn't a maven-buildable
> project.
>
> Then I looked and saw there was a build.xml in the "build-files"
> directory. I tried running that with Ant - that failed because I hadn't
> checked out uimaj-ep-runtime into the same directory structure. Once I
> did that, I tried it again, and got a failure: missing an eclipse plugin
> that exported org.apache.log4j.
>
> See this note:
> http://www.mail-archive.com/uima-dev@incubator.apache.org/msg05850.html
>
> I downloaded the eclipse plugin for this into my eclipse being used to
> build this, and tried again. It got farther :-) but failed, saying it
> couldn't load the plug-in "org.eclipse.core.filesystem.linux.ppc". I
> discovered that I hadn't downloaded the "all" version of the "delta
> pak" I did that, and now it builds.
>
> So the only issue with building may be to make the log4j "optional".
>
> -Marshall
CasEditor build does not work with Maven and is also not part of the annotator package. It is a
separate release package. Joern is currently workig on the build. As soon he finished his work we
are ready to build the CasEditor for the first release candidate.
-- Michael
Re: Issues with sandbox annotator distribution
Posted by Marshall Schor <ms...@schor.com>.
Issues building CasEditor
First I tried "mvn install" - that said this wasn't a maven-buildable
project.
Then I looked and saw there was a build.xml in the "build-files"
directory. I tried running that with Ant - that failed because I hadn't
checked out uimaj-ep-runtime into the same directory structure. Once I
did that, I tried it again, and got a failure: missing an eclipse plugin
that exported org.apache.log4j.
See this note:
http://www.mail-archive.com/uima-dev@incubator.apache.org/msg05850.html
I downloaded the eclipse plugin for this into my eclipse being used to
build this, and tried again. It got farther :-) but failed, saying it
couldn't load the plug-in "org.eclipse.core.filesystem.linux.ppc". I
discovered that I hadn't downloaded the "all" version of the "delta
pak" I did that, and now it builds.
So the only issue with building may be to make the log4j "optional".
-Marshall
Re: Issues with sandbox annotator distribution
Posted by Marshall Schor <ms...@schor.com>.
Michael Baessler wrote:
> Marshall Schor wrote:
>
>> I'm trying to build the sandbox annotator distr from SVN - I started
>> with an extract from the current level in SVN (trunk). I cd to
>> SandboxDistr, and did mvn install.
>>
>
> You cannot build the Sandbox from trunk since it has some dependencies to UIMA core projects.
> Either you use the current sandbox tag sandbox-2.2.2-10 or you have the necessary uima-docbook-tool
> project in the workspace.
>
>
>> In the reactor it showed two entries for Apache UIMA Java SDK Add-Ons -
>> this seems wrong. These names are coming from the 2 poms in the
>> sandbox-distr - the names probably should be changed to be more
>> descriptive.
>>
> OK, we can change the description for the next release.
>
>> The mvn install failed with a build error because it couldn't find the
>> PearPackagingMavenPlugin.
>>
>> I re-ran mvn install on just that project. It also got a build error,
>> after compiling/testing/building the jar.
>> This was due to missing the uima-docbook-tool. I extracted that. and
>> re-ran.
>>
>>
> related to to the trunk build mentioned above. When using the sandbox tag, all need stuff is extracted.
>
>
>> The various docbook docs in the sandbox need to adopt the fix used in
>> other uima books to avoid overflowing the footer on even pages (minor).
>> I think adding this to the src/styles/top/pdf.xsl might do the trick:
>> <!-- width specifications: inside, center, outside -->
>> <!-- OVERRIDE: inside is large to accommodate large version strings
>> without overflowing -->
>> <xsl:param name="footer.column.widths">6 8 1</xsl:param>
>>
>> The RegEx docbook has some lines inside <programlisting> elements that
>> are too long - they go off the page in the pdf. Look at page 12 for
>> instance.
>>
> Can we do this more the next release, I think it is a minor one?
>
OK to do in next release, I agree it's minor. -Marshall
> -- Michael
>
>
>
Re: Issues with sandbox annotator distribution
Posted by Michael Baessler <mb...@michael-baessler.de>.
Marshall Schor wrote:
> I'm trying to build the sandbox annotator distr from SVN - I started
> with an extract from the current level in SVN (trunk). I cd to
> SandboxDistr, and did mvn install.
You cannot build the Sandbox from trunk since it has some dependencies to UIMA core projects.
Either you use the current sandbox tag sandbox-2.2.2-10 or you have the necessary uima-docbook-tool
project in the workspace.
>
> In the reactor it showed two entries for Apache UIMA Java SDK Add-Ons -
> this seems wrong. These names are coming from the 2 poms in the
> sandbox-distr - the names probably should be changed to be more
> descriptive.
OK, we can change the description for the next release.
>
> The mvn install failed with a build error because it couldn't find the
> PearPackagingMavenPlugin.
>
> I re-ran mvn install on just that project. It also got a build error,
> after compiling/testing/building the jar.
> This was due to missing the uima-docbook-tool. I extracted that. and
> re-ran.
>
related to to the trunk build mentioned above. When using the sandbox tag, all need stuff is extracted.
> The various docbook docs in the sandbox need to adopt the fix used in
> other uima books to avoid overflowing the footer on even pages (minor).
> I think adding this to the src/styles/top/pdf.xsl might do the trick:
> <!-- width specifications: inside, center, outside -->
> <!-- OVERRIDE: inside is large to accommodate large version strings
> without overflowing -->
> <xsl:param name="footer.column.widths">6 8 1</xsl:param>
>
> The RegEx docbook has some lines inside <programlisting> elements that
> are too long - they go off the page in the pdf. Look at page 12 for
> instance.
Can we do this more the next release, I think it is a minor one?
-- Michael