Re: JIRA access
+1 Cheers! Clay -- "My religion is simple. My religion is kindness." - HH The Dalai Lama of Tibet > On May 24, 2015, at 12:53 PM, Glenn Adams wrote: > > I would not have any problem with that if the group wishes to do so. > >> On Sun, May 24, 2015 at 1:37 PM, Clay Leeds wrote: >> Hi Glenn, >> >> Does it make sense to give all PMCs admin rights? IMHO committees could but >> we can draw the line somewhere. ;-) >> Cheers! >> >> Clay >> >> -- >> >> "My religion is simple. My religion is kindness." >> - HH The Dalai Lama of Tibet >> >>> On May 24, 2015, at 10:34 AM, Glenn Adams wrote: >>> >>> I've added Andreas to the Committer role on both FOP and XGC. Also, I've >>> added you (Luis) to the Administrator role on FOP and XGC. Someone besides >>> me should be able to administrate these projects. >>> On Sun, May 24, 2015 at 7:38 AM, Luis Bernardo wrote: You need to be added to one of the roles that is able to resolve issues before you can do that. For FOP and XGC only Glenn has admin rights. For BATIK both Glenn and I have. > On 5/24/15 12:47 PM, Andreas Delmelle wrote: > Hi > > Just wondering: > Should I be able to set JIRA issues to 'Resolved' or assign them to > myself, or does this require someone else (Glenn?) to provide me with the > appropriate permissions first? > > If the latter, can you take care of this? > > > Thanks! > > > KR > > Andreas >
Re: JIRA access
I would not have any problem with that if the group wishes to do so. On Sun, May 24, 2015 at 1:37 PM, Clay Leeds wrote: > Hi Glenn, > > Does it make sense to give all PMCs admin rights? IMHO committees could > but we can draw the line somewhere. ;-) > > Cheers! > > Clay > > -- > > "My religion is simple. My religion is kindness." > - HH The Dalai Lama of Tibet > > > On May 24, 2015, at 10:34 AM, Glenn Adams wrote: > > I've added Andreas to the Committer role on both FOP and XGC. Also, I've > added you (Luis) to the Administrator role on FOP and XGC. Someone besides > me should be able to administrate these projects. > > On Sun, May 24, 2015 at 7:38 AM, Luis Bernardo > wrote: > >> >> You need to be added to one of the roles that is able to resolve issues >> before you can do that. >> >> For FOP and XGC only Glenn has admin rights. For BATIK both Glenn and I >> have. >> >> >> On 5/24/15 12:47 PM, Andreas Delmelle wrote: >> >>> Hi >>> >>> Just wondering: >>> Should I be able to set JIRA issues to 'Resolved' or assign them to >>> myself, or does this require someone else (Glenn?) to provide me with the >>> appropriate permissions first? >>> >>> If the latter, can you take care of this? >>> >>> >>> Thanks! >>> >>> >>> KR >>> >>> Andreas >>> >> >> >
Re: JIRA access
Hi Glenn, Does it make sense to give all PMCs admin rights? IMHO committees could but we can draw the line somewhere. ;-) Cheers! Clay -- "My religion is simple. My religion is kindness." - HH The Dalai Lama of Tibet > On May 24, 2015, at 10:34 AM, Glenn Adams wrote: > > I've added Andreas to the Committer role on both FOP and XGC. Also, I've > added you (Luis) to the Administrator role on FOP and XGC. Someone besides me > should be able to administrate these projects. > >> On Sun, May 24, 2015 at 7:38 AM, Luis Bernardo >> wrote: >> >> You need to be added to one of the roles that is able to resolve issues >> before you can do that. >> >> For FOP and XGC only Glenn has admin rights. For BATIK both Glenn and I have. >> >> >>> On 5/24/15 12:47 PM, Andreas Delmelle wrote: >>> Hi >>> >>> Just wondering: >>> Should I be able to set JIRA issues to 'Resolved' or assign them to myself, >>> or does this require someone else (Glenn?) to provide me with the >>> appropriate permissions first? >>> >>> If the latter, can you take care of this? >>> >>> >>> Thanks! >>> >>> >>> KR >>> >>> Andreas >> >
Re: JIRA access
I've added Andreas to the Committer role on both FOP and XGC. Also, I've added you (Luis) to the Administrator role on FOP and XGC. Someone besides me should be able to administrate these projects. On Sun, May 24, 2015 at 7:38 AM, Luis Bernardo wrote: > > You need to be added to one of the roles that is able to resolve issues > before you can do that. > > For FOP and XGC only Glenn has admin rights. For BATIK both Glenn and I > have. > > > On 5/24/15 12:47 PM, Andreas Delmelle wrote: > >> Hi >> >> Just wondering: >> Should I be able to set JIRA issues to 'Resolved' or assign them to >> myself, or does this require someone else (Glenn?) to provide me with the >> appropriate permissions first? >> >> If the latter, can you take care of this? >> >> >> Thanks! >> >> >> KR >> >> Andreas >> > >
Re: JIRA access
> On 24 May 2015, at 15:38, Luis Bernardo wrote: > > > You need to be added to one of the roles that is able to resolve issues > before you can do that. > > For FOP and XGC only Glenn has admin rights. For BATIK both Glenn and I have. OK, thanks for the info. We'll wait for Glenn to wake up, then. KR Andreas
Re: JIRA access
You need to be added to one of the roles that is able to resolve issues before you can do that. For FOP and XGC only Glenn has admin rights. For BATIK both Glenn and I have. On 5/24/15 12:47 PM, Andreas Delmelle wrote: Hi Just wondering: Should I be able to set JIRA issues to 'Resolved' or assign them to myself, or does this require someone else (Glenn?) to provide me with the appropriate permissions first? If the latter, can you take care of this? Thanks! KR Andreas
JIRA access
Hi Just wondering: Should I be able to set JIRA issues to 'Resolved' or assign them to myself, or does this require someone else (Glenn?) to provide me with the appropriate permissions first? If the latter, can you take care of this? Thanks! KR Andreas
[jira] [Commented] (FOP-2472) Allow to clear the hyphenation tree cache at runtime
[
https://issues.apache.org/jira/browse/FOP-2472?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14557712#comment-14557712
]
Andreas L. Delmelle commented on FOP-2472:
--
Change as suggested committed to trunk. See: http://svn.apache.org/r1681436
Thanks, Marc!
> Allow to clear the hyphenation tree cache at runtime
>
>
> Key: FOP-2472
> URL: https://issues.apache.org/jira/browse/FOP-2472
> Project: FOP
> Issue Type: Improvement
>Affects Versions: 1.1
>Reporter: Marc Wiest
>Priority: Minor
> Labels: cache, hyphenation
> Original Estimate: 0.5h
> Remaining Estimate: 0.5h
>
> I suggest adding the following method (or similar) to the
> org.apache.fop.hyphenation.Hyphenator class.
> I had to hack FOP and create a custom build for myself, because I need to
> alter and reload the hyphenation files at runtime.
> The use case is, that I have a web application that allows editors - on an
> admin page - to add hyphenation exceptions on-the-fly. In that case the
> hyphenation pattern files are re-created including the new exceptions, but
> need to be reloaded by FOP. The below worked for me, please consider adding
> to the trunk.
> {code:title=Hyphenator.java|borderStyle=solid}
> /**
> * Clear the hyphenation tree cache, in case the underlying data files have
> changed at runtime.
> */
> public static synchronized void clearHyphenationTreeCache()
> {
> hTreeCache = new HyphenationTreeCache();
> }
> {code}
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
Re: Fix FB warnings (was: Re: [VOTE] Release XML Graphics FOP 2.0)
> On 23 May 2015, at 23:15, Andreas Delmelle
> wrote:
> FYI - High and medium priority warnings addressed in r1681384, and absent an
> answer to my question, assumed the lazy approach there, for now.
>
> Will try to have a look at the low priority ones tomorrow.
... and low priority warnings now addressed in r1681435.
Going through those, the number of implicit assertions made at various places
in the codebase is quite amazing.
In some cases, making those explicit looks a bit silly, but it actually makes
perfect sense.
Example from the o.a.f.render.afp package:
---
/** {@inheritDoc} */
@Override
protected AFPDataObjectInfo createDataObjectInfo() {
return new AFPGraphicsObjectInfo();
}
/** {@inheritDoc} */
public void handleImage(RenderingContext context, Image image, Rectangle pos)
throws IOException {
AFPRenderingContext afpContext = (AFPRenderingContext)context;
AFPDataObjectInfo info = createDataObjectInfo();
assert (info instanceof AFPGraphicsObjectInfo);
AFPGraphicsObjectInfo graphicsObjectInfo = (AFPGraphicsObjectInfo) info;
---
For us, humans, it looks evident that casting the object returned by
createDataObjectInfo() to an AFPGraphicsObjectInfo is legitimate.
However, strictly speaking, one cannot exclude the possibility that someone
creates a subclass and overrides createDataObjectInfo(), but not
handleImage(), in which case the code would fail at runtime with an ugly
ClassCastException...
Perhaps it is also possible and cleaner to force the return type to an
AFPGraphicsObjectInfo, which is a subclass of AFPDataObjectInfo. I may look
into that later. At least now, the assertion is clearly visible in the code.
KR
Andreas
