Re: Switching to Java 1.5

[Adrian Cumiskey]

Hi all,

I have attached a patch file which provides support for Retroweaver at
compilation time in FOP's ant build script.  You can grab the latest
Retroweaver from
http://downloads.sourceforge.net/retroweaver/retroweaver-2.0.5.zip.  There
is already quite some generics comments which could be easily uncommented in
the FOP source code, so feel free to experiment.

Adrian.

2008/6/5 Jess Holle <[EMAIL PROTECTED]>:

>  I can't speak for the broader market but for my usages anything prior to
> Java 5 is "dead wood" and of no interest.
>
> As of October of this year anything prior to Java 5 will be officially
> unsupported by Sun except where you have a paid support contract with them
> (including that for Solaris).  Add to that the fact that Java 1.4 is so
> limiting for so many things and Java 5 is supported on even the most odd
> ball platforms (except Java ME, but I don't see FOP on ME...)
>
>
> The Web Maestro wrote:
>
> +1 from me on a new poll for discussion.
>
> On Thu, Jun 5, 2008 at 11:56 AM, Jeremias Maerki <[EMAIL PROTECTED]> <[EMAIL 
> PROTECTED]> wrote:
>
>
>  +1 to being cautious about dropping support for Java 1.4 without
> consulting the user base first, i.e. +1 for another user poll, though I
> wouldn't do it before October.
> +1 to putting the users' desires above the developers' desires.
> +1 to moving to Java 1.5 when the time is right.
> -0.5 (no veto) to moving to Java 1.5 before Oct 2008.
> +1 to making experiments with Retroweaver (but please not in Trunk).
>
> On 05.06.2008 17:46:07 Vincent Hennebert wrote:
>
>
>  Hi Guys,
>
> I would like to raise this topic again: what about switching to Java 1.5
> as a minimum requirement?
>
> The End of Life transition period for Java 1.4 will end on the 30th of
> October 2008 [1]. The next version of FOP (after 0.95) will probably not
> have been released by this time, so we could start using 1.5 features in
> the Trunk.
>
> [1] http://java.sun.com/j2se/1.4.2/download.html
>
> I don't particularly expect any disagreement from a developer point of
> vue (who doesn't want to use 1.5 features?), so in the end this will
> probably depend on the users' reactions, but I thought I'd ask for
> opinions here first.
>
> According to the poll Jeremias made in October 2007 [2], only 14.3% of
> the users would think it's a bad idea to switch to 1.5. A year later the
> percentage will probably have further decreased.
>
> [2] http://wiki.apache.org/xmlgraphics/UserPollOct2007
>
> I guess a new poll will still be necessary. Or we could base it on lazy
> consensus: "If you still want Java 1.4 compatibility, speak up now!".
>
> Anyway, even if 1.4 compatibility is still considered to be required,
> there are tools to convert 1.5 code into 1.4 compatible one. I'm mainly
> thinking of Retroweaver:http://retroweaver.sourceforge.net/
> It's BSD licensed, so IIC there wouldn't be any problem to distribute it
> with FOP. Obviously it would be an (optional) compile-time dependency
> only. I haven't personally tested it, but I'm told it's working pretty
> well and it seems to be well maintained. Of course I'd volunteer to
> introduce it into the build system and see how it works. FWIW, it's
> based on the ASM library, that I've had the opportunity to play with
> a few years ago, and what I can say is that it's a really nice, strong,
> lightweight, easy to use library for manipulating class 
> files.http://asm.objectweb.org/
>
> Obviously we wouldn't switch everything to 1.5 immediately. We would do
> it progressively, when fixing bugs or implementing new features. So it
> should be easy to check that the conversion is working properly by
> running the testsuite on a 1.4 jvm, before every commit. Also, we could
> restrain ourselves to features that are directly translatable to 1.4:
> generics, enhanced for loop, autoboxing/unboxing. Most of all we could
> stick to using methods from the Java standard library that are also
> available in the 1.4 version (and, for instance, not use the new
> concurrency package for now).
>
> Just having the possibility to use generics would give us tremendous
> benefits: simpler, cleaner, safer code, more easily understandable, more
> easily maintainable, etc. I can't wait anymore to use those features.
>
> So, WDYT?
> Thanks,
> Vincent
>
>
> --
> Vincent HennebertAnyware 
> Technologieshttp://people.apache.org/~vhennebert 
>  http://www.anyware-tech.com
> Apache FOP Committer FOP Development/Consulting
>
>
>  Jeremias Maerki
>
>
>
>
>
>


-- 

Adrian.
Index: build.properties
===
--- build.properties	(revision 662228)
+++ build.properties	(working copy)
@@ -11,12 +11,16 @@
 ## All Jars from the optional lib directory are added used for
 ## compilation and JUnit tests. Put your jars for additional
 ## dependencies and tools here.
-# optional.lib.dir = /home/bart/java/lib
+optional

DO NOT REPLY [Bug 45146] New: duplicate license.txt constrain ClassLoader

[bugzilla]

https://issues.apache.org/bugzilla/show_bug.cgi?id=45146

   Summary: duplicate license.txt constrain ClassLoader
   Product: Fop
   Version: 0.93
  Platform: PC
OS/Version: Windows XP
Status: NEW
  Severity: normal
  Priority: P2
 Component: general
AssignedTo: fop-dev@xmlgraphics.apache.org
ReportedBy: [EMAIL PROTECTED]


While using fop 0.93Beta in a web application (Jboss 4.2.0) I stumbled on a
ClassNotFoundException:
org.apache.avalon.framework.configuration.ConfigurationException.

But the requested jar avalon-framework-4.2.0.jar is clearly on the path,
the very reason are duplicate and identical entries inside this jar for
license.txt and notice.txt which prevent some(?) ClassLoaders from extracting
this archive.

Using java 1.5.0_10, Firefox 2.0.0.14 as well as Iexplore 7

Bye, Matz


-- 
Configure bugmail: https://issues.apache.org/bugzilla/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
You are the assignee for the bug.

Re: Switching to Java 1.5

[Jess Holle]

I can't speak for the broader market but for my usages anything prior to 
Java 5 is "dead wood" and of no interest.


As of October of this year anything prior to Java 5 will be officially 
unsupported by Sun except where you have a paid support contract with 
them (including that for Solaris).  Add to that the fact that Java 1.4 
is so limiting for so many things and Java 5 is supported on even the 
most odd ball platforms (except Java ME, but I don't see FOP on ME...)


The Web Maestro wrote:

+1 from me on a new poll for discussion.

On Thu, Jun 5, 2008 at 11:56 AM, Jeremias Maerki <[EMAIL PROTECTED]> wrote:
  

+1 to being cautious about dropping support for Java 1.4 without
consulting the user base first, i.e. +1 for another user poll, though I
wouldn't do it before October.
+1 to putting the users' desires above the developers' desires.
+1 to moving to Java 1.5 when the time is right.
-0.5 (no veto) to moving to Java 1.5 before Oct 2008.
+1 to making experiments with Retroweaver (but please not in Trunk).

On 05.06.2008 17:46:07 Vincent Hennebert wrote:


Hi Guys,

I would like to raise this topic again: what about switching to Java 1.5
as a minimum requirement?

The End of Life transition period for Java 1.4 will end on the 30th of
October 2008 [1]. The next version of FOP (after 0.95) will probably not
have been released by this time, so we could start using 1.5 features in
the Trunk.

[1] http://java.sun.com/j2se/1.4.2/download.html

I don't particularly expect any disagreement from a developer point of
vue (who doesn't want to use 1.5 features?), so in the end this will
probably depend on the users' reactions, but I thought I'd ask for
opinions here first.

According to the poll Jeremias made in October 2007 [2], only 14.3% of
the users would think it's a bad idea to switch to 1.5. A year later the
percentage will probably have further decreased.

[2] http://wiki.apache.org/xmlgraphics/UserPollOct2007

I guess a new poll will still be necessary. Or we could base it on lazy
consensus: "If you still want Java 1.4 compatibility, speak up now!".

Anyway, even if 1.4 compatibility is still considered to be required,
there are tools to convert 1.5 code into 1.4 compatible one. I'm mainly
thinking of Retroweaver:
http://retroweaver.sourceforge.net/
It's BSD licensed, so IIC there wouldn't be any problem to distribute it
with FOP. Obviously it would be an (optional) compile-time dependency
only. I haven't personally tested it, but I'm told it's working pretty
well and it seems to be well maintained. Of course I'd volunteer to
introduce it into the build system and see how it works. FWIW, it's
based on the ASM library, that I've had the opportunity to play with
a few years ago, and what I can say is that it's a really nice, strong,
lightweight, easy to use library for manipulating class files.
http://asm.objectweb.org/

Obviously we wouldn't switch everything to 1.5 immediately. We would do
it progressively, when fixing bugs or implementing new features. So it
should be easy to check that the conversion is working properly by
running the testsuite on a 1.4 jvm, before every commit. Also, we could
restrain ourselves to features that are directly translatable to 1.4:
generics, enhanced for loop, autoboxing/unboxing. Most of all we could
stick to using methods from the Java standard library that are also
available in the 1.4 version (and, for instance, not use the new
concurrency package for now).

Just having the possibility to use generics would give us tremendous
benefits: simpler, cleaner, safer code, more easily understandable, more
easily maintainable, etc. I can't wait anymore to use those features.

So, WDYT?
Thanks,
Vincent


--
Vincent HennebertAnyware Technologies
http://people.apache.org/~vhennebert http://www.anyware-tech.com
Apache FOP Committer FOP Development/Consulting
  



Jeremias Maerki







  

Re: Switching to Java 1.5

[The Web Maestro]

+1 from me on a new poll for discussion.

On Thu, Jun 5, 2008 at 11:56 AM, Jeremias Maerki <[EMAIL PROTECTED]> wrote:
> +1 to being cautious about dropping support for Java 1.4 without
> consulting the user base first, i.e. +1 for another user poll, though I
> wouldn't do it before October.
> +1 to putting the users' desires above the developers' desires.
> +1 to moving to Java 1.5 when the time is right.
> -0.5 (no veto) to moving to Java 1.5 before Oct 2008.
> +1 to making experiments with Retroweaver (but please not in Trunk).
>
> On 05.06.2008 17:46:07 Vincent Hennebert wrote:
>> Hi Guys,
>>
>> I would like to raise this topic again: what about switching to Java 1.5
>> as a minimum requirement?
>>
>> The End of Life transition period for Java 1.4 will end on the 30th of
>> October 2008 [1]. The next version of FOP (after 0.95) will probably not
>> have been released by this time, so we could start using 1.5 features in
>> the Trunk.
>>
>> [1] http://java.sun.com/j2se/1.4.2/download.html
>>
>> I don't particularly expect any disagreement from a developer point of
>> vue (who doesn't want to use 1.5 features?), so in the end this will
>> probably depend on the users' reactions, but I thought I'd ask for
>> opinions here first.
>>
>> According to the poll Jeremias made in October 2007 [2], only 14.3% of
>> the users would think it's a bad idea to switch to 1.5. A year later the
>> percentage will probably have further decreased.
>>
>> [2] http://wiki.apache.org/xmlgraphics/UserPollOct2007
>>
>> I guess a new poll will still be necessary. Or we could base it on lazy
>> consensus: "If you still want Java 1.4 compatibility, speak up now!".
>>
>> Anyway, even if 1.4 compatibility is still considered to be required,
>> there are tools to convert 1.5 code into 1.4 compatible one. I'm mainly
>> thinking of Retroweaver:
>> http://retroweaver.sourceforge.net/
>> It's BSD licensed, so IIC there wouldn't be any problem to distribute it
>> with FOP. Obviously it would be an (optional) compile-time dependency
>> only. I haven't personally tested it, but I'm told it's working pretty
>> well and it seems to be well maintained. Of course I'd volunteer to
>> introduce it into the build system and see how it works. FWIW, it's
>> based on the ASM library, that I've had the opportunity to play with
>> a few years ago, and what I can say is that it's a really nice, strong,
>> lightweight, easy to use library for manipulating class files.
>> http://asm.objectweb.org/
>>
>> Obviously we wouldn't switch everything to 1.5 immediately. We would do
>> it progressively, when fixing bugs or implementing new features. So it
>> should be easy to check that the conversion is working properly by
>> running the testsuite on a 1.4 jvm, before every commit. Also, we could
>> restrain ourselves to features that are directly translatable to 1.4:
>> generics, enhanced for loop, autoboxing/unboxing. Most of all we could
>> stick to using methods from the Java standard library that are also
>> available in the 1.4 version (and, for instance, not use the new
>> concurrency package for now).
>>
>> Just having the possibility to use generics would give us tremendous
>> benefits: simpler, cleaner, safer code, more easily understandable, more
>> easily maintainable, etc. I can't wait anymore to use those features.
>>
>> So, WDYT?
>> Thanks,
>> Vincent
>>
>>
>> --
>> Vincent HennebertAnyware Technologies
>> http://people.apache.org/~vhennebert http://www.anyware-tech.com
>> Apache FOP Committer FOP Development/Consulting
>
>
>
>
> Jeremias Maerki
>
>



-- 
Regards,

The Web Maestro
-- 
<[EMAIL PROTECTED]> - 
My religion is simple. My religion is kindness.
- HH The 14th Dalai Lama of Tibet

Re: Switching to Java 1.5

[Chris Bowditch]

Vincent Hennebert wrote:


Hi Guys,

I would like to raise this topic again: what about switching to Java 1.5
as a minimum requirement?


Hi Vincent,

I'm happy to allow the use of generics in trunk code if retroweaver is 
used to maintain Java 1.4 support. I don't think the time is right to 
remove Java 1.4 compatibility altogether. Only a few weeks ago there 
were complaints on fop-user that the latest version couldn't be used 
because they were stuck on 1.3.




The End of Life transition period for Java 1.4 will end on the 30th of
October 2008 [1]. The next version of FOP (after 0.95) will probably not
have been released by this time, so we could start using 1.5 features in
the Trunk.

[1] http://java.sun.com/j2se/1.4.2/download.html

I don’t particularly expect any disagreement from a developer point of
vue (who doesn’t want to use 1.5 features?), so in the end this will
probably depend on the users’ reactions, but I thought I’d ask for
opinions here first.

According to the poll Jeremias made in October 2007 [2], only 14.3% of
the users would think it’s a bad idea to switch to 1.5. A year later the
percentage will probably have further decreased.


14.3% is a big percentage of a user base to cut off. Even if its fallen 
to 5% thats still unacceptable in my opinion. I want to see FOP getting 
a bigger user base so the developer base increases.


[2] http://wiki.apache.org/xmlgraphics/UserPollOct2007

I guess a new poll will still be necessary. Or we could base it on lazy
consensus: “If you still want Java 1.4 compatibility, speak up now!”.


+1 for a new Poll.



Chris

Re: StaticContentLM breaks its content?

[Andreas Delmelle]

On Jun 5, 2008, at 13:27, Vincent Hennebert wrote:


Does anyone know why does StaticContentLM implement its own breaker
(StaticContentBreaker) and breaks its content using the
PageBreakingAlgorithm? AFAIK descendants of a static-content  
element are

not supposed to be broken over several pages.


I can't say for sure, since I did not implement it, but if I were to  
guess...


The main algorithm that is associated to the PageBreaker, serves to  
compute breaks in the flow content. The 'parts' produced there don't  
really correspond to pages, but to body-regions (and footnotes; in  
the future most likely also before- and after-floats). Static- 
contents do not play an active role here. We're only creating a sort  
of sub-pages for the side-regions after reaching each effective page- 
break in the flow. The legal breaks in the static-content itself are  
apparently only computed provisionally. In  
StaticContentBreaker.doPhase3(), we check whether the algorithm  
produced more than one part to see if there is overflow. Following  
that, the computed breaks are removed from the element list.


Reading that again, it does seem a /bit/ weird... Why even bother to  
compute the breaks if we just throw them away afterwards? I may be  
missing something.


The main reasons for which there seems to be a separate Breaker:
- to perform/mimic those parts that are handled by PageBreaker for  
the flow-descendants
- to keep the associated BreakingAlgorithm and its results/state  
completely isolated from what happens in PageBreaker


Note that there is no direct link between PageBreaker and  
StaticContentLayoutManager (apart from inserting one for the footnote- 
separator, but that's a special case). For regular static-contents,  
the creation of the LMs is triggered upon finishing a page.  
(PageSequenceLayoutManager.finishPage())


Note also: even if an identical static-content, without any dynamic  
content --retrieve-marker-- is used for all pages, currently we still  
recreate the LM-tree and redo the layout for each page. This could be  
improved for the most general use-cases IMO by holding a reference to  
the created StaticContentLMs. If we have already used the simple-page- 
master for a preceding page, we could recycle the LMs for its static- 
contents; if there are no retrieve-markers, all we'd really need to  
perform multiple times is add the areas.




Andreas

Re: StaticContentLM breaks its content?

[Jeremias Maerki]

It's right that the descendants of static-content should not be broken,
but using the breaker allows to make use of the stretch/shrink
functionality (min/opt/max stuff) without having to write extra
duplicate code just for static content.

On 05.06.2008 13:27:36 Vincent Hennebert wrote:
> Does anyone know why does StaticContentLM implement its own breaker
> (StaticContentBreaker) and breaks its content using the
> PageBreakingAlgorithm? AFAIK descendants of a static-content element are
> not supposed to be broken over several pages.


Jeremias Maerki

Re: Switching to Java 1.5

[Jeremias Maerki]

+1 to being cautious about dropping support for Java 1.4 without
consulting the user base first, i.e. +1 for another user poll, though I
wouldn't do it before October.
+1 to putting the users' desires above the developers' desires.
+1 to moving to Java 1.5 when the time is right.
-0.5 (no veto) to moving to Java 1.5 before Oct 2008.
+1 to making experiments with Retroweaver (but please not in Trunk).

On 05.06.2008 17:46:07 Vincent Hennebert wrote:
> Hi Guys,
> 
> I would like to raise this topic again: what about switching to Java 1.5
> as a minimum requirement?
> 
> The End of Life transition period for Java 1.4 will end on the 30th of
> October 2008 [1]. The next version of FOP (after 0.95) will probably not
> have been released by this time, so we could start using 1.5 features in
> the Trunk.
> 
> [1] http://java.sun.com/j2se/1.4.2/download.html
> 
> I don’t particularly expect any disagreement from a developer point of
> vue (who doesn’t want to use 1.5 features?), so in the end this will
> probably depend on the users’ reactions, but I thought I’d ask for
> opinions here first.
> 
> According to the poll Jeremias made in October 2007 [2], only 14.3% of
> the users would think it’s a bad idea to switch to 1.5. A year later the
> percentage will probably have further decreased.
> 
> [2] http://wiki.apache.org/xmlgraphics/UserPollOct2007
> 
> I guess a new poll will still be necessary. Or we could base it on lazy
> consensus: “If you still want Java 1.4 compatibility, speak up now!”.
> 
> Anyway, even if 1.4 compatibility is still considered to be required,
> there are tools to convert 1.5 code into 1.4 compatible one. I’m mainly
> thinking of Retroweaver:
> http://retroweaver.sourceforge.net/
> It’s BSD licensed, so IIC there wouldn’t be any problem to distribute it
> with FOP. Obviously it would be an (optional) compile-time dependency
> only. I haven’t personally tested it, but I’m told it’s working pretty
> well and it seems to be well maintained. Of course I’d volunteer to
> introduce it into the build system and see how it works. FWIW, it’s
> based on the ASM library, that I’ve had the opportunity to play with
> a few years ago, and what I can say is that it’s a really nice, strong,
> lightweight, easy to use library for manipulating class files.
> http://asm.objectweb.org/
> 
> Obviously we wouldn’t switch everything to 1.5 immediately. We would do
> it progressively, when fixing bugs or implementing new features. So it
> should be easy to check that the conversion is working properly by
> running the testsuite on a 1.4 jvm, before every commit. Also, we could
> restrain ourselves to features that are directly translatable to 1.4:
> generics, enhanced for loop, autoboxing/unboxing. Most of all we could
> stick to using methods from the Java standard library that are also
> available in the 1.4 version (and, for instance, not use the new
> concurrency package for now).
> 
> Just having the possibility to use generics would give us tremendous
> benefits: simpler, cleaner, safer code, more easily understandable, more
> easily maintainable, etc. I can’t wait anymore to use those features.
> 
> So, WDYT?
> Thanks,
> Vincent
> 
> 
> -- 
> Vincent HennebertAnyware Technologies
> http://people.apache.org/~vhennebert http://www.anyware-tech.com
> Apache FOP Committer FOP Development/Consulting




Jeremias Maerki

Re: Switching to Java 1.5

[Max Berger]

Dear  Fop Devs,

I use retrotranslator for another project which has to run on specific  
version of scientfic Linux, where only Java 1.4 is installed.


There are two steps for using retrotranslator:
- Use NO 1.5 classpath features, just generics: Works very well with  
retrotranslator
- Use other 1.5 classpath features: Warning: AutoBoxing is part of  
this, since it uses the new Integer.valueOf() methods, which are not  
in 1.4. In this case, Fop would have to be distributed with the  
retrotranslator-runtime, which is 300kb


Retrotranlator-runtime contains many backports for common librarys,  
such as java.util.concurrent.


One thing is does not support (which made it unusable for other  
projects, such as JEuclid is the new high-plane unicode support in  
java 1.5. This would also be VERY interesting for fop, and i'd be a  
pitty not to use it).


Retroweaver and retrotranslator both provide similar functionality. I  
just chose retrotranslator because there is a maven plugin :)


I think in the long term this would be a good strategy for a soft move  
to 1.5, but I would like to ensure fop 0.96 works with 1.4


+1

Max

Am 05.06.2008 um 18:32 schrieb Adrian Cumiskey:

I would imagine that the availability of binary 1.4 compatibility  
should be enough for most users.


I don't see how there should be any problems so long as we continue  
to try and use the Java 1.4 libraries and the generics features of  
1.5.  I have tested out Retroweaver briefly in the past and it  
seemed to work well, but it would interesting to hear from anyone  
who has any hands on experience with using it.


+1 from me.

Adrian.

Vincent Hennebert wrote:

Hi Guys,
I would like to raise this topic again: what about switching to  
Java 1.5

as a minimum requirement?
The End of Life transition period for Java 1.4 will end on the 30th  
of
October 2008 [1]. The next version of FOP (after 0.95) will  
probably not
have been released by this time, so we could start using 1.5  
features in

the Trunk.
[1] http://java.sun.com/j2se/1.4.2/download.html
I don’t particularly expect any disagreement from a developer point  
of

vue (who doesn’t want to use 1.5 features?), so in the end this will
probably depend on the users’ reactions, but I thought I’d ask for
opinions here first.
According to the poll Jeremias made in October 2007 [2], only 14.3%  
of
the users would think it’s a bad idea to switch to 1.5. A year  
later the

percentage will probably have further decreased.
[2] http://wiki.apache.org/xmlgraphics/UserPollOct2007
I guess a new poll will still be necessary. Or we could base it on  
lazy

consensus: “If you still want Java 1.4 compatibility, speak up now!”.
Anyway, even if 1.4 compatibility is still considered to be required,
there are tools to convert 1.5 code into 1.4 compatible one. I’m  
mainly

thinking of Retroweaver:
http://retroweaver.sourceforge.net/
It’s BSD licensed, so IIC there wouldn’t be any problem to  
distribute it

with FOP. Obviously it would be an (optional) compile-time dependency
only. I haven’t personally tested it, but I’m told it’s working  
pretty

well and it seems to be well maintained. Of course I’d volunteer to
introduce it into the build system and see how it works. FWIW, it’s
based on the ASM library, that I’ve had the opportunity to play with
a few years ago, and what I can say is that it’s a really nice,  
strong,

lightweight, easy to use library for manipulating class files.
http://asm.objectweb.org/
Obviously we wouldn’t switch everything to 1.5 immediately. We  
would do
it progressively, when fixing bugs or implementing new features. So  
it

should be easy to check that the conversion is working properly by
running the testsuite on a 1.4 jvm, before every commit. Also, we  
could

restrain ourselves to features that are directly translatable to 1.4:
generics, enhanced for loop, autoboxing/unboxing. Most of all we  
could

stick to using methods from the Java standard library that are also
available in the 1.4 version (and, for instance, not use the new
concurrency package for now).
Just having the possibility to use generics would give us tremendous
benefits: simpler, cleaner, safer code, more easily understandable,  
more

easily maintainable, etc. I can’t wait anymore to use those features.
So, WDYT?
Thanks,
Vincent

Re: Switching to Java 1.5

[Andreas Delmelle]

On Jun 5, 2008, at 17:46, Vincent Hennebert wrote:


Hi Guys,

I would like to raise this topic again: what about switching to  
Java 1.5

as a minimum requirement?


No objection from me. +1 on moving forward with this in the trunk.


Andreas

Re: Switching to Java 1.5

[Adrian Cumiskey]

I would imagine that the availability of binary 1.4 compatibility should be 
enough for most users.

I don't see how there should be any problems so long as we continue to try and use the Java 1.4 
libraries and the generics features of 1.5.  I have tested out Retroweaver briefly in the past and 
it seemed to work well, but it would interesting to hear from anyone who has any hands on experience 
with using it.


+1 from me.

Adrian.

Vincent Hennebert wrote:

Hi Guys,

I would like to raise this topic again: what about switching to Java 1.5
as a minimum requirement?

The End of Life transition period for Java 1.4 will end on the 30th of
October 2008 [1]. The next version of FOP (after 0.95) will probably not
have been released by this time, so we could start using 1.5 features in
the Trunk.

[1] http://java.sun.com/j2se/1.4.2/download.html

I don’t particularly expect any disagreement from a developer point of
vue (who doesn’t want to use 1.5 features?), so in the end this will
probably depend on the users’ reactions, but I thought I’d ask for
opinions here first.

According to the poll Jeremias made in October 2007 [2], only 14.3% of
the users would think it’s a bad idea to switch to 1.5. A year later the
percentage will probably have further decreased.

[2] http://wiki.apache.org/xmlgraphics/UserPollOct2007

I guess a new poll will still be necessary. Or we could base it on lazy
consensus: “If you still want Java 1.4 compatibility, speak up now!”.

Anyway, even if 1.4 compatibility is still considered to be required,
there are tools to convert 1.5 code into 1.4 compatible one. I’m mainly
thinking of Retroweaver:
http://retroweaver.sourceforge.net/
It’s BSD licensed, so IIC there wouldn’t be any problem to distribute it
with FOP. Obviously it would be an (optional) compile-time dependency
only. I haven’t personally tested it, but I’m told it’s working pretty
well and it seems to be well maintained. Of course I’d volunteer to
introduce it into the build system and see how it works. FWIW, it’s
based on the ASM library, that I’ve had the opportunity to play with
a few years ago, and what I can say is that it’s a really nice, strong,
lightweight, easy to use library for manipulating class files.
http://asm.objectweb.org/

Obviously we wouldn’t switch everything to 1.5 immediately. We would do
it progressively, when fixing bugs or implementing new features. So it
should be easy to check that the conversion is working properly by
running the testsuite on a 1.4 jvm, before every commit. Also, we could
restrain ourselves to features that are directly translatable to 1.4:
generics, enhanced for loop, autoboxing/unboxing. Most of all we could
stick to using methods from the Java standard library that are also
available in the 1.4 version (and, for instance, not use the new
concurrency package for now).

Just having the possibility to use generics would give us tremendous
benefits: simpler, cleaner, safer code, more easily understandable, more
easily maintainable, etc. I can’t wait anymore to use those features.

So, WDYT?
Thanks,
Vincent

Switching to Java 1.5

[Vincent Hennebert]

Hi Guys,

I would like to raise this topic again: what about switching to Java 1.5
as a minimum requirement?

The End of Life transition period for Java 1.4 will end on the 30th of
October 2008 [1]. The next version of FOP (after 0.95) will probably not
have been released by this time, so we could start using 1.5 features in
the Trunk.

[1] http://java.sun.com/j2se/1.4.2/download.html

I don’t particularly expect any disagreement from a developer point of
vue (who doesn’t want to use 1.5 features?), so in the end this will
probably depend on the users’ reactions, but I thought I’d ask for
opinions here first.

According to the poll Jeremias made in October 2007 [2], only 14.3% of
the users would think it’s a bad idea to switch to 1.5. A year later the
percentage will probably have further decreased.

[2] http://wiki.apache.org/xmlgraphics/UserPollOct2007

I guess a new poll will still be necessary. Or we could base it on lazy
consensus: “If you still want Java 1.4 compatibility, speak up now!”.

Anyway, even if 1.4 compatibility is still considered to be required,
there are tools to convert 1.5 code into 1.4 compatible one. I’m mainly
thinking of Retroweaver:
http://retroweaver.sourceforge.net/
It’s BSD licensed, so IIC there wouldn’t be any problem to distribute it
with FOP. Obviously it would be an (optional) compile-time dependency
only. I haven’t personally tested it, but I’m told it’s working pretty
well and it seems to be well maintained. Of course I’d volunteer to
introduce it into the build system and see how it works. FWIW, it’s
based on the ASM library, that I’ve had the opportunity to play with
a few years ago, and what I can say is that it’s a really nice, strong,
lightweight, easy to use library for manipulating class files.
http://asm.objectweb.org/

Obviously we wouldn’t switch everything to 1.5 immediately. We would do
it progressively, when fixing bugs or implementing new features. So it
should be easy to check that the conversion is working properly by
running the testsuite on a 1.4 jvm, before every commit. Also, we could
restrain ourselves to features that are directly translatable to 1.4:
generics, enhanced for loop, autoboxing/unboxing. Most of all we could
stick to using methods from the Java standard library that are also
available in the 1.4 version (and, for instance, not use the new
concurrency package for now).

Just having the possibility to use generics would give us tremendous
benefits: simpler, cleaner, safer code, more easily understandable, more
easily maintainable, etc. I can’t wait anymore to use those features.

So, WDYT?
Thanks,
Vincent


-- 
Vincent HennebertAnyware Technologies
http://people.apache.org/~vhennebert http://www.anyware-tech.com
Apache FOP Committer FOP Development/Consulting

StaticContentLM breaks its content?

[Vincent Hennebert]

Hi,

Does anyone know why does StaticContentLM implement its own breaker
(StaticContentBreaker) and breaks its content using the
PageBreakingAlgorithm? AFAIK descendants of a static-content element are
not supposed to be broken over several pages.

Thanks,
Vincent


-- 
Vincent HennebertAnyware Technologies
http://people.apache.org/~vhennebert http://www.anyware-tech.com
Apache FOP Committer FOP Development/Consulting

DO NOT REPLY [Bug 45134] FOP unwarranted page split on table with numbre-rows-spanned

[bugzilla]

https://issues.apache.org/bugzilla/show_bug.cgi?id=45134


Vincent Hennebert <[EMAIL PROTECTED]> changed:

   What|Removed |Added

 Status|NEW |ASSIGNED




--- Comment #1 from Vincent Hennebert <[EMAIL PROTECTED]>  2008-06-05 03:56:23 
PST ---
Hi,

Thanks for the bug report and the clean testcase. It's probably a duplicate of
bug #45047 but I need to further investigate to be sure. Basically the fixed
heights set on table-row elements are creating trouble. If you remove them you
get the same result without the spurious page.

I can imagine the stepping effect you want to achieve by setting heights on the
table rows. I guess you're not happy with the result FOP currently produces
(without regards to the spurious page)? :-\

Vincent


-- 
Configure bugmail: https://issues.apache.org/bugzilla/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
You are the assignee for the bug.

DO NOT REPLY [Bug 43824] RTF doesn't support proportional column widths

[bugzilla]

https://issues.apache.org/bugzilla/show_bug.cgi?id=43824





--- Comment #5 from Jeremias Maerki <[EMAIL PROTECTED]>  2008-06-05 02:53:39 
PST ---
I can probably tell you more tomorrow. Nothing's fixed, yet. I expect them to
want to contribute this back to FOP at some point and put it under the ALv2.
One of the problems is the lack of an ODF library with a compatible license.
All Java ODF libraries I know of are published under the LGPL which complicates
things for FOP. Timeframe: rather soon (<2 months probably).


-- 
Configure bugmail: https://issues.apache.org/bugzilla/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
You are the assignee for the bug.

DO NOT REPLY [Bug 43824] RTF doesn't support proportional column widths

[bugzilla]

https://issues.apache.org/bugzilla/show_bug.cgi?id=43824





--- Comment #4 from Antti Karanta <[EMAIL PROTECTED]>  2008-06-05 02:21:06 PST 
---

(In reply to comment #3)

> [1] Incidentally, I'm going to a client today to coach them for implementing
> ODF output support.

  This is very interesting. Is it going to be in their use only or is it going
to be published into public domain? If so, are there any time estimates when
this might happen?


-- 
Configure bugmail: https://issues.apache.org/bugzilla/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
You are the assignee for the bug.

DO NOT REPLY [Bug 45134] New: FOP unwarranted page split on table with numbre-rows-spanned

[bugzilla]

https://issues.apache.org/bugzilla/show_bug.cgi?id=45134

   Summary: FOP unwarranted page split on table with numbre-rows-
spanned
   Product: Fop
   Version: 1.0dev
  Platform: PC
OS/Version: Windows 2000
Status: NEW
  Severity: normal
  Priority: P2
 Component: page-master/layout
AssignedTo: fop-dev@xmlgraphics.apache.org
ReportedBy: [EMAIL PROTECTED]


Created an attachment (id=22077)
 --> (https://issues.apache.org/bugzilla/attachment.cgi?id=22077)
FO to reproduce issue.

Hi

I have a use-case where three successive tables with number-rows-spanned that
should fit in one page are actually split across two pages .
The same three successive tables with NO number-rows-spanned fit in one page.

See inclused FO.

Thanks.


-- 
Configure bugmail: https://issues.apache.org/bugzilla/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
You are the assignee for the bug.

DO NOT REPLY [Bug 43606] RTF does not support page-number-citation / page-number-citation-last

[bugzilla]

https://issues.apache.org/bugzilla/show_bug.cgi?id=43606





--- Comment #3 from Jeremias Maerki <[EMAIL PROTECTED]>  2008-06-05 01:28:37 
PST ---
Maximilan, see http://markmail.org/message/ikryur27g6joxqk6 for hints.


-- 
Configure bugmail: https://issues.apache.org/bugzilla/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
You are the assignee for the bug.

DO NOT REPLY [Bug 43824] RTF doesn't support proportional column widths

[bugzilla]

https://issues.apache.org/bugzilla/show_bug.cgi?id=43824





--- Comment #3 from Jeremias Maerki <[EMAIL PROTECTED]>  2008-06-05 01:26:09 
PST ---
Maximilian, this goes in the direction of supporting percentages in RTF output.
This is mostly done in the layout managers for the page-oriented output
formats, so that means it has to be recreated for the flow-based output
formats. I assume some kind of tracking mechanism is necessary to have the base
values for percentage-based calculations (and proportional-column-width() for
that matter). If done properly this might even be useful for the layout
managers at some point. Anyway, take a look at
org.apache.fop.datatypes.PercentBaseContext. This interface is implemented by
AbstractBaseLayoutManager. In the case of RTF, this should probably be a
separate class (i.e. that tracking mechanism I mentioned above) so it can be
reused by other/future flow-based output formats [1]. For the table columns,
take a look at org.apache.fop.layoutmgr.table.TableLayoutManager which contains
code for handling the proportional-column-width() approach. Something similar
has to be done for the flow-based formats.

[1] Incidentally, I'm going to a client today to coach them for implementing
ODF output support.


-- 
Configure bugmail: https://issues.apache.org/bugzilla/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
You are the assignee for the bug.

DO NOT REPLY [Bug 43825] RTF Renderer doesn't support fo:leader

[bugzilla]

https://issues.apache.org/bugzilla/show_bug.cgi?id=43825





--- Comment #3 from Jeremias Maerki <[EMAIL PROTECTED]>  2008-06-05 01:17:54 
PST ---
Maximilan, as Chris already noted, it is not possible to fully map fo:leader
into RTF. Some approximation might be possible. The place to implement this is
org.apache.fop.render.rtf.RTFHandler.leader(Leader). You can find various test
cases for leader in test/layoutengine/standard-testcases/leader-*.xml (use with
../testcase2fo.xsl). How exactly fo:leader should be mapped to RTF, I haven't
investigated. Thanks for volunteering!


-- 
Configure bugmail: https://issues.apache.org/bugzilla/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
You are the assignee for the bug.