+1 for merging it to trunk.
That said, I'm a little puzzled with the release process.
In my mind, a RC should come before a production release, freezing all features.
Only bugfix should be permitted on RC.
Adding new feature to RC2 is a precedent that allows to add a new
feature after each RC, witch need to release a new... RC, etc.
I humbly suggest that the release process start with a 1.1 branch,
from witch RCx and final release will be tagged, that should allow to
continue merging branches onto trunk without any interaction on branch
2012/7/2 Chris Bowditch <email@example.com>:
--> On 26/06/2012 15:39, mehdi houshmand wrote:
>> Sorry, added "[VOTE]" to subject line... My bad
> +1 from me. Good work Mehdi and Pete.
>> On 26 June 2012 15:38, mehdi houshmand <firstname.lastname@example.org
>> <mailto:email@example.com>> wrote:
>> Hi All,
>> I think we've got to the stage in the URI unification branch where
>> it's ready to be merged into trunk (not into 1.1RC1). I know there
>> have been proponents against the inclusion of this feature and/or
>> those who are concerned the wider implications as it means FOP has
>> fewer contingency methods when attempting file access. I'll try
>> and explain how we've addressed those concerns as well as some of
>> the code improvements we've made.
>> - Syntactic URI fall-back mechanisms - if a URI is syntactically
>> erroneous i.e. contains white-space, "\" instead of "/", we do
>> some validation on to mitigate some of the common mistakes.
>> However, we don't allow for falling back to 'new File(".")' or
>> "new URL(...).openStream()" since these can obviously cause
>> clashes in a highly parallelised multi-tenant environment.
>> - Single FOP conf parse - Previously the renderer specific regions
>> of the FOP conf was being parsed on every run. This is costly to
>> performance for the obvious reason, but as well as this, it meant
>> that font auto-detection was having to be executed on every run.
>> The font-caching was created to mitigate some of those performance
>> costs, however, caching the FOP conf makes much more sense. It
>> means we can get rid of the font-caching and don't have to to
>> worry about performance but it also allowed to do a lot of clean
>> up in the configuration packages. The renderer specific config is
>> also lazy loaded such that it is only parsed when the respective
>> renderer is invoked, mitigating the one-off cost of parsing that
>> - The environment profile - We've created an environment profile
>> that abstracts the system in which FOP is invoked. This allows us
>> to programmatically enforce restrictions to, for example,
>> font-caching and auto-detection since users may want to control
>> this behaviour for any number of reasons.
>> - Improved URI handling - because the URI resolution has been
>> unified to a couple of classes, the behaviour is much easier for
>> users to understand.
>> - Consistent base directories - We've tried to ensure that base
>> directories are consistent with FOP previously, the <base> and
>> <font-base> still work as previously.
>> There are however some outstanding TODOs that need to be
>> addressed, however, though they are important, they don't need to
>> be all merged in at the same time. I will be working on these and
>> keep the community updated:
>> - XGC and libraries - This is most likely the next project, we
>> need to do the same in the XGC project and look at some of FOPs
>> dependencies (Batik too!). The plan will be to move all the
>> resource resolver classes to XGC since that is the parent library
>> so that they can be used though out the XMLGraphics libraries.
>> - Improved MIME type resolution - currently FOP's file-type
>> (file-MIME-type) is performed in-situ using file-name endings.
>> This is, while working perfectly fine on a desktop environment,
>> would be less than desirable if file-names were just hashes or the
>> like from a virtual file-system. We need to give the user the
>> flexibility to define a file MIME type without forcing them to put
>> the file-ending in the URI.
>> - Default handling in some of the Configurators - We have improved
>> the mechanism that handles default values in the configuration as
>> well as config injected via RendererOptions (on the FOUserAgent)
>> and the FOP conf for PDF. However, time constraints haven't
>> allowed us to do the same for PS and AFP, which would be nice to
>> do. This isn't of utmost priority, but it would be nice to not
>> have the "if (x != null)" peppered around the source
>> Sorry for the long email, I just thought it'd be a good time to
>> expose some of the work we've been doing,
>> P.S. More information can be found wiki under the developers
>> section, it's currently down so I can't post a link.