Re: Building FOP Trunk with Any - BUILD FAILED

2008-07-12 Thread Andreas Delmelle

On Jul 11, 2008, at 13:22, Jeremias Maerki wrote:


Bonekrusher and I had an exchange off-list. He did a few tests for me
and my recent change didn't help either.

Basically, we established the following:
- He's also running WinXP
- He's running the same JDK as I do.


The /exact/ same one (identical build)?

Just asking, since I remember running across some issues/ 
inconsistencies in the way the java.net.URL and java.net.URI  
translate themselves to a String.
Maybe that's what's playing here... Is the warning about the  
deprecated File.toURL() maybe related and a hint?


As of Java 6, the recommended way is to use File.toURI().toURL().  
According to the API docs, File.toURL() does not automatically  
escape characters that are illegal in URLs. It is recommended that  
new code convert an abstract pathname into a URL by first converting  
it into a URI, via the toURI method, and then converting the URI into  
a URL via the URI.toURL method.


Makes you wonder why the implementation of toURL() then does not  
simply do that already... I assume this is for reasons of backward- 
compatibility, so as to not break any existing code that relies on  
that behavior (?)




Cheers

Andreas


Re: Building FOP Trunk with Any - BUILD FAILED

2008-07-12 Thread Jeremias Maerki
On 12.07.2008 11:56:23 Andreas Delmelle wrote:
 On Jul 11, 2008, at 13:22, Jeremias Maerki wrote:
 
  Bonekrusher and I had an exchange off-list. He did a few tests for me
  and my recent change didn't help either.
 
  Basically, we established the following:
  - He's also running WinXP
  - He's running the same JDK as I do.
 
 The /exact/ same one (identical build)?

Yes, Sun 1.6.0_04

 
 Just asking, since I remember running across some issues/ 
 inconsistencies in the way the java.net.URL and java.net.URI  
 translate themselves to a String.
 Maybe that's what's playing here... Is the warning about the  
 deprecated File.toURL() maybe related and a hint?

If it is in fact the file URL that's the problem, I'm pretty sure the
problem happens within Xalan as I'm passing in a StreamResult(File).

 As of Java 6, the recommended way is to use File.toURI().toURL().  
 According to the API docs, File.toURL() does not automatically  
 escape characters that are illegal in URLs. It is recommended that  
 new code convert an abstract pathname into a URL by first converting  
 it into a URI, via the toURI method, and then converting the URI into  
 a URL via the URI.toURL method.

I guess it makes sense to change all occurences now that we're on Java
1.4. I've changed the StreamSource(File) to
StreamSource(File.toURI().toURL().toExternalForm()) as a first
experiment. Bonekrusher can then retry on his machine.
http://svn.apache.org/viewvc?rev=676161view=rev

On my machine the following:
System.out.println(outputFile.toURI().toASCIIString());
System.out.println(outputFile.toURI().toString());
System.out.println(outputFile.toURI().toURL().toExternalForm());
System.out.println(outputFile.toURL().toExternalForm());
yielded the following results:
[eventResourceGenerator] 
file:/C:/Dev/FOP/main/xml-fop-temp/build/gensrc/org/apache/fop/events/event-model.xml
[eventResourceGenerator] 
file:/C:/Dev/FOP/main/xml-fop-temp/build/gensrc/org/apache/fop/events/event-model.xml
[eventResourceGenerator] 
file:/C:/Dev/FOP/main/xml-fop-temp/build/gensrc/org/apache/fop/events/event-model.xml
[eventResourceGenerator] 
file:/C:/Dev/FOP/main/xml-fop-temp/build/gensrc/org/apache/fop/events/event-model.xml

Just for reference, Bonekrusher got
file:\C:\fop_trunk\trunk\build\gensrc\org\apache\fop\events\event-model.xml
on his machine (see his first post).

 Makes you wonder why the implementation of toURL() then does not  
 simply do that already... I assume this is for reasons of backward- 
 compatibility, so as to not break any existing code that relies on  
 that behavior (?)

Probably.

 
 
 Cheers
 
 Andreas




Jeremias Maerki



Re: svn commit: r676161 - /xmlgraphics/fop/trunk/src/java/org/apache/fop/events/model/EventModel.java

2008-07-12 Thread Andreas Delmelle

On Jul 12, 2008, at 14:19, [EMAIL PROTECTED] wrote:


Author: jeremias
Date: Sat Jul 12 05:19:40 2008
New Revision: 676161

URL: http://svn.apache.org/viewvc?rev=676161view=rev
Log:
Attempt to fix a potential build problem.


FWIW, I've locally replaced all occurrences of File.toURL() in the  
codebase to File.toURI().toURL(). Once I've confirmed this breaks no  
tests, I'll commit the changes, so this is out of the way.


Going through the occurrences, I'm getting the impression that in  
some cases, we don't even really need the URL. The URI would do just  
fine if we don't need the functionality for opening a stream... Maybe  
in this particular case, passing through a URL could also be avoided  
(?) If the error is generated by the used StreamResult implementation  
calling File.toURL(), then something like:


Result res = new StreamResult(outputFile.toURI().toASCIIString());

would already be enough (?)


Andreas


