Re: Preparation of Doxia 1.0-beta-1 release
On Dec 8, 2008, at 7:37 AM, Vincent Siveton wrote: 2008/12/8 Paul Spencer [EMAIL PROTECTED]: On Dec 8, 2008, at 7:17 AM, Vincent Siveton wrote: 2008/12/8 Lukas Theussl [EMAIL PROTECTED]: I just noticed that the fml module now takes ~5min to build instead of a few Same for xdoc module. secs for all other modules. There are some svn checkouts during testing, are those necessary? Does it mean you can't build doxia off-line? The tests are to perform XSD validations under our current documentation. Since we add new XSD files in this release, I think these tests are useful. About off-line build, we need to be sure that latest Maven doc is again valid (and BTW doxia needs external dependencies) Instead of svn co, we could link to relative doc path, ie from doxia-module-fml using ../../../plugins/maven-ant-plugin/src/site This approach has pros/cons like svn co. WDYT? Why are you not using a dependency? A svn co does not insure a reproduceable build. Using a separate dependency or a given test folder insures that the documentation is valid, right. But how to be sure that the *latest* doc is still valid under our xsd? Is it a reasonable test case? I am not sure the best way to insure the documentation is in sync. The snippet macro from a test case is one tool. The test cases can verify the XSD matches the doc. I say matches because it does not verify the documentation is in sync with the test case. Vincent Paul Spencer
Re: Preparation of Doxia 1.0-beta-1 release
2008/12/8 Paul Spencer [EMAIL PROTECTED]: On Dec 8, 2008, at 7:17 AM, Vincent Siveton wrote: 2008/12/8 Lukas Theussl [EMAIL PROTECTED]: I just noticed that the fml module now takes ~5min to build instead of a few Same for xdoc module. secs for all other modules. There are some svn checkouts during testing, are those necessary? Does it mean you can't build doxia off-line? The tests are to perform XSD validations under our current documentation. Since we add new XSD files in this release, I think these tests are useful. About off-line build, we need to be sure that latest Maven doc is again valid (and BTW doxia needs external dependencies) Instead of svn co, we could link to relative doc path, ie from doxia-module-fml using ../../../plugins/maven-ant-plugin/src/site This approach has pros/cons like svn co. WDYT? Why are you not using a dependency? A svn co does not insure a reproduceable build. Using a separate dependency or a given test folder insures that the documentation is valid, right. But how to be sure that the *latest* doc is still valid under our xsd? Is it a reasonable test case? Vincent Paul Spencer
Re: Preparation of Doxia 1.0-beta-1 release
On Dec 8, 2008, at 7:17 AM, Vincent Siveton wrote: 2008/12/8 Lukas Theussl [EMAIL PROTECTED]: I just noticed that the fml module now takes ~5min to build instead of a few Same for xdoc module. secs for all other modules. There are some svn checkouts during testing, are those necessary? Does it mean you can't build doxia off-line? The tests are to perform XSD validations under our current documentation. Since we add new XSD files in this release, I think these tests are useful. About off-line build, we need to be sure that latest Maven doc is again valid (and BTW doxia needs external dependencies) Instead of svn co, we could link to relative doc path, ie from doxia-module-fml using ../../../plugins/maven-ant-plugin/src/site This approach has pros/cons like svn co. WDYT? Why are you not using a dependency? A svn co does not insure a reproduceable build. Paul Spencer
Re: Preparation of Doxia 1.0-beta-1 release
2008/12/8 Lukas Theussl [EMAIL PROTECTED]: I just noticed that the fml module now takes ~5min to build instead of a few Same for xdoc module. secs for all other modules. There are some svn checkouts during testing, are those necessary? Does it mean you can't build doxia off-line? The tests are to perform XSD validations under our current documentation. Since we add new XSD files in this release, I think these tests are useful. About off-line build, we need to be sure that latest Maven doc is again valid (and BTW doxia needs external dependencies) Instead of svn co, we could link to relative doc path, ie from doxia-module-fml using ../../../plugins/maven-ant-plugin/src/site This approach has pros/cons like svn co. WDYT? Vincent -Lukas Vincent Siveton wrote: Hi guys, IMHO Doxia 1.0-beta-1 could be release soon, ideally for xmas! So, do you think we are missing issues? Any other comments? Cheers, Vincent
Re: Preparation of Doxia 1.0-beta-1 release
I just noticed that the fml module now takes ~5min to build instead of a few secs for all other modules. There are some svn checkouts during testing, are those necessary? Does it mean you can't build doxia off-line? -Lukas Vincent Siveton wrote: Hi guys, IMHO Doxia 1.0-beta-1 could be release soon, ideally for xmas! So, do you think we are missing issues? Any other comments? Cheers, Vincent
Re: svn commit: r723989 - /maven/doxia/doxia/trunk/doxia-core/src/main/java/org/apache/maven/doxia/parser/AbstractXmlParser.java
Hi Benjamin,
Right and I fixed it in r724309.
Thanks!
Vincent
2008/12/6 Benjamin Bentmann [EMAIL PROTECTED]:
Hi Vincent,
Author: vsiveton
Date: Sat Dec 6 06:41:44 2008
New Revision: 723989
URL: http://svn.apache.org/viewvc?rev=723989view=rev
Log:
DOXIA-265: Add an EntityResolver in AbstractXmlParser#getXmlReader()
o added a simple cached file mechanism
Modified:
maven/doxia/doxia/trunk/doxia-core/src/main/java/org/apache/maven/doxia/parser/AbstractXmlParser.java
[...]
+byte[] res = (byte[]) cache.get( systemId );
+// already cached?
+if ( res == null )
+{
+File temp =
+new File( System.getProperty( java.io.tmpdir ),
FileUtils.getFile( systemId ).getName() );
+// maybe already as a temp file?
+if ( !temp.exists() )
+{
+res = IOUtil.toByteArray( new URL( systemId
).openStream() );
+IOUtil.copy( res, WriterFactory.newPlatformWriter(
temp ) );
+}
+else
+{
+res = IOUtil.toByteArray(
ReaderFactory.newPlatformReader( temp ) );
+}
+
+cache.put( systemId, res );
+}
+
+InputSource is = new InputSource( new ByteArrayInputStream(
res ) );
+is.setPublicId( publicId );
+is.setSystemId( systemId );
+
Is it safe to use a reader here, especially a platform reader? Byte streams
that don't match the intended encoding get crippled but is the encoding of
the data known here? Should this maybe just use
IOUtil.copy( byte[], OutputStream )
and
IOUtil.toByteArray( InputStream )
i.e. simply move bytes around instead of thinking about characters?
Benjamin
