On Thu, Aug 12, 2010 at 02:25:33PM +0200, Jeremias Maerki wrote:
Hi,
I have returned and read the discussions. I have the following
remarks:
Building fop with jdk 1.4, as required, gives an error when
checkstyle-all-5.0.jar is present. The major.minor version 49.0 is not
supported. Thus removing
I wonder how we are going to organize the application and review of
the Complex Script Support work. Glenn has now submitted a patch and
we have created a branch for this work.
We can apply the patch and then make comments or request
changes. Glenn does further work and reacts to our comments and
On Fri, Aug 13, 2010 at 4:32 PM, Simon Pepping spepp...@leverkruid.euwrote:
Glenn notes that he used comments to suppress checkstyle warnings in
such cases as:
- certain uses of package, protected, or public visibility of fields,
which would have required a fairly large number of changes to
What I had in mind was as follows:
1. after the cleanup/warnings patch is applied to trunk, it should be
merged into the complex scripts branch (which still does not have the
complex scripts patch applied);
2. I merge the head of the updated complex scripts branch with my
existing
It has been suggested to me that I provide a few C.V. details to the group,
to help introduce my background that may be of some use in FOP work, so here
are a few details. If anyone would like a fuller bio, let me know and I will
happily send.
- began working with TeX78 in the late 70's;
-
Glenn,
On Fri, Aug 13, 2010 at 05:07:52PM +0800, Glenn Adams wrote:
In any case, we now appear to be at a juncture where one of the following
options may be implemented:
(1) leave the CS* comments in place, but DON'T change the checkstyle rules
AT THIS TIME (but reserve option to change
Hi,
What if the CS* comments are removed in trunk, so the committers are happy, but
accepted in the branch, so Glenn can work as he wants to? Not a perfect
solution, but maybe an acceptable compromise, as long as somebody removes the
comments prior to merging the branch back into trunk?
https://issues.apache.org/bugzilla/show_bug.cgi?id=49733
--- Comment #6 from Simon Pepping spepp...@apache.org 2010-08-13 09:00:50 EDT
---
Created an attachment (id=25884)
-- (https://issues.apache.org/bugzilla/attachment.cgi?id=25884)
Transcript of javadocs generation
I get 56 javadocs
https://issues.apache.org/bugzilla/show_bug.cgi?id=49733
--- Comment #7 from Simon Pepping spepp...@apache.org 2010-08-13 09:19:45 EDT
---
(In reply to comment #6)
Created an attachment (id=25884)
-- (https://issues.apache.org/bugzilla/attachment.cgi?id=25884) [details]
Transcript of javadocs
https://issues.apache.org/bugzilla/show_bug.cgi?id=49733
--- Comment #8 from Glenn Adams gl...@skynav.com 2010-08-13 09:45:45 EDT ---
(In reply to comment #6)
Created an attachment (id=25884)
-- (https://issues.apache.org/bugzilla/attachment.cgi?id=25884) [details]
Transcript of javadocs
I've mentioned the deprecated methods in my reply to Vincent. I'll
restore two instances which can be handled later. At least one is kind
of important as long as I haven't done a Barcode4J 2.1 release (which is
long overdue).
Do I understand you correctly, Simon, that you're OK to leave the CS
Thanks for the idea. But I'm not sure if that creates too much fuzz when
merging changes. What do the others think?
On 13.08.2010 14:47:42 Georg Datterl wrote:
Hi,
What if the CS* comments are removed in trunk, so the committers are
happy, but accepted in the branch, so Glenn can work as he
https://issues.apache.org/bugzilla/show_bug.cgi?id=49733
--- Comment #9 from Simon Pepping spepp...@apache.org 2010-08-13 11:05:18 EDT
---
(In reply to comment #7)
I get 56 javadocs warnings, whereas you get none. How come?
I will fix these warnings in the HEAD revision of trunk, unless you
I want to move forward with Glenn's work. As you wrote, it is an
important addition to FOP which we cannot let go unused.
I feel that the CHECKSTYLE comments are clear, and allow us to take
any action later that we require. They could be harmful if we would
feel that further work would have to be
Thanks for providing your view. So we have a similar view.
This gives me another shove in the butt to finally make the B4J 2.1
release. JEuclid should already be fine. I've seen that Max has already
switched to the other method. So, we can easily remove the deprecate
method before the next
Jeremias Maerki wrote:
Hi All,
I've mentioned the deprecated methods in my reply to Vincent. I'll
restore two instances which can be handled later. At least one is kind
of important as long as I haven't done a Barcode4J 2.1 release (which is
long overdue).
Do I understand you correctly,
16 matches
Mail list logo
