Marshall Schor (JIRA | 1 Jun 2010 04:56
Picon
Favicon

[jira] Created: (UIMA-1796) Automate inclusion in release notes of Jira issues

Automate inclusion in release notes of Jira issues
--------------------------------------------------

                 Key: UIMA-1796
                 URL: https://issues.apache.org/jira/browse/UIMA-1796
             Project: UIMA
          Issue Type: Improvement
          Components: Build, Packaging and Test
            Reporter: Marshall Schor
            Assignee: Marshall Schor
            Priority: Minor
             Fix For: 2.3.1

Current release process has a manual step to generate the release note which is done by generating a Jira
report of issues fixed in a particular release, and copying it into a set of release notes at the end.  The
overall release note typically looks like:

A brief descriptions
An overview of major changes for this release
Migration information from previous releases
How to get involved
How to report issues
List of Jira's fixed (generated)

Figure out how to automate the list of Jira's.  A possibility: use the maven changes plugin

--

-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
(Continue reading)

Tommaso Teofili (JIRA | 1 Jun 2010 09:42
Picon
Favicon

[jira] Commented: (UIMA-1051) doc build not working on Linux


    [
https://issues.apache.org/jira/browse/UIMA-1051?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12873914#action_12873914
] 

Tommaso Teofili commented on UIMA-1051:
---------------------------------------

I think that it's time to try to fix this, I am on a Mac and had to go to parent-pom-docbook POM.xml and remove
every <embedFile> tag to be able to install PearPackagingMavenPlugin.

I think that it's definitely a bad practice to have absolute paths and even worse when this avoid
non-Windows users/devs to build and install artifacts.
So requiring them to remove such tags or manually change the absolute paths is not an option in my opinion.

I will try to inspect if I can fix it another way (thinking about separating OS-based profiles for docbook at
the moment).

> doc build not working on Linux
> ------------------------------
>
>                 Key: UIMA-1051
>                 URL: https://issues.apache.org/jira/browse/UIMA-1051
>             Project: UIMA
>          Issue Type: Bug
>          Components: Async Scaleout, Documentation
>    Affects Versions: 2.2.2AS, 2.2.2, 2.3
>            Reporter: Marshall Schor
>            Priority: Minor
>
(Continue reading)

Eddie Epstein (JIRA | 1 Jun 2010 15:39
Picon
Favicon

[jira] Commented: (UIMA-1789) deployAsyncService script should use -XX:+HeapDumpOnOutOfMemoryError


    [
https://issues.apache.org/jira/browse/UIMA-1789?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12873996#action_12873996
] 

Eddie Epstein commented on UIMA-1789:
-------------------------------------

A problem with enabling heap dumps as the default is that many large files can accumulate for unsuspecting
users. To me, enabling heaps dumps is something done specifically when looking for problems, not a
typical default configuration. It would be nice to hear other opinions on the matter.

> deployAsyncService script should use -XX:+HeapDumpOnOutOfMemoryError
> --------------------------------------------------------------------
>
>                 Key: UIMA-1789
>                 URL: https://issues.apache.org/jira/browse/UIMA-1789
>             Project: UIMA
>          Issue Type: Improvement
>          Components: Async Scaleout
>            Reporter: Jörn Kottmann
>            Priority: Minor
>
> In case a user application needs to much memory an OuOfMemoryError stops the UIMA AS service. It would
> be nice if the VM would just dump the memory for further analysis and stops afterwards.
> For a sun vm this can be achieved with this command line option:
> -XX:+HeapDumpOnOutOfMemoryError
> Can this be done in our script, does it also work with other VMs ?

--

-- 
(Continue reading)

Jerry Cwiklik (JIRA | 1 Jun 2010 21:32
Picon
Favicon

[jira] Created: (UIMA-1797) UIMA AS processParentLast logic is not working correctly

UIMA AS processParentLast logic is not working correctly
--------------------------------------------------------

                 Key: UIMA-1797
                 URL: https://issues.apache.org/jira/browse/UIMA-1797
             Project: UIMA
          Issue Type: Bug
          Components: Async Scaleout
    Affects Versions: 2.3AS
            Reporter: Jerry Cwiklik
            Assignee: Jerry Cwiklik

UIMA AS aggregate fails with NPE when using multiple CMs  configured with processParentLast=true. The
aggregate throws this:
java.lang.NullPointerException
        at org.apache.uima.aae.controller.AggregateAnalysisEngineController_impl.forceToDropTheCas(AggregateAnalysisEngineController_impl.java:1822)
        at org.apache.uima.aae.controller.AggregateAnalysisEngineController_impl.finalStep(AggregateAnalysisEngineController_impl.java:1624)
        at org.apache.uima.aae.controller.AggregateAnalysisEngineController_impl.finalStep(AggregateAnalysisEngineController_impl.java:1714)
        at org.apache.uima.aae.controller.AggregateAnalysisEngineController_impl.executeFlowStep(AggregateAnalysisEngineController_impl.java:2175)
        at org.apache.uima.aae.controller.AggregateAnalysisEngineController_impl.process(AggregateAnalysisEngineController_impl.java:1207)
        at org.apache.uima.aae.handler.HandlerBase.invokeProcess(HandlerBase.java:118)
        at org.apache.uima.aae.handler.input.ProcessResponseHandler.cancelTimerAndProcess(ProcessResponseHandler.java:108)
        at org.apache.uima.aae.handler.input.ProcessResponseHandler.handleProcessResponseWithCASReference(ProcessResponseHandler.java:383)
        at org.apache.uima.aae.handler.input.ProcessResponseHandler.handle(ProcessResponseHandler.java:647)
        at org.apache.uima.aae.handler.HandlerBase.delegate(HandlerBase.java:149)
        at org.apache.uima.aae.handler.input.ProcessRequestHandler_impl.handle(ProcessRequestHandler_impl.java:989)
        at org.apache.uima.aae.spi.transport.vm.UimaVmMessageListener.onMessage(UimaVmMessageListener.java:107)
        at org.apache.uima.aae.spi.transport.vm.UimaVmMessageDispatcher$1.run(UimaVmMessageDispatcher.java:70)
        at java.util.concurrent.ThreadPoolExecutor$Worker.runTask(ThreadPoolExecutor.java:886)
        at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:908)
(Continue reading)

Marshall Schor (JIRA | 2 Jun 2010 02:11
Picon
Favicon

[jira] Commented: (UIMA-1051) doc build not working on Linux


    [
https://issues.apache.org/jira/browse/UIMA-1051?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12874328#action_12874328
] 

Marshall Schor commented on UIMA-1051:
--------------------------------------

I agree.  The absolute paths (to windows palaitino fonts) only work on Windows, and perhaps not on more
recent versions... 

Alternatives:

* give up on the special Palatino font, and just use something commonly available.
* use OS - triggered profiles to select Palatino on Windows platform, and something more or less equivalent
on (most?) (all?) other platforms (Linux & Mac).

The downside to switching fonts based on platforms is that the page layout may change, and the PDFs
generated may have different page numbers.  This may make the olink databases (which record page numbers,
among other things, for PDFs) dependent on the platform.  

It may also be the case that even if we went with a commonly available font, such as Times Roman, that the fonts
for that on different platforms may be slightly different, so the above problem may be there in any case.

My feeling at this point is to drop the special Palatino font, and go with the most common default variable
spacing PDF font (probably Times Roman), on all platforms.  Other opinions?

> doc build not working on Linux
> ------------------------------
>
(Continue reading)

Marshall Schor (JIRA | 2 Jun 2010 02:21
Picon
Favicon

[jira] Commented: (UIMA-1789) deployAsyncService script should use -XX:+HeapDumpOnOutOfMemoryError


    [
https://issues.apache.org/jira/browse/UIMA-1789?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12874331#action_12874331
] 

Marshall Schor commented on UIMA-1789:
--------------------------------------

Another potential issue is that this parameter is one of the XX ones, which means it is likely not standard
for all JVMs.  For instance, the IBM JVM doesn't have this option - see
http://publib.boulder.ibm.com/infocenter/javasdk/v6r0/index.jsp and search on -XX.

Another danger for users is that they would not expect this to be enabled by default.  This means that they
could become puzzled by very long termination events (in the case they were using a 64-bit OS and running
with very large heaps), or run out of disk space, etc.  

My opinion is that the right diagnosis strategy for an OutOfMemory error is probably situation dependent,
and only some of them (on some JVMs) would warrant a heap dump.  So I think this should be left to developers to
specify explicitly (if their JVM supports it), and not enabled by default.

> deployAsyncService script should use -XX:+HeapDumpOnOutOfMemoryError
> --------------------------------------------------------------------
>
>                 Key: UIMA-1789
>                 URL: https://issues.apache.org/jira/browse/UIMA-1789
>             Project: UIMA
>          Issue Type: Improvement
>          Components: Async Scaleout
>            Reporter: Jörn Kottmann
>            Priority: Minor
(Continue reading)

Marshall Schor (JIRA | 2 Jun 2010 03:33
Picon
Favicon

[jira] Commented: (UIMA-1051) doc build not working on Linux


    [
https://issues.apache.org/jira/browse/UIMA-1051?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12874363#action_12874363
] 

Marshall Schor commented on UIMA-1051:
--------------------------------------

I committed and deployed (snapshot) an update which for the PDF form uses the default Times Roman, not the
Palatino, and removed the font stuff for that.  

It looks OK to me.  Tommaso, can you update to head etc., and see if it works on now on your build platform?

> doc build not working on Linux
> ------------------------------
>
>                 Key: UIMA-1051
>                 URL: https://issues.apache.org/jira/browse/UIMA-1051
>             Project: UIMA
>          Issue Type: Bug
>          Components: Async Scaleout, Documentation
>    Affects Versions: 2.2.2AS, 2.2.2, 2.3
>            Reporter: Marshall Schor
>            Priority: Minor
>
> The document build on Linux for UIMA-AS (and  for base UIMA too) fails to properly make the olink (cross
document reference database system) work, because of differing file naming conventions between linux
and windows.
> The document build also fails to handle the font selection - that code was built just for Windows.

(Continue reading)

Tommaso Teofili (JIRA | 2 Jun 2010 10:55
Picon
Favicon

[jira] Commented: (UIMA-1051) doc build not working on Linux


    [
https://issues.apache.org/jira/browse/UIMA-1051?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12874507#action_12874507
] 

Tommaso Teofili commented on UIMA-1051:
---------------------------------------

Thanks Marshall, artifacts install well on my platform (Mac) too.
However in generated PDF pages where there are code snippets it seems that some (longer) lines go out of the
margin of the page.

> doc build not working on Linux
> ------------------------------
>
>                 Key: UIMA-1051
>                 URL: https://issues.apache.org/jira/browse/UIMA-1051
>             Project: UIMA
>          Issue Type: Bug
>          Components: Async Scaleout, Documentation
>    Affects Versions: 2.2.2AS, 2.2.2, 2.3
>            Reporter: Marshall Schor
>            Priority: Minor
>
> The document build on Linux for UIMA-AS (and  for base UIMA too) fails to properly make the olink (cross
document reference database system) work, because of differing file naming conventions between linux
and windows.
> The document build also fails to handle the font selection - that code was built just for Windows.

--

-- 
(Continue reading)

Tommaso Teofili (JIRA | 2 Jun 2010 11:29
Picon
Favicon

[jira] Issue Comment Edited: (UIMA-1051) doc build not working on Linux


    [
https://issues.apache.org/jira/browse/UIMA-1051?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12874507#action_12874507
] 

Tommaso Teofili edited comment on UIMA-1051 at 6/2/10 5:28 AM:
---------------------------------------------------------------

Thanks Marshall, artifacts install well and documentation builds on my platform (Mac) too.
However in generated PDF pages where there are code snippets it seems that some (longer) lines go out of the
margin of the page.

      was (Author: teofili):
    Thanks Marshall, artifacts install well on my platform (Mac) too.
However in generated PDF pages where there are code snippets it seems that some (longer) lines go out of the
margin of the page.

> doc build not working on Linux
> ------------------------------
>
>                 Key: UIMA-1051
>                 URL: https://issues.apache.org/jira/browse/UIMA-1051
>             Project: UIMA
>          Issue Type: Bug
>          Components: Async Scaleout, Documentation
>    Affects Versions: 2.2.2AS, 2.2.2, 2.3
>            Reporter: Marshall Schor
>            Priority: Minor
>
> The document build on Linux for UIMA-AS (and  for base UIMA too) fails to properly make the olink (cross
(Continue reading)

Marshall Schor | 2 Jun 2010 15:05

Staging area for website changes

Most website systems have a CMS (Content Management System) to allow
staging of changes, review, and making the changes go live, with some
automation.

Apache is considering such a system (from Day software) but it isn't yet
available. 

I'd like to have something where we could do some testing and evaluation
of new stuff before it goes live.  I'm thinking of using a convention of
uima.apache.org/staging root to do this.  The site:deploy goal would put
things here, and after review, we would move things to the official spots. 

We could put an "index.html" under this that says this is a staging
area, should not be "linked" to, and that information here is not
officially approved and is subject to frequent change.

Another alternative: Maven uses a somewhat different convention: they
have for each plugin, for instance, a staging area that is named
maven.apache.org/plugins/abc-plugin-1.2.1  - that is, they append the
version number to the subproject's top level name. 

Do either of these seem like a reasonable approach for now, until
something better comes along?  My leaning at this point is to the
simpler first alternative, above.

-Marshall


Gmane