[jira] [Commented] (UIMA-5586) uv3: DocumentAnnotation subclasses not handled as in UIMAv2 during deserialization
[
https://issues.apache.org/jira/browse/UIMA-5586?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16176818#comment-16176818
]
Richard Eckart de Castilho commented on UIMA-5586:
--
{noformat}
package de.tudarmstadt.ukp.dkpro.core.api.metadata.type;
import org.apache.uima.jcas.tcas.DocumentAnnotation;
public class DocumentMetaData extends DocumentAnnotation {
public final static String _TypeName =
"de.tudarmstadt.ukp.dkpro.core.api.metadata.type.DocumentMetaData";
{noformat}
> uv3: DocumentAnnotation subclasses not handled as in UIMAv2 during
> deserialization
> --
>
> Key: UIMA-5586
> URL: https://issues.apache.org/jira/browse/UIMA-5586
> Project: UIMA
> Issue Type: Bug
> Components: Core Java Framework
>Affects Versions: 3.0.0SDK-beta
>Reporter: Richard Eckart de Castilho
>
> Consider the case that you have custom subclass of the uima
> `DocumentAnnotation`, let's call it `DocumentMetaData`. Next, we have an XMI
> file which contains an annotation of the `DocumentMetaData` type.
> When loading such an XMI file in UIMAv2, the CAS ends up with a single
> `DocumentMetaData` annotation which is accessible via
> `cas.getDocumentAnnotation()`.
> When loading the same file with UIMAv3, the CAS ends up with both, a
> `DocumentAnnotation` and a `DocumentMetaData` annotation and
> `cas.getDocumentAnnotation()` returns the former.
> The same appears to happen when deserializing a CAS from various binary
> formats.
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
[jira] [Commented] (UIMA-5586) uv3: DocumentAnnotation subclasses not handled as in UIMAv2 during deserialization
[ https://issues.apache.org/jira/browse/UIMA-5586?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16176748#comment-16176748 ] Marshall Schor commented on UIMA-5586: -- I found a strange bug in the code that converts JCas class names to uima types - by any chance is the type of your DocumentMetaData "org.apache.uima.jcas.cas.DocumentMetaData" or "org.apache.uima.jcas.tcas.DocumentMetaData"? That would encounter the bug... Also, found out that I forgot to convert the built-in DocumentAnnotation JCas class to the new format. > uv3: DocumentAnnotation subclasses not handled as in UIMAv2 during > deserialization > -- > > Key: UIMA-5586 > URL: https://issues.apache.org/jira/browse/UIMA-5586 > Project: UIMA > Issue Type: Bug > Components: Core Java Framework >Affects Versions: 3.0.0SDK-beta >Reporter: Richard Eckart de Castilho > > Consider the case that you have custom subclass of the uima > `DocumentAnnotation`, let's call it `DocumentMetaData`. Next, we have an XMI > file which contains an annotation of the `DocumentMetaData` type. > When loading such an XMI file in UIMAv2, the CAS ends up with a single > `DocumentMetaData` annotation which is accessible via > `cas.getDocumentAnnotation()`. > When loading the same file with UIMAv3, the CAS ends up with both, a > `DocumentAnnotation` and a `DocumentMetaData` annotation and > `cas.getDocumentAnnotation()` returns the former. > The same appears to happen when deserializing a CAS from various binary > formats. -- This message was sent by Atlassian JIRA (v6.4.14#64029)
Re: [jira] [Created] (UIMA-5586) uv3: XmiCasDeserializer does not handle DocumentAnnotation subclasses as before
thanks! will take a look... -M On 9/22/2017 5:14 AM, Richard Eckart de Castilho (JIRA) wrote: > Richard Eckart de Castilho created UIMA-5586: > > > Summary: uv3: XmiCasDeserializer does not handle > DocumentAnnotation subclasses as before > Key: UIMA-5586 > URL: https://issues.apache.org/jira/browse/UIMA-5586 > Project: UIMA > Issue Type: Bug > Components: Core Java Framework > Affects Versions: 3.0.0SDK-beta > Reporter: Richard Eckart de Castilho > > > Consider the case that you have custom subclass of the uima > `DocumentAnnotation`, let's call it `DocumentMetaData`. Next, we have an XMI > file which contains an annotation of the `DocumentMetaData` type. > > When loading such an XMI file in UIMAv2, the CAS ends up with a single > `DocumentMetaData` annotation which is accessible via > `cas.getDocumentAnnotation()`. > > When loading the same file with UIMAv3, the CAS ends up with both, a > `DocumentAnnotation` and a `DocumentMetaData` annotation and > `cas.getDocumentAnnotation()` returns the former. > > > > -- > This message was sent by Atlassian JIRA > (v6.4.14#64029) >
[jira] [Updated] (UIMA-3346) "generate" goal should include type system imports
[ https://issues.apache.org/jira/browse/UIMA-3346?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Richard Eckart de Castilho updated UIMA-3346: - Fix Version/s: (was: 2.4.0uimaFIT) 2.3.1uimaFIT > "generate" goal should include type system imports > -- > > Key: UIMA-3346 > URL: https://issues.apache.org/jira/browse/UIMA-3346 > Project: UIMA > Issue Type: Improvement > Components: uimaFIT-Maven-Plugin >Affects Versions: 2.2.0uimaFIT >Reporter: Jens Grivolla >Assignee: Richard Eckart de Castilho >Priority: Minor > Fix For: 2.3.1uimaFIT > > Attachments: UIMA-3346.2.patch, UIMA-3346.patch > > > The "generate" goal of the uimaFIT maven plugin should include type system > imports in the generated descriptors. This would make those descriptors > directly usable in descriptor-based workflows such as CPE or UIMA-AS. > In our case, we point to the TS descriptor files directly in types.txt, thus > not relying on any "magic" TS discovery. This could translate directly to a > corresponding import by name in the XML descriptor. More sophisticated setups > might of course be more difficult to handle. -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Comment Edited] (UIMA-5586) uv3: DocumentAnnotation subclasses not handled as in UIMAv2 during deserialization
[
https://issues.apache.org/jira/browse/UIMA-5586?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16176191#comment-16176191
]
Richard Eckart de Castilho edited comment on UIMA-5586 at 9/22/17 9:44 AM:
---
Possibly related to this issue is another observation. When deserializing some
binary CAS formats, there is a NPE in certain cases. Here is an example that
might serve for reproduction:
{noformat}
@Test
public void test6LenientPlainUima() throws Exception
{
CAS source = JCasFactory.createJCas().getCas();
CAS target = JCasFactory.createJCas().getCas();
new DocumentMetaData(source.getJCas(), 0, 0).addToIndexes();
@SuppressWarnings("resource")
ByteArrayOutputStream bos = new ByteArrayOutputStream();
CasIOUtils.save(source, bos, COMPRESSED_FILTERED);
bos.close();
CasIOUtils.load(new ByteArrayInputStream(bos.toByteArray()), target);
}
{noformat}
Mind this is a minimal code for reproduction. The same happens when
deserializing within the context of an initialized AnalysisEngine.
The NPE only seems to be thrown when the `DocumentMetaData` is added via JCas:
{noformat}
java.lang.NullPointerException
at org.apache.uima.cas.impl.CASImpl.getView(CASImpl.java:2224)
at
org.apache.uima.cas.impl.BinaryCasSerDes6.deserializeAfterVersion(BinaryCasSerDes6.java:1892)
at
org.apache.uima.cas.impl.BinaryCasSerDes.reinit(BinaryCasSerDes.java:595)
at org.apache.uima.util.CasIOUtils.load(CasIOUtils.java:382)
at org.apache.uima.util.CasIOUtils.load(CasIOUtils.java:313)
at org.apache.uima.util.CasIOUtils.load(CasIOUtils.java:237)
...
{noformat}
I have set up a similar test using only the plain CAS API which seems to work
fine:
{noformat}
@Test
public void test6LenientPlainUima2() throws Exception
{
TypeSystemDescription tsd = new TypeSystemDescription_impl();
TypeDescription td = tsd.addType("DocumentMetaData", "",
CAS.TYPE_NAME_DOCUMENT_ANNOTATION);
td.addFeature("feat", "", CAS.TYPE_NAME_STRING);
CAS source = CasCreationUtils.createCas(tsd, null, null, null);
CAS target = CasCreationUtils.createCas(tsd, null, null, null);
AnnotationFS dmd = source
.createAnnotation(source.getTypeSystem().getType("DocumentMetaData"), 0, 0);
source.addFsToIndexes(dmd);
assertEquals("DocumentMetaData",
source.getDocumentAnnotation().getType().getName());
@SuppressWarnings("resource")
ByteArrayOutputStream bos = new ByteArrayOutputStream();
CasIOUtils.save(source, bos, COMPRESSED_FILTERED);
bos.close();
CasIOUtils.load(new ByteArrayInputStream(bos.toByteArray()), target);
}
{noformat}
was (Author: rec):
Possibly related to this issue is another observation. When deserializing some
binary CAS formats, there is a NPE in certain cases. Here is an example that
might serve for reproduction:
{noformat}
@Test
public void test6LenientPlainUima() throws Exception
{
CAS source = JCasFactory.createJCas().getCas();
CAS target = JCasFactory.createJCas().getCas();
new DocumentMetaData(source.getJCas(), 0, 0).addToIndexes();
@SuppressWarnings("resource")
ByteArrayOutputStream bos = new ByteArrayOutputStream();
CasIOUtils.save(source, bos, COMPRESSED_FILTERED);
bos.close();
CasIOUtils.load(new ByteArrayInputStream(bos.toByteArray()), target);
}
{noformat}
The NPE only seems to be thrown when the `DocumentMetaData` is added via JCas:
{noformat}
java.lang.NullPointerException
at org.apache.uima.cas.impl.CASImpl.getView(CASImpl.java:2224)
at
org.apache.uima.cas.impl.BinaryCasSerDes6.deserializeAfterVersion(BinaryCasSerDes6.java:1892)
at
org.apache.uima.cas.impl.BinaryCasSerDes.reinit(BinaryCasSerDes.java:595)
at org.apache.uima.util.CasIOUtils.load(CasIOUtils.java:382)
at org.apache.uima.util.CasIOUtils.load(CasIOUtils.java:313)
at org.apache.uima.util.CasIOUtils.load(CasIOUtils.java:237)
...
{noformat}
I have set up a similar test using only the plain CAS API which seems to work
fine:
{noformat}
@Test
public void test6LenientPlainUima2() throws Exception
{
TypeSystemDescription tsd = new TypeSystemDescription_impl();
TypeDescription td = tsd.addType("DocumentMetaData", "",
CAS.TYPE_NAME_DOCUMENT_ANNOTATION);
td.addFeature("feat", "", CAS.TYPE_NAME_STRING);
CAS source = CasCreationUtils.createCas(tsd, null, null, null);
CAS target = CasCreationUtils.createCas(tsd, null, null, null);
AnnotationFS dmd = source
.createAnnotation(source.getTypeSystem().getType("DocumentMetaData"), 0, 0);
[jira] [Comment Edited] (UIMA-5586) uv3: DocumentAnnotation subclasses not handled as in UIMAv2 during deserialization
[
https://issues.apache.org/jira/browse/UIMA-5586?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16176191#comment-16176191
]
Richard Eckart de Castilho edited comment on UIMA-5586 at 9/22/17 9:42 AM:
---
Possibly related to this issue is another observation. When deserializing some
binary CAS formats, there is a NPE in certain cases. Here is an example that
might serve for reproduction:
{noformat}
@Test
public void test6LenientPlainUima() throws Exception
{
CAS source = JCasFactory.createJCas().getCas();
CAS target = JCasFactory.createJCas().getCas();
new DocumentMetaData(source.getJCas(), 0, 0).addToIndexes();
@SuppressWarnings("resource")
ByteArrayOutputStream bos = new ByteArrayOutputStream();
CasIOUtils.save(source, bos, COMPRESSED_FILTERED);
bos.close();
CasIOUtils.load(new ByteArrayInputStream(bos.toByteArray()), target);
}
{noformat}
The NPE only seems to be thrown when the `DocumentMetaData` is added via JCas:
{noformat}
java.lang.NullPointerException
at org.apache.uima.cas.impl.CASImpl.getView(CASImpl.java:2224)
at
org.apache.uima.cas.impl.BinaryCasSerDes6.deserializeAfterVersion(BinaryCasSerDes6.java:1892)
at
org.apache.uima.cas.impl.BinaryCasSerDes.reinit(BinaryCasSerDes.java:595)
at org.apache.uima.util.CasIOUtils.load(CasIOUtils.java:382)
at org.apache.uima.util.CasIOUtils.load(CasIOUtils.java:313)
at org.apache.uima.util.CasIOUtils.load(CasIOUtils.java:237)
...
{noformat}
I have set up a similar test using only the plain CAS API which seems to work
fine:
{noformat}
@Test
public void test6LenientPlainUima2() throws Exception
{
TypeSystemDescription tsd = new TypeSystemDescription_impl();
TypeDescription td = tsd.addType("DocumentMetaData", "",
CAS.TYPE_NAME_DOCUMENT_ANNOTATION);
td.addFeature("feat", "", CAS.TYPE_NAME_STRING);
CAS source = CasCreationUtils.createCas(tsd, null, null, null);
CAS target = CasCreationUtils.createCas(tsd, null, null, null);
AnnotationFS dmd = source
.createAnnotation(source.getTypeSystem().getType("DocumentMetaData"), 0, 0);
source.addFsToIndexes(dmd);
assertEquals("DocumentMetaData",
source.getDocumentAnnotation().getType().getName());
@SuppressWarnings("resource")
ByteArrayOutputStream bos = new ByteArrayOutputStream();
CasIOUtils.save(source, bos, COMPRESSED_FILTERED);
bos.close();
CasIOUtils.load(new ByteArrayInputStream(bos.toByteArray()), target);
}
{noformat}
was (Author: rec):
Possibly related to this issue is another observation. When deserializing some
binary CAS formats, there is a NPE in certain cases. Here is an example that
might serve for reproduction:
{noformat}
@Test
public void test6LenientPlainUima() throws Exception
{
CAS source = JCasFactory.createJCas().getCas();
CAS target = JCasFactory.createJCas().getCas();
new DocumentMetaData(source.getJCas(), 0, 0).addToIndexes();
@SuppressWarnings("resource")
ByteArrayOutputStream bos = new ByteArrayOutputStream();
CasIOUtils.save(source, bos, COMPRESSED_FILTERED);
bos.close();
CasIOUtils.load(new ByteArrayInputStream(bos.toByteArray()), target);
}
{noformat}
The NPE only seems to be thrown when the `DocumentMetaData` is added via JCas.
I have set up a similar test using only the plain CAS API which seems to work
fine:
{noformat}
@Test
public void test6LenientPlainUima2() throws Exception
{
TypeSystemDescription tsd = new TypeSystemDescription_impl();
TypeDescription td = tsd.addType("DocumentMetaData", "",
CAS.TYPE_NAME_DOCUMENT_ANNOTATION);
td.addFeature("feat", "", CAS.TYPE_NAME_STRING);
CAS source = CasCreationUtils.createCas(tsd, null, null, null);
CAS target = CasCreationUtils.createCas(tsd, null, null, null);
AnnotationFS dmd = source
.createAnnotation(source.getTypeSystem().getType("DocumentMetaData"), 0, 0);
source.addFsToIndexes(dmd);
assertEquals("DocumentMetaData",
source.getDocumentAnnotation().getType().getName());
@SuppressWarnings("resource")
ByteArrayOutputStream bos = new ByteArrayOutputStream();
CasIOUtils.save(source, bos, COMPRESSED_FILTERED);
bos.close();
CasIOUtils.load(new ByteArrayInputStream(bos.toByteArray()), target);
}
{noformat}
> uv3: DocumentAnnotation subclasses not handled as in UIMAv2 during
> deserialization
> --
>
> Key: UIMA-5586
> URL: https://issues.apache.org/jira/browse/UIMA-5586
>
[jira] [Commented] (UIMA-5586) uv3: DocumentAnnotation subclasses not handled as in UIMAv2 during deserialization
[
https://issues.apache.org/jira/browse/UIMA-5586?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16176191#comment-16176191
]
Richard Eckart de Castilho commented on UIMA-5586:
--
Possibly related to this issue is another observation. When deserializing some
binary CAS formats, there is a NPE in certain cases. Here is an example that
might serve for reproduction:
{noformat}
@Test
public void test6LenientPlainUima() throws Exception
{
CAS source = JCasFactory.createJCas().getCas();
CAS target = JCasFactory.createJCas().getCas();
new DocumentMetaData(source.getJCas(), 0, 0).addToIndexes();
@SuppressWarnings("resource")
ByteArrayOutputStream bos = new ByteArrayOutputStream();
CasIOUtils.save(source, bos, COMPRESSED_FILTERED);
bos.close();
CasIOUtils.load(new ByteArrayInputStream(bos.toByteArray()), target);
}
{noformat}
The NPE only seems to be thrown when the `DocumentMetaData` is added via JCas.
I have set up a similar test using only the plain CAS API which seems to work
fine:
{noformat}
@Test
public void test6LenientPlainUima2() throws Exception
{
TypeSystemDescription tsd = new TypeSystemDescription_impl();
TypeDescription td = tsd.addType("DocumentMetaData", "",
CAS.TYPE_NAME_DOCUMENT_ANNOTATION);
td.addFeature("feat", "", CAS.TYPE_NAME_STRING);
CAS source = CasCreationUtils.createCas(tsd, null, null, null);
CAS target = CasCreationUtils.createCas(tsd, null, null, null);
AnnotationFS dmd = source
.createAnnotation(source.getTypeSystem().getType("DocumentMetaData"), 0, 0);
source.addFsToIndexes(dmd);
assertEquals("DocumentMetaData",
source.getDocumentAnnotation().getType().getName());
@SuppressWarnings("resource")
ByteArrayOutputStream bos = new ByteArrayOutputStream();
CasIOUtils.save(source, bos, COMPRESSED_FILTERED);
bos.close();
CasIOUtils.load(new ByteArrayInputStream(bos.toByteArray()), target);
}
{noformat}
> uv3: DocumentAnnotation subclasses not handled as in UIMAv2 during
> deserialization
> --
>
> Key: UIMA-5586
> URL: https://issues.apache.org/jira/browse/UIMA-5586
> Project: UIMA
> Issue Type: Bug
> Components: Core Java Framework
>Affects Versions: 3.0.0SDK-beta
>Reporter: Richard Eckart de Castilho
>
> Consider the case that you have custom subclass of the uima
> `DocumentAnnotation`, let's call it `DocumentMetaData`. Next, we have an XMI
> file which contains an annotation of the `DocumentMetaData` type.
> When loading such an XMI file in UIMAv2, the CAS ends up with a single
> `DocumentMetaData` annotation which is accessible via
> `cas.getDocumentAnnotation()`.
> When loading the same file with UIMAv3, the CAS ends up with both, a
> `DocumentAnnotation` and a `DocumentMetaData` annotation and
> `cas.getDocumentAnnotation()` returns the former.
> The same appears to happen when deserializing a CAS from various binary
> formats.
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
[jira] [Updated] (UIMA-5586) uv3: DocumentAnnotation subclasses not handled as in UIMAv2 during deserialization
[ https://issues.apache.org/jira/browse/UIMA-5586?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Richard Eckart de Castilho updated UIMA-5586: - Description: Consider the case that you have custom subclass of the uima `DocumentAnnotation`, let's call it `DocumentMetaData`. Next, we have an XMI file which contains an annotation of the `DocumentMetaData` type. When loading such an XMI file in UIMAv2, the CAS ends up with a single `DocumentMetaData` annotation which is accessible via `cas.getDocumentAnnotation()`. When loading the same file with UIMAv3, the CAS ends up with both, a `DocumentAnnotation` and a `DocumentMetaData` annotation and `cas.getDocumentAnnotation()` returns the former. The same appears to happen when deserializing a CAS from various binary formats. was: Consider the case that you have custom subclass of the uima `DocumentAnnotation`, let's call it `DocumentMetaData`. Next, we have an XMI file which contains an annotation of the `DocumentMetaData` type. When loading such an XMI file in UIMAv2, the CAS ends up with a single `DocumentMetaData` annotation which is accessible via `cas.getDocumentAnnotation()`. When loading the same file with UIMAv3, the CAS ends up with both, a `DocumentAnnotation` and a `DocumentMetaData` annotation and `cas.getDocumentAnnotation()` returns the former. > uv3: DocumentAnnotation subclasses not handled as in UIMAv2 during > deserialization > -- > > Key: UIMA-5586 > URL: https://issues.apache.org/jira/browse/UIMA-5586 > Project: UIMA > Issue Type: Bug > Components: Core Java Framework >Affects Versions: 3.0.0SDK-beta >Reporter: Richard Eckart de Castilho > > Consider the case that you have custom subclass of the uima > `DocumentAnnotation`, let's call it `DocumentMetaData`. Next, we have an XMI > file which contains an annotation of the `DocumentMetaData` type. > When loading such an XMI file in UIMAv2, the CAS ends up with a single > `DocumentMetaData` annotation which is accessible via > `cas.getDocumentAnnotation()`. > When loading the same file with UIMAv3, the CAS ends up with both, a > `DocumentAnnotation` and a `DocumentMetaData` annotation and > `cas.getDocumentAnnotation()` returns the former. > The same appears to happen when deserializing a CAS from various binary > formats. -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Updated] (UIMA-5586) uv3: DocumentAnnotation subclasses not handled as in UIMAv2 during deserialization
[ https://issues.apache.org/jira/browse/UIMA-5586?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Richard Eckart de Castilho updated UIMA-5586: - Summary: uv3: DocumentAnnotation subclasses not handled as in UIMAv2 during deserialization (was: uv3: XmiCasDeserializer does not handle DocumentAnnotation subclasses as before) > uv3: DocumentAnnotation subclasses not handled as in UIMAv2 during > deserialization > -- > > Key: UIMA-5586 > URL: https://issues.apache.org/jira/browse/UIMA-5586 > Project: UIMA > Issue Type: Bug > Components: Core Java Framework >Affects Versions: 3.0.0SDK-beta >Reporter: Richard Eckart de Castilho > > Consider the case that you have custom subclass of the uima > `DocumentAnnotation`, let's call it `DocumentMetaData`. Next, we have an XMI > file which contains an annotation of the `DocumentMetaData` type. > When loading such an XMI file in UIMAv2, the CAS ends up with a single > `DocumentMetaData` annotation which is accessible via > `cas.getDocumentAnnotation()`. > When loading the same file with UIMAv3, the CAS ends up with both, a > `DocumentAnnotation` and a `DocumentMetaData` annotation and > `cas.getDocumentAnnotation()` returns the former. -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Created] (UIMA-5586) uv3: XmiCasDeserializer does not handle DocumentAnnotation subclasses as before
Richard Eckart de Castilho created UIMA-5586: Summary: uv3: XmiCasDeserializer does not handle DocumentAnnotation subclasses as before Key: UIMA-5586 URL: https://issues.apache.org/jira/browse/UIMA-5586 Project: UIMA Issue Type: Bug Components: Core Java Framework Affects Versions: 3.0.0SDK-beta Reporter: Richard Eckart de Castilho Consider the case that you have custom subclass of the uima `DocumentAnnotation`, let's call it `DocumentMetaData`. Next, we have an XMI file which contains an annotation of the `DocumentMetaData` type. When loading such an XMI file in UIMAv2, the CAS ends up with a single `DocumentMetaData` annotation which is accessible via `cas.getDocumentAnnotation()`. When loading the same file with UIMAv3, the CAS ends up with both, a `DocumentAnnotation` and a `DocumentMetaData` annotation and `cas.getDocumentAnnotation()` returns the former. -- This message was sent by Atlassian JIRA (v6.4.14#64029)
Re: redesigining our Eclipse plugin release build flow - list of issues to find out about
Kudos to you for approaching this. I'll try to help where I can, but I am very committed to other things right now :-( (Maybe in two weeks, I'll have more time) Best, Peter Am 20.09.2017 um 17:34 schrieb Marshall Schor: > I'm starting to think about redoing our Eclipse Plugin release flow. I'm > hoping > to start a thread where people can post answers to issues (there are many...). > > Motivation: start using the Symantec signing process for Jars (in addition to > the PGP Apache signing process), so that Eclipse, when installing new plugins > doesn't warn about unsigned artifacts. > > There are many things to figure out. One is how to manage the cost of the > signing. Signing costs real money, which Apache covers (see > https://reference.apache.org/pmc/codesigning). > > 1) To find out: is the cost per Jar, or per "signing event" which can include > multiple Jars? This can affect some design choices. > > 2) Another thing is when (in our release flow) to sign. The signing process > alters the JARs. > > Our current flow is 1) generate candidate with PGP signature, 2) Vote 3) > repeat if failed rc, otherwise promote. An Apache principle is to have the > Vote > be on the signed artifacts, which are then promoted without modification. > This > implies the step 1) would need to include signing. > > This means that every failed release candidate costs money. I found out that > some projects "accept" this, but have low failed percentages, like 1 in 10. > In > our process, we seem to frequently have multiple release candidates per > release. > > Perhaps a way forward is to have a process for the Eclipse plugin release > which > is different, and isn't invoked until a "preliminary" candidate review has > been > done; once this has happened, and there's confidence that the signed version > would likely pass the vote, an official Eclipse plugin release candidate could > be posted with signed JARs. > > 3) Another thing to figure out, assuming that signing costs "per jar", is to > insure only new Jars are signed, not the older versions. This could affect > efforts to limit the number of JARs (or not). > > 4) Another thing to figure out is what needs to be signed. I think that only > Eclipse plugin jars need signing, and not the other jars associated with the > update site, like artifacts.jar, content.jar, and for each feature, > feat-name.jar (e.g. org.apache.uima.runtime_3.0.0.alpha02.jar). But maybe > that's wrong. The site > https://wiki.eclipse.org/JAR_Signing#What_gets_signed.3F > says multiple things: 1) "by default, every Jar pushed to an update site is > signed", 2) "in standalone zip distributions, all JARed plugins will be > signed". So, my guess is that you don't need to sign the other kinds of > JARs. > > Some websites imply that JARs other than the plugin ones are signed ( > https://wiki.eclipse.org/Platform-releng-signedbuild ), but it's unclear if > they > need signing in order to get the Eclipse install program not to complain. > That > website says the master zip having all the plugins and features is sent to the > signing process. > > 5) Some of our Jars (typically, the runtime Jars) have other Jars inside > them. > This site https://wiki.eclipse.org/JAR_Signing#What_gets_signed.3F says "JARs > nested at arbitrary depth within other JARs" are signed, too. Is that needed > to > make the Eclipse install program not complain about installing unsigned > artifacts? > > 6) One site ( https://wiki.eclipse.org/JAR_Signing#What_gets_signed.3F ) says > there may be legal reasons you are not permitted to sign an embedded JAR. > I've > never seen anything about that, and don't know how to determine if such a > prohibition exists. This page says, under what gets signed, "Some JARs may be > excluded if there are technical or legal reasons why they cannot be signed". > > 7) Signing and pack200 interact. This page > https://wiki.eclipse.org/Tycho/Pack200#Pack200_and_Signing describes a flow: > 1. pack200 operated to "normalize" - this is specified by the "repack" option > 2. sign > 3. pack200 operated to generate the compressed version > 4. p2 metadata generation / updating > > Our current eclipse plugin build flow runs pack200 with both the "-repack" and > "-pack" options. I think this would need to be split into two steps (assuming > we keep pack200 - see following), with the results from -repack being sent for > signing, and then the result subsequently packed. > > 8) I question if we need to do pack200 packing. It has these effects: > 1. for every Jar, it generates 2 Jars: the original and the packed. So there > are 2 jars that need "signing", thus it costs twice as much. > 2. A typical Jar (caseditor.ide) is 69K bytes, packed 28K. A big jar > uima-runtime is 4M, packed: 1.3M > So the result is increased space on the distribution medium, but decreased > bandwidth for downloading. But the download frequency is very low - only when > someone installs the UIMA
[jira] [Resolved] (UIMA-5585) Ruta: allow ResourceManager extension classloader for loading ruta extensions
[ https://issues.apache.org/jira/browse/UIMA-5585?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Peter Klügl resolved UIMA-5585. --- Resolution: Fixed fixed > Ruta: allow ResourceManager extension classloader for loading ruta extensions > - > > Key: UIMA-5585 > URL: https://issues.apache.org/jira/browse/UIMA-5585 > Project: UIMA > Issue Type: Bug > Components: Ruta >Affects Versions: 2.6.1ruta >Reporter: Peter Klügl >Assignee: Peter Klügl > Fix For: 2.6.2ruta > > > Ruta: allow ResourceManager extension classloader for loading ruta extensions -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Created] (UIMA-5585) Ruta: allow ResourceManager extension classloader for loading ruta extensions
Peter Klügl created UIMA-5585: - Summary: Ruta: allow ResourceManager extension classloader for loading ruta extensions Key: UIMA-5585 URL: https://issues.apache.org/jira/browse/UIMA-5585 Project: UIMA Issue Type: Bug Components: Ruta Affects Versions: 2.6.1ruta Reporter: Peter Klügl Assignee: Peter Klügl Fix For: 2.6.2ruta Ruta: allow ResourceManager extension classloader for loading ruta extensions -- This message was sent by Atlassian JIRA (v6.4.14#64029)
