RE: Common code in CVS branches
Peter B. West wrote: Branches generally don't occur with subset of files. The usual procedure is to tag a working set of files, then checkout the tag. If there are files you don't want in the new working set, delete and 'cvs remove' them. Until you 'cvs remove', the comments I made above would apply, I think. That's the way I would envisage a new subset branch being created. But see Jeremias' comments on the difficulties of educating committers. I'll take your word for how it is used in real life, and this perhaps explains how we got to the status quo. I just wonder why? It seems like tagging only the subset of files that need to be different is a much more elegant way to handle the problem. It 1) greatly simplifies the commit process (it really eliminates the educating committers problem that Jeremias mentioned), 2) defers branching individual files until they must be branched, 3) provides a moderately easy way of knowing which files are actually different. It requires only that when a file needs to be added to the branch that someone run a cvs tag command on that file, and that if you are working on the branch you use cvs checkout -f to make sure you get the trunk version of the common files. If you fail to do the latter, the compiler will no doubt remind you. Although I'm pretty green with CVS, I have used RCS pretty heavily, and have used the above concept successfully with it. We used scripts to accomplish the same sort of things that CVS handles so nicely, but the concepts are pretty much the same. Since the success of maintaining any re-merged work depends on this concept, I'll do some testing on that first to make sure that I'm not missing anything. BTW, it is this viewpoint that makes me think that we have the branches reversed. If the working / maintenance code is the core code that you start with, then the new design code is the stuff that is branching off. Go back to the point in time immediately before the first file was changed in the redesign work. You modify file foo.java and want to commit it to the repository as the first piece of the redesign. You have decided that the redesign will live in the trunk and that the old code will be pushed onto a branch (exactly as we have done). The only way that you can accomplish this is to force a checkin of the code that **did not** change onto the branch. Other have pointed out that it really doesn't matter where the branches are, and in a strict sense they are correct (and we can use the admin -b to change the default branch if we want to). However, it seems extremely awkward and counter-intuitive to create a branch on code that didn't change. I don't feel strongly about the position of the two branches. However, there seems to be general agreement that this is a complex project. Since complexities tend to be exponential in nature, every one of them that can be eliminated tends to have a large benefit. Victor Mote - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, email: [EMAIL PROTECTED]
RE: Common code in CVS branches
Jeremias Maerki wrote: 1.0 as soon as possible. I'm grateful for Victor's work and I hope it won't be a distraction. Because distractions may leave the focus of potential co-developers on the maintenance branch even though the redesign is already quite advanced. I'm aware that this is a concern. However, consider the following: 1. The layout redesign is not the only work that is needed before a 1.0 release. If people can work on the other features in parallel with those who are working on redesign, then we get to 1.0 faster. 2. As I understand it, there is maintenance code work that needs to be merged into the trunk anyway. This should accomplish that, again in parallel with the redesign. We don't want to have features in 0.20.4 that aren't in 1.0. 3. If we can get the code that should be common merged, then anyone who works on common code for the benefit of the maintenance branch must make sure that they haven't broken anything in the redesign along the way. This *might* expose them more to the redesign work. 4. If the old layout is as dead-end as I have been told (and I have no reason to doubt it), then *no one* will want to spend any time on the code that is specific to the maintenance branch only. People working on layout will do so in the redesign code, people working on anything else will do so in the common code. We can still quibble about whether people should be working on this or that, but at least everyone will be working on 1.0. That is the theory anyway. Victor Mote - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, email: [EMAIL PROTECTED]
Re: Common code in CVS branches
Hi All, Not sure where to start with all this... On Mon, 2002-11-04 at 08:34, Jeremias Maerki wrote: Yes, for peripheral components (PDF lib, fonts etc.). That is one of the main problems with the old code, these components are all linked together in bad ways, making it hard to improve and deal with improvements to any particular part. So work on the old code really means using the new code if these are to be considered separate components. I fully agree with you. That's why I mentioned my employer who actually understands the reasons for the redesign and looks forwards to FOP 1.0, but thinks that there are certain issues that have to be dealt with right now. That's why I'm going to look at multithreading issues in the maintenance branch this week. If we had enough resources (like in Jakarta Tomcat, XML Xerces and XML Xalan, where they maintain/maintained two or more dev tracks at once) I wouldn't mind a two-track-approach. But in our situation I tend to force the redesign so we can deliver FOP 1.0 as soon as possible. I'm grateful for Victor's work and I hope it won't be a distraction. Because distractions may leave the focus of potential co-developers on the maintenance branch even though the redesign is already quite advanced. I'm wondering how advanced it really needs to be before anyone wants to work on it. It is almost suitable to be used with the docs that forrest creates. I understand your particular situation and the required things for production. Keiron. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, email: [EMAIL PROTECTED]
RE: Common code in CVS branches
On Mon, 2002-11-04 at 09:35, Victor Mote wrote: I'll take your word for how it is used in real life, and this perhaps explains how we got to the status quo. I just wonder why? It seems like tagging only the subset of files that need to be different is a much more elegant way to handle the problem. It 1) greatly simplifies the commit process (it really eliminates the educating committers problem that Jeremias mentioned), 2) defers branching individual files until they must be branched, 3) provides a moderately easy way of knowing which files are actually different. It requires only that when a file needs to be added to the branch that someone run a cvs tag command on that file, and that if you are working on the branch you use cvs checkout -f to make sure you get the trunk version of the common files. If you fail to do the latter, the compiler will no doubt remind you. The selection of the branch really was simple: - the old code had a number of problems - we were getting nowhere trying to improve on that code due to the poor design creep - the code was branched only for bug fix updates with the intention of abandoning it - branch for old code simply as reference and for bug fixing - new code on trunk as the main development focus - work on new code to address design problems Redesign, rewrite call it what you want. The design of some fundamental parts is different (area tree, renderers, xml handling, image handling, layout), a number of things where rewritten to accomodate the different design approach. I really don't think that you can say, even with the benefit of hindsight, that working from the original code would have got us towards a better design in the same time. Quite simply the code was a mess. BTW, it is this viewpoint that makes me think that we have the branches reversed. If the working / maintenance code is the core code that you start with, then the new design code is the stuff that is branching off. Go back to the point in time immediately before the first file was changed in the redesign work. You modify file foo.java and want to commit it to the repository as the first piece of the redesign. You have decided that the redesign will live in the trunk and that the old code will be pushed onto a branch (exactly as we have done). The only way that you can accomplish this is to force a checkin of the code that **did not** change onto the branch. Other have pointed out that it really doesn't matter where the branches are, and in a strict sense they are correct (and we can use the admin -b to change the default branch if we want to). However, it seems extremely awkward and counter-intuitive to create a branch on code that didn't change. I don't feel strongly about the position of the two branches. However, there seems to be general agreement that this is a complex project. Since complexities tend to be exponential in nature, every one of them that can be eliminated tends to have a large benefit. As I have said a number of times and will continue to say. The old code was linked all over the place making it unecessarily complex, a suitable design was not forming and there was essentially no hope of implementing certain important features. We needed to start from scratch in some areas and attack it from a different perspective. There didn't seem to be a need to waste a lot of time bringing across the old code in gradual steps. Even now it seems like it would take far longer to bring across in small steps than it would to simply focus on what we have now. Should we then focus on a simpler cleaner design to get rid of these exponential complexities. How good does it need to be working before you will consider it suitable to work on. Keiron - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, email: [EMAIL PROTECTED]
RE: Common code in CVS branches
On Mon, 2002-11-04 at 09:57, Victor Mote wrote: Jeremias Maerki wrote: 1.0 as soon as possible. I'm grateful for Victor's work and I hope it won't be a distraction. Because distractions may leave the focus of potential co-developers on the maintenance branch even though the redesign is already quite advanced. I'm aware that this is a concern. However, consider the following: 1. The layout redesign is not the only work that is needed before a 1.0 release. If people can work on the other features in parallel with those who are working on redesign, then we get to 1.0 faster. Wouldn't that work better under the same design prinicples and support code. The branch does not have this. 2. As I understand it, there is maintenance code work that needs to be merged into the trunk anyway. This should accomplish that, again in parallel with the redesign. We don't want to have features in 0.20.4 that aren't in 1.0. Only about 1 or 2 minor things that I know, is there a list of them anywhere. We are working on a 1.0 final, in the meantime we could do a developers release that has less. 3. If we can get the code that should be common merged, then anyone who works on common code for the benefit of the maintenance branch must make sure that they haven't broken anything in the redesign along the way. This *might* expose them more to the redesign work. 4. If the old layout is as dead-end as I have been told (and I have no reason to doubt it), then *no one* will want to spend any time on the code that is specific to the maintenance branch only. People working on layout will do so in the redesign code, people working on anything else will do so in the common code. We can still quibble about whether people should be working on this or that, but at least everyone will be working on 1.0. It comes down to resources, who will do all this. That is the theory anyway. Victor Mote - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, email: [EMAIL PROTECTED]
Re: Common code in CVS branches
On 04 Nov 2002 10:05:06 +0100 Keiron Liddle wrote: Hi All, Not sure where to start with all this... On Mon, 2002-11-04 at 08:34, Jeremias Maerki wrote: Yes, for peripheral components (PDF lib, fonts etc.). That is one of the main problems with the old code, these components are all linked together in bad ways, making it hard to improve and deal with improvements to any particular part. So work on the old code really means using the new code if these are to be considered separate components. Thanks for filling the white spots I left with my answer. I fully agree with you. That's why I mentioned my employer who actually understands the reasons for the redesign and looks forwards to FOP 1.0, but thinks that there are certain issues that have to be dealt with right now. That's why I'm going to look at multithreading issues in the maintenance branch this week. If we had enough resources (like in Jakarta Tomcat, XML Xerces and XML Xalan, where they maintain/maintained two or more dev tracks at once) I wouldn't mind a two-track-approach. But in our situation I tend to force the redesign so we can deliver FOP 1.0 as soon as possible. I'm grateful for Victor's work and I hope it won't be a distraction. Because distractions may leave the focus of potential co-developers on the maintenance branch even though the redesign is already quite advanced. I'm wondering how advanced it really needs to be before anyone wants to work on it. It is almost suitable to be used with the docs that forrest creates. The fact that we started to get a few patches for the redesign after our discussions in August is already a good sign. I understand your particular situation and the required things for production. Yeah, I'd be grateful if the situation was different. At least, it looks like I will be able to work on the redesign soon. For how long and if I'm going to get paid for it I'm still trying to check out. Jeremias Maerki - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, email: [EMAIL PROTECTED]
RE: handling patches
On Sat, 2002-11-02 at 21:31, Victor Mote wrote: I agree that maintenance branches are not obliged to be merged eventually, but you still have not shown any benefit to keeping them in the same tree if they are not. Usual development pattern would also be that someone makes sure that new functionality doesn't get added to the maintenance release. That is apparently what Keiron is attempting to do now, and I have no problem with that. However, our web site says this: I'm not trying to make sure functionality doesn't get to the branch, I am trying to get a focus on something that I consider to be more efficient use of time. If you want to work with the latest and nicest code, you can use the cvs version. See the section on AnonCVS in the xml.apache.org documentation for details Important: Currently, releases of FOP are coming out of the fop-0_20_2-maintain branch. The MAIN branch is used for the redesign. See NEW DESIGN for more information. I hope I will be forgiven for not correctly interpreting the multitude of mixed signals. When someone starts quoting the website then it is time to update it :) - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, email: [EMAIL PROTECTED]
cvs commit: xml-fop/src/org/apache/fop/fo/pagination PageSequence.java
keiron 2002/11/04 03:50:11
Modified:src/org/apache/fop/layoutmgr PageLayoutManager.java
src/org/apache/fop/fo/pagination PageSequence.java
Log:
page numbering across sequences and number formatting
Revision ChangesPath
1.22 +20 -7 xml-fop/src/org/apache/fop/layoutmgr/PageLayoutManager.java
Index: PageLayoutManager.java
===
RCS file: /home/cvs/xml-fop/src/org/apache/fop/layoutmgr/PageLayoutManager.java,v
retrieving revision 1.21
retrieving revision 1.22
diff -u -r1.21 -r1.22
--- PageLayoutManager.java25 Oct 2002 09:29:45 - 1.21
+++ PageLayoutManager.java4 Nov 2002 11:50:11 - 1.22
@@ -13,6 +13,7 @@
import org.apache.fop.fo.pagination.PageSequence;
import org.apache.fop.fo.pagination.Region;
import org.apache.fop.fo.pagination.SimplePageMaster;
+import org.apache.fop.fo.pagination.PageNumberGenerator;
import org.apache.fop.fo.properties.Constants;
import java.util.ArrayList;
@@ -33,6 +34,10 @@
}
}
+private PageNumberGenerator pageNumberGenerator;
+private int pageCount = 1;
+private String pageNumberString;
+
/** True if haven't yet laid out any pages.*/
private boolean bFirstPage;
/** Current page being worked on. */
@@ -60,8 +65,6 @@
private AreaTree areaTree;
private PageSequence pageSequence;
-private int pageCount = 1;
-
/**
* This is the top level layout manager.
* It is created by the PageSequence FO.
@@ -72,6 +75,15 @@
pageSequence = pageseq;
}
+public void setPageCounting(int pc, PageNumberGenerator generator) {
+pageCount = pc;
+pageNumberGenerator = generator;
+pageNumberString = pageNumberGenerator.makeFormattedPageNumber(pageCount);
+}
+
+public int getPageCount() {
+return pageCount;
+}
/**
* The layout process is designed to be able to be run in a thread.
@@ -104,10 +116,11 @@
// finish page and add to area tree
finishPage();
+pageCount++;
+pageNumberString =
pageNumberGenerator.makeFormattedPageNumber(pageCount);
}
-pageCount++;
}
-
+pageCount--;
}
@@ -135,7 +148,7 @@
}
public String getCurrentPageNumber() {
-return + pageCount;
+return pageNumberString;
}
public PageViewport resolveRefID(String ref) {
@@ -251,7 +264,7 @@
private PageViewport makeNewPage(boolean bIsBlank, boolean bIsLast) {
finishPage();
try {
-curPage = pageSequence.createPage(bIsBlank, bIsLast);
+curPage = pageSequence.createPage(pageCount, bIsBlank, bIsLast);
} catch (FOPException fopex) { /* */
fopex.printStackTrace();
}
1.57 +39 -135 xml-fop/src/org/apache/fop/fo/pagination/PageSequence.java
Index: PageSequence.java
===
RCS file: /home/cvs/xml-fop/src/org/apache/fop/fo/pagination/PageSequence.java,v
retrieving revision 1.56
retrieving revision 1.57
diff -u -r1.56 -r1.57
--- PageSequence.java 25 Oct 2002 09:29:43 - 1.56
+++ PageSequence.java 4 Nov 2002 11:50:11 - 1.57
@@ -1,14 +1,9 @@
/*
* $Id$
- * Copyright (C) 2001 The Apache Software Foundation. All rights reserved.
+ * Copyright (C) 2001-2002 The Apache Software Foundation. All rights reserved.
* For details on use and redistribution please refer to the
* LICENSE file included with these sources.
*/
-/*
- Modified by Mark Lillywhite [EMAIL PROTECTED] Does not add
- itself to the root any more. Does not hang onto currentPage
- pointer, which caused GC issues.
- */
package org.apache.fop.fo.pagination;
@@ -115,7 +110,7 @@
/**
* The main content flow for this page-sequence.
*/
-private Flow mainFlow=null;
+private Flow mainFlow = null;
/**
* The fo:title object for this page-sequence.
@@ -146,8 +141,8 @@
_flowMap = new HashMap();
-thisIsFirstPage =
-true;// we are now on the first page of the page sequence
+// we are now on the first page of the page sequence
+thisIsFirstPage = true;
ipnValue = this.properties.get(initial-page-number).getString();
if (ipnValue.equals(auto)) {
@@ -171,10 +166,10 @@
String masterName = this.properties.get(master-reference).getString();
this.currentSimplePageMaster =
this.layoutMasterSet.getSimplePageMaster(masterName);
-if (this.currentSimplePageMaster==null) {
+if
Re: Common code in CVS branches
Jeremias Maerki wrote: Comments on your thoughts about branches: It sounds like the CVS manipulation gets to be a project of its own. If it's too complicated, some won't follow the rules, more work is generated for maintaining the codebase. That's the impression I get. It's definitely 1) more complicated, though not massively more so, and 2) requires closer liaison between committers on common code commits. 1) bad 2) good? I can't follow you on 2). Do you mean between maintenance-oriented committers and redesign-oriented committers? If that gets a problem then we have a split in the project and that wouldn't be good. Between all committers. I meant that closer liaison between committers is a good thing. All committers then have a more lively appreciation of what the others are up to. Peter -- Peter B. West [EMAIL PROTECTED] http://www.powerup.com.au/~pbwest/ Lord, to whom shall we go? - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, email: [EMAIL PROTECTED]
RE: handling patches (how about fop 2)
Here is one other point to consider: if you expect the redesign when complete to perform at at least the same level, i.e. with the same coverage of the specification and as many or fewer defects, when it comes online and replaces the current maintenance release, then I imho the project should continue on as it currently is. However, if you expect there to be a significant number of bugs to be discovered and performance to be initially lower, then the project should move to perhaps fop2 so that users could more easily know that there could be problems when they upgrade to a new version of fop. Does this make any sense? Matthew L. Avizinis mailto:mla;gleim.com Gleim Publications, Inc. 4201 NW 95th Blvd. Gainesville, FL 32606 (352)-375-0772 www.gleim.com http://www.gleim.com -Original Message- From: Victor Mote [mailto:vic;outfitr.com] Sent: Saturday, November 02, 2002 11:27 AM To: [EMAIL PROTECTED] Subject: RE: handling patches (how about fop 2) Oleg Tkachenko wrote: and contributors efforts. Maintenance branch, as you correctly noted, is in production at many sites therefore making it a project on its own will lead to a strengthening of its meaning and this way we'll encourage many existing and future contributors to work on it, instead of helping us to get HEAD up. This is a fair point, but I think it weighs only in the decision about whether we have a rewrite or not. In other words, it might weigh into the economics of whether it is worth it for us to merge the sections of code that can be merged. We might be willing to spend more time and effort getting the two branches pulled back together than we would be if the above were not true. If we really do have a rewrite, then I think it will clarify everything to split into two projects, and I don't begrudge folks from working on the old one instead of the new one any more than I would begrudge the RenderX guys working on their product instead of FOP, or the Batik guys working on Batik instead of FOP. The problem that Oleg mentions is already the status quo. Victor Mote - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, email: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, email: [EMAIL PROTECTED]
cvs commit: xml-fop/src/org/apache/fop/fo/pagination FoLayoutMasterSet.java FoPageSequenceMaster.java FoRegionAfter.java FoRegionBeforeAfter.java FoRegionBefore.java FoRegionBody.java FoRegionEnd.java FoRegionStartEnd.java FoRegionStart.java FoSimplePageMaster.java
pbwest 2002/11/04 06:46:03
Modified:src/org/apache/fop/fo/pagination Tag: FOP_0-20-0_Alt-Design
FoLayoutMasterSet.java FoPageSequenceMaster.java
FoRegionAfter.java FoRegionBeforeAfter.java
FoRegionBefore.java FoRegionBody.java
FoRegionEnd.java FoRegionStartEnd.java
FoRegionStart.java FoSimplePageMaster.java
Log:
Node and TreeException extracted from Tree.
Revision ChangesPath
No revision
No revision
1.1.2.13 +7 -7
xml-fop/src/org/apache/fop/fo/pagination/Attic/FoLayoutMasterSet.java
Index: FoLayoutMasterSet.java
===
RCS file:
/home/cvs/xml-fop/src/org/apache/fop/fo/pagination/Attic/FoLayoutMasterSet.java,v
retrieving revision 1.1.2.12
retrieving revision 1.1.2.13
diff -u -r1.1.2.12 -r1.1.2.13
--- FoLayoutMasterSet.java30 Oct 2002 13:19:04 - 1.1.2.12
+++ FoLayoutMasterSet.java4 Nov 2002 14:46:03 - 1.1.2.13
@@ -17,7 +17,7 @@
import org.apache.fop.xml.UriLocalName;
import org.apache.fop.xml.XMLNamespaces;
import org.apache.fop.xml.SyncedFoXmlEventsBuffer;
-import org.apache.fop.datastructs.Tree;
+import org.apache.fop.datastructs.TreeException;
import org.apache.fop.fo.pagination.FoPageSequenceMaster;
import org.apache.fop.fo.pagination.PageSequenceMaster;
@@ -102,7 +102,7 @@
*/
public FoLayoutMasterSet
(FOTree foTree, FONode parent, FoXMLEvent event)
-throws Tree.TreeException, FOPException, PropertyException
+throws TreeException, FOPException, PropertyException
{
super(foTree, FObjectNames.LAYOUT_MASTER_SET, parent, event,
FOPropertySets.LAYOUT_SET, sparsePropsMap, sparseIndices,
@@ -157,7 +157,7 @@
try {
foPageSeq =
new FoPageSequenceMaster(foTree, this, ev);
-} catch (Tree.TreeException e) {
+} catch (TreeException e) {
throw new FOPException
(TreeException: + e.getMessage());
}
@@ -184,7 +184,7 @@
catch (PropertyException e) {
throw new FOPException(e);
}
-catch (Tree.TreeException e) {
+catch (TreeException e) {
throw new FOPException(e);
}
if (pageMasters.size() == 0)
1.1.2.13 +8 -8
xml-fop/src/org/apache/fop/fo/pagination/Attic/FoPageSequenceMaster.java
Index: FoPageSequenceMaster.java
===
RCS file:
/home/cvs/xml-fop/src/org/apache/fop/fo/pagination/Attic/FoPageSequenceMaster.java,v
retrieving revision 1.1.2.12
retrieving revision 1.1.2.13
diff -u -r1.1.2.12 -r1.1.2.13
--- FoPageSequenceMaster.java 30 Oct 2002 13:09:11 - 1.1.2.12
+++ FoPageSequenceMaster.java 4 Nov 2002 14:46:03 - 1.1.2.13
@@ -27,7 +27,7 @@
import org.apache.fop.fo.FObjectNames;
import org.apache.fop.fo.FOTree;
import org.apache.fop.fo.FONode;
-import org.apache.fop.datastructs.Tree;
+import org.apache.fop.datastructs.TreeException;
import org.apache.fop.datatypes.PropertyValue;
import org.apache.fop.datatypes.NCName;
import org.apache.fop.datatypes.Ints;
@@ -188,7 +188,7 @@
};
public FoPageSequenceMaster(FOTree foTree, FONode parent, FoXMLEvent event)
-throws Tree.TreeException, FOPException, PropertyException
+throws TreeException, FOPException, PropertyException
{
super(foTree, FObjectNames.PAGE_SEQUENCE_MASTER, parent, event,
FOPropertySets.SEQ_MASTER_SET, sparsePropsMap, sparseIndices,
@@ -241,7 +241,7 @@
public FoSinglePageMasterReference
(FOTree foTree, FONode parent, FoXMLEvent event)
-throws Tree.TreeException, FOPException, PropertyException
+throws TreeException, FOPException, PropertyException
{
super(foTree, FObjectNames.SINGLE_PAGE_MASTER_REFERENCE, parent,
event, FOPropertySets.SEQ_MASTER_SET, s_p_m_r_PropsMap,
@@ -263,7 +263,7 @@
public FoRepeatablePageMasterReference
(FOTree foTree, FONode parent, FoXMLEvent event)
-throws Tree.TreeException, FOPException, PropertyException
+throws TreeException, FOPException, PropertyException
{
super(foTree, FObjectNames.REPEATABLE_PAGE_MASTER_REFERENCE,
parent, event, FOPropertySets.SEQ_MASTER_SET,
@@ -289,7 +289,7 @@
public FoRepeatablePageMasterAlternatives
cvs commit: xml-fop/src/org/apache/fop/fo FONode.java FoRoot.java
pbwest 2002/11/04 06:54:56
Modified:src/org/apache/fop/fo Tag: FOP_0-20-0_Alt-Design FONode.java
FoRoot.java
Log:
Node and TreeException extracted from Tree.
Revision ChangesPath
No revision
No revision
1.19.2.21 +7 -6 xml-fop/src/org/apache/fop/fo/FONode.java
Index: FONode.java
===
RCS file: /home/cvs/xml-fop/src/org/apache/fop/fo/FONode.java,v
retrieving revision 1.19.2.20
retrieving revision 1.19.2.21
diff -u -r1.19.2.20 -r1.19.2.21
--- FONode.java 30 Oct 2002 14:41:49 - 1.19.2.20
+++ FONode.java 4 Nov 2002 14:54:56 - 1.19.2.21
@@ -14,7 +14,8 @@
import org.apache.fop.datatypes.TextDecorations;
import org.apache.fop.datatypes.indirect.Inherit;
import org.apache.fop.datatypes.indirect.IndirectValue;
-import org.apache.fop.datastructs.Tree;
+import org.apache.fop.datastructs.Node;
+import org.apache.fop.datastructs.TreeException;
import org.apache.fop.datastructs.ROBitSet;
import org.apache.fop.apps.FOPException;
import org.apache.fop.xml.FoXMLEvent;
@@ -46,7 +47,7 @@
* Class for nodes in the FO tree.
*/
-public class FONode extends FOTree.Node{
+public class FONode extends Node{
private static final String tag = $Name$;
private static final String revision = $Revision$;
@@ -135,9 +136,9 @@
public FONode
(FOTree foTree, int type, FONode parent, FoXMLEvent event, int attrSet,
HashMap sparsePropsMap, int[] sparseIndices, int numProps)
-throws Tree.TreeException, FOPException, PropertyException
+throws TreeException, FOPException, PropertyException
{
-foTree.super(parent);
+super(foTree, parent);
this.foTree = foTree;
this.type = type;
this.parent = parent;
1.1.2.13 +6 -6 xml-fop/src/org/apache/fop/fo/Attic/FoRoot.java
Index: FoRoot.java
===
RCS file: /home/cvs/xml-fop/src/org/apache/fop/fo/Attic/FoRoot.java,v
retrieving revision 1.1.2.12
retrieving revision 1.1.2.13
diff -u -r1.1.2.12 -r1.1.2.13
--- FoRoot.java 30 Oct 2002 14:35:11 - 1.1.2.12
+++ FoRoot.java 4 Nov 2002 14:54:56 - 1.1.2.13
@@ -13,7 +13,7 @@
import org.apache.fop.apps.FOPException;
import org.apache.fop.fo.FOPropertySets;
import org.apache.fop.fo.FObjectNames;
-import org.apache.fop.datastructs.Tree;
+import org.apache.fop.datastructs.TreeException;
import org.apache.fop.datatypes.Ints;
import org.apache.fop.fo.FOTree;
import org.apache.fop.fo.FONode;
@@ -78,7 +78,7 @@
*/
public FoRoot
(FOTree foTree, FoXMLEvent event)
-throws Tree.TreeException, FOPException, PropertyException
+throws TreeException, FOPException, PropertyException
{
// This is the root node of the tree; hence the null argument
super(foTree, FObjectNames.ROOT, null, event, FOPropertySets.ROOT_SET,
@@ -125,7 +125,7 @@
layoutMasters = new FoLayoutMasterSet(foTree, this, ev);
// Clean up the fo:layout-master-set event
xmlevents.getEndElement(ev);
-} catch(Tree.TreeException e) {
+} catch(TreeException e) {
throw new FOPException(TreeException: + e.getMessage());
} catch(PropertyException e) {
throw new FOPException(PropertyException: + e.getMessage());
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
cvs commit: xml-fop/src/org/apache/fop/viewer/resources resources.cs resources.de
jeremias2002/11/04 07:14:33
Modified:src/org/apache/fop/viewer Tag: fop-0_20_2-maintain
GoToPageDialog.java PreviewDialog.java
src/org/apache/fop/viewer/resources Tag: fop-0_20_2-maintain
resources.cs resources.de
Log:
Bugzilla Entry 14161
Added translation for GoToPageDialog
Update for czech translations
Submitted by: Michal Buchtik [EMAIL PROTECTED]
Update for german translations
Fix CRLF problems
Revision ChangesPath
No revision
No revision
1.2.2.1 +10 -7 xml-fop/src/org/apache/fop/viewer/GoToPageDialog.java
Index: GoToPageDialog.java
===
RCS file: /home/cvs/xml-fop/src/org/apache/fop/viewer/GoToPageDialog.java,v
retrieving revision 1.2
retrieving revision 1.2.2.1
diff -u -r1.2 -r1.2.2.1
--- GoToPageDialog.java 30 Jul 2001 20:29:35 - 1.2
+++ GoToPageDialog.java 4 Nov 2002 15:14:31 - 1.2.2.1
@@ -1,6 +1,6 @@
/*
* $Id$
- * Copyright (C) 2001 The Apache Software Foundation. All rights reserved.
+ * Copyright (C) 2001-2002 The Apache Software Foundation. All rights reserved.
* For details on use and redistribution please refer to the
* LICENSE file included with these sources.
*/
@@ -21,6 +21,8 @@
import org.apache.fop.messaging.MessageHandler;
public class GoToPageDialog extends JDialog {
+private Translator res;
+
JPanel panel1 = new JPanel();
GridBagLayout gridBagLayout1 = new GridBagLayout();
JLabel pgNbLabel = new JLabel();
@@ -30,9 +32,10 @@
int pageNumber = -1;
-public GoToPageDialog(Frame frame, String title, boolean modal) {
+public GoToPageDialog(Frame frame, String title, boolean modal, Translator
resource) {
super(frame, title, modal);
try {
+res = resource;
jbInit();
pack();
} catch (Exception ex) {
@@ -42,13 +45,13 @@
}
public GoToPageDialog() {
-this(null, , false);
+this(null, , false, null);
}
void jbInit() throws Exception {
panel1.setLayout(gridBagLayout1);
-pgNbLabel.setText(Page number);
-okButton.setText(Ok);
+pgNbLabel.setText(res.getString(Page number));
+okButton.setText(res.getString(Ok));
okButton.addActionListener(new java.awt.event.ActionListener() {
public void actionPerformed(ActionEvent e) {
@@ -56,7 +59,7 @@
}
});
-cancelButton.setText(Cancel);
+cancelButton.setText(res.getString(Cancel));
cancelButton.addActionListener(new java.awt.event.ActionListener() {
public void actionPerformed(ActionEvent e) {
1.7.2.4 +667 -703 xml-fop/src/org/apache/fop/viewer/PreviewDialog.java
Index: PreviewDialog.java
===
RCS file: /home/cvs/xml-fop/src/org/apache/fop/viewer/PreviewDialog.java,v
retrieving revision 1.7.2.3
retrieving revision 1.7.2.4
diff -u -r1.7.2.3 -r1.7.2.4
--- PreviewDialog.java2 Aug 2002 20:28:59 - 1.7.2.3
+++ PreviewDialog.java4 Nov 2002 15:14:31 - 1.7.2.4
@@ -1,703 +1,667 @@
-/*
- * $Id$
- * Copyright (C) 2001 The Apache Software Foundation. All rights reserved.
- * For details on use and redistribution please refer to the
- * LICENSE file included with these sources.
- */
-
-package org.apache.fop.viewer;
-
-/*
- * originally contributed by
- * Juergen Verwohlt: [EMAIL PROTECTED],
- * Rainer Steinkuhle: [EMAIL PROTECTED],
- * Stanislav Gorkhover: [EMAIL PROTECTED]
- * Doro Wiarda ([EMAIL PROTECTED]:
- * added MessageListener support and made
- * the showing of the progress and error
- * messages Swing thread safe.
- * This is needed as xml parse errors do not
- * necessarily occur in the
- * EventDispatchThread.
- */
-
-import java.awt.*;
-import java.awt.print.*;
-import java.awt.event.*;
-import java.awt.image.BufferedImage;
-import java.util.StringTokenizer;
-import java.util.Vector;
-
-import javax.swing.*;
-
-import org.apache.fop.layout.*;
-import org.apache.fop.render.awt.*;
-import org.apache.fop.messaging.*;
-import org.apache.fop.apps.AWTStarter;
-import org.apache.fop.apps.FOPException;
-
-/**
- * Frame and User Interface for Preview
- */
-public class PreviewDialog extends JFrame implements ProgressListener,
-MessageListener {
-
-protected Translator res;
-
-protected int currentPage = 0;
-protected int pageCount = 0;
-
-protected AWTRenderer renderer;
-protected AWTStarter starter;
-
-
DO NOT REPLY [Bug 14161] - [PATCH] add translation to GoToPageDialog
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT http://nagoya.apache.org/bugzilla/show_bug.cgi?id=14161. ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND INSERTED IN THE BUG DATABASE. http://nagoya.apache.org/bugzilla/show_bug.cgi?id=14161 [PATCH] add translation to GoToPageDialog [EMAIL PROTECTED] changed: What|Removed |Added Status|NEW |RESOLVED Resolution||FIXED --- Additional Comments From [EMAIL PROTECTED] 2002-11-04 15:17 --- Patch applied. Thanks. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, email: [EMAIL PROTECTED]
cvs commit: xml-fop/src/org/apache/fop/datastructs Node.java TreeException.java Tree.java
pbwest 2002/11/04 07:17:10
Modified:src/org/apache/fop/datastructs Tag: FOP_0-20-0_Alt-Design
Tree.java
Added: src/org/apache/fop/datastructs Tag: FOP_0-20-0_Alt-Design
Node.java TreeException.java
Log:
Node and TreeException externalised from Tree.
Revision ChangesPath
No revision
No revision
1.1.2.3 +48 -967 xml-fop/src/org/apache/fop/datastructs/Attic/Tree.java
Index: Tree.java
===
RCS file: /home/cvs/xml-fop/src/org/apache/fop/datastructs/Attic/Tree.java,v
retrieving revision 1.1.2.2
retrieving revision 1.1.2.3
diff -u -r1.1.2.2 -r1.1.2.3
--- Tree.java 24 Oct 2002 14:16:53 - 1.1.2.2
+++ Tree.java 4 Nov 2002 15:17:10 - 1.1.2.3
@@ -9,40 +9,18 @@
package org.apache.fop.datastructs;
-import java.util.ArrayList;
-import java.util.ConcurrentModificationException;
-import java.util.NoSuchElementException;
-import java.util.Iterator;
-import java.util.ListIterator;
-
-// TODO:
-// Should I provide a separate or supplementary exception for CoMods appends
-// on the trailing edge of the tree? I.e., for each append, check if it is an
-// append to a node which is the final sibling at any level of the tree.
-// If so, set a copy the modCount value as the trailingEdgeModAge.
-// If a ConcurrentModificationException is about to be thrown, check whether
-// the trailingEdgeModAge is the same as the modCount. If so, throw a
-// ConcurrentTreeAppendException instead. Probably, make that a subclass of
-// ConcurrentModificationException so that the check can be done on the
-// catch of the CoModEx.
/**
- * A generalised tree class with traversal ttIterator/tts.
+ * A generalised tree class.
*
* pThe ttTree/tt class is analogous to one of the ttCollection/tt
* classes. It provides a bag with a certain structure into which objects
- * may be collected for manipulation./p
+ * may be collected for manipulation.
*
* pThe outer class, Tree, is the level at which are defined those fields
* and methods which are provided for the manipulation of the tree as a
* whole. The tree is actually comprised of a collection of ttNode/tt
- * elements./p
- *
- * pThe primary reasons for the existence of a separate ttTree/tt
- * class is to provide an object for tree-wide synchronization, and to
- * have a home for ttmodCount/tt for the provision of
- * ifast-fail/i iterators. For more details, see the
- * discussion of ttmodCount/tt in ttAbstractList/tt./p
+ * elements.
*
* @author a href=mailto:pbwest;powerup.com.auPeter B. West/a
* @version $Revision$ $Name$
@@ -56,9 +34,16 @@
* ttAbstractList/tt.
*/
protected int modCount = 0;
+
+/**
+ * Count of the nodes in this tree.
+ */
protected int nodeCount = 0;
-protected Node root;
+/**
+ * The root node of this tree.
+ */
+protected Node root = null;
public Tree() {}
@@ -71,970 +56,66 @@
}
}
+/**
+ * Get the value of the imodCount/i field, used to warn of concurrent
+ * modification of the tree during certain unsynchronized operations.
+ * @return - the ttint/tt imodCount/i.
+ */
public int getModCount() {
synchronized (this) {
return modCount;
}
}
+/**
+ * Test the imodCount/i field value.
+ * @param value - the value to test against imodCount/i.
+ * @return ttboolean/tt test result.
+ */
public boolean modCountEqualTo(int value) {
synchronized (this) {
return value == modCount;
}
}
+/**
+ * Get the number of nodes in the tree.
+ * @return the number of nodes.
+ */
public int size() {
return nodeCount;
}
+/**
+ * Is the tree empty?
+ * @return ttboolean/tt answer to the question. Tests whether the
+ * root node is ttnull/tt.
+ */
public boolean isEmpty() {
-return nodeCount == 0;
+return root == null;
}
-public Node getRoot() {
-return root;
-}
-
-public void unsetRoot() {
-root = null;
+/**
+ * Set the iroot/i field.
+ * @param root the ttNode/tt which is to be the root of the tree.
+ */
+public void setRoot(Node root) {
+this.root = root;
}
-
-public class TreeException extends Exception {
-public TreeException(String message) {
-super(message);
-}
-
+/**
+ * Get the root node of the tree.
+ * @return the root ttNode/tt.
+ */
+public Node
RE: Common code in CVS branches
Keiron Liddle wrote: That is one of the main problems with the old code, these components are all linked together in bad ways, making it hard to improve and deal with improvements to any particular part. So work on the old code really means using the new code if these are to be considered separate components. I understand, and I will interpret these comments and other related ones together to be a veto on my proposal to try to merge the two branches. I totally understand and respect that, and will comply. I do think that I got the wrong impression somewhere along the way. To the extent that I am able to demand anything, I really think we must at the very least make it very clear in our web site/doc that the maintenance branch is not open for business except for bug fixes, and with perhaps a two-sentence explanation of why. That may prevent you from getting to have this discussion again. I'm wondering how advanced it really needs to be before anyone wants to work on it. It is almost suitable to be used with the docs that forrest creates. I'll start in on it right away. If you have a specific task that a greenhorn can chew on, please let me know. Otherwise, I'm sure I'll be able to find something interesting. Victor Mote - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, email: [EMAIL PROTECTED]
DO NOT REPLY [Bug 13919] - [Patch] Font Refactor, phase 1, maintenance branch
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT http://nagoya.apache.org/bugzilla/show_bug.cgi?id=13919. ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND INSERTED IN THE BUG DATABASE. http://nagoya.apache.org/bugzilla/show_bug.cgi?id=13919 [Patch] Font Refactor, phase 1, maintenance branch [EMAIL PROTECTED] changed: What|Removed |Added Status|NEW |RESOLVED Resolution||WONTFIX --- Additional Comments From [EMAIL PROTECTED] 2002-11-04 15:32 --- As discussed on dev mailing list, we will not do this work in the maintenance branch. This patch will be resubmitted if and when it can be reworked for the trunk. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, email: [EMAIL PROTECTED]
DO NOT REPLY [Bug 14057] - [PATCH] implement text-transform
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT http://nagoya.apache.org/bugzilla/show_bug.cgi?id=14057. ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND INSERTED IN THE BUG DATABASE. http://nagoya.apache.org/bugzilla/show_bug.cgi?id=14057 [PATCH] implement text-transform [EMAIL PROTECTED] changed: What|Removed |Added Status|NEW |RESOLVED Resolution||WONTFIX --- Additional Comments From [EMAIL PROTECTED] 2002-11-04 15:37 --- As discussed on dev mailing list, we will not do this work in the maintenance branch. This patch will be resubmitted if and when it can be reworked for the trunk. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, email: [EMAIL PROTECTED]
cvs commit: xml-fop build.sh
jeremias2002/11/04 08:05:09 Modified:.Tag: fop-0_20_2-maintain build.sh Log: Bugzilla Entry 13310 Improved classpath construction Submitted by: Victor Mote [EMAIL PROTECTED] Revision ChangesPath No revision No revision 1.15.2.10 +11 -2 xml-fop/build.sh Index: build.sh === RCS file: /home/cvs/xml-fop/build.sh,v retrieving revision 1.15.2.9 retrieving revision 1.15.2.10 diff -u -r1.15.2.9 -r1.15.2.10 --- build.sh 12 Sep 2002 20:38:26 - 1.15.2.9 +++ build.sh 4 Nov 2002 16:05:05 - 1.15.2.10 @@ -27,8 +27,17 @@ LIBDIR=lib -LOCALCLASSPATH=$JAVA_HOME/lib/tools.jar:$JAVA_HOME/lib/classes.zip:$LIBDIR/ant-1.4.1.jar:$LIBDIR/batik.jar:$LIBDIR/buildtools.jar:$LIBDIR/xercesImpl-2.0.1.jar:$LIBDIR/xalan-2.3.1.jar:$LIBDIR/xml-apis.jar:$LIBDIR/bsf.jar -LOCALCLASSPATH=$LOCALCLASSPATH:$LIBDIR/jimi-1.0.jar:$LIBDIR/avalon-framework-cvs-20020806.jar +LOCALCLASSPATH=$JAVA_HOME/lib/tools.jar +LOCALCLASSPATH=$LOCALCLASSPATH:$JAVA_HOME/lib/classes.zip +LOCALCLASSPATH=$LOCALCLASSPATH:$LIBDIR/ant-1.4.1.jar +LOCALCLASSPATH=$LOCALCLASSPATH:$LIBDIR/batik.jar +LOCALCLASSPATH=$LOCALCLASSPATH:$LIBDIR/buildtools.jar +LOCALCLASSPATH=$LOCALCLASSPATH:$LIBDIR/xercesImpl-2.0.1.jar +LOCALCLASSPATH=$LOCALCLASSPATH:$LIBDIR/xalan-2.3.1.jar +LOCALCLASSPATH=$LOCALCLASSPATH:$LIBDIR/xml-apis.jar +LOCALCLASSPATH=$LOCALCLASSPATH:$LIBDIR/bsf.jar +LOCALCLASSPATH=$LOCALCLASSPATH:$LIBDIR/jimi-1.0.jar +LOCALCLASSPATH=$LOCALCLASSPATH:$LIBDIR/avalon-framework-cvs-20020806.jar # antRun must be executable (can't do this in build.xml because Ant uses antRun # to do the chmod) - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
place for patches
Where would be a good place to put some patches. I have current cvs working with cocoon+forrest and have a patch to work with the fop-block and a patch to make bookmarks in the pdf output. Really basic stuff but it might be useful to someone. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, email: [EMAIL PROTECTED]
Re: Common code in CVS branches
On Mon, 2002-11-04 at 17:38, Oleg Tkachenko wrote: Keiron Liddle wrote: The major areas of neglect would have to be: - font handling - api classes - awt viewer Please, reserve last one for me, I'm almost finishing with it. Sorry, should have mentioned you are working on it. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, email: [EMAIL PROTECTED]
where to start knowing about fop code
Hi all, I m new bie in this Fop project. I just want to know what is the start point in Fop project and how it goes. can any body help me to start with? thanks in advance. SriGet faster connections -- switch to MSN Internet Access! Click Here - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, email: [EMAIL PROTECTED]
Re: where to start knowing about fop code
Sridhar Velagapudi wrote: I m new bie in this Fop project. I just want to know what is the start point in Fop project and how it goes. can any body help me to start with? thanks in advance. There is a directory docs/html-docs in your FOP distribution. Start there. J.Pietschmann - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, email: [EMAIL PROTECTED]
Current status of re-design
I've been following this list for a few weeks now, but I'm still unclear as to the current status of the re-design efforts. The FOP Web site's status page hasn't been updated since June, apparently, when the estimate of being 35% done was issued. Anyone want to take a stab at saying where things stand now. Is NewFOP able to generate any PDF files? Is there a set of formatting objects and properties that are known to work/sort of work/not work? Thank you. Patrick Rusk P.S. Last night I was up at 3:30 AM EST (US) when FOP emails started flying back and forth. I thought, Wow! These guys are really commiteed to all be working this late. Until I realized most of you are from Europe or Australia. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, email: [EMAIL PROTECTED]
Re: Common code in CVS branches
Victor If it's ok with you, go with font support. I guess you already read yourself halfway in and you know my ideas. That would really be great. Anything else you might want to take is ok, though, and of course, highly appreciated. What are your ideas? On 04.11.2002 17:33:55 Keiron Liddle wrote: On Mon, 2002-11-04 at 16:19, Victor Mote wrote: I'll start in on it right away. If you have a specific task that a greenhorn can chew on, please let me know. Otherwise, I'm sure I'll be able to find something interesting. Hi Victor, The major areas of neglect would have to be: - font handling - api classes - awt viewer Jeremias Maerki - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, email: [EMAIL PROTECTED]
RE: Common code in CVS branches
Jeremias Maerki wrote: If it's ok with you, go with font support. I guess you already read yourself halfway in and you know my ideas. That would really be great. Anything else you might want to take is ok, though, and of course, highly appreciated. What are your ideas? That sounds fine. I'm installing a new workstation today, but hope to be started on this work tomorrow. Victor Mote - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, email: [EMAIL PROTECTED]
Re: Line ending chaos in our codebase
On Monday 04 November 2002 23:53, Peter B. West wrote: . . .I don't know the mechanism for handling line-end differences on entry into a CVS repository on a unix box. . . . AFAIK as long as the binary file flag is not set, CVS takes care of line endings by itself when a file is checked out (http://www.loria.fr/~molli/cvs/doc/cvs_9.html#SEC76), converting them to what's appropriate for the platform. Funny things can happen if people checkout files on a unix box and edit them from a windows box, but most windows editors handle this correctly. -Bertrand - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, email: [EMAIL PROTECTED]
Re: Line ending chaos in our codebase
On Monday 04 November 2002 17:02, Jeremias Maerki wrote: . . .Does anyone have a good idea how to... 2. enforce correct line endings? Using the commitinfo administrative file, scripts can be configured in CVS to run when a file is committed, at which point you could detect the problem. I'm not sure if it's worth the effort though. When such a problem is found, you could also study file revisions to find out who created the problem and tell people to fix their environment. -Bertrand - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, email: [EMAIL PROTECTED]
Re: Line ending chaos in our codebase
Thanks, Peter and Betrand, for your answers. On Tue, 5 Nov 2002 07:21:54 +0100 Bertrand Delacretaz wrote: On Monday 04 November 2002 17:02, Jeremias Maerki wrote: . . .Does anyone have a good idea how to... 2. enforce correct line endings? Using the commitinfo administrative file, scripts can be configured in CVS to run when a file is committed, at which point you could detect the problem. I've heard suggestions like this being discussed in other projects. But they were never installed. So, I guess it's really up to self-control. I'm not sure if it's worth the effort though. When such a problem is found, you could also study file revisions to find out who created the problem and tell people to fix their environment. The person in question seems to have discovered the issue himself and fixed it. I'm into some work on the maintenance branch anyway, so I'll fix the files when I run into them. Jeremias Maerki - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, email: [EMAIL PROTECTED]
DO NOT REPLY [Bug 13310] - [PATCH] javadoc build errors warnings
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT http://nagoya.apache.org/bugzilla/show_bug.cgi?id=13310. ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND INSERTED IN THE BUG DATABASE. http://nagoya.apache.org/bugzilla/show_bug.cgi?id=13310 [PATCH] javadoc build errors warnings [EMAIL PROTECTED] changed: What|Removed |Added Status|NEW |RESOLVED Resolution||FIXED --- Additional Comments From [EMAIL PROTECTED] 2002-11-05 07:55 --- Patch applied. Thanks! - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, email: [EMAIL PROTECTED]
