Are there Eclipse configuration options necessary to meet any of these
winners?
One step ahead of you. See our podling web site. :)
-Adam
> And the winners are...
>
> Braces: {
> Looks like I'm outvoted on this one.
> }
>
> Indentation: 2 spaces. No tabs!
>
> Member Variables: before methods
>
> Line Length: 100 (Preferred indent after wrapping: 8 spces)
>
> Imports: do not use package imports (e.g. import org.uima.*). order
>
Please review.
Now if only our code conformed to our conventions. :)
Also, I liked Thilo's idea of saying something about compiler warning
settings and/or FindBugs rules. I'll let Thilo drive the proposal on
that if he wants to.
-Adam
Reformat all source code to match adopted conventions
-
Key: UIMA-48
URL: http://issues.apache.org/jira/browse/UIMA-48
Project: UIMA
Issue Type: Task
Reporter: Adam Lally
We s
[ http://issues.apache.org/jira/browse/UIMA-47?page=all ]
Adam Lally resolved UIMA-47.
Resolution: Fixed
Website changes committed and extracted to people.apache.org.
> Post code style guidelines on website
> -
>
>
[ http://issues.apache.org/jira/browse/UIMA-20?page=all ]
Lev Kozakov updated UIMA-20:
Attachment: uima.example.DateTime.pear
uima.example.RoomNumber.pear
Both PEARs were recompiled with 1.4 compliance level
> PearMerger unit test failure
>
Post code style guidelines on website
-
Key: UIMA-47
URL: http://issues.apache.org/jira/browse/UIMA-47
Project: UIMA
Issue Type: Task
Components: Website
Reporter: Adam Lally
And the winners are...
Braces: {
Looks like I'm outvoted on this one.
}
Indentation: 2 spaces. No tabs!
Member Variables: before methods
Line Length: 100 (Preferred indent after wrapping: 8 spces)
Imports: do not use package imports (e.g. import org.uima.*). order
imports alphabetically
I have no preferences for one of the two possibilities, but it sound
good to me what Thilo wrote below about the permissions.
-- Michael
Thilo Goetz wrote:
I'm lukewarm on wikis in general, but I do like the idea a little
better of having one with the possibility of granting permissions for
c
[EMAIL PROTECTED] wrote:
Braces: Each brace on a line by itself - Lally
Braces: Opening brace not on a separate line, closing one on separate
line - Schor
Braces: Opening brace not on a separate line, closing one on
separate line - Thilo (no strong feelings though)
Braces: {
[ http://issues.apache.org/jira/browse/UIMA-46?page=all ]
Adam Lally closed UIMA-46.
--
Resolution: Fixed
Fixed by changing CasCreationUtils to always add features to supertypes before
adding features to subtypes.
> Duplicate feature name on supertype and subty
On 11/17/06, Thilo Goetz <[EMAIL PROTECTED]> wrote:
Is this something you would like to see fixed in the TypeSystemMgr, or
in the code that calls the TypeSystemMgr? I believe I can probably fix
it in the TypeSystemMgr without too much work.
I already committed the fix for it in the code that
Is this something you would like to see fixed in the TypeSystemMgr, or
in the code that calls the TypeSystemMgr? I believe I can probably fix
it in the TypeSystemMgr without too much work.
--Thilo
Adam Lally (JIRA) wrote:
Duplicate feature name on supertype and subtype does not work if subty
Duplicate feature name on supertype and subtype does not work if subtype
definition comes first in descriptor
-
Key: UIMA-46
URL: http://issues.apache.org/
>> Braces: Each brace on a line by itself - Lally
>> Braces: Opening brace not on a separate line, closing one on separate
>> line - Schor
>Braces: Opening brace not on a separate line, closing one on
> separate line - Thilo (no strong feelings though)
Braces: {
same as schor & thilo (edd
I'm lukewarm on wikis in general, but I do like the idea a little better
of having one with the possibility of granting permissions for certain
areas. So +1 for confluence.
--Thilo
Adam Lally wrote:
On 11/17/06, Marshall Schor <[EMAIL PROTECTED]> wrote:
There are 2 wikis that can be used for
On 11/17/06, Marshall Schor <[EMAIL PROTECTED]> wrote:
There are 2 wikis that can be used for projects: moin and confluence.
I think I slightly prefer the confluence - I like the potential it has
for collaborative authoring - I can see that being used for having the
community help improve the do
There are 2 wikis that can be used for projects: moin and confluence.
I think I slightly prefer the confluence - I like the potential it has
for collaborative authoring - I can see that being used for having the
community help improve the documentation.
If no one objects, I'll ask the apache
Don't get me wrong, I would love to have a simpler process. However,
while we're not sure where to draw the line, let's err on the side of
caution. I hope that an ICLA is not too much of an impediment for
people who want to contribute to UIMA. If we can figure out how to work
that JIRA optio
Re: Requiring ICLAs - there's a trade off here. If trivial things
require contributors to file ICLAs, then we might put off getting
contributions. There was some discussion on [EMAIL PROTECTED] also
about this - something about Jira processing having a checkbox to say
you have rights to contr
Marshall, do you recall why we put that code there? I only have a vague
recollection that something was broken without this weird condition.
In general, how are we going to proceed with the array stuff?
Can/should we drop support for the old array names and simply move to
the new scheme? Is
Sorry to shout... but I'd like to get some closure on this so it would
be good if all the committers gave their style preferences. Thanks!
-Adam
For anything that's non-trivial (i.e., more than two lines) or
non-obvious, even if less than two lines, we require an ICLA. The ICLA
should be on file before the patch gets submitted. Strictly speaking,
we need to ask people to resubmit their patches after their ICLA is on
file.
--Thilo
A
Review and clean up unit tests
--
Key: UIMA-45
URL: http://issues.apache.org/jira/browse/UIMA-45
Project: UIMA
Issue Type: Task
Components: Build, Packaging and Test
Reporter: Adam Lally
On 11/17/06, Michael Baessler <[EMAIL PROTECTED]> wrote:
so I would recommend that
we just rename the IBMResultPrinter class to ResultPrinter. I will take
care of that if all agree.
Fine with me.
While you're in there you might also want to take a look at what I did
to TestPropertyReader in
[ http://issues.apache.org/jira/browse/UIMA-41?page=all ]
Thilo Goetz resolved UIMA-41.
-
Resolution: Invalid
It's a non-issue, everything is implemented as it should.
> LowLevelCAS.ll_getTypeClass() needs to be updated for the new 2.0 types
> --
I apologize, maybe I should get glasses. Everything's there, I just
didn't see it.
Marshall Schor wrote:
Best not to ascribe blame for these, I think. This may have in fact
been my oversight :-)
-Marshall
Thilo Goetz wrote:
Adam Lally wrote:
I fixed a bug (reported on the forum) that the
[ http://issues.apache.org/jira/browse/UIMA-11?page=all ]
Thilo Goetz closed UIMA-11.
---
Resolution: Fixed
Replaced occurrences of org.apache.itu with org.apache.uima.uimacpp, and
occurrences of Taf with Uimacpp.
> org.apache.itu package should be renamed
> -
I'm also think it is better to have a JIRA issue for all changes.
-- Michael
Marshall Schor wrote:
I agree. -Marshall
Thilo Goetz wrote:
Adam Lally wrote:
On 11/15/06, Thilo Goetz <[EMAIL PROTECTED]> wrote:
I updated our website to fix a broken link without a Jira issue
(didn't
really thin
[
http://issues.apache.org/jira/browse/UIMA-44?page=comments#action_12450737 ]
Michael Baessler commented on UIMA-44:
--
ResultPrinter is already used by JUnit itself, so I used UIMAResultPrinter.
> rename IBMResultPrinter class
> ---
rename IBMResultPrinter class
-
Key: UIMA-44
URL: http://issues.apache.org/jira/browse/UIMA-44
Project: UIMA
Issue Type: Bug
Components: Tools
Reporter: Michael Baessler
Assigned To:
Adam Lally wrote:
I've replaced most occurrences of "IBM" now. Here's a list of what I
didn't fix:
6) uimaj-test-util contains class IBMResultPrinter developed by
Michael. Does this need to be here?
Currently I don't see that we need the uimaj-test-util project when
using Maven for our comm
32 matches
Mail list logo
