Hi Chris/Glenn/Anyone else,
You say command-line options should override the fop.xconf values, which
makes sense. But should not-given command-line options override fop.xconf
values too? Bare with me here, there is sense in the folly of that
sentence. Ok, so let's take the example above, with
On Thu, Jul 5, 2012 at 12:41 AM, mehdi houshmand med1...@gmail.com wrote:
Hi Chris/Glenn/Anyone else,
You say command-line options should override the fop.xconf values, which
makes sense. But should not-given command-line options override fop.xconf
values too? Bare with me here, there is
Hi Vincent, FOP Dev,
On Wed, Jul 4, 2012 at 12:32 PM, Vincent Hennebert vhenneb...@gmail.com wrote:
snip/
And BTW, what is the recommended way to get a FopFactoryConfig? The
javadoc of buildConfig doesn’t say. I think it should.
The need to obtain an instance of a FopFactoryConfig
Ok, so I've made the CLI options override when set, and not override when
not set. I think that CommandLineOption class needs a little TLC, we can
use Commons CLI or some such library (
http://java-source.net/open-source/command-line). No point reinventing the
wheel.
On 5 July 2012 08:27, Glenn
On 3 July 2012 15:48, Vincent Hennebert vhenneb...@gmail.com wrote:
I had started to build up a list of questions and comments but didn’t
get round to finishing it in time. Anyway, here it is, hopefully it will
still provide valuable feedback. The most important items to address are
the
Just a few amendments:
- File.createTempFile(...) failed the unit tests and I didn't have time to
investigate why, this could be done in the future, though I'm not sure the
pros/cons of doing so.
- The method signature change getBaseURI - getBaseDirectoryURI wasn't
done. After speaking to PH, it
One thing I forgot to mention: this work deserves its entry in the
status.xml file, with importance set to ‘high’.
On 04/07/12 08:38, mehdi houshmand wrote:
On 3 July 2012 15:48, Vincent Hennebert wrote:
snip/
The new classes FopConfParser, FopFactoryBuilder and FopFactoryConfig
should be
On 4 July 2012 12:32, Vincent Hennebert vhenneb...@gmail.com wrote:
One thing I forgot to mention: this work deserves its entry in the
status.xml file, with importance set to ‘high’.
snip/
Let me insist on that one. The inconsistency is actually introduced by
Fop classes. Before the merge
On Wed, Jul 4, 2012 at 9:25 AM, mehdi houshmand med1...@gmail.com wrote:
On 4 July 2012 12:32, Vincent Hennebert vhenneb...@gmail.com wrote:
There does seem to be a regression. Before, the FopFactoryConfigurator
object was getting the strict-validation element from the config file
and
On 04/07/2012 17:15, Glenn Adams wrote:
On Wed, Jul 4, 2012 at 9:25 AM, mehdi houshmand med1...@gmail.com
mailto:med1...@gmail.com wrote:
On 4 July 2012 12:32, Vincent Hennebert vhenneb...@gmail.com
mailto:vhenneb...@gmail.com wrote:
There does seem to be a regression.
I'm a bit confused... Am I correct that this [VOTE] relates to merging
the Temp_URI_Unification to fop/trunk and not to FOP-1.1rc*? If so,
then +1 and if not then +0 since I don't quite understand... (not
blocker, but not enough info for me to +1... ;-)
Kind regards,
Clay Leeds
--
I wouldn't worry Clay, I'm not sure I really know what this thread is about
any more either. Either way, it's been merged but thanks for your support.
The fix of this regression is easy, I'll fix it in the morning.
On 4 July 2012 18:32, The Web Maestro the.webmaes...@gmail.com wrote:
I'm a bit
Thanks! Happy Fourth (it's still the 4th even outside the U.S. ;-)!
Thanks for your efforts all!
My religion is simple. My religion is kindness.
- HH The Dalai Lama of Tibet
On Jul 4, 2012, at 11:35 AM, mehdi houshmand med1...@gmail.com wrote:
I wouldn't worry Clay, I'm not sure I really know
snip/
Let me insist on that one. The inconsistency is actually introduced by
Fop classes. Before the merge there were 14 classes having FOP in their
names, vs 6 having Fop. Also, the product name is FOP, not Fop, and that
should be reflected in the class names.
I still don't agree, it's
Thanks guys, that's 5 x +1 and no one in opposition. I'll merge in the
branch imminently and update the docs as appropriate
On 2 July 2012 14:40, Glenn Adams gl...@skynav.com wrote:
On Mon, Jul 2, 2012 at 7:25 AM, mehdi houshmand med1...@gmail.com wrote:
Ahh I see, ok, thanks Pascal. I think
I had started to build up a list of questions and comments but didn’t
get round to finishing it in time. Anyway, here it is, hopefully it will
still provide valuable feedback. The most important items to address are
the possible regression regarding strict FO validation and the public
API.
The
On 02/07/12 14:40, Glenn Adams wrote:
On Mon, Jul 2, 2012 at 7:25 AM, mehdi houshmand med1...@gmail.com wrote:
Ahh I see, ok, thanks Pascal. I think we got our wires crossed a little
there ;)
Glenn, my plan was to merge the URI-resolution stuff in tomorrow. If this
burdens you in some way,
+1
On Tue, Jun 26, 2012 at 3:39 PM, mehdi houshmand med1...@gmail.com wrote:
Sorry, added [VOTE] to subject line... My bad
On 26 June 2012 15:38, mehdi houshmand med1...@gmail.com wrote:
Hi All,
I think we've got to the stage in the URI unification branch where it's
ready to be merged
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.
Chris
On 26 June 2012 15:38, mehdi houshmand med1...@gmail.com
mailto:med1...@gmail.com wrote:
Hi All,
I think we've got to the stage in the URI
Hi,
+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
Hi Pascal,
I won't be merging this into anything other than trunk. Sorry, maybe I
should have made that more explicit.
Mehdi
On 2 July 2012 12:32, Pascal Sancho psancho@gmail.com wrote:
Hi,
+1 for merging it to trunk.
That said, I'm a little puzzled with the release process.
In my
Mehdi,
I speak about post 1.1RC1.
Your merge will be against the trunk.
What about the 1.1RC2 or 1.1 final?
In the current usage, *all* FOP releases are tagged directly from
trunk (via a branch that is only to set FOP version and lib
dependencies).
So, every further RC or final releases are
Sorry, an unwanted key stroke...
2012/7/2 Pascal Sancho psancho@gmail.com:
Mehdi,
I speak about post 1.1RC1.
Your merge will be against the trunk.
What about the 1.1RC2 or 1.1 final?
In the current usage, *all* FOP releases are tagged directly from
trunk (via a branch that is only to
Excuse my ignorance here, but why do any changes to trunk affect 1.1RC*?
The 1.1 branch has already been defined and voted upon, I don't see how any
changes to trunk would affect it? I'm not very familiar with the FOPs
releasing process so do excuse me.
Mehdi
On 2 July 2012 13:42, Pascal Sancho
Sorry Mehdi, I realize that I started a new discussion.
Merging your development branch onto the trunk is not what puzzled me.
This has to be done as this.
What I said is: currently there are concurrent enhancements and releases.
So, between the 1st RC and the final release there can be a lot of
Ahh I see, ok, thanks Pascal. I think we got our wires crossed a little
there ;)
Glenn, my plan was to merge the URI-resolution stuff in tomorrow. If this
burdens you in some way, could you let me know how and maybe we can come to
some resolution? As far as I can see, it shouldn't affect the
On Mon, Jul 2, 2012 at 7:25 AM, mehdi houshmand med1...@gmail.com wrote:
Ahh I see, ok, thanks Pascal. I think we got our wires crossed a little
there ;)
Glenn, my plan was to merge the URI-resolution stuff in tomorrow. If this
burdens you in some way, could you let me know how and maybe we
27 matches
Mail list logo