Re: svn commit: r676161 - /xmlgraphics/fop/trunk/src/java/org/apache/fop/events/model/EventModel.java

2008-07-12 Thread Jeremias Maerki
On 12.07.2008 14:49:03 Andreas Delmelle wrote:
 On Jul 12, 2008, at 14:19, [EMAIL PROTECTED] wrote:
 
  Author: jeremias
  Date: Sat Jul 12 05:19:40 2008
  New Revision: 676161
 
  URL: http://svn.apache.org/viewvc?rev=676161view=rev
  Log:
  Attempt to fix a potential build problem.
 
 FWIW, I've locally replaced all occurrences of File.toURL() in the  
 codebase to File.toURI().toURL(). Once I've confirmed this breaks no  
 tests, I'll commit the changes, so this is out of the way.

Thanks a lot.

 Going through the occurrences, I'm getting the impression that in  
 some cases, we don't even really need the URL. The URI would do just  
 fine if we don't need the functionality for opening a stream... Maybe  
 in this particular case, passing through a URL could also be avoided  
 (?) If the error is generated by the used StreamResult implementation  
 calling File.toURL(), then something like:
 
 Result res = new StreamResult(outputFile.toURI().toASCIIString());
 
 would already be enough (?)

In most cases, yes. But there's really a difference between a URI and a
URL. But what's confusing is the following (the Javadocs for
StreamSource):

quote
public StreamSource(String systemId)
Construct a StreamSource from a URL.
Parameters:
systemId - Must be a String that conforms to the URI syntax.
/quote

URL and URI are both used here. But I think URL is the mandatory term
here. The other thing is URI Syntax which does not refer to URI
itself. Since a URL is a URI, but not all URIs are URLs, I believe your
example above is slightly incorrect.

Jeremias Maerki



Re: svn commit: r676161 - /xmlgraphics/fop/trunk/src/java/org/apache/fop/events/model/EventModel.java

2008-07-12 Thread Peter B. West

Jeremias Maerki wrote:

On 12.07.2008 14:49:03 Andreas Delmelle wrote:

On Jul 12, 2008, at 14:19, [EMAIL PROTECTED] wrote:


Author: jeremias
Date: Sat Jul 12 05:19:40 2008
New Revision: 676161

URL: http://svn.apache.org/viewvc?rev=676161view=rev
Log:
Attempt to fix a potential build problem.
FWIW, I've locally replaced all occurrences of File.toURL() in the  
codebase to File.toURI().toURL(). Once I've confirmed this breaks no  
tests, I'll commit the changes, so this is out of the way.


Thanks a lot.

Going through the occurrences, I'm getting the impression that in  
some cases, we don't even really need the URL. The URI would do just  
fine if we don't need the functionality for opening a stream... Maybe  
in this particular case, passing through a URL could also be avoided  
(?) If the error is generated by the used StreamResult implementation  
calling File.toURL(), then something like:


Result res = new StreamResult(outputFile.toURI().toASCIIString());

would already be enough (?)


In most cases, yes. But there's really a difference between a URI and a
URL. But what's confusing is the following (the Javadocs for
StreamSource):

quote
public StreamSource(String systemId)
Construct a StreamSource from a URL.
Parameters:
systemId - Must be a String that conforms to the URI syntax.
/quote

URL and URI are both used here. But I think URL is the mandatory term
here. The other thing is URI Syntax which does not refer to URI
itself. Since a URL is a URI, but not all URIs are URLs, I believe your
example above is slightly incorrect.

Jeremias Maerki


It's a SystemId. The class includes setSystemId(...) and 
setPublicId(...), so a URL looks right. One way to find out.


--
Peter B. West http://cv.pbw.id.au/
Folio http://defoe.sourceforge.net/folio/


Re: svn commit: r676161 - /xmlgraphics/fop/trunk/src/java/org/apache/fop/events/model/EventModel.java

2008-07-12 Thread Andreas Delmelle

On Jul 12, 2008, at 14:57, Jeremias Maerki wrote:


On 12.07.2008 14:49:03 Andreas Delmelle wrote:

Going through the occurrences, I'm getting the impression that in
some cases, we don't even really need the URL. The URI would do just
fine if we don't need the functionality for opening a stream... Maybe
in this particular case, passing through a URL could also be avoided
(?) If the error is generated by the used StreamResult implementation
calling File.toURL(), then something like:

Result res = new StreamResult(outputFile.toURI().toASCIIString());

would already be enough (?)


In most cases, yes. But there's really a difference between a URI  
and a

URL. But what's confusing is the following (the Javadocs for
StreamSource):

quote
public StreamSource(String systemId)
Construct a StreamSource from a URL.
Parameters:
systemId - Must be a String that conforms to the URI syntax.
/quote

URL and URI are both used here. But I think URL is the mandatory  
term

here. The other thing is URI Syntax which does not refer to URI
itself. Since a URL is a URI, but not all URIs are URLs, I believe  
your

example above is slightly incorrect.


Nice catch. For the moment, better to be safe than sorry. Indeed, a  
URI could also be something not referring to a file (or, better put:  
a valid input source for a transformation)
Strictly speaking, according to the above definition, the systemId is  
allowed to be a 'mailto:' (?) :-/


Sloppy editors... ;-)

Cheers

Andreas