Thanks, Victor and Peter. It all sounds a bit scary (I knew that before).
Let's look at it the other way: Is there a downside to moving all the
files on the client and checking in everything? What do you guys think
would be the best way to accomplish such a thing?
Jeremias Maerki
On 27.11.2002 17:12:38 Oleg Tkachenko wrote:
Jeremias Maerki wrote:
Oleg and I wonder what we should do with the fact that the FOP servlet
exists in docs/examples/embedding and contrib/servlet. Joerg seems to
have some ideas about this, so I hope he tells us when he's back from
On 28.11.2002 08:33:31 Keiron Liddle wrote:
On Wed, 2002-11-27 at 19:19, Oleg Tkachenko wrote:
There could be two ways to set these values. From the command line we
want the config file to set values and when embedding they could extend
the user agent to set the values.
And what about
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=14924.
ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND
INSERTED IN THE BUG DATABASE.
keiron 2002/11/28 02:38:33
xml-fop/src/documentation/content/xdocs/design/alt.design - New directory
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
keiron 2002/11/28 02:38:35
xml-fop/src/documentation/content/xdocs/design/understanding - New directory
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
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=14928.
ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND
INSERTED IN THE BUG DATABASE.
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=14928.
ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND
INSERTED IN THE BUG DATABASE.
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=1063.
ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND
INSERTED IN THE BUG DATABASE.
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=14924.
ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND
INSERTED IN THE BUG DATABASE.
keiron 2002/11/28 05:04:51
Modified:src/org/apache/fop/layoutmgr/list
ListBlockLayoutManager.java
ListItemLayoutManager.java
src/org/apache/fop/layoutmgr/table Cell.java
TableLayoutManager.java
Jeremias Maerki wrote:
Thanks, Victor and Peter. It all sounds a bit scary (I knew that before).
Let's look at it the other way: Is there a downside to moving all the
files on the client and checking in everything?
Lost history?
What do you guys think
would be the best way to accomplish such
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=13866.
ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND
INSERTED IN THE BUG DATABASE.
keiron 2002/11/28 06:14:53
Modified:src/org/apache/fop/layoutmgr StaticContentLayoutManager.java
Log:
clear old breaks
Revision ChangesPath
1.7 +3 -1
xml-fop/src/org/apache/fop/layoutmgr/StaticContentLayoutManager.java
Index:
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=13586.
ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND
INSERTED IN THE BUG DATABASE.
Jeremias Maerki wrote:
I'd vote for an Avalon Configuration object which can be built easily
from XML and passed through from Cocoon which is also based on Avalon.
Configuration objects are also easily built by hand if necessary.
Right. Lets stop reinventing the wheel (being diving into
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=14924.
ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND
INSERTED IN THE BUG DATABASE.
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=14924.
ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND
INSERTED IN THE BUG DATABASE.
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=14924.
ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND
INSERTED IN THE BUG DATABASE.
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=14924.
ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND
INSERTED IN THE BUG DATABASE.
chrisg 2002/11/28 07:23:23
Modified:.Tag: fop-0_20_2-maintain CHANGES
src/org/apache/fop/fo/flow Tag: fop-0_20_2-maintain
Block.java
Log:
Added infinite loop detection (just halts processing, see bug #8878)
Submitted by: Rhett
jeremias2002/11/28 07:43:17
Modified:src/org/apache/fop/apps Tag: fop-0_20_2-maintain Driver.java
Log:
Good error messages when Driver is not initialized properly.
Revision ChangesPath
No revision
No revision
1.36.2.8
jeremias2002/11/28 07:44:06
Modified:src/org/apache/fop/fo/pagination Tag: fop-0_20_2-maintain
ConditionalPageMasterReference.java
Log:
Make sure that a warning is shown when page-position=last is used.
Revision ChangesPath
No
Oleg Tkachenko wrote:
Jeremias Maerki wrote:
[..]
Hack of the repository looks feasible, I did it once (one more to do is
to modify parent CVS/Entry file, which lists all child directories as
D/foo-dir). Lets try on a non crucial directory first :)
Won't this break old releases?
For
Jeremias Maerki wrote:
On 27.11.2002 17:12:38 Oleg Tkachenko wrote:
Jeremias Maerki wrote:
[..]
The question is actually whether contrib/servlet stuff is included into the
distribution. If so, I don't see any reason to duplicate java code and war.
Just need to change documentation and
Christian Geisert wrote:
Won't this break old releases?
For example checking out FOP with tag fop-0_20_3 then build.sh
will probably fail.
I think you right :(
--
Oleg Tkachenko
eXperanto team
Multiconn Technologies, Israel
On 28.11.2002 15:48:40 Oleg Tkachenko wrote:
Jeremias Maerki wrote:
I'd vote for an Avalon Configuration object which can be built easily
from XML and passed through from Cocoon which is also based on Avalon.
Configuration objects are also easily built by hand if necessary.
Right. Lets
jeremias2002/11/28 08:06:39
Modified:src/org/apache/fop/render/xml Tag: fop-0_20_2-maintain
XMLRenderer.java
Log:
Avoid NPE when options aren't set on the XMLRenderer (Bug 14768)
Submitted by: Matthias Brunner [EMAIL PROTECTED]
Revision Changes
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=14768.
ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND
INSERTED IN THE BUG DATABASE.
Jeremias Maerki wrote:
From your original plan we still have to finish the documentation stuff,
Yes the documentation needs at least to be checked for old versions,
errors etc. And it would be nice to document the ant task and new
extensions.
right? Maybe we can also include the reorganized
Also following other project's conventions. The config files get
included in the jar, so I think they ARE source.
Another issue with the conf dir is that it's also part
of the binary distribution.
Christian
-
To
Hi,
for the documentation for the maintenance release I think the
best thing is to copy src/documentation over from trunk and then
add a simple exec command=forrest to build.xml
Comments?
The track.png in status.html needs a update. How is it done?
Christian
How will we maintain the website after the copy? Change in trunk then
copy over to maint branch each time something is changed? Or can we
somehow keep both documentation parts separate in their branches and
copy the stuff together when the website needs an update?
On 28.11.2002 17:33:51 Christian
On 28.11.2002 17:15:46 Christian Geisert wrote:
Jeremias Maerki wrote:
From your original plan we still have to finish the documentation stuff,
Yes the documentation needs at least to be checked for old versions,
errors etc. And it would be nice to document the ant task and new
Jeremias Maerki wrote:
Let's look at it the other way: Is there a downside to moving all the
files on the client and checking in everything? What do you guys think
would be the best way to accomplish such a thing?
The downside to moving the files on the client then checking in is that
you
Christian Geisert wrote:
for the documentation for the maintenance release I think the
best thing is to copy src/documentation over from trunk and then
add a simple exec command=forrest to build.xml
Comments?
I had a thought left over from our discussion of branching a few weeks ago
that
Victor Mote wrote:
Jeremias Maerki wrote:
Let's look at it the other way: Is there a downside to moving all the
files on the client and checking in everything? What do you guys think
would be the best way to accomplish such a thing?
The downside to moving the files on the client then
Victor Mote wrote:
Christian Geisert wrote:
for the documentation for the maintenance release I think the
best thing is to copy src/documentation over from trunk and then
add a simple exec command=forrest to build.xml
Comments?
I had a thought left over from our discussion of branching a
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=13866.
ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND
INSERTED IN THE BUG DATABASE.
39 matches
Mail list logo
