Nabble - Doxia - dev

Re: Question about APT and Applets

2009-10-13T08:07:00Z

Not possible with apt, use xdoc.

-Lukas

Michael Remijan wrote:
> When generating my project website, I'm using APT and I need to include an Applet on the page. I have not been able to find any examples of doing this. Anyone know how to do it?
>

Question about APT and Applets

2009-10-13T07:44:45Z

When generating my project website, I'm using APT and I need to include an Applet on the page. I have not been able to find any examples of doing this. Anyone know how to do it?

Re: svn commit: r805576 - in /maven/doxia/doxia/trunk/doxia-modules/doxia-module-xdoc/src: main/java/org/apache/maven/doxia/module/xdoc/XdocParser.java test/java/org/apache/maven/doxia/module/xdoc/XdocParserTest.java

2009-08-20T00:51:30Z

Vincent Siveton wrote:
> Hi Lukas,
>
> 2009/8/19 Lukas Theussl <ltheussl@...>:
>> IIUC, according to the xdoc schema it is perfectly legal to specify a
>> <title> in both <properties> and <head>, so throwing an Exception is not the
>> right solution IMO. I would prefer one of the following two alternatives:
>
> Yes both are legal, but the doc doesn't specify which one is the
> "official" title of a xdoc.

properties/title is required by the xsd and should have priority, head/title is
only there for compatibility with xhtml, but it is optional.

>
>> 1) define and document which title gets used if both are specified and emit
>> a warning that the other is ignored
>
> I was thinking about this idea but due to the parser impl, it will be
> always head/title which emits a warn due to the exception actually.
>
> IMHO head/title should be the right title, properties/title is more
> for backward compatibility reasons. WDYT?

The other way round IMO. The properties/title is a required element, while
head/title is optional, and properties comes before head, so simply emit a warning
when a second title is encountered.

-Lukas

>
> Cheers,
>
> Vincent
>

Re: svn commit: r805576 - in /maven/doxia/doxia/trunk/doxia-modules/doxia-module-xdoc/src: main/java/org/apache/maven/doxia/module/xdoc/XdocParser.java test/java/org/apache/maven/doxia/module/xdoc/XdocParserTest.java

2009-08-19T02:17:20Z

Hi Lukas,

2009/8/19 Lukas Theussl <ltheussl@...>:
> IIUC, according to the xdoc schema it is perfectly legal to specify a
> <title> in both <properties> and <head>, so throwing an Exception is not the
> right solution IMO. I would prefer one of the following two alternatives:

Yes both are legal, but the doc doesn't specify which one is the
"official" title of a xdoc.

> 1) define and document which title gets used if both are specified and emit
> a warning that the other is ignored

I was thinking about this idea but due to the parser impl, it will be
always head/title which emits a warn due to the exception actually.

IMHO head/title should be the right title, properties/title is more
for backward compatibility reasons. WDYT?

Cheers,

Vincent

Re: svn commit: r805576 - in /maven/doxia/doxia/trunk/doxia-modules/doxia-module-xdoc/src: main/java/org/apache/maven/doxia/module/xdoc/XdocParser.java test/java/org/apache/maven/doxia/module/xdoc/XdocParserTest.java

2009-08-19T00:32:20Z

Hi Vincent,

[I'm back! :) ]

IIUC, according to the xdoc schema it is perfectly legal to specify a <title> in
both <properties> and <head>, so throwing an Exception is not the right solution
IMO. I would prefer one of the following two alternatives:

1) define and document which title gets used if both are specified and emit a
warning that the other is ignored

2) if a second title is encountered, emit it as an (unkown) meta event

I think 1) is good enough since specifying two titles is not logical (even if
legal) and should be fixed in the source document.

-Lukas

vsiveton@... wrote:

> Author: vsiveton
> Date: Tue Aug 18 21:04:23 2009
> New Revision: 805576
>
> URL: http://svn.apache.org/viewvc?rev=805576&view=rev
> Log:
> DOXIA-359: Xdoc parser doesnt make the difference for <title/>
>
> o added an exception when 2 <title/> are defined in <properties/> and also in <head/>
>
> Modified:
> maven/doxia/doxia/trunk/doxia-modules/doxia-module-xdoc/src/main/java/org/apache/maven/doxia/module/xdoc/XdocParser.java
> maven/doxia/doxia/trunk/doxia-modules/doxia-module-xdoc/src/test/java/org/apache/maven/doxia/module/xdoc/XdocParserTest.java
>
> Modified: maven/doxia/doxia/trunk/doxia-modules/doxia-module-xdoc/src/main/java/org/apache/maven/doxia/module/xdoc/XdocParser.java
> URL: http://svn.apache.org/viewvc/maven/doxia/doxia/trunk/doxia-modules/doxia-module-xdoc/src/main/java/org/apache/maven/doxia/module/xdoc/XdocParser.java?rev=805576&r1=805575&r2=805576&view=diff
> ==============================================================================
> --- maven/doxia/doxia/trunk/doxia-modules/doxia-module-xdoc/src/main/java/org/apache/maven/doxia/module/xdoc/XdocParser.java (original)
> +++ maven/doxia/doxia/trunk/doxia-modules/doxia-module-xdoc/src/main/java/org/apache/maven/doxia/module/xdoc/XdocParser.java Tue Aug 18 21:04:23 2009
> @@ -69,6 +69,9 @@
> /** Indicates that we're inside <properties> or <head>.*/
> private boolean inHead;
>
> + /** Indicates that <title> was called from <properties> or <head>.*/
> + private boolean hasTitle;
> +
> /** {@inheritDoc} */
> public void parse( Reader source, Sink sink )
> throws ParseException
> @@ -94,6 +97,8 @@
> //setIgnorableWhitespace( true );
>
> super.parse( tmp, sink );
> +
> + this.hasTitle = false;
> }
>
> /** {@inheritDoc} */
> @@ -120,7 +125,13 @@
> }
> else if ( parser.getName().equals( TITLE.toString() ) )
> {
> + if ( hasTitle )
> + {
> + throw new XmlPullParserException( "<title/> should be defined in <properties/> or in <head/>, "
> + + "not both." );
> + }
> sink.title( attribs );
> + this.hasTitle = true;
> }
> else if ( parser.getName().equals( AUTHOR_TAG.toString() ) )
> {
>
> Modified: maven/doxia/doxia/trunk/doxia-modules/doxia-module-xdoc/src/test/java/org/apache/maven/doxia/module/xdoc/XdocParserTest.java
> URL: http://svn.apache.org/viewvc/maven/doxia/doxia/trunk/doxia-modules/doxia-module-xdoc/src/test/java/org/apache/maven/doxia/module/xdoc/XdocParserTest.java?rev=805576&r1=805575&r2=805576&view=diff
> ==============================================================================
> --- maven/doxia/doxia/trunk/doxia-modules/doxia-module-xdoc/src/test/java/org/apache/maven/doxia/module/xdoc/XdocParserTest.java (original)
> +++ maven/doxia/doxia/trunk/doxia-modules/doxia-module-xdoc/src/test/java/org/apache/maven/doxia/module/xdoc/XdocParserTest.java Tue Aug 18 21:04:23 2009
> @@ -189,6 +189,20 @@
> assertEquals( "body", ( (SinkEventElement) it.next() ).getName() );
> assertEquals( "body_", ( (SinkEventElement) it.next() ).getName() );
> assertFalse( it.hasNext() );
> +
> + text = "<document>"
> + + "<properties><title>title</title>"
> + + "<author email=\"a@...\">John Doe</author></properties>"
> + + "<head><title>title</title></head><body></body></document>";
> + try
> + {
> + parser.parse( text, sink );
> + assertTrue( false );
> + }
> + catch ( ParseException e )
> + {
> + assertTrue( true );
> + }
> }
>
> /** @throws Exception */
>
>
>

Re: svn commit: r799837 - in /maven/doxia/doxia-tools/trunk/doxia-linkcheck/src/main/java/org/apache/maven/doxia/linkcheck/validation: LinkValidatorManager.java OnlineHTTPLinkValidator.java

2009-08-02T03:41:47Z

Hi Dennis,

2009/8/2 Dennis Lundberg <dennisl@...>:
> These are logically not necessary, but are put in there for performance
> reasons. Only if the logger is in debug mode (in this case) will the 3
> String objects it uses actually be created by the JVM. Otherwise no
> objects will be created, resulting in slightly enhanced
> performance/memory usage. At least if used in heavy loops.

Definitely agree for the performance, it was why I added them in the
past r709693 :)

In this revision, I added some message objects for logging but agree I
removed some unwanted checks.

Cheers,

Vincent

Re: svn commit: r799837 - in /maven/doxia/doxia-tools/trunk/doxia-linkcheck/src/main/java/org/apache/maven/doxia/linkcheck/validation: LinkValidatorManager.java OnlineHTTPLinkValidator.java

2009-08-02T00:18:20Z

Vincent,

Is there a special reason for removing the level.checking for logging
statements, like the one below? You removed a bunch of these.

if ( LOG.isDebugEnabled() )
{
LOG.debug( "Will use method : [" + bean.getMethod() + "]" );
}

These are logically not necessary, but are put in there for performance
reasons. Only if the logger is in debug mode (in this case) will the 3
String objects it uses actually be created by the JVM. Otherwise no
objects will be created, resulting in slightly enhanced
performance/memory usage. At least if used in heavy loops.

vsiveton@... wrote:

> Author: vsiveton
> Date: Sat Aug 1 11:17:23 2009
> New Revision: 799837
>
> URL: http://svn.apache.org/viewvc?rev=799837&view=rev
> Log:
> o added timeout and httpClientsParameters
> o improved log call
>
> Modified:
> maven/doxia/doxia-tools/trunk/doxia-linkcheck/src/main/java/org/apache/maven/doxia/linkcheck/validation/LinkValidatorManager.java
> maven/doxia/doxia-tools/trunk/doxia-linkcheck/src/main/java/org/apache/maven/doxia/linkcheck/validation/OnlineHTTPLinkValidator.java
>
> Modified: maven/doxia/doxia-tools/trunk/doxia-linkcheck/src/main/java/org/apache/maven/doxia/linkcheck/validation/LinkValidatorManager.java
> URL: http://svn.apache.org/viewvc/maven/doxia/doxia-tools/trunk/doxia-linkcheck/src/main/java/org/apache/maven/doxia/linkcheck/validation/LinkValidatorManager.java?rev=799837&r1=799836&r2=799837&view=diff
> ==============================================================================
> --- maven/doxia/doxia-tools/trunk/doxia-linkcheck/src/main/java/org/apache/maven/doxia/linkcheck/validation/LinkValidatorManager.java (original)
> +++ maven/doxia/doxia-tools/trunk/doxia-linkcheck/src/main/java/org/apache/maven/doxia/linkcheck/validation/LinkValidatorManager.java Sat Aug 1 11:17:23 2009
> @@ -34,6 +34,7 @@
> import java.io.ObjectInputStream;
> import java.io.ObjectOutputStream;
> import java.io.Serializable;
> +import java.net.URI;
> import java.util.HashMap;
> import java.util.Iterator;
> import java.util.LinkedList;
> @@ -404,6 +405,17 @@
> return link.indexOf( pattern ) != -1;
> }
>
> + URI uri = URI.create( link );
> +
> + if ( uri.getScheme() != null && !pattern.startsWith( uri.getScheme() ) )
> + {
> + return true;
> + }
> +
> + if ( pattern.matches( "\\*+/?.*" ) && !link.startsWith( "/" ) && !link.startsWith( "./" ) )
> + {
> + link = "./" + link;
> + }
> String diff = StringUtils.difference( link, pattern );
> if ( diff.startsWith( "/" ) )
> {
>
> Modified: maven/doxia/doxia-tools/trunk/doxia-linkcheck/src/main/java/org/apache/maven/doxia/linkcheck/validation/OnlineHTTPLinkValidator.java
> URL: http://svn.apache.org/viewvc/maven/doxia/doxia-tools/trunk/doxia-linkcheck/src/main/java/org/apache/maven/doxia/linkcheck/validation/OnlineHTTPLinkValidator.java?rev=799837&r1=799836&r2=799837&view=diff
> ==============================================================================
> --- maven/doxia/doxia-tools/trunk/doxia-linkcheck/src/main/java/org/apache/maven/doxia/linkcheck/validation/OnlineHTTPLinkValidator.java (original)
> +++ maven/doxia/doxia-tools/trunk/doxia-linkcheck/src/main/java/org/apache/maven/doxia/linkcheck/validation/OnlineHTTPLinkValidator.java Sat Aug 1 11:17:23 2009
> @@ -22,6 +22,8 @@
> import java.io.IOException;
>
> import java.net.URL;
> +import java.util.Iterator;
> +import java.util.Map;
>
> import org.apache.commons.httpclient.Credentials;
> import org.apache.commons.httpclient.Header;
> @@ -38,6 +40,8 @@
> import org.apache.commons.httpclient.auth.AuthScope;
> import org.apache.commons.httpclient.methods.GetMethod;
> import org.apache.commons.httpclient.methods.HeadMethod;
> +import org.apache.commons.httpclient.params.HttpClientParams;
> +import org.apache.commons.httpclient.params.HttpMethodParams;
>
> import org.apache.commons.logging.Log;
> import org.apache.commons.logging.LogFactory;
> @@ -45,7 +49,6 @@
> import org.apache.maven.doxia.linkcheck.model.LinkcheckFileResult;
> import org.codehaus.plexus.util.StringUtils;
>
> -
> /**
> * Checks links which are normal URLs
> *
> @@ -54,7 +57,8 @@
> * @author <a href="mailto:vincent.siveton@...">Vincent Siveton</a>
> * @version $Id$
> */
> -public final class OnlineHTTPLinkValidator extends HTTPLinkValidator
> +public final class OnlineHTTPLinkValidator
> + extends HTTPLinkValidator
> {
> /** Log for debug output. */
> private static final Log LOG = LogFactory.getLog( OnlineHTTPLinkValidator.class );
> @@ -97,10 +101,7 @@
> bean = new HttpBean();
> }
>
> - if ( LOG.isDebugEnabled() )
> - {
> - LOG.debug( "Will use method : [" + bean.getMethod() + "]" );
> - }
> + LOG.debug( "Will use method : [" + bean.getMethod() + "]" );
>
> this.http = bean;
>
> @@ -135,42 +136,50 @@
> initHttpClient();
> }
>
> - String link = lvi.getLink();
> + if ( this.http.getHttpClientParameters() != null )
> + {
> + for ( Iterator it = this.http.getHttpClientParameters().entrySet().iterator(); it.hasNext(); )
> + {
> + Map.Entry entry = (Map.Entry) it.next();
> +
> + if ( entry.getValue() != null )
> + {
> + System.setProperty( entry.getKey().toString(), entry.getValue().toString() );
> + }
> + }
> + }
>
> + // Some web servers don't allow the default user-agent sent by httpClient
> + System.setProperty( HttpMethodParams.USER_AGENT, "Mozilla/4.0 (compatible; MSIE 6.0; Windows NT 5.0)" );
> +
> + String link = lvi.getLink();
> try
> {
> if ( link.startsWith( "/" ) )
> {
> if ( getBaseURL() == null )
> {
> - if ( LOG.isWarnEnabled() )
> - {
> + LOG.warn( "Cannot check link [" + link + "] in page [" + lvi.getSource()
> + + "], as no base URL has been set!" );
>
> - LOG.warn( "Cannot check link [" + link + "] in page [" + lvi.getSource()
> - + "], as no base URL has been set!" );
> - }
> return new LinkValidationResult( LinkcheckFileResult.WARNING_LEVEL, false,
> - "No base URL specified" );
> + "No base URL specified" );
> }
>
> link = getBaseURL() + link;
> }
>
> HttpMethod hm = null;
> -
> try
> {
> hm = checkLink( link, 0 );
> }
> catch ( Throwable t )
> {
> - if ( LOG.isDebugEnabled() )
> - {
> - LOG.debug( "Received: [" + t + "] for [" + link + "] in page [" + lvi.getSource() + "]", t );
> - }
> + LOG.debug( "Received: [" + t + "] for [" + link + "] in page [" + lvi.getSource() + "]", t );
>
> - return new LinkValidationResult( LinkcheckFileResult.ERROR_LEVEL, false, t.getClass().getName() + " : "
> - + t.getMessage() );
> + return new LinkValidationResult( LinkcheckFileResult.ERROR_LEVEL, false, t.getClass().getName()
> + + " : " + t.getMessage() );
> }
>
> if ( hm == null )
> @@ -182,116 +191,114 @@
> if ( hm.getStatusCode() == HttpStatus.SC_OK )
> {
> return new HTTPLinkValidationResult( LinkcheckFileResult.VALID_LEVEL, true, hm.getStatusCode(),
> - hm.getStatusText() );
> - }
> + hm.getStatusText() );
> + }
>
> - // If there's a redirection ... add a warning
> - if ( hm.getStatusCode() == HttpStatus.SC_MOVED_PERMANENTLY
> - || hm.getStatusCode() == HttpStatus.SC_MOVED_TEMPORARILY
> - || hm.getStatusCode() == HttpStatus.SC_TEMPORARY_REDIRECT )
> - {
> - if ( LOG.isWarnEnabled() )
> + String msg =
> + "Received: [" + hm.getStatusCode() + "] for [" + link + "] in page [" + lvi.getSource() + "]";
> + // If there's a redirection ... add a warning
> + if ( hm.getStatusCode() == HttpStatus.SC_MOVED_PERMANENTLY
> + || hm.getStatusCode() == HttpStatus.SC_MOVED_TEMPORARILY
> + || hm.getStatusCode() == HttpStatus.SC_TEMPORARY_REDIRECT )
> {
> - LOG.warn( "Received: [" + hm.getStatusCode() + "] for [" + link + "] in page [" + lvi.getSource()
> - + "]" );
> - }
> + LOG.warn( msg );
>
> return new HTTPLinkValidationResult( LinkcheckFileResult.WARNING_LEVEL, true, hm.getStatusCode(),
> hm.getStatusText() );
> }
>
> - if ( LOG.isDebugEnabled() )
> - {
> - LOG.debug( "Received: [" + hm.getStatusCode() + "] for [" + link + "] in page [" + lvi.getSource()
> - + "]" );
> - }
> + LOG.debug( msg );
>
> return new HTTPLinkValidationResult( LinkcheckFileResult.ERROR_LEVEL, false, hm.getStatusCode(),
> hm.getStatusText() );
> -
> }
> catch ( Throwable t )
> {
> + String msg = "Received: [" + t + "] for [" + link + "] in page [" + lvi.getSource() + "]";
> if ( LOG.isDebugEnabled() )
> {
> - LOG.debug( "Received: [" + t + "] for [" + link + "] in page [" + lvi.getSource() + "]", t );
> + LOG.debug( msg, t );
> }
> else
> {
> - LOG.error( "Received: [" + t + "] for [" + link + "] in page [" + lvi.getSource() + "]" );
> + LOG.error( msg );
> }
>
> return new LinkValidationResult( LinkcheckFileResult.ERROR_LEVEL, false, t.getMessage() );
> }
> + finally
> + {
> + System.getProperties().remove( HttpMethodParams.USER_AGENT );
> +
> + if ( this.http.getHttpClientParameters() != null )
> + {
> + for ( Iterator it = this.http.getHttpClientParameters().entrySet().iterator(); it.hasNext(); )
> + {
> + Map.Entry entry = (Map.Entry) it.next();
> +
> + if ( entry.getValue() != null )
> + {
> + System.getProperties().remove( entry.getKey().toString() );
> + }
> + }
> + }
> + }
> }
>
> /** Initialize the HttpClient. */
> private void initHttpClient()
> {
> - if ( LOG.isDebugEnabled() )
> - {
> - LOG.debug( "A new HttpClient instance is needed ..." );
> - }
> -
> - // Some web servers don't allow the default user-agent sent by httpClient
> - System.setProperty( "httpclient.useragent", "Mozilla/4.0 (compatible; MSIE 6.0; Windows NT 5.0)" );
> + LOG.debug( "A new HttpClient instance is needed ..." );
>
> this.cl = new HttpClient( new MultiThreadedHttpConnectionManager() );
>
> + // Default params
> + if ( this.http.getTimeout() != 0 )
> + {
> + this.cl.getHttpConnectionManager().getParams().setConnectionTimeout( this.http.getTimeout() );
> + this.cl.getHttpConnectionManager().getParams().setSoTimeout( this.http.getTimeout() );
> + }
> + this.cl.getParams().setBooleanParameter( HttpClientParams.ALLOW_CIRCULAR_REDIRECTS, true );
> +
> HostConfiguration hc = new HostConfiguration();
>
> HttpState state = new HttpState();
> -
> if ( StringUtils.isNotEmpty( this.http.getProxyHost() ) )
> {
> hc.setProxy( this.http.getProxyHost(), this.http.getProxyPort() );
>
> - if ( LOG.isDebugEnabled() )
> - {
> - LOG.debug( "Proxy Host:" + this.http.getProxyHost() );
> - LOG.debug( "Proxy Port:" + this.http.getProxyPort() );
> - }
> + LOG.debug( "Proxy Host:" + this.http.getProxyHost() );
> + LOG.debug( "Proxy Port:" + this.http.getProxyPort() );
>
> if ( StringUtils.isNotEmpty( this.http.getProxyUser() ) && this.http.getProxyPassword() != null )
> {
> - if ( LOG.isDebugEnabled() )
> - {
> - LOG.debug( "Proxy User:" + this.http.getProxyUser() );
> - }
> + LOG.debug( "Proxy User:" + this.http.getProxyUser() );
>
> Credentials credentials;
> -
> if ( StringUtils.isNotEmpty( this.http.getProxyNtlmHost() ) )
> {
> - credentials = new NTCredentials( this.http.getProxyUser(), this.http.getProxyPassword(), this.http
> - .getProxyNtlmHost(), this.http.getProxyNtlmDomain() );
> + credentials =
> + new NTCredentials( this.http.getProxyUser(), this.http.getProxyPassword(),
> + this.http.getProxyNtlmHost(), this.http.getProxyNtlmDomain() );
> }
> else
> {
> - credentials = new UsernamePasswordCredentials( this.http.getProxyUser(), this.http
> - .getProxyPassword() );
> + credentials =
> + new UsernamePasswordCredentials( this.http.getProxyUser(), this.http.getProxyPassword() );
> }
>
> state.setProxyCredentials( AuthScope.ANY, credentials );
> }
> -
> }
> else
> {
> - if ( LOG.isDebugEnabled() )
> - {
> - LOG.debug( "Not using a proxy" );
> - }
> + LOG.debug( "Not using a proxy" );
> }
>
> this.cl.setHostConfiguration( hc );
> -
> this.cl.setState( state );
>
> - if ( LOG.isDebugEnabled() )
> - {
> - LOG.debug( "New HttpClient instance created." );
> - }
> + LOG.debug( "New HttpClient instance created." );
> }
>
> /**
> @@ -305,13 +312,29 @@
> private HttpMethod checkLink( String link, int nbRedirect )
> throws IOException
> {
> - if ( nbRedirect > MAX_NB_REDIRECT )
> + int max = MAX_NB_REDIRECT;
> + if ( this.http.getHttpClientParameters() != null
> + && this.http.getHttpClientParameters().get( HttpClientParams.MAX_REDIRECTS ) != null )
> {
> - throw new HttpException( "Maximum number of redirections (" + MAX_NB_REDIRECT + ") exceeded" );
> + try
> + {
> + max =
> + Integer.valueOf(
> + this.http.getHttpClientParameters().get( HttpClientParams.MAX_REDIRECTS )
> + .toString() ).intValue();
> + }
> + catch ( NumberFormatException e )
> + {
> + LOG.warn( "HttpClient parameter '" + HttpClientParams.MAX_REDIRECTS
> + + "' is not a number. Ignoring" );
> + }
> + }
> + if ( nbRedirect > max )
> + {
> + throw new HttpException( "Maximum number of redirections (" + max + ") exceeded" );
> }
>
> HttpMethod hm;
> -
> if ( HEAD_METHOD.equalsIgnoreCase( this.http.getMethod() ) )
> {
> hm = new HeadMethod( link );
> @@ -322,17 +345,15 @@
> }
> else
> {
> - if ( LOG.isErrorEnabled() )
> - {
> - LOG.error( "Unsupported method: " + this.http.getMethod() + ", using 'get'." );
> - }
> + LOG.error( "Unsupported method: " + this.http.getMethod() + ", using 'get'." );
> hm = new GetMethod( link );
> }
>
> + // Default
> + hm.setFollowRedirects( this.http.isFollowRedirects() );
> +
> try
> {
> - hm.setFollowRedirects( this.http.isFollowRedirects() );
> -
> URL url = new URL( link );
>
> cl.getHostConfiguration().setHost( url.getHost(), url.getPort(), url.getProtocol() );
> @@ -340,28 +361,23 @@
> cl.executeMethod( hm );
>
> StatusLine sl = hm.getStatusLine();
> -
> if ( sl == null )
> {
> - if ( LOG.isErrorEnabled() )
> - {
> - LOG.error( "Unknown error validating link : " + link );
> - }
> + LOG.error( "Unknown error validating link : " + link );
> +
> return null;
> }
>
> if ( hm.getStatusCode() == HttpStatus.SC_MOVED_PERMANENTLY
> - || hm.getStatusCode() == HttpStatus.SC_MOVED_TEMPORARILY
> - || hm.getStatusCode() == HttpStatus.SC_TEMPORARY_REDIRECT )
> + || hm.getStatusCode() == HttpStatus.SC_MOVED_TEMPORARILY
> + || hm.getStatusCode() == HttpStatus.SC_TEMPORARY_REDIRECT )
> {
> Header locationHeader = hm.getResponseHeader( "location" );
>
> if ( locationHeader == null )
> {
> - if ( LOG.isErrorEnabled() )
> - {
> - LOG.error( "Site sent redirect, but did not set Location header" );
> - }
> + LOG.error( "Site sent redirect, but did not set Location header" );
> +
> return hm;
> }
>
> @@ -376,7 +392,7 @@
>
> newLink =
> oldUrl.getProtocol() + "://" + oldUrl.getHost()
> - + ( oldUrl.getPort() > 0 ? ":" + oldUrl.getPort() : "" ) + newLink;
> + + ( oldUrl.getPort() > 0 ? ":" + oldUrl.getPort() : "" ) + newLink;
> }
> else
> {
> @@ -386,10 +402,7 @@
>
> HttpMethod oldHm = hm;
>
> - if ( LOG.isDebugEnabled() )
> - {
> - LOG.debug( "[" + link + "] is redirected to [" + newLink + "]" );
> - }
> + LOG.debug( "[" + link + "] is redirected to [" + newLink + "]" );
>
> oldHm.releaseConnection();
>
>
>
>

--
Dennis Lundberg

Re: svn commit: r776294 - in /maven/doxia/doxia/trunk: doxia-core/src/main/java/org/apache/maven/doxia/parser/ doxia-core/src/main/java/org/apache/maven/doxia/util/ doxia-core/src/test/java/org/apache/maven/doxia/util/ doxia-modules/doxia-module-xdoc

2009-05-22T09:23:52Z

Vincent Siveton wrote:

> Hi Dennis,
>
> 2009/5/19 Dennis Lundberg <dennisl@...>:
>> Hi Vincent
>>
>> Can you please add back HtmlTools.unescapeHtml( String ), add a
>> @deprecated note for it and have it redirect to the new method?
>
> I don't think it will be useful since it is a new method in 1.1.1 and
> 1.1.1 has no release...

My bad, I thought it was the method that was introduced back in the
1.0-alphas.

>
> Cheers,
>
> Vincent
>

--
Dennis Lundberg

Re: svn commit: r776294 - in /maven/doxia/doxia/trunk: doxia-core/src/main/java/org/apache/maven/doxia/parser/ doxia-core/src/main/java/org/apache/maven/doxia/util/ doxia-core/src/test/java/org/apache/maven/doxia/util/ doxia-modules/doxia-module-xdoc/src/m...

2009-05-20T03:27:52Z

Hi Dennis,

As Vincent said, this method was only added in 1.1.1.

OTOH, I have run clirr on the whole doxia codebase and after fixing a few issues,
we are completely compatible with 1.1 now.

Only in doxia-maven-plugin I had to exclude some classes because clirr doesn't
take into account the manipulations by the shade plugin, but absolutely nothing
has changed there between 1.1 and 1.1.1. If anybody knows a better way to handle
that, let me know.

Cheers,
-Lukas

Dennis Lundberg wrote:

> Hi Vincent
>
> Can you please add back HtmlTools.unescapeHtml( String ), add a
> @deprecated note for it and have it redirect to the new method?
>
> This is a public method of a public helper class in Doxia core. I don't
> know if it used outside of Doxia, but we shouldn't just rename it for a
> point release.
>
> vsiveton@... wrote:
>> Author: vsiveton
>> Date: Tue May 19 12:36:02 2009
>> New Revision: 776294
>>
>> URL: http://svn.apache.org/viewvc?rev=776294&view=rev
>> Log:
>> o refactor unescapeHtml to unescapeHTML for consistency reason
>>
>> Modified:
>> maven/doxia/doxia/trunk/doxia-core/src/main/java/org/apache/maven/doxia/parser/AbstractXmlParser.java
>> maven/doxia/doxia/trunk/doxia-core/src/main/java/org/apache/maven/doxia/util/HtmlTools.java
>> maven/doxia/doxia/trunk/doxia-core/src/test/java/org/apache/maven/doxia/util/HtmlToolsTest.java
>> maven/doxia/doxia/trunk/doxia-modules/doxia-module-xdoc/src/main/java/org/apache/maven/doxia/module/xdoc/XdocParser.java
>>
>> Modified: maven/doxia/doxia/trunk/doxia-core/src/main/java/org/apache/maven/doxia/parser/AbstractXmlParser.java
>> URL: http://svn.apache.org/viewvc/maven/doxia/doxia/trunk/doxia-core/src/main/java/org/apache/maven/doxia/parser/AbstractXmlParser.java?rev=776294&r1=776293&r2=776294&view=diff
>> ==============================================================================
>> --- maven/doxia/doxia/trunk/doxia-core/src/main/java/org/apache/maven/doxia/parser/AbstractXmlParser.java (original)
>> +++ maven/doxia/doxia/trunk/doxia-core/src/main/java/org/apache/maven/doxia/parser/AbstractXmlParser.java Tue May 19 12:36:02 2009
>> @@ -395,7 +395,7 @@
>> // TODO: the MXParser doesn't actually handle correctly surrogate char, ie
>> // if orignalText = "𝟯", text = "\ud7ef"
>>
>> - String unescaped = HtmlTools.unescapeHtml( text );
>> + String unescaped = HtmlTools.unescapeHTML( text );
>>
>> // TODO: StringEscapeUtils.unescapeHtml returns unknown entities as is,
>> // they should be handled as one character as well
>>
>> Modified: maven/doxia/doxia/trunk/doxia-core/src/main/java/org/apache/maven/doxia/util/HtmlTools.java
>> URL: http://svn.apache.org/viewvc/maven/doxia/doxia/trunk/doxia-core/src/main/java/org/apache/maven/doxia/util/HtmlTools.java?rev=776294&r1=776293&r2=776294&view=diff
>> ==============================================================================
>> --- maven/doxia/doxia/trunk/doxia-core/src/main/java/org/apache/maven/doxia/util/HtmlTools.java (original)
>> +++ maven/doxia/doxia/trunk/doxia-core/src/main/java/org/apache/maven/doxia/util/HtmlTools.java Tue May 19 12:36:02 2009
>> @@ -207,7 +207,7 @@
>> * @return a new unescaped <code>String</code>, <code>null</code> if null string input.
>> * @since 1.1.1.
>> */
>> - public static String unescapeHtml( String text )
>> + public static String unescapeHTML( String text )
>> {
>> if ( text == null )
>> {
>>
>> Modified: maven/doxia/doxia/trunk/doxia-core/src/test/java/org/apache/maven/doxia/util/HtmlToolsTest.java
>> URL: http://svn.apache.org/viewvc/maven/doxia/doxia/trunk/doxia-core/src/test/java/org/apache/maven/doxia/util/HtmlToolsTest.java?rev=776294&r1=776293&r2=776294&view=diff
>> ==============================================================================
>> --- maven/doxia/doxia/trunk/doxia-core/src/test/java/org/apache/maven/doxia/util/HtmlToolsTest.java (original)
>> +++ maven/doxia/doxia/trunk/doxia-core/src/test/java/org/apache/maven/doxia/util/HtmlToolsTest.java Tue May 19 12:36:02 2009
>> @@ -56,22 +56,22 @@
>> */
>> public void testUnescapeHTML()
>> {
>> - assertNull( HtmlTools.unescapeHtml( null ) );
>> - assertEquals( "", HtmlTools.unescapeHtml( "" ) );
>> - assertEquals( "<", HtmlTools.unescapeHtml( "<" ) );
>> - assertEquals( ">", HtmlTools.unescapeHtml( ">" ) );
>> - assertEquals( "&", HtmlTools.unescapeHtml( "&" ) );
>> - assertEquals( "\"", HtmlTools.unescapeHtml( """ ) );
>> - assertEquals( "&", HtmlTools.unescapeHtml( "&" ) );
>> - assertEquals( "<Français>", HtmlTools.unescapeHtml( "<Français>" ) );
>> - assertEquals( "\u0159", HtmlTools.unescapeHtml( "ř" ) );
>> - assertEquals( "\uD808\uDF45", HtmlTools.unescapeHtml( "𒍅" ) );
>> - assertEquals( "\uD835\uDFED", HtmlTools.unescapeHtml( "𝟭" ) );
>> - assertEquals( "\uD808\uDF45\uD835\uDFED", HtmlTools.unescapeHtml( "𒍅𝟭" ) );
>> + assertNull( HtmlTools.unescapeHTML( null ) );
>> + assertEquals( "", HtmlTools.unescapeHTML( "" ) );
>> + assertEquals( "<", HtmlTools.unescapeHTML( "<" ) );
>> + assertEquals( ">", HtmlTools.unescapeHTML( ">" ) );
>> + assertEquals( "&", HtmlTools.unescapeHTML( "&" ) );
>> + assertEquals( "\"", HtmlTools.unescapeHTML( """ ) );
>> + assertEquals( "&", HtmlTools.unescapeHTML( "&" ) );
>> + assertEquals( "<Français>", HtmlTools.unescapeHTML( "<Français>" ) );
>> + assertEquals( "\u0159", HtmlTools.unescapeHTML( "ř" ) );
>> + assertEquals( "\uD808\uDF45", HtmlTools.unescapeHTML( "𒍅" ) );
>> + assertEquals( "\uD835\uDFED", HtmlTools.unescapeHTML( "𝟭" ) );
>> + assertEquals( "\uD808\uDF45\uD835\uDFED", HtmlTools.unescapeHTML( "𒍅𝟭" ) );
>>
>> try
>> {
>> - HtmlTools.unescapeHtml( "test 𝟭 test" );
>> + HtmlTools.unescapeHTML( "test 𝟭 test" );
>> assertTrue( false );
>> }
>> catch ( IllegalArgumentException e )
>>
>> Modified: maven/doxia/doxia/trunk/doxia-modules/doxia-module-xdoc/src/main/java/org/apache/maven/doxia/module/xdoc/XdocParser.java
>> URL: http://svn.apache.org/viewvc/maven/doxia/doxia/trunk/doxia-modules/doxia-module-xdoc/src/main/java/org/apache/maven/doxia/module/xdoc/XdocParser.java?rev=776294&r1=776293&r2=776294&view=diff
>> ==============================================================================
>> --- maven/doxia/doxia/trunk/doxia-modules/doxia-module-xdoc/src/main/java/org/apache/maven/doxia/module/xdoc/XdocParser.java (original)
>> +++ maven/doxia/doxia/trunk/doxia-modules/doxia-module-xdoc/src/main/java/org/apache/maven/doxia/module/xdoc/XdocParser.java Tue May 19 12:36:02 2009
>> @@ -185,7 +185,7 @@
>>
>> sink.sectionTitle( Sink.SECTION_LEVEL_1, attribs );
>>
>> - sink.text( HtmlTools.unescapeHtml( parser.getAttributeValue( null, Attribute.NAME.toString() ) ) );
>> + sink.text( HtmlTools.unescapeHTML( parser.getAttributeValue( null, Attribute.NAME.toString() ) ) );
>>
>> sink.sectionTitle1_();
>> }
>> @@ -204,7 +204,7 @@
>>
>> sink.sectionTitle( Sink.SECTION_LEVEL_2, attribs );
>>
>> - sink.text( HtmlTools.unescapeHtml( parser.getAttributeValue( null, Attribute.NAME.toString() ) ) );
>> + sink.text( HtmlTools.unescapeHTML( parser.getAttributeValue( null, Attribute.NAME.toString() ) ) );
>>
>> sink.sectionTitle2_();
>> }
>>
>>
>>
>
>

Re: svn commit: r776294 - in /maven/doxia/doxia/trunk: doxia-core/src/main/java/org/apache/maven/doxia/parser/ doxia-core/src/main/java/org/apache/maven/doxia/util/ doxia-core/src/test/java/org/apache/maven/doxia/util/ doxia-modules/doxia-module-xdoc

2009-05-19T12:33:49Z

Hi Dennis,

2009/5/19 Dennis Lundberg <dennisl@...>:
> Hi Vincent
>
> Can you please add back HtmlTools.unescapeHtml( String ), add a
> @deprecated note for it and have it redirect to the new method?

I don't think it will be useful since it is a new method in 1.1.1 and
1.1.1 has no release...

Cheers,

Vincent

Re: svn commit: r776294 - in /maven/doxia/doxia/trunk: doxia-core/src/main/java/org/apache/maven/doxia/parser/ doxia-core/src/main/java/org/apache/maven/doxia/util/ doxia-core/src/test/java/org/apache/maven/doxia/util/ doxia-modules/doxia-module-xdoc/src/m...

2009-05-19T11:58:28Z

Hi Vincent

Can you please add back HtmlTools.unescapeHtml( String ), add a
@deprecated note for it and have it redirect to the new method?

This is a public method of a public helper class in Doxia core. I don't
know if it used outside of Doxia, but we shouldn't just rename it for a
point release.

vsiveton@... wrote:

> Author: vsiveton
> Date: Tue May 19 12:36:02 2009
> New Revision: 776294
>
> URL: http://svn.apache.org/viewvc?rev=776294&view=rev
> Log:
> o refactor unescapeHtml to unescapeHTML for consistency reason
>
> Modified:
> maven/doxia/doxia/trunk/doxia-core/src/main/java/org/apache/maven/doxia/parser/AbstractXmlParser.java
> maven/doxia/doxia/trunk/doxia-core/src/main/java/org/apache/maven/doxia/util/HtmlTools.java
> maven/doxia/doxia/trunk/doxia-core/src/test/java/org/apache/maven/doxia/util/HtmlToolsTest.java
> maven/doxia/doxia/trunk/doxia-modules/doxia-module-xdoc/src/main/java/org/apache/maven/doxia/module/xdoc/XdocParser.java
>
> Modified: maven/doxia/doxia/trunk/doxia-core/src/main/java/org/apache/maven/doxia/parser/AbstractXmlParser.java
> URL: http://svn.apache.org/viewvc/maven/doxia/doxia/trunk/doxia-core/src/main/java/org/apache/maven/doxia/parser/AbstractXmlParser.java?rev=776294&r1=776293&r2=776294&view=diff
> ==============================================================================
> --- maven/doxia/doxia/trunk/doxia-core/src/main/java/org/apache/maven/doxia/parser/AbstractXmlParser.java (original)
> +++ maven/doxia/doxia/trunk/doxia-core/src/main/java/org/apache/maven/doxia/parser/AbstractXmlParser.java Tue May 19 12:36:02 2009
> @@ -395,7 +395,7 @@
> // TODO: the MXParser doesn't actually handle correctly surrogate char, ie
> // if orignalText = "𝟯", text = "\ud7ef"
>
> - String unescaped = HtmlTools.unescapeHtml( text );
> + String unescaped = HtmlTools.unescapeHTML( text );
>
> // TODO: StringEscapeUtils.unescapeHtml returns unknown entities as is,
> // they should be handled as one character as well
>
> Modified: maven/doxia/doxia/trunk/doxia-core/src/main/java/org/apache/maven/doxia/util/HtmlTools.java
> URL: http://svn.apache.org/viewvc/maven/doxia/doxia/trunk/doxia-core/src/main/java/org/apache/maven/doxia/util/HtmlTools.java?rev=776294&r1=776293&r2=776294&view=diff
> ==============================================================================
> --- maven/doxia/doxia/trunk/doxia-core/src/main/java/org/apache/maven/doxia/util/HtmlTools.java (original)
> +++ maven/doxia/doxia/trunk/doxia-core/src/main/java/org/apache/maven/doxia/util/HtmlTools.java Tue May 19 12:36:02 2009
> @@ -207,7 +207,7 @@
> * @return a new unescaped <code>String</code>, <code>null</code> if null string input.
> * @since 1.1.1.
> */
> - public static String unescapeHtml( String text )
> + public static String unescapeHTML( String text )
> {
> if ( text == null )
> {
>
> Modified: maven/doxia/doxia/trunk/doxia-core/src/test/java/org/apache/maven/doxia/util/HtmlToolsTest.java
> URL: http://svn.apache.org/viewvc/maven/doxia/doxia/trunk/doxia-core/src/test/java/org/apache/maven/doxia/util/HtmlToolsTest.java?rev=776294&r1=776293&r2=776294&view=diff
> ==============================================================================
> --- maven/doxia/doxia/trunk/doxia-core/src/test/java/org/apache/maven/doxia/util/HtmlToolsTest.java (original)
> +++ maven/doxia/doxia/trunk/doxia-core/src/test/java/org/apache/maven/doxia/util/HtmlToolsTest.java Tue May 19 12:36:02 2009
> @@ -56,22 +56,22 @@
> */
> public void testUnescapeHTML()
> {
> - assertNull( HtmlTools.unescapeHtml( null ) );
> - assertEquals( "", HtmlTools.unescapeHtml( "" ) );
> - assertEquals( "<", HtmlTools.unescapeHtml( "<" ) );
> - assertEquals( ">", HtmlTools.unescapeHtml( ">" ) );
> - assertEquals( "&", HtmlTools.unescapeHtml( "&" ) );
> - assertEquals( "\"", HtmlTools.unescapeHtml( """ ) );
> - assertEquals( "&", HtmlTools.unescapeHtml( "&" ) );
> - assertEquals( "<Français>", HtmlTools.unescapeHtml( "<Français>" ) );
> - assertEquals( "\u0159", HtmlTools.unescapeHtml( "ř" ) );
> - assertEquals( "\uD808\uDF45", HtmlTools.unescapeHtml( "𒍅" ) );
> - assertEquals( "\uD835\uDFED", HtmlTools.unescapeHtml( "𝟭" ) );
> - assertEquals( "\uD808\uDF45\uD835\uDFED", HtmlTools.unescapeHtml( "𒍅𝟭" ) );
> + assertNull( HtmlTools.unescapeHTML( null ) );
> + assertEquals( "", HtmlTools.unescapeHTML( "" ) );
> + assertEquals( "<", HtmlTools.unescapeHTML( "<" ) );
> + assertEquals( ">", HtmlTools.unescapeHTML( ">" ) );
> + assertEquals( "&", HtmlTools.unescapeHTML( "&" ) );
> + assertEquals( "\"", HtmlTools.unescapeHTML( """ ) );
> + assertEquals( "&", HtmlTools.unescapeHTML( "&" ) );
> + assertEquals( "<Français>", HtmlTools.unescapeHTML( "<Français>" ) );
> + assertEquals( "\u0159", HtmlTools.unescapeHTML( "ř" ) );
> + assertEquals( "\uD808\uDF45", HtmlTools.unescapeHTML( "𒍅" ) );
> + assertEquals( "\uD835\uDFED", HtmlTools.unescapeHTML( "𝟭" ) );
> + assertEquals( "\uD808\uDF45\uD835\uDFED", HtmlTools.unescapeHTML( "𒍅𝟭" ) );
>
> try
> {
> - HtmlTools.unescapeHtml( "test 𝟭 test" );
> + HtmlTools.unescapeHTML( "test 𝟭 test" );
> assertTrue( false );
> }
> catch ( IllegalArgumentException e )
>
> Modified: maven/doxia/doxia/trunk/doxia-modules/doxia-module-xdoc/src/main/java/org/apache/maven/doxia/module/xdoc/XdocParser.java
> URL: http://svn.apache.org/viewvc/maven/doxia/doxia/trunk/doxia-modules/doxia-module-xdoc/src/main/java/org/apache/maven/doxia/module/xdoc/XdocParser.java?rev=776294&r1=776293&r2=776294&view=diff
> ==============================================================================
> --- maven/doxia/doxia/trunk/doxia-modules/doxia-module-xdoc/src/main/java/org/apache/maven/doxia/module/xdoc/XdocParser.java (original)
> +++ maven/doxia/doxia/trunk/doxia-modules/doxia-module-xdoc/src/main/java/org/apache/maven/doxia/module/xdoc/XdocParser.java Tue May 19 12:36:02 2009
> @@ -185,7 +185,7 @@
>
> sink.sectionTitle( Sink.SECTION_LEVEL_1, attribs );
>
> - sink.text( HtmlTools.unescapeHtml( parser.getAttributeValue( null, Attribute.NAME.toString() ) ) );
> + sink.text( HtmlTools.unescapeHTML( parser.getAttributeValue( null, Attribute.NAME.toString() ) ) );
>
> sink.sectionTitle1_();
> }
> @@ -204,7 +204,7 @@
>
> sink.sectionTitle( Sink.SECTION_LEVEL_2, attribs );
>
> - sink.text( HtmlTools.unescapeHtml( parser.getAttributeValue( null, Attribute.NAME.toString() ) ) );
> + sink.text( HtmlTools.unescapeHTML( parser.getAttributeValue( null, Attribute.NAME.toString() ) ) );
>
> sink.sectionTitle2_();
> }
>
>
>

--
Dennis Lundberg

Re: svn commit: r769769 - in /maven/doxia/doxia/trunk: ./ doxia-book/ doxia-core/ doxia-logging-api/ doxia-maven-plugin/ doxia-modules/ doxia-modules/doxia-module-apt/ doxia-modules/doxia-module-confluence/ doxia-modules/doxia-module-docbook-simple/ doxia-...

2009-05-14T04:03:23Z

It worked without hiccups this time. That's my favorite problem-solving-strategy:
just sit and wait until it goes away! :)

Thanks for the pointers anyway!

-Lukas

PS just in case: the vote is open on the maven-dev list

Dennis Lundberg wrote:

> Just wait a few minutes and the run 'mvn release:prepare' one more time.
> It will pick up from where it stopped.
>
> Lukas Theussl wrote:
>> I keep getting this error when running release:prepare:
>>
>>
>> [INFO]
>> ------------------------------------------------------------------------
>> [ERROR] BUILD FAILURE
>> [INFO]
>> ------------------------------------------------------------------------
>> [INFO] Unable to tag SCM
>> Provider message:
>> The svn tag command failed.
>> Command output:
>> svn: Commit failed (details follow):
>> svn: The specified baseline is not the latest baseline, so it may not be
>> checked out.
>>
>>
>> Raphael has reported the same problem with the archetype-plugin [1]. I
>> have also found some hints that it might be due to lagging sync of the
>> eu svn mirror so I switched back to https://svn.apache.org/ but still
>> get the same error.
>>
>> Anybody has some more hints? I'm giving up for now...
>>
>> -Lukas
>>
>>
>> [1] http://www.mail-archive.com/dev@.../msg80254.html
>>
>>
>> ltheussl@... wrote:
>>> Author: ltheussl
>>> Date: Wed Apr 29 12:18:58 2009
>>> New Revision: 769769
>>>
>>> URL: http://svn.apache.org/viewvc?rev=769769&view=rev
>>> Log:
>>> Undo again, sigh...
>>>
>>> Modified:
>>> maven/doxia/doxia/trunk/doxia-book/pom.xml
>>> maven/doxia/doxia/trunk/doxia-core/pom.xml
>>> maven/doxia/doxia/trunk/doxia-logging-api/pom.xml
>>> maven/doxia/doxia/trunk/doxia-maven-plugin/pom.xml
>>> maven/doxia/doxia/trunk/doxia-modules/doxia-module-apt/pom.xml
>>> maven/doxia/doxia/trunk/doxia-modules/doxia-module-confluence/pom.xml
>>>
>>> maven/doxia/doxia/trunk/doxia-modules/doxia-module-docbook-simple/pom.xml
>>> maven/doxia/doxia/trunk/doxia-modules/doxia-module-fml/pom.xml
>>> maven/doxia/doxia/trunk/doxia-modules/doxia-module-fo/pom.xml
>>> maven/doxia/doxia/trunk/doxia-modules/doxia-module-itext/pom.xml
>>> maven/doxia/doxia/trunk/doxia-modules/doxia-module-latex/pom.xml
>>> maven/doxia/doxia/trunk/doxia-modules/doxia-module-rtf/pom.xml
>>> maven/doxia/doxia/trunk/doxia-modules/doxia-module-twiki/pom.xml
>>> maven/doxia/doxia/trunk/doxia-modules/doxia-module-xdoc/pom.xml
>>> maven/doxia/doxia/trunk/doxia-modules/doxia-module-xhtml/pom.xml
>>> maven/doxia/doxia/trunk/doxia-modules/pom.xml
>>> maven/doxia/doxia/trunk/doxia-sink-api/pom.xml
>>> maven/doxia/doxia/trunk/doxia-test-docs/pom.xml
>>> maven/doxia/doxia/trunk/pom.xml
>>>
>> [snip]
>>
>
>

Re: entities: text or rawText?

2009-05-13T04:43:16Z

For reference: the XhtmlBaseParser in Doxia 1.1.1 emits entities as text, except
if they are not recognized (ie haven't been declared), then they are emitted as
unknown events.

-Lukas

Vincent Siveton wrote:

> Hi Lukas,
>
> 2009/5/4 Lukas Theussl <ltheussl@...>:
>> Vincent,
>>
>> I'm trying to understand some of the issues we have with entities in the
>> XmlParser. Is there a special reason why entities are emitted as rawText and
>> not text?
>
> The text used by XhtmlBaseParser#handleEntity() could contain
> predefined entities [1] and numeric code entities (ie Æ will
> become Æ by XmlPullParser)
> XhtmlBaseSink#text() escapes chars and XhtmlBaseSink#rawText() not.
>
> So using rawText() is to be sure to not escape text with entities.
>
>> I think they should be emitted as text:
>>
>> First, custom entities can be used to simply define some replacement text
>> inside documents (eg <!ENTITY version "1.0">).
>>
>> Second, the resulting events should be consumable by all sinks, not just
>> x(ht)ml based ones. Consider for instance the text "&Æ" (where
>> AElig is defined as <!ENTITY AElig "Æ">). Currently it is emitted by
>> the XhtmlBaseParser as one text event "&" and one rawText event "Æ".
>> This means that eg the Latex Sink will produce wrong output (the AElig
>> should be converted to "\AE" in latex).
>>
>> IMO the resolved entity should be emitted in a format-independent way, eg as
>> one (unicode?) character, just like & is emitted as one character above.
>> The consuming sink then has to transform that into a format-specific
>> representation.
>
> It could be another implementation.
> XhtmlBaseParser#handleEntity() could unescape xml and call only sink.text()
>
> Cheers,
>
> Vincent
>
> [1] http://www.w3.org/TR/2004/REC-xml11-20040204/#sec-predefined-ent
>

Re: entities: text or rawText?

2009-05-04T03:57:07Z

Hi Lukas,

2009/5/4 Lukas Theussl <ltheussl@...>:
>
> Vincent,
>
> I'm trying to understand some of the issues we have with entities in the
> XmlParser. Is there a special reason why entities are emitted as rawText and
> not text?

The text used by XhtmlBaseParser#handleEntity() could contain
predefined entities [1] and numeric code entities (ie Æ will
become Æ by XmlPullParser)
XhtmlBaseSink#text() escapes chars and XhtmlBaseSink#rawText() not.

So using rawText() is to be sure to not escape text with entities.

> I think they should be emitted as text:
>
> First, custom entities can be used to simply define some replacement text
> inside documents (eg <!ENTITY version "1.0">).
>
> Second, the resulting events should be consumable by all sinks, not just
> x(ht)ml based ones. Consider for instance the text "&Æ" (where
> AElig is defined as <!ENTITY AElig "Æ">). Currently it is emitted by
> the XhtmlBaseParser as one text event "&" and one rawText event "Æ".
> This means that eg the Latex Sink will produce wrong output (the AElig
> should be converted to "\AE" in latex).
>
> IMO the resolved entity should be emitted in a format-independent way, eg as
> one (unicode?) character, just like & is emitted as one character above.
> The consuming sink then has to transform that into a format-specific
> representation.

It could be another implementation.
XhtmlBaseParser#handleEntity() could unescape xml and call only sink.text()

Cheers,

Vincent

[1] http://www.w3.org/TR/2004/REC-xml11-20040204/#sec-predefined-ent

entities: text or rawText?

2009-05-04T02:47:33Z

Vincent,

I'm trying to understand some of the issues we have with entities in the
XmlParser. Is there a special reason why entities are emitted as rawText and not text?

I think they should be emitted as text:

First, custom entities can be used to simply define some replacement text inside
documents (eg <!ENTITY version "1.0">).

Second, the resulting events should be consumable by all sinks, not just x(ht)ml
based ones. Consider for instance the text "&Æ" (where AElig is defined
as <!ENTITY AElig "Æ">). Currently it is emitted by the XhtmlBaseParser as
one text event "&" and one rawText event "Æ". This means that eg the Latex
Sink will produce wrong output (the AElig should be converted to "\AE" in latex).

IMO the resolved entity should be emitted in a format-independent way, eg as one
(unicode?) character, just like & is emitted as one character above. The
consuming sink then has to transform that into a format-specific representation.

WDYT?
-Lukas

Re: svn commit: r769769 - in /maven/doxia/doxia/trunk: ./ doxia-book/ doxia-core/ doxia-logging-api/ doxia-maven-plugin/ doxia-modules/ doxia-modules/doxia-module-apt/ doxia-modules/doxia-module-confluence/ doxia-modules/doxia-module-docbook-simple/ doxia-...

2009-05-02T13:21:04Z

Just wait a few minutes and the run 'mvn release:prepare' one more time.
It will pick up from where it stopped.

Lukas Theussl wrote:

>
> I keep getting this error when running release:prepare:
>
>
> [INFO]
> ------------------------------------------------------------------------
> [ERROR] BUILD FAILURE
> [INFO]
> ------------------------------------------------------------------------
> [INFO] Unable to tag SCM
> Provider message:
> The svn tag command failed.
> Command output:
> svn: Commit failed (details follow):
> svn: The specified baseline is not the latest baseline, so it may not be
> checked out.
>
>
> Raphael has reported the same problem with the archetype-plugin [1]. I
> have also found some hints that it might be due to lagging sync of the
> eu svn mirror so I switched back to https://svn.apache.org/ but still
> get the same error.
>
> Anybody has some more hints? I'm giving up for now...
>
> -Lukas
>
>
> [1] http://www.mail-archive.com/dev@.../msg80254.html
>
>
> ltheussl@... wrote:
>> Author: ltheussl
>> Date: Wed Apr 29 12:18:58 2009
>> New Revision: 769769
>>
>> URL: http://svn.apache.org/viewvc?rev=769769&view=rev
>> Log:
>> Undo again, sigh...
>>
>> Modified:
>> maven/doxia/doxia/trunk/doxia-book/pom.xml
>> maven/doxia/doxia/trunk/doxia-core/pom.xml
>> maven/doxia/doxia/trunk/doxia-logging-api/pom.xml
>> maven/doxia/doxia/trunk/doxia-maven-plugin/pom.xml
>> maven/doxia/doxia/trunk/doxia-modules/doxia-module-apt/pom.xml
>> maven/doxia/doxia/trunk/doxia-modules/doxia-module-confluence/pom.xml
>>
>> maven/doxia/doxia/trunk/doxia-modules/doxia-module-docbook-simple/pom.xml
>> maven/doxia/doxia/trunk/doxia-modules/doxia-module-fml/pom.xml
>> maven/doxia/doxia/trunk/doxia-modules/doxia-module-fo/pom.xml
>> maven/doxia/doxia/trunk/doxia-modules/doxia-module-itext/pom.xml
>> maven/doxia/doxia/trunk/doxia-modules/doxia-module-latex/pom.xml
>> maven/doxia/doxia/trunk/doxia-modules/doxia-module-rtf/pom.xml
>> maven/doxia/doxia/trunk/doxia-modules/doxia-module-twiki/pom.xml
>> maven/doxia/doxia/trunk/doxia-modules/doxia-module-xdoc/pom.xml
>> maven/doxia/doxia/trunk/doxia-modules/doxia-module-xhtml/pom.xml
>> maven/doxia/doxia/trunk/doxia-modules/pom.xml
>> maven/doxia/doxia/trunk/doxia-sink-api/pom.xml
>> maven/doxia/doxia/trunk/doxia-test-docs/pom.xml
>> maven/doxia/doxia/trunk/pom.xml
>>
>
> [snip]
>

--
Dennis Lundberg

Re: svn commit: r769769 - in /maven/doxia/doxia/trunk: ./ doxia-book/ doxia-core/ doxia-logging-api/ doxia-maven-plugin/ doxia-modules/ doxia-modules/doxia-module-apt/ doxia-modules/doxia-module-confluence/ doxia-modules/doxia-module-docbook-simple/ doxia-...

2009-04-29T14:17:15Z

Lukas Theussl wrote:

> Raphael has reported the same problem with the archetype-plugin [1]. I
> have also found some hints that it might be due to lagging sync of the
> eu svn mirror so I switched back to https://svn.apache.org/ but still
> get the same error.

AFAIK, since recently svn.apache.org is resolved using geo DNS [0] so
you likely still get the EU mirror with the lagging problem.

> Anybody has some more hints? I'm giving up for now...

I haven't tried with SVN but if you relocate your working copy to
eris.apache.org, i.e. use the machine name rather the service name, you
should enforce the master instead of harmonia. That's at least what I
see from tracert.

Benjamin

[0]
http://mail-archives.apache.org/mod_mbox/www-infrastructure-dev/200904.mbox/%3C4239a4320904011536x5726d0eraae7065967ac1b77@...%3E

Re: svn commit: r769769 - in /maven/doxia/doxia/trunk: ./ doxia-book/ doxia-core/ doxia-logging-api/ doxia-maven-plugin/ doxia-modules/ doxia-modules/doxia-module-apt/ doxia-modules/doxia-module-confluence/ doxia-modules/doxia-module-docbook-simple/

2009-04-29T05:53:16Z

Be sure to do a svn update before running maven
BTW you could always reprepare the process.

Cheers,

Vincent

2009/4/29, Lukas Theussl <ltheussl@...>:

>
> I keep getting this error when running release:prepare:
>
>
> [INFO]
> ------------------------------------------------------------------------
> [ERROR] BUILD FAILURE
> [INFO]
> ------------------------------------------------------------------------
> [INFO] Unable to tag SCM
> Provider message:
> The svn tag command failed.
> Command output:
> svn: Commit failed (details follow):
> svn: The specified baseline is not the latest baseline, so it may not be
> checked out.
>
>
> Raphael has reported the same problem with the archetype-plugin [1]. I have
> also found some hints that it might be due to lagging sync of the eu svn
> mirror so I switched back to https://svn.apache.org/ but still get the same
> error.
>
> Anybody has some more hints? I'm giving up for now...
>
> -Lukas
>
>
> [1]
> http://www.mail-archive.com/dev@.../msg80254.html
>
>
>
> ltheussl@... wrote:
>
> > Author: ltheussl
> > Date: Wed Apr 29 12:18:58 2009
> > New Revision: 769769
> >
> > URL: http://svn.apache.org/viewvc?rev=769769&view=rev
> > Log:
> > Undo again, sigh...
> >
> > Modified:
> > maven/doxia/doxia/trunk/doxia-book/pom.xml
> > maven/doxia/doxia/trunk/doxia-core/pom.xml
> > maven/doxia/doxia/trunk/doxia-logging-api/pom.xml
> > maven/doxia/doxia/trunk/doxia-maven-plugin/pom.xml
> >
> maven/doxia/doxia/trunk/doxia-modules/doxia-module-apt/pom.xml
> >
> maven/doxia/doxia/trunk/doxia-modules/doxia-module-confluence/pom.xml
> >
> maven/doxia/doxia/trunk/doxia-modules/doxia-module-docbook-simple/pom.xml
> >
> maven/doxia/doxia/trunk/doxia-modules/doxia-module-fml/pom.xml
> >
> maven/doxia/doxia/trunk/doxia-modules/doxia-module-fo/pom.xml
> >
> maven/doxia/doxia/trunk/doxia-modules/doxia-module-itext/pom.xml
> >
> maven/doxia/doxia/trunk/doxia-modules/doxia-module-latex/pom.xml
> >
> maven/doxia/doxia/trunk/doxia-modules/doxia-module-rtf/pom.xml
> >
> maven/doxia/doxia/trunk/doxia-modules/doxia-module-twiki/pom.xml
> >
> maven/doxia/doxia/trunk/doxia-modules/doxia-module-xdoc/pom.xml
> >
> maven/doxia/doxia/trunk/doxia-modules/doxia-module-xhtml/pom.xml
> > maven/doxia/doxia/trunk/doxia-modules/pom.xml
> > maven/doxia/doxia/trunk/doxia-sink-api/pom.xml
> > maven/doxia/doxia/trunk/doxia-test-docs/pom.xml
> > maven/doxia/doxia/trunk/pom.xml
> >
> >
>
> [snip]
>

Re: svn commit: r769769 - in /maven/doxia/doxia/trunk: ./ doxia-book/ doxia-core/ doxia-logging-api/ doxia-maven-plugin/ doxia-modules/ doxia-modules/doxia-module-apt/ doxia-modules/doxia-module-confluence/ doxia-modules/doxia-module-docbook-simple/ doxia-...

2009-04-29T05:30:23Z

I keep getting this error when running release:prepare:

[INFO] ------------------------------------------------------------------------
[ERROR] BUILD FAILURE
[INFO] ------------------------------------------------------------------------
[INFO] Unable to tag SCM
Provider message:
The svn tag command failed.
Command output:
svn: Commit failed (details follow):
svn: The specified baseline is not the latest baseline, so it may not be checked out.

Raphael has reported the same problem with the archetype-plugin [1]. I have also
found some hints that it might be due to lagging sync of the eu svn mirror so I
switched back to https://svn.apache.org/ but still get the same error.

Anybody has some more hints? I'm giving up for now...

-Lukas

[1] http://www.mail-archive.com/dev@.../msg80254.html

ltheussl@... wrote:

> Author: ltheussl
> Date: Wed Apr 29 12:18:58 2009
> New Revision: 769769
>
> URL: http://svn.apache.org/viewvc?rev=769769&view=rev
> Log:
> Undo again, sigh...
>
> Modified:
> maven/doxia/doxia/trunk/doxia-book/pom.xml
> maven/doxia/doxia/trunk/doxia-core/pom.xml
> maven/doxia/doxia/trunk/doxia-logging-api/pom.xml
> maven/doxia/doxia/trunk/doxia-maven-plugin/pom.xml
> maven/doxia/doxia/trunk/doxia-modules/doxia-module-apt/pom.xml
> maven/doxia/doxia/trunk/doxia-modules/doxia-module-confluence/pom.xml
> maven/doxia/doxia/trunk/doxia-modules/doxia-module-docbook-simple/pom.xml
> maven/doxia/doxia/trunk/doxia-modules/doxia-module-fml/pom.xml
> maven/doxia/doxia/trunk/doxia-modules/doxia-module-fo/pom.xml
> maven/doxia/doxia/trunk/doxia-modules/doxia-module-itext/pom.xml
> maven/doxia/doxia/trunk/doxia-modules/doxia-module-latex/pom.xml
> maven/doxia/doxia/trunk/doxia-modules/doxia-module-rtf/pom.xml
> maven/doxia/doxia/trunk/doxia-modules/doxia-module-twiki/pom.xml
> maven/doxia/doxia/trunk/doxia-modules/doxia-module-xdoc/pom.xml
> maven/doxia/doxia/trunk/doxia-modules/doxia-module-xhtml/pom.xml
> maven/doxia/doxia/trunk/doxia-modules/pom.xml
> maven/doxia/doxia/trunk/doxia-sink-api/pom.xml
> maven/doxia/doxia/trunk/doxia-test-docs/pom.xml
> maven/doxia/doxia/trunk/pom.xml
>

[snip]

Re: surefire forkMode setting

2009-04-03T03:40:05Z

Go ahead.

Cheers,

Vincent

2009/4/3 Lukas Theussl <ltheussl@...>:

>
> Hi,
>
> Is there any reason why we have this setting in the doxia parent pom:
>
> <plugin>
> <artifactId>maven-surefire-plugin</artifactId>
> <configuration>
> <forkMode>never</forkMode>
> </configuration>
> </plugin>
>
>
>
> I just noticed that this is the cause of cobertura reporting 0% coverage
> everywhere, see eg [1] (this is the same as reported at [2]). Leaving the
> forkMode at once (the default), cobertura works correctly. Any objections to
> remove that part?
>
> -Lukas
>
>
> [1] http://maven.apache.org/doxia/doxia/doxia-core/cobertura/index.html
> [2] http://jira.codehaus.org/browse/MCOBERTURA-70
>

surefire forkMode setting

2009-04-03T00:11:45Z

Hi,

Is there any reason why we have this setting in the doxia parent pom:

<plugin>
<artifactId>maven-surefire-plugin</artifactId>
<configuration>
<forkMode>never</forkMode>
</configuration>
</plugin>

I just noticed that this is the cause of cobertura reporting 0% coverage
everywhere, see eg [1] (this is the same as reported at [2]). Leaving the forkMode
at once (the default), cobertura works correctly. Any objections to remove that part?

-Lukas

[1] http://maven.apache.org/doxia/doxia/doxia-core/cobertura/index.html
[2] http://jira.codehaus.org/browse/MCOBERTURA-70

Re: Merging with XWiki and WikiModel

2009-03-08T13:22:08Z

Hi Herve,

On Mar 8, 2009, at 2:53 PM, Hervé BOUTEMY wrote:

> Vincent,
>
> After our discussion on IRC, I perfectly understand how we could
> benefit from
> convergence in the domain of document parsing and rendering, with the
> advantage of not only more developpers, but more users too, then
> more tests.

yep.

Regarding tests we have more than 900 unit tests overall for the XWiki
Rendering engine. This is absolutely needed because parsing/rendering
seems an easy task but it's really complex when you tackle edge cases.
We would never have been able to code a strong bi-directional wiki <--
> XHTML conversion without these tests.

> Vincent Siveton did a great job with an Eclipse plugin that was
> integrated in
> m2eclipse, but:
> - this is only Eclipse-centric, how about other IDE's?
> - it would still need a lot of work to continue improve it (it
> actually helps
> me a lot when editing pages, no show-stopper bugs: only minor things)
>> - our brand new GWT-based WYSIWYG editor
> Is there something in XWiki to help editing pages that are on local
> disk (and
> stored in svn)?

There's a Storage interface. Currently we have one implementation for
Hibernate and another for JCR. It's possible to add one SVN but nobody
has been working on this.
Re local disk, I guess the JCR implementation could be used for that.

> Would this GWT-based WYSIWYG editor help here? Or is it only
> web-centric?

The WYSIWYG editor is a web-based editor of course but it takes its
content from any XHTML content (which can be generated by the XWiki
Rendering from any source).

Thanks
-Vincent

> Regards,
>
> Hervé
>
> Le lundi 02 février 2009, Vincent Massol a écrit :
>> Hi there,
>>
>> On Jan 31, 2009, at 12:04 AM, Vincent Siveton wrote:
>>> Hi Jason,
>>>
>>> 2009/1/29 Jason van Zyl <jason@...>:
>>>> Howdy,
>>>>
>>>> I've been looking at reporting in Maven 3.x and I've been following
>>>> the work
>>>> that Vincent Massol has been doing over at XWiki where he has made
>>>> some
>>>> attempts at melding Doxia, the XWiki rendering engine, and
>>>> WikiModel. You
>>>> can see the proposal here:
>>>>
>>>> http://dev.xwiki.org/xwiki/bin/view/Design/RenderingEngineConvergence
>>>>
>>>> I am looking to remove the Doxia dependency from Maven 3.x so that
>>>> reporting
>>>> is removed from core and just becomes another set of components.
>>>> Having
>>>
>>> I definitely agree to decouple Maven from Doxia, or conversely :)
>>> We actually have a lot of problems due to this coupling, see
>>> MNG-3402.
>>>
>>>> Doxia coupled to Maven is not very nice so in the next couple
>>>> releases of
>>>> the Maven 3.x alphas the hard dependency on Doxia will be removed.
>>>> This will
>>>> open the door for anyone who wants to add a different mechanism.
>>>> Doxia
>>>> reports will still work, I'm not planning on removing the
>>>> functionality just
>>>> unbinding it from the core. But that opens the door for something
>>>> new!
>>>
>>> Some questions to clarify what you have in mind:
>>> - how do you plan to integrate reporting concretely to Maven 3?
>>> - what about the backward compatibility in the reporting plugins?
>>>
>>>> What I personally think the best path would be is to help what
>>>> Vincent has
>>>> started. There are really only three people here who work on Doxia,
>>>> the
>>>> releases are very slow in coming and I think you would immediately
>>>> double or
>>>
>>> Agree but we work when we have time :)
>>> @Dennis: what are your availabilities to release the version 1.0?
>>> After this release, 1.1 could be out, IMHO all stuffs are there.
>>>
>>>> triple the size of the team merging with the XWiki folks and
>>>> getting the
>>>> WikiModel developer as well. This is what the XWiki folks do all
>>>> the time
>>>> and I think you would get some more velocity in the progress of the
>>>> project
>>>> as a whole. Vincent is using Plexus for his stuff so it's not that
>>>> wildly
>>>> different but I think you would get more visibility over there and
>>>> a higher
>>>
>>> The xwiki proposal seems to move the Doxia code to the xwiki
>>> umbrella,
>>> so do you plan to do it?
>>>
>>> @Vincent, could you clarify why a fork is not possible for you?
>>
>> Let me explain the point of view of the xwiki community (I hope I'm
>> summarizing it well here):
>>
>> * XWiki is not a wiki. It's a platform offering wiki components to
>> develop any type of content-centric web application based on the wiki
>> paradigm.
>>
>> * We've started reorganizing ourselves to implement this vision back
>> in 2007. We've started by decoupling our monolithic code into modules
>> and components (using Plexus).
>>
>> * We're not finding that there are some important pieces that we want
>> to make top level projects, independent of the other xwiki modules/
>> components. For the moment we have identified 2 pieces:
>> - the rendering engine
>> - our brand new GWT-based WYSIWYG editor
>>
>> * We could propose these under new projects at the ASF for example.
>> These are the reasons preventing us from doing so right now:
>> - we'd like to promote the XWiki project name as the place where to
>> get wiki "components". If we start splitting the rendering engine or
>> the wysiwyg editor we won't achieve this
>> - having to implement and support several projects (the xwiki one +
>> the engine one at ASF + the wysiwyg one wherever else
>> (@code.google.org for ex)) is going to spread our committer base thin
>> achieving the opposite as what we want to achieve which is making all
>> people interested on working on wiki "components" together.
>> - we have a very good infrastructure team and we completely host
>> all our tools. We like it this way since it's real fast and it works
>> real well and we can only complain to ourselves if something is not
>> right and we can fix it right away. Note that the infra is paid by
>> XWiki SAS (a company offering services on top of the xwiki oss
>> project
>> - See http://tinyurl.com/7c488p for more details)
>> - basically we can work faster if the code is on the xwiki svn
>>
>> It's possible that one day we'll propose the whole project to the ASF
>> but I don't think we're ready for that yet. For the moment we like it
>> the way we are able to progress fast and we don't feel the need.
>>
>> Note that xwiki projects are currently under the LGPL but we can
>> discuss making the new rendering engine (which would be the merge
>> between doxia, xwiki and wikimodel ) under the ASL if you feel this
>> is
>> better.
>>
>> Now why are we interested in merging them all? Actually that wasn't
>> our idea. It was Jason's. We were fine developing and progressing
>> fast
>> on our own xwiki rendering engine. But at the same time it's true
>> that
>> I've realized it was a pity that XWiki/WikiModel and Doxia are re-
>> developing the same things instead of collaborating and working on
>> building something together. So I see 2 win-win advantages for us
>> all:
>> - for Doxia this can be a way to make it live on and be active again,
>> with even more features and better support
>> - for XWiki we would love to get some new committers on board to help
>> us with the rendering engine (we currently have about 3 committers
>> active on it either full time or part time). In addition the merge
>> between these 3 engines (xwiki/wikimodel/doxia) would create a new
>> rendering engine that could easily be the best rendering engine on
>> the
>> web. For us one advantage would be to spread the xwiki name even more
>> and thus get more contributors and users of the xwiki "components"
>> and
>> applications.
>>
>> Last, while I see it very interesting to everyone to perform this
>> merge, I can understand if some people would prefer to continue
>> working on what they do on their side without merging. That's fine
>> and
>> I'm not going to fight for doing the merge at all cost. Especially
>> since doing the merge is going to be costly for us in term of time/
>> effort. For it to be worthwhile we must all agree to it and like the
>> idea.
>>
>> So what happens if the merge isn't done? On the xwiki side we'll
>> continue to improve our rendering engine fast (we're progressing very
>> fast right now since we have very active committers and since the
>> rendering is actively used in all the xwiki applications this will
>> continue). Even though we have a Doxia bridge we're not using it for
>> different reasons but one of them is that the Doxia parsers we've
>> tried were not good enough. I remember trying the confluence one and
>> it was very buggy. So I was just waiting for the need to use the
>> confluence parser to arise before rewriting it using wikimodel
>> (it's a
>> one day job at max to get a very strong parser, thanks to wikimodel
>> tools).
>>
>> Merging has its share or work required on both sides but it's the
>> best
>> option in the end IMO. Now it's for you to decide if this has enough
>> interest for Doxia.
>>
>> Cheers,
>> -Vincent
>>
>> PS: If you want to see how the xwiki project is managed read
>> http://tinyurl.com/7c488p and go to http://dev.xwiki.org which
>> contains all
>> our dev practices
>>
>>> Cheers,
>>>
>>> Vincent
>>>
>>>> degree of collaboration. I think you would also get a model that is
>>>> more
>>>> complete for things like blogs, wikis, and books.
>>>>
>>>> Any thoughts? I've CC'd Vincent too as I'm not sure he's on this
>>>> list.
>>>>
>>>> Thanks,
>>>>
>>>> Jason
>
>

Re: Merging with XWiki and WikiModel

2009-03-08T07:04:14Z

I'm cross-posting this between Doxia and Maven dev lists, because this has
both interests.

Le samedi 31 janvier 2009, Jason van Zyl a écrit :

> On 30-Jan-09, at 3:04 PM, Vincent Siveton wrote:
> > Hi Jason,
> >
> > 2009/1/29 Jason van Zyl <jason@...>:
> >> Howdy,
> >>
> >> I've been looking at reporting in Maven 3.x and I've been following
> >> the work
> >> that Vincent Massol has been doing over at XWiki where he has made
> >> some
> >> attempts at melding Doxia, the XWiki rendering engine, and
> >> WikiModel. You
> >> can see the proposal here:
> >>
> >> http://dev.xwiki.org/xwiki/bin/view/Design/RenderingEngineConvergence
> >>
> >> I am looking to remove the Doxia dependency from Maven 3.x so that
> >> reporting
> >> is removed from core and just becomes another set of components.
> >> Having
> >
> > I definitely agree to decouple Maven from Doxia, or conversely :)
> > We actually have a lot of problems due to this coupling, see MNG-3402.
> >
> >> Doxia coupled to Maven is not very nice so in the next couple
> >> releases of
> >> the Maven 3.x alphas the hard dependency on Doxia will be removed.
> >> This will
> >> open the door for anyone who wants to add a different mechanism.
> >> Doxia
> >> reports will still work, I'm not planning on removing the
> >> functionality just
> >> unbinding it from the core. But that opens the door for something
> >> new!
> >
> > Some questions to clarify what you have in mind:
> > - how do you plan to integrate reporting concretely to Maven 3?
>
> As a completely separate execution environment. So the plugin manager
> in 3.x will only deal with build plugins. Then a separate plugin
> manager can be created for Doxia based reports and those will map to
> the current reporting element. Then I would like to create another
> execution environment for a more data centric report model.

the idea is interesting.
Is there something somewhere on this? How can I help?
The key plugin is maven-site-plugin: a new branch?

Regards,

Hervé

Re: Merging with XWiki and WikiModel

2009-03-08T06:53:48Z

Vincent,

After our discussion on IRC, I perfectly understand how we could benefit from
convergence in the domain of document parsing and rendering, with the
advantage of not only more developpers, but more users too, then more tests.

Vincent Siveton did a great job with an Eclipse plugin that was integrated in
m2eclipse, but:
- this is only Eclipse-centric, how about other IDE's?
- it would still need a lot of work to continue improve it (it actually helps
me a lot when editing pages, no show-stopper bugs: only minor things)
> - our brand new GWT-based WYSIWYG editor
Is there something in XWiki to help editing pages that are on local disk (and
stored in svn)? Would this GWT-based WYSIWYG editor help here? Or is it only
web-centric?

Regards,

Hervé

Le lundi 02 février 2009, Vincent Massol a écrit :

> Hi there,
>
> On Jan 31, 2009, at 12:04 AM, Vincent Siveton wrote:
> > Hi Jason,
> >
> > 2009/1/29 Jason van Zyl <jason@...>:
> >> Howdy,
> >>
> >> I've been looking at reporting in Maven 3.x and I've been following
> >> the work
> >> that Vincent Massol has been doing over at XWiki where he has made
> >> some
> >> attempts at melding Doxia, the XWiki rendering engine, and
> >> WikiModel. You
> >> can see the proposal here:
> >>
> >> http://dev.xwiki.org/xwiki/bin/view/Design/RenderingEngineConvergence
> >>
> >> I am looking to remove the Doxia dependency from Maven 3.x so that
> >> reporting
> >> is removed from core and just becomes another set of components.
> >> Having
> >
> > I definitely agree to decouple Maven from Doxia, or conversely :)
> > We actually have a lot of problems due to this coupling, see MNG-3402.
> >
> >> Doxia coupled to Maven is not very nice so in the next couple
> >> releases of
> >> the Maven 3.x alphas the hard dependency on Doxia will be removed.
> >> This will
> >> open the door for anyone who wants to add a different mechanism.
> >> Doxia
> >> reports will still work, I'm not planning on removing the
> >> functionality just
> >> unbinding it from the core. But that opens the door for something
> >> new!
> >
> > Some questions to clarify what you have in mind:
> > - how do you plan to integrate reporting concretely to Maven 3?
> > - what about the backward compatibility in the reporting plugins?
> >
> >> What I personally think the best path would be is to help what
> >> Vincent has
> >> started. There are really only three people here who work on Doxia,
> >> the
> >> releases are very slow in coming and I think you would immediately
> >> double or
> >
> > Agree but we work when we have time :)
> > @Dennis: what are your availabilities to release the version 1.0?
> > After this release, 1.1 could be out, IMHO all stuffs are there.
> >
> >> triple the size of the team merging with the XWiki folks and
> >> getting the
> >> WikiModel developer as well. This is what the XWiki folks do all
> >> the time
> >> and I think you would get some more velocity in the progress of the
> >> project
> >> as a whole. Vincent is using Plexus for his stuff so it's not that
> >> wildly
> >> different but I think you would get more visibility over there and
> >> a higher
> >
> > The xwiki proposal seems to move the Doxia code to the xwiki umbrella,
> > so do you plan to do it?
> >
> > @Vincent, could you clarify why a fork is not possible for you?
>
> Let me explain the point of view of the xwiki community (I hope I'm
> summarizing it well here):
>
> * XWiki is not a wiki. It's a platform offering wiki components to
> develop any type of content-centric web application based on the wiki
> paradigm.
>
> * We've started reorganizing ourselves to implement this vision back
> in 2007. We've started by decoupling our monolithic code into modules
> and components (using Plexus).
>
> * We're not finding that there are some important pieces that we want
> to make top level projects, independent of the other xwiki modules/
> components. For the moment we have identified 2 pieces:
> - the rendering engine
> - our brand new GWT-based WYSIWYG editor
>
> * We could propose these under new projects at the ASF for example.
> These are the reasons preventing us from doing so right now:
> - we'd like to promote the XWiki project name as the place where to
> get wiki "components". If we start splitting the rendering engine or
> the wysiwyg editor we won't achieve this
> - having to implement and support several projects (the xwiki one +
> the engine one at ASF + the wysiwyg one wherever else
> (@code.google.org for ex)) is going to spread our committer base thin
> achieving the opposite as what we want to achieve which is making all
> people interested on working on wiki "components" together.
> - we have a very good infrastructure team and we completely host
> all our tools. We like it this way since it's real fast and it works
> real well and we can only complain to ourselves if something is not
> right and we can fix it right away. Note that the infra is paid by
> XWiki SAS (a company offering services on top of the xwiki oss project
> - See http://tinyurl.com/7c488p for more details)
> - basically we can work faster if the code is on the xwiki svn
>
> It's possible that one day we'll propose the whole project to the ASF
> but I don't think we're ready for that yet. For the moment we like it
> the way we are able to progress fast and we don't feel the need.
>
> Note that xwiki projects are currently under the LGPL but we can
> discuss making the new rendering engine (which would be the merge
> between doxia, xwiki and wikimodel ) under the ASL if you feel this is
> better.
>
> Now why are we interested in merging them all? Actually that wasn't
> our idea. It was Jason's. We were fine developing and progressing fast
> on our own xwiki rendering engine. But at the same time it's true that
> I've realized it was a pity that XWiki/WikiModel and Doxia are re-
> developing the same things instead of collaborating and working on
> building something together. So I see 2 win-win advantages for us all:
> - for Doxia this can be a way to make it live on and be active again,
> with even more features and better support
> - for XWiki we would love to get some new committers on board to help
> us with the rendering engine (we currently have about 3 committers
> active on it either full time or part time). In addition the merge
> between these 3 engines (xwiki/wikimodel/doxia) would create a new
> rendering engine that could easily be the best rendering engine on the
> web. For us one advantage would be to spread the xwiki name even more
> and thus get more contributors and users of the xwiki "components" and
> applications.
>
> Last, while I see it very interesting to everyone to perform this
> merge, I can understand if some people would prefer to continue
> working on what they do on their side without merging. That's fine and
> I'm not going to fight for doing the merge at all cost. Especially
> since doing the merge is going to be costly for us in term of time/
> effort. For it to be worthwhile we must all agree to it and like the
> idea.
>
> So what happens if the merge isn't done? On the xwiki side we'll
> continue to improve our rendering engine fast (we're progressing very
> fast right now since we have very active committers and since the
> rendering is actively used in all the xwiki applications this will
> continue). Even though we have a Doxia bridge we're not using it for
> different reasons but one of them is that the Doxia parsers we've
> tried were not good enough. I remember trying the confluence one and
> it was very buggy. So I was just waiting for the need to use the
> confluence parser to arise before rewriting it using wikimodel (it's a
> one day job at max to get a very strong parser, thanks to wikimodel
> tools).
>
> Merging has its share or work required on both sides but it's the best
> option in the end IMO. Now it's for you to decide if this has enough
> interest for Doxia.
>
> Cheers,
> -Vincent
>
> PS: If you want to see how the xwiki project is managed read
> http://tinyurl.com/7c488p and go to http://dev.xwiki.org which contains all
> our dev practices
>
> > Cheers,
> >
> > Vincent
> >
> >> degree of collaboration. I think you would also get a model that is
> >> more
> >> complete for things like blogs, wikis, and books.
> >>
> >> Any thoughts? I've CC'd Vincent too as I'm not sure he's on this
> >> list.
> >>
> >> Thanks,
> >>
> >> Jason

Re: Fwd: [ANN] Maven Doxia 1.1 Released

2009-03-08T06:36:38Z

Hi

2009/3/8 Hervé BOUTEMY <herve.boutemy@...>:
> I worked on the overview schema: see the new version attached to this mail.
> Please comment if you think other changes are needed before I commit it and
> update everyhting (the .png and imagemap).

+1 go for it

> I have one question though: if I export the schema as an image with OpenOffice
> 2.4, I et an image that is a lot bigger than the current one. How did you
> create the .png? Is it a discepency between our versions of OpenOffice (I'm
> working with 2.4 on Linux)?

It seems that it is no longer possible with 2.4.

Cheers,

Vincent

Re: Fwd: [ANN] Maven Doxia 1.1 Released

2009-03-08T06:09:16Z

great!
thank you Vincent.

I worked on the overview schema: see the new version attached to this mail.
Please comment if you think other changes are needed before I commit it and
update everyhting (the .png and imagemap).

I have one question though: if I export the schema as an image with OpenOffice
2.4, I et an image that is a lot bigger than the current one. How did you
create the .png? Is it a discepency between our versions of OpenOffice (I'm
working with 2.4 on Linux)?

Regards,

Hervé

Le dimanche 08 mars 2009, Vincent Siveton a écrit :

> ---------- Forwarded message ----------
> From: Vincent Siveton <vsiveton@...>
> Date: 2009/3/7
> Subject: [ANN] Maven Doxia 1.1 Released
> To: announce@..., users@...
>
>
> The Maven team is pleased to announce the release of the Maven Doxia,
> Doxia Sitetools, version 1.1 and Maven Doxia Tools, version 1.0.
>
> Doxia is a content generation framework which aims to provide its
> users with powerful techniques for generating static and dynamic
> content: Doxia can be used in web-based publishing context to generate
> static sites, in addition to being incorporated into dynamic content
> generation systems like blogs, wikis and content management systems.
>
> http://maven.apache.org/doxia/
>
> Release Notes - Maven Doxia - Version 1.1
>
> ** Bug
> * [DOXIA-51] - RtfSink supports only ".ppm" image type in
> figureGraphics() * [DOXIA-59] - Doxia creates files with inconsistent new
> lines
> * [DOXIA-99] - Figures require extension in APT and they should not
> * [DOXIA-127] - Twiki module cannot parse two forced links in the
> same paragraph
> * [DOXIA-148] - FmlParser emits HTML specific events
> * [DOXIA-152] - Xdoc parser shouldn't insert anchors for section titles
> * [DOXIA-156] - XhtmlSink#tableCell( boolean headerRow, String
> width ) uses a COLSPAN attribute instead of WIDTH attribute
> * [DOXIA-157] - Doxia Book doesn't work with xdoc source files
> * [DOXIA-160] - Book output in doc-book format is not well formed
> * [DOXIA-161] - filename with dot have a false output name
> * [DOXIA-162] - Failure to parse paragraph line with an EOL
> * [DOXIA-166] - Book output ignores book, chapter and section titles
> * [DOXIA-168] - Confluence module does not allow nested formatting
> - e.g. a bullet cannot contain *bold* text or a [link]
> * [DOXIA-169] - Confluence module does not recognize line breaks (\\)
> * [DOXIA-171] - Confluence "quote" macro not recognised
> * [DOXIA-173] - Support for Confluence anchor macro
> * [DOXIA-175] - Confluence module does not recognise backslash as
> escape character
> * [DOXIA-176] - Confluence parser doesn't strip leading space for
> section titles
> * [DOXIA-177] - Invalid XHTML because of wrong position of table caption
> * [DOXIA-178] - Confluence: nested wiki formats (e.g. bold italic)
> do not work
> * [DOXIA-180] - Confluence module should remove leading '#' from anchor
> link * [DOXIA-181] - Confluence ParagraphBlockParser does not offer
> lines to other parsers
> * [DOXIA-182] - Confluence support for img macro
> * [DOXIA-183] - Remove xhtml specific events from xdoc parser
> * [DOXIA-189] - newline added after every closing tag
> * [DOXIA-190] - text like (=something=) is parsed incorrectly
> * [DOXIA-193] - forced url links where parsed as WikiWords links
> * [DOXIA-201] - <param> tags are always parsed as macro parameters
> * [DOXIA-212] - There is no way to include images using relative urls
> * [DOXIA-215] - Trailing spaces after table definition causes exception
> * [DOXIA-216] - Linkcheck broken
> * [DOXIA-221] - Fix ArrayIndexOutOfBoundsException in XhtmlBaseSink
> * [DOXIA-222] - XhtmlBaseParser swallows significant whitespace
> * [DOXIA-225] - DocBookParser swallows significant whitespace
> * [DOXIA-227] - [regression] attributes stripped from img tags
> * [DOXIA-230] - Review Doxia generation for Apt and Docbook
> * [DOXIA-235] - Confluence parser doesn't strip leading spaces for
> list items
> * [DOXIA-240] - NPE when building documentation
> * [DOXIA-241] - Xdoc/XhtmlBaseParser doesn't close sections properly
> * [DOXIA-242] - Echo macro outputs internal params
> * [DOXIA-246] - TOC macro: higher entries are ignored
> * [DOXIA-247] - unable to parse document when the last character is '}'
> * [DOXIA-250] - Xml parser should handle entities defined in doctype
> * [DOXIA-251] - The AbstractXmlParser should take care of EOL
> * [DOXIA-257] - APT local anchor / link doesn't work when there is
> a whitespace in the anchor name
> * [DOXIA-259] - Source code snippets are not indented automatically
> * [DOXIA-261] - The Twiki noautolink is not used at all
> * [DOXIA-270] - Review doxia-converter artefact to respect ASF rules
> * [DOXIA-273] - Broken link in External Resources page
> * [DOXIA-274] - Broken link in "What is Doxia?" page
> * [DOXIA-291] - Wrong classid in SwfMacro
> * [DOXIA-292] - Be sure to call tableRows(int[], boolean) to be
> backward compatible with Doxia 1.0
>
> ** Improvement
> * [DOXIA-78] - Doxia XDOC parser and XHTML renderer ignore
> "rowspan" and "colspan" attributes for tables
> * [DOXIA-137] - Add comments to sink API
> * [DOXIA-142] - Allow snippet macro contents to be output as-is,
> instead of verbatim
> * [DOXIA-144] - Review signature methods
> * [DOXIA-153] - HTML tags in twiki not rendered correctly
> * [DOXIA-154] - Xdoc parser should recognize <script> tag
> * [DOXIA-155] - AbstractXmlParser should recognize CDATA, entities
> and comments
> * [DOXIA-163] - Add support for underscores
> * [DOXIA-164] - Add support for strikethroughs
> * [DOXIA-191] - Display images given an url
> * [DOXIA-192] - checkstyle
> * [DOXIA-194] - Generate usefull links for WikiWords
> * [DOXIA-204] - Add generic parameters support to Figure and Link events
> * [DOXIA-205] - Add new standard parameters to figure sink API
> * [DOXIA-206] - Add new standard parameters to link sink API
> * [DOXIA-208] - standardize link/anchor handling: remove usage of
> StructureSinkUtils
> * [DOXIA-210] - Snippet macro should include whole file if no id is
> given * [DOXIA-217] - Make default internal classes
> * [DOXIA-223] - Decouple end-of-line detection in LineBreaker from OS
> * [DOXIA-237] - add a way to use standard HTML4/XHTML entities
> like α ∞ ∇ ...
> * [DOXIA-243] - Add an 'unknown' element to Sink API
> * [DOXIA-244] - Upgrade to fop 0.94
> * [DOXIA-252] - Date format in the title of an apt file is not
> described in detail within the online documentation
> * [DOXIA-258] - Remove EOL in the docbook sink
> * [DOXIA-265] - Add an EntityResolver in
> AbstractXmlParser#getXmlReader() * [DOXIA-277] - Specify the language
> identification
>
> ** New Feature
> * [DOXIA-124] - Confluence sink Support
> * [DOXIA-135] - Handle SSI in xdoc
> * [DOXIA-145] - Adding logger feature
> * [DOXIA-195] - Guess a title for the parsed page
> * [DOXIA-196] - Support for <verbatim> block
> * [DOXIA-198] - Support for images with links
> * [DOXIA-245] - Xdoc parser should generate anchors for id
> attributes of section or subsection
> * [DOXIA-253] - Implement SinkFactory for all supported modules
> * [DOXIA-262] - Add a Twiki sink
> * [DOXIA-263] - Improve validation of input documents
> * [DOXIA-289] - Create anchor automatically from headings
>
> ** Task
> * [DOXIA-56] - clean up doxia api and code
> * [DOXIA-123] - Create an xdoc DTD or XSD for maven 2
> * [DOXIA-136] - Create an FML DTD or XSD
> * [DOXIA-138] - Review and clarify the APT guide
> * [DOXIA-140] - Review the Doxia site documentation
> * [DOXIA-159] - Move DocumentModel from docrenderer into doxia-core
> * [DOXIA-219] - Bump to new release of plexus-utils
> * [DOXIA-220] - Fix project name for doxia-logging-api
> * [DOXIA-234] - Deprecate methods in Sink API that don't use
> SinkEventAttributes
> * [DOXIA-236] - Clarify Sink API
> * [DOXIA-254] - Using the last version of modello-maven-plugin
>
> ** Test
> * [DOXIA-187] - Use AbstractSinkTest in DocBookBookSinkTest
>
> ** Wish
> * [DOXIA-248] - Move Parser.JUSTIFY_* over to Sink interface
> * [DOXIA-249] - Wrap publish date and project version into named
> <span>'s
>
> Enjoy,
>
> -The Maven team

architecture.odg (18K) Download Attachment

Fwd: [ANN] Maven Doxia 1.1 Released

2009-03-08T04:51:36Z

---------- Forwarded message ----------
From: Vincent Siveton <vsiveton@...>
Date: 2009/3/7
Subject: [ANN] Maven Doxia 1.1 Released
To: announce@..., users@...

The Maven team is pleased to announce the release of the Maven Doxia,
Doxia Sitetools, version 1.1 and Maven Doxia Tools, version 1.0.

Doxia is a content generation framework which aims to provide its
users with powerful techniques for generating static and dynamic
content: Doxia can be used in web-based publishing context to generate
static sites, in addition to being incorporated into dynamic content
generation systems like blogs, wikis and content management systems.

http://maven.apache.org/doxia/

Release Notes - Maven Doxia - Version 1.1

** Bug
* [DOXIA-51] - RtfSink supports only ".ppm" image type in figureGraphics()
* [DOXIA-59] - Doxia creates files with inconsistent new lines
* [DOXIA-99] - Figures require extension in APT and they should not
* [DOXIA-127] - Twiki module cannot parse two forced links in the
same paragraph
* [DOXIA-148] - FmlParser emits HTML specific events
* [DOXIA-152] - Xdoc parser shouldn't insert anchors for section titles
* [DOXIA-156] - XhtmlSink#tableCell( boolean headerRow, String
width ) uses a COLSPAN attribute instead of WIDTH attribute
* [DOXIA-157] - Doxia Book doesn't work with xdoc source files
* [DOXIA-160] - Book output in doc-book format is not well formed
* [DOXIA-161] - filename with dot have a false output name
* [DOXIA-162] - Failure to parse paragraph line with an EOL
* [DOXIA-166] - Book output ignores book, chapter and section titles
* [DOXIA-168] - Confluence module does not allow nested formatting
- e.g. a bullet cannot contain *bold* text or a [link]
* [DOXIA-169] - Confluence module does not recognize line breaks (\\)
* [DOXIA-171] - Confluence "quote" macro not recognised
* [DOXIA-173] - Support for Confluence anchor macro
* [DOXIA-175] - Confluence module does not recognise backslash as
escape character
* [DOXIA-176] - Confluence parser doesn't strip leading space for
section titles
* [DOXIA-177] - Invalid XHTML because of wrong position of table caption
* [DOXIA-178] - Confluence: nested wiki formats (e.g. bold italic)
do not work
* [DOXIA-180] - Confluence module should remove leading '#' from anchor link
* [DOXIA-181] - Confluence ParagraphBlockParser does not offer
lines to other parsers
* [DOXIA-182] - Confluence support for img macro
* [DOXIA-183] - Remove xhtml specific events from xdoc parser
* [DOXIA-189] - newline added after every closing tag
* [DOXIA-190] - text like (=something=) is parsed incorrectly
* [DOXIA-193] - forced url links where parsed as WikiWords links
* [DOXIA-201] - <param> tags are always parsed as macro parameters
* [DOXIA-212] - There is no way to include images using relative urls
* [DOXIA-215] - Trailing spaces after table definition causes exception
* [DOXIA-216] - Linkcheck broken
* [DOXIA-221] - Fix ArrayIndexOutOfBoundsException in XhtmlBaseSink
* [DOXIA-222] - XhtmlBaseParser swallows significant whitespace
* [DOXIA-225] - DocBookParser swallows significant whitespace
* [DOXIA-227] - [regression] attributes stripped from img tags
* [DOXIA-230] - Review Doxia generation for Apt and Docbook
* [DOXIA-235] - Confluence parser doesn't strip leading spaces for
list items
* [DOXIA-240] - NPE when building documentation
* [DOXIA-241] - Xdoc/XhtmlBaseParser doesn't close sections properly
* [DOXIA-242] - Echo macro outputs internal params
* [DOXIA-246] - TOC macro: higher entries are ignored
* [DOXIA-247] - unable to parse document when the last character is '}'
* [DOXIA-250] - Xml parser should handle entities defined in doctype
* [DOXIA-251] - The AbstractXmlParser should take care of EOL
* [DOXIA-257] - APT local anchor / link doesn't work when there is
a whitespace in the anchor name
* [DOXIA-259] - Source code snippets are not indented automatically
* [DOXIA-261] - The Twiki noautolink is not used at all
* [DOXIA-270] - Review doxia-converter artefact to respect ASF rules
* [DOXIA-273] - Broken link in External Resources page
* [DOXIA-274] - Broken link in "What is Doxia?" page
* [DOXIA-291] - Wrong classid in SwfMacro
* [DOXIA-292] - Be sure to call tableRows(int[], boolean) to be
backward compatible with Doxia 1.0

** Improvement
* [DOXIA-78] - Doxia XDOC parser and XHTML renderer ignore
"rowspan" and "colspan" attributes for tables
* [DOXIA-137] - Add comments to sink API
* [DOXIA-142] - Allow snippet macro contents to be output as-is,
instead of verbatim
* [DOXIA-144] - Review signature methods
* [DOXIA-153] - HTML tags in twiki not rendered correctly
* [DOXIA-154] - Xdoc parser should recognize <script> tag
* [DOXIA-155] - AbstractXmlParser should recognize CDATA, entities
and comments
* [DOXIA-163] - Add support for underscores
* [DOXIA-164] - Add support for strikethroughs
* [DOXIA-191] - Display images given an url
* [DOXIA-192] - checkstyle
* [DOXIA-194] - Generate usefull links for WikiWords
* [DOXIA-204] - Add generic parameters support to Figure and Link events
* [DOXIA-205] - Add new standard parameters to figure sink API
* [DOXIA-206] - Add new standard parameters to link sink API
* [DOXIA-208] - standardize link/anchor handling: remove usage of
StructureSinkUtils
* [DOXIA-210] - Snippet macro should include whole file if no id is given
* [DOXIA-217] - Make default internal classes
* [DOXIA-223] - Decouple end-of-line detection in LineBreaker from OS
* [DOXIA-237] - add a way to use standard HTML4/XHTML entities
like α ∞ ∇ ...
* [DOXIA-243] - Add an 'unknown' element to Sink API
* [DOXIA-244] - Upgrade to fop 0.94
* [DOXIA-252] - Date format in the title of an apt file is not
described in detail within the online documentation
* [DOXIA-258] - Remove EOL in the docbook sink
* [DOXIA-265] - Add an EntityResolver in AbstractXmlParser#getXmlReader()
* [DOXIA-277] - Specify the language identification

** New Feature
* [DOXIA-124] - Confluence sink Support
* [DOXIA-135] - Handle SSI in xdoc
* [DOXIA-145] - Adding logger feature
* [DOXIA-195] - Guess a title for the parsed page
* [DOXIA-196] - Support for <verbatim> block
* [DOXIA-198] - Support for images with links
* [DOXIA-245] - Xdoc parser should generate anchors for id
attributes of section or subsection
* [DOXIA-253] - Implement SinkFactory for all supported modules
* [DOXIA-262] - Add a Twiki sink
* [DOXIA-263] - Improve validation of input documents
* [DOXIA-289] - Create anchor automatically from headings

** Task
* [DOXIA-56] - clean up doxia api and code
* [DOXIA-123] - Create an xdoc DTD or XSD for maven 2
* [DOXIA-136] - Create an FML DTD or XSD
* [DOXIA-138] - Review and clarify the APT guide
* [DOXIA-140] - Review the Doxia site documentation
* [DOXIA-159] - Move DocumentModel from docrenderer into doxia-core
* [DOXIA-219] - Bump to new release of plexus-utils
* [DOXIA-220] - Fix project name for doxia-logging-api
* [DOXIA-234] - Deprecate methods in Sink API that don't use
SinkEventAttributes
* [DOXIA-236] - Clarify Sink API
* [DOXIA-254] - Using the last version of modello-maven-plugin

** Test
* [DOXIA-187] - Use AbstractSinkTest in DocBookBookSinkTest

** Wish
* [DOXIA-248] - Move Parser.JUSTIFY_* over to Sink interface
* [DOXIA-249] - Wrap publish date and project version into named <span>'s

Enjoy,

-The Maven team

Re: svn commit: r746595 - in /maven/doxia/doxia-sitetools/trunk/src/site: resources/ resources/doxia-sitetools-deps.odg resources/doxia-sitetools-deps.png xdoc/ xdoc/index.xml

2009-02-23T05:43:30Z

It is awesome!

Thanks Hervé!

Cheers,

Vincent

PS: Hope to see the same for doxia itself :)

2009/2/21, hboutemy@... <hboutemy@...>:

> Author: hboutemy
> Date: Sat Feb 21 21:53:11 2009
> New Revision: 746595
>
> URL: http://svn.apache.org/viewvc?rev=746595&view=rev
> Log:
> added a dependencies map to the index page
>
> Added:
> maven/doxia/doxia-sitetools/trunk/src/site/resources/
> maven/doxia/doxia-sitetools/trunk/src/site/resources/doxia-sitetools-deps.odg (with props)
> maven/doxia/doxia-sitetools/trunk/src/site/resources/doxia-sitetools-deps.png (with props)
> maven/doxia/doxia-sitetools/trunk/src/site/xdoc/
> maven/doxia/doxia-sitetools/trunk/src/site/xdoc/index.xml (with props)
>
> Added: maven/doxia/doxia-sitetools/trunk/src/site/resources/doxia-sitetools-deps.odg
> URL: http://svn.apache.org/viewvc/maven/doxia/doxia-sitetools/trunk/src/site/resources/doxia-sitetools-deps.odg?rev=746595&view=auto
> ==============================================================================
> Binary file - no diff available.
>
> Propchange: maven/doxia/doxia-sitetools/trunk/src/site/resources/doxia-sitetools-deps.odg
> ------------------------------------------------------------------------------
> svn:mime-type = application/octet-stream
>
> Added: maven/doxia/doxia-sitetools/trunk/src/site/resources/doxia-sitetools-deps.png
> URL: http://svn.apache.org/viewvc/maven/doxia/doxia-sitetools/trunk/src/site/resources/doxia-sitetools-deps.png?rev=746595&view=auto
> ==============================================================================
> Binary file - no diff available.
>
> Propchange: maven/doxia/doxia-sitetools/trunk/src/site/resources/doxia-sitetools-deps.png
> ------------------------------------------------------------------------------
> svn:mime-type = image/png
>
> Added: maven/doxia/doxia-sitetools/trunk/src/site/xdoc/index.xml
> URL: http://svn.apache.org/viewvc/maven/doxia/doxia-sitetools/trunk/src/site/xdoc/index.xml?rev=746595&view=auto
> ==============================================================================
> --- maven/doxia/doxia-sitetools/trunk/src/site/xdoc/index.xml (added)
> +++ maven/doxia/doxia-sitetools/trunk/src/site/xdoc/index.xml Sat Feb 21 21:53:11 2009
> @@ -0,0 +1,40 @@
> +<?xml version="1.0"?>
> +
> +<document>
> +
> + <properties>
> + <title>Doxia Sitetools</title>
> + <author email="hboutemy_AT_apache_DOT_org">Hervé Boutemy</author>
> + </properties>
> +
> + <body>
> +
> + <section name="Modello">
> +
> + <p>Doxia Sitetools generates sites, consisting of static and dynamic content that was generated by Doxia.</p>
> +
> + <p>
> + 
> + <script type="text/javascript">
> + tag='<img src="doxia-sitetools-deps.png" width="482" height="217" border="0" usemap="#Doxia_sitetools_dependencies" />';
> + tag=tag.substring(0,tag.length-2)+' usemap=\'#Doxia_sitetools_dependencies\''+tag.substring(tag.length-2);
> + document.write(tag);
> + </script>
> + <map name="Doxia_sitetools_dependencies">
> + <area shape="rect" coords="40,0,164,31" href="doxia-site-renderer/" />
> + <area shape="rect" coords="300,0,423,31" href="doxia-doc-renderer/" />
> + <area shape="rect" coords="20,135,184,167" href="doxia-decoration-model/" />
> + <area shape="rect" coords="0,57,84,87" href="http://velocity.apache.org" />
> + <area shape="rect" coords="111,58,236,88" href="http://maven.apache.org/doxia/doxia/doxia-modules/doxia-module-xhtml/" />
> + <area shape="rect" coords="251,57,354,89" href="http://maven.apache.org/doxia/doxia/doxia-modules/doxia-module-fo/" />
> + <area shape="rect" coords="356,57,478,88" href="http://maven.apache.org/doxia/doxia/doxia-modules/doxia-module-itext/" />
> + <area shape="rect" coords="106,53,481,119" href="http://maven.apache.org/doxia/doxia/doxia-modules/" />
> + <area shape="rect" coords="182,186,285,216" href="http://plexus.codehaus.org/" />
> + </map>
> + </p>
> +
> + </section>
> +
> + </body>
> +
> +</document>
>
> Propchange: maven/doxia/doxia-sitetools/trunk/src/site/xdoc/index.xml
> ------------------------------------------------------------------------------
> svn:eol-style = native
>
> Propchange: maven/doxia/doxia-sitetools/trunk/src/site/xdoc/index.xml
> ------------------------------------------------------------------------------
> svn:keywords = Author Date Id Revision
>
>
>

Re: Using Doxia 1.1 with Maven 2.0.x and more (WAS: svn commit: r740732 - in /maven/doxia: doxia/trunk/doxia-maven-plugin/pom.xml site/pom.xml)

2009-02-19T06:31:30Z

I'm replying to this over on dev@maven so that everyone can see.

On 05/02/2009, at 12:39 AM, Vincent Siveton wrote:

> Hi guys,
>
> The good news is that using the shade plugin, I was able to run a the
> latest Doxia plugin (using Doxia 1.1) with mvn 2.0.9 and 2.1.0.M2 and
> site-plugin 2.0-beta-7.
> The bad news, I don't know what are the potential side effects.
>
> You could do similar things for the pdf plugin [1]. Let's just add the
> shade-plugin (and fix prerequisites), install and pdf:pdf : you will
> be able to have a nice pdf.
>
> Comments welcome.
>
> Cheers,
>
> Vincent
>
> PS I didn't want to create another branch for this proof of concept so
> I committed directly under the trunk, we could revert it if needed.
>
> [1] https://svn.apache.org/repos/asf/maven/sandbox/trunk/plugins/maven-pdf-plugin
>
> ---------- Forwarded message ----------
> From: <vsiveton@...>
> Date: 2009/2/4
> Subject: svn commit: r740732 - in /maven/doxia:
> doxia/trunk/doxia-maven-plugin/pom.xml site/pom.xml
> To: doxia-commits@...
>
>
> Author: vsiveton
> Date: Wed Feb 4 13:28:25 2009
> New Revision: 740732
>
> URL: http://svn.apache.org/viewvc?rev=740732&view=rev
> Log:
> MNG-3402: MavenArtifactFilterManager needs to not filtering doxia-
> sink-api
>
> o proof of concept for a workaround using shade-plugin
> o mvn site on the Doxia site generates correctly the site using Maven
> 2.0.9 and 2.1.0.M2
>
> Modified:
> maven/doxia/doxia/trunk/doxia-maven-plugin/pom.xml
> maven/doxia/site/pom.xml
>
> Modified: maven/doxia/doxia/trunk/doxia-maven-plugin/pom.xml
> URL: http://svn.apache.org/viewvc/maven/doxia/doxia/trunk/doxia-maven-plugin/pom.xml?rev=740732&r1=740731&r2=740732&view=diff
> =
> =
> =
> =
> =
> =
> =
> =
> ======================================================================
> --- maven/doxia/doxia/trunk/doxia-maven-plugin/pom.xml (original)
> +++ maven/doxia/doxia/trunk/doxia-maven-plugin/pom.xml Wed Feb 4
> 13:28:25 2009
> @@ -51,6 +51,49 @@
> <version>${projectVersion}</version>
> </dependency>
> <dependency>
> + <groupId>${project.groupId}</groupId>
> + <artifactId>doxia-core</artifactId>
> + <version>${projectVersion}</version>
> + </dependency>
> + <dependency>
> + <groupId>${project.groupId}</groupId>
> + <artifactId>doxia-logging-api</artifactId>
> + <version>${projectVersion}</version>
> + </dependency>
> +
> + 
> + <dependency>
> + <groupId>org.apache.maven.doxia</groupId>
> + <artifactId>doxia-module-apt</artifactId>
> + <version>${projectVersion}</version>
> + </dependency>
> + <dependency>
> + <groupId>org.apache.maven.doxia</groupId>
> + <artifactId>doxia-module-docbook-simple</artifactId>
> + <version>${projectVersion}</version>
> + </dependency>
> + <dependency>
> + <groupId>org.apache.maven.doxia</groupId>
> + <artifactId>doxia-module-itext</artifactId>
> + <version>${projectVersion}</version>
> + </dependency>
> + <dependency>
> + <groupId>org.apache.maven.doxia</groupId>
> + <artifactId>doxia-module-latex</artifactId>
> + <version>${projectVersion}</version>
> + </dependency>
> + <dependency>
> + <groupId>org.apache.maven.doxia</groupId>
> + <artifactId>doxia-module-xdoc</artifactId>
> + <version>${projectVersion}</version>
> + </dependency>
> + <dependency>
> + <groupId>org.apache.maven.doxia</groupId>
> + <artifactId>doxia-module-xhtml</artifactId>
> + <version>${projectVersion}</version>
> + </dependency>
> +
> + <dependency>
> <groupId>org.codehaus.plexus</groupId>
> <artifactId>plexus-utils</artifactId>
> </dependency>
> @@ -61,6 +104,42 @@
> </dependency>
> </dependencies>
>
> + <build>
> + <plugins>
> + 
> + <plugin>
> + <artifactId>maven-shade-plugin</artifactId>
> + <version>1.2</version>
> + <executions>
> + <execution>
> + <phase>package</phase>
> + <goals>
> + <goal>shade</goal>
> + </goals>
> + <configuration>
> + <finalName>${project.build.finalName}</finalName>
> + <createDependencyReducedPom>
> + false
> + </createDependencyReducedPom>
> + <keepDependenciesWithProvidedScope>
> + true
> + </keepDependenciesWithProvidedScope>
> + <transformers>
> + <transformer
> implementation
> =
> "org
> .apache.maven.plugins.shade.resource.ComponentsXmlResourceTransformer"
> />
> + </transformers>
> + <artifactSet>
> + <includes>
> + <include>org.apache.maven.doxia:doxia-sink-api</
> include>
> + <include>org.apache.maven.doxia:doxia-logging-
> api</include>
> + </includes>
> + </artifactSet>
> + </configuration>
> + </execution>
> + </executions>
> + </plugin>
> + </plugins>
> + </build>
> +
> <reporting>
> <plugins>
> <plugin>
>
> Modified: maven/doxia/site/pom.xml
> URL: http://svn.apache.org/viewvc/maven/doxia/site/pom.xml?rev=740732&r1=740731&r2=740732&view=diff
> =
> =
> =
> =
> =
> =
> =
> =
> ======================================================================
> --- maven/doxia/site/pom.xml (original)
> +++ maven/doxia/site/pom.xml Wed Feb 4 13:28:25 2009
> @@ -147,7 +147,7 @@
> <plugin>
> <groupId>org.apache.maven.doxia</groupId>
> <artifactId>doxia-maven-plugin</artifactId>
> - <version>1.0-alpha-10</version>
> + <version>1.1-SNAPSHOT</version>
> <executions>
> <execution>
> <phase>pre-site</phase>

--
Brett Porter
brett@...
http://blogs.exist.com/bporter/

Re: svn commit: r744300 - /maven/doxia/doxia-sitetools/trunk/pom.xml

2009-02-19T00:11:50Z

It would also be nice if snapshots were deployed before bumping deps all over the
place.

-Lukas

Vincent Siveton wrote:

> Hi Brian,
>
> Do you plan to release the parent shortly?
>
> Vincent
>
> 2009/2/13, brianf@... <brianf@...>:
>> Author: brianf
>> Date: Fri Feb 13 23:54:30 2009
>> New Revision: 744300
>>
>> URL: http://svn.apache.org/viewvc?rev=744300&view=rev
>> Log:
>> use the new parent
>>
>> Modified:
>> maven/doxia/doxia-sitetools/trunk/pom.xml
>>
>> Modified: maven/doxia/doxia-sitetools/trunk/pom.xml
>> URL: http://svn.apache.org/viewvc/maven/doxia/doxia-sitetools/trunk/pom.xml?rev=744300&r1=744299&r2=744300&view=diff
>> ==============================================================================
>> --- maven/doxia/doxia-sitetools/trunk/pom.xml (original)
>> +++ maven/doxia/doxia-sitetools/trunk/pom.xml Fri Feb 13 23:54:30 2009
>> @@ -25,7 +25,7 @@
>> <parent>
>> <groupId>org.apache.maven</groupId>
>> <artifactId>maven-parent</artifactId>
>> - <version>10</version>
>> + <version>11-SNAPSHOT</version>
>> <relativePath>../../pom/maven/pom.xml</relativePath>
>> </parent>
>>
>>
>>
>>
>

Re: svn commit: r744300 - /maven/doxia/doxia-sitetools/trunk/pom.xml

2009-02-17T15:40:52Z

Hi Brian,

Do you plan to release the parent shortly?

Vincent

2009/2/13, brianf@... <brianf@...>:

> Author: brianf
> Date: Fri Feb 13 23:54:30 2009
> New Revision: 744300
>
> URL: http://svn.apache.org/viewvc?rev=744300&view=rev
> Log:
> use the new parent
>
> Modified:
> maven/doxia/doxia-sitetools/trunk/pom.xml
>
> Modified: maven/doxia/doxia-sitetools/trunk/pom.xml
> URL: http://svn.apache.org/viewvc/maven/doxia/doxia-sitetools/trunk/pom.xml?rev=744300&r1=744299&r2=744300&view=diff
> ==============================================================================
> --- maven/doxia/doxia-sitetools/trunk/pom.xml (original)
> +++ maven/doxia/doxia-sitetools/trunk/pom.xml Fri Feb 13 23:54:30 2009
> @@ -25,7 +25,7 @@
> <parent>
> <groupId>org.apache.maven</groupId>
> <artifactId>maven-parent</artifactId>
> - <version>10</version>
> + <version>11-SNAPSHOT</version>
> <relativePath>../../pom/maven/pom.xml</relativePath>
> </parent>
>
>
>
>

Re: Unable to stage the site for trunk or 1.0.x branch

2009-02-06T01:17:51Z

Vincent Siveton wrote:

> Weird, I was able to do it out of box

This might depend on the state of one's local repo such that the call to
resolver.resolveTransitively() in AbstractJavadocMojo delivers different
artifacts. Hence, I would expect that running "mvn install" before
site:stage would temporarily fix the problem for Dennis.

Benjamin

Re: Unable to stage the site for trunk or 1.0.x branch

2009-02-05T19:32:15Z

Weird, I was able to do it out of box
mvn site:stage -Preporting
http://people.apache.org/~vsiveton/doxia-1.0.x/

Cheers,

Vincent

2009/2/5 Dennis Lundberg <dennisl@...>:

> OK, but I get these errors *without* the Clirr plugin, i.e. on a clean
> checkout from svn.
>
> Vincent Siveton wrote:
>> Hi Dennis,
>>
>> Clirr plugin doesnt support ${reactorProjects} or aggregate so it is a
>> normal behaviour IMHO (and javadoc plugin 2.5 is correct).
>>
>> As a workaround, you could create a reporting-aggregate similar to [1].
>>
>> Cheers
>>
>> Vincent
>>
>> [1] https://svn.apache.org/repos/asf/maven/components/branches/maven-2.0.x/pom.xml
>>
>> 2009/2/4 Dennis Lundberg <dennisl@...>:
>>> Hi guys
>>>
>>> The "just adding a Clirr report" turned out to be a little more than that...
>>>
>>> When I run 'mvn -Preporting site:stage' on either doxia trunk or
>>> doxia-1.0.x branch I get the following errors. They happen when the
>>> javadoc plugin is creating its aggregated report. I have tried
>>> everything I can think of, but am still unable to solve this. Can
>>> someone please give me a helping hand?
>>>
>>>
>>> [ERROR] BUILD ERROR
>>> [INFO]
>>> ------------------------------------------------------------------------
>>> [INFO] Error during page generation
>>>
>>> Embedded error: Error rendering Maven report: Exit code: 1 -
>>> G:\apache\maven\trunks\doxia\doxia-1.0.x\doxia-modules\doxia-module-con
>>> fluence\src\test\java\org\apache\maven\doxia\module\confluence\ConfluenceParserTest.java:30:
>>> cannot resolve symbol
>>> symbol : class ConfluenceParser
>>> location: class
>>> org.apache.maven.doxia.module.confluence.ConfluenceParserTest
>>> private ConfluenceParser parser;
>>> ^
>>> G:\apache\maven\trunks\doxia\doxia-1.0.x\doxia-modules\doxia-module-twiki\src\test\java\org\apache\maven\doxia\module\twiki\parser\A
>>> bstractBlockTestCase.java:24: cannot resolve symbol
>>> symbol : class TWikiParser
>>> location: package twiki
>>> import org.apache.maven.doxia.module.twiki.TWikiParser;
>>> ^
>>> G:\apache\maven\trunks\doxia\doxia-1.0.x\doxia-modules\doxia-module-twiki\src\test\java\org\apache\maven\doxia\module\twiki\parser\A
>>> bstractBlockTestCase.java:38: cannot resolve symbol
>>> symbol : class SectionBlockParser
>>> location: class
>>> org.apache.maven.doxia.module.twiki.parser.AbstractBlockTestCase
>>> protected final SectionBlockParser sectionParser = new
>>> SectionBlockParser();
>>> ^
>>> G:\apache\maven\trunks\doxia\doxia-1.0.x\doxia-modules\doxia-module-twiki\src\test\java\org\apache\maven\doxia\module\twiki\parser\A
>>> bstractBlockTestCase.java:42: cannot resolve symbol
>>> symbol : class ParagraphBlockParser
>>> location: class
>>> org.apache.maven.doxia.module.twiki.parser.AbstractBlockTestCase
>>> protected final ParagraphBlockParser paraParser =
>>> ^
>>> G:\apache\maven\trunks\doxia\doxia-1.0.x\doxia-modules\doxia-module-twiki\src\test\java\org\apache\maven\doxia\module\twiki\parser\A
>>> bstractBlockTestCase.java:47: cannot resolve symbol
>>> symbol : class GenericListBlockParser
>>> location: class
>>> org.apache.maven.doxia.module.twiki.parser.AbstractBlockTestCase
>>> protected final GenericListBlockParser listParser =
>>> ^
>>> G:\apache\maven\trunks\doxia\doxia-1.0.x\doxia-modules\doxia-module-twiki\src\test\java\org\apache\maven\doxia\module\twiki\parser\A
>>> bstractBlockTestCase.java:52: cannot resolve symbol
>>> symbol : class FormatedTextParser
>>> location: class
>>> org.apache.maven.doxia.module.twiki.parser.AbstractBlockTestCase
>>> protected final FormatedTextParser formatTextParser =
>>> ^
>>> G:\apache\maven\trunks\doxia\doxia-1.0.x\doxia-modules\doxia-module-twiki\src\test\java\org\apache\maven\doxia\module\twiki\parser\A
>>> bstractBlockTestCase.java:57: cannot resolve symbol
>>> symbol : class TextParser
>>> location: class
>>> org.apache.maven.doxia.module.twiki.parser.AbstractBlockTestCase
>>> protected final TextParser textParser = new TextParser();
>>> ^
>>> G:\apache\maven\trunks\doxia\doxia-1.0.x\doxia-modules\doxia-module-twiki\src\test\java\org\apache\maven\doxia\module\twiki\parser\A
>>> bstractBlockTestCase.java:61: cannot resolve symbol
>>> symbol : class HRuleBlockParser
>>> location: class
>>> org.apache.maven.doxia.module.twiki.parser.AbstractBlockTestCase
>>> protected final HRuleBlockParser hruleParser = new HRuleBlockParser();
>>> ^
>>> G:\apache\maven\trunks\doxia\doxia-1.0.x\doxia-modules\doxia-module-twiki\src\test\java\org\apache\maven\doxia\module\twiki\parser\A
>>> bstractBlockTestCase.java:65: cannot resolve symbol
>>> symbol : class TableBlockParser
>>> location: class
>>> org.apache.maven.doxia.module.twiki.parser.AbstractBlockTestCase
>>> protected final TableBlockParser tableParser = new TableBlockParser();
>>> ^
>>> G:\apache\maven\trunks\doxia\doxia-1.0.x\doxia-modules\doxia-module-twiki\src\test\java\org\apache\maven\doxia\module\twiki\parser\A
>>> bstractBlockTestCase.java:69: cannot resolve symbol
>>> symbol : class TWikiParser
>>> location: class
>>> org.apache.maven.doxia.module.twiki.parser.AbstractBlockTestCase
>>> protected final TWikiParser twikiParser = new TWikiParser();
>>> ^
>>> G:\apache\maven\trunks\doxia\doxia-1.0.x\doxia-modules\doxia-module-twiki\src\test\java\org\apache\maven\doxia\module\twiki\parser\W
>>> ordsTest.java:36: cannot resolve symbol
>>> symbol : class Block
>>> location: class org.apache.maven.doxia.module.twiki.parser.WordsTest
>>> private static final Block [] TOARRAY = new Block[]{};
>>> ^
>>> G:\apache\maven\trunks\doxia\doxia-1.0.x\doxia-modules\doxia-module-fml\src\test\java\org\apache\maven\doxia\module\fml\FmlParserTes
>>> t.java:22: cannot resolve symbol
>>> symbol : class FmlParser
>>> location: package fml
>>> import org.apache.maven.doxia.module.fml.FmlParser;
>>> ^
>>> G:\apache\maven\trunks\doxia\doxia-1.0.x\doxia-modules\doxia-module-twiki\src\test\java\org\apache\maven\doxia\module\twiki\parser\A
>>> bstractBlockTestCase.java:38: cannot resolve symbol
>>> symbol : class SectionBlockParser
>>> location: class
>>> org.apache.maven.doxia.module.twiki.parser.AbstractBlockTestCase
>>> protected final SectionBlockParser sectionParser = new
>>> SectionBlockParser();
>>> ^
>>> G:\apache\maven\trunks\doxia\doxia-1.0.x\doxia-modules\doxia-module-twiki\src\test\java\org\apache\maven\doxia\module\twiki\parser\A
>>> bstractBlockTestCase.java:43: cannot resolve symbol
>>> symbol : class ParagraphBlockParser
>>> location: class
>>> org.apache.maven.doxia.module.twiki.parser.AbstractBlockTestCase
>>> new ParagraphBlockParser();
>>> ^
>>> G:\apache\maven\trunks\doxia\doxia-1.0.x\doxia-modules\doxia-module-twiki\src\test\java\org\apache\maven\doxia\module\twiki\parser\A
>>> bstractBlockTestCase.java:48: cannot resolve symbol
>>> symbol : class GenericListBlockParser
>>> location: class
>>> org.apache.maven.doxia.module.twiki.parser.AbstractBlockTestCase
>>> new GenericListBlockParser();
>>> ^
>>> G:\apache\maven\trunks\doxia\doxia-1.0.x\doxia-modules\doxia-module-twiki\src\test\java\org\apache\maven\doxia\module\twiki\parser\A
>>> bstractBlockTestCase.java:53: cannot resolve symbol
>>> symbol : class FormatedTextParser
>>> location: class
>>> org.apache.maven.doxia.module.twiki.parser.AbstractBlockTestCase
>>> new FormatedTextParser();
>>> ^
>>> G:\apache\maven\trunks\doxia\doxia-1.0.x\doxia-modules\doxia-module-twiki\src\test\java\org\apache\maven\doxia\module\twiki\parser\A
>>> bstractBlockTestCase.java:57: cannot resolve symbol
>>> symbol : class TextParser
>>> location: class
>>> org.apache.maven.doxia.module.twiki.parser.AbstractBlockTestCase
>>> protected final TextParser textParser = new TextParser();
>>> ^
>>> G:\apache\maven\trunks\doxia\doxia-1.0.x\doxia-modules\doxia-module-twiki\src\test\java\org\apache\maven\doxia\module\twiki\parser\A
>>> bstractBlockTestCase.java:61: cannot resolve symbol
>>> symbol : class HRuleBlockParser
>>> location: class
>>> org.apache.maven.doxia.module.twiki.parser.AbstractBlockTestCase
>>> protected final HRuleBlockParser hruleParser = new HRuleBlockParser();
>>> ^
>>> G:\apache\maven\trunks\doxia\doxia-1.0.x\doxia-modules\doxia-module-twiki\src\test\java\org\apache\maven\doxia\module\twiki\parser\A
>>> bstractBlockTestCase.java:65: cannot resolve symbol
>>> symbol : class TableBlockParser
>>> location: class
>>> org.apache.maven.doxia.module.twiki.parser.AbstractBlockTestCase
>>> protected final TableBlockParser tableParser = new TableBlockParser();
>>> ^
>>> G:\apache\maven\trunks\doxia\doxia-1.0.x\doxia-modules\doxia-module-twiki\src\test\java\org\apache\maven\doxia\module\twiki\parser\A
>>> bstractBlockTestCase.java:69: cannot resolve symbol
>>> symbol : class TWikiParser
>>> location: class
>>> org.apache.maven.doxia.module.twiki.parser.AbstractBlockTestCase
>>> protected final TWikiParser twikiParser = new TWikiParser();
>>> ^
>>>
>>> --
>>> Dennis Lundberg
>>>
>>
>
>
> --
> Dennis Lundberg
>

Re: Unable to stage the site for trunk or 1.0.x branch

2009-02-05T11:22:27Z

OK, but I get these errors *without* the Clirr plugin, i.e. on a clean
checkout from svn.

Vincent Siveton wrote:

> Hi Dennis,
>
> Clirr plugin doesnt support ${reactorProjects} or aggregate so it is a
> normal behaviour IMHO (and javadoc plugin 2.5 is correct).
>
> As a workaround, you could create a reporting-aggregate similar to [1].
>
> Cheers
>
> Vincent
>
> [1] https://svn.apache.org/repos/asf/maven/components/branches/maven-2.0.x/pom.xml
>
> 2009/2/4 Dennis Lundberg <dennisl@...>:
>> Hi guys
>>
>> The "just adding a Clirr report" turned out to be a little more than that...
>>
>> When I run 'mvn -Preporting site:stage' on either doxia trunk or
>> doxia-1.0.x branch I get the following errors. They happen when the
>> javadoc plugin is creating its aggregated report. I have tried
>> everything I can think of, but am still unable to solve this. Can
>> someone please give me a helping hand?
>>
>>
>> [ERROR] BUILD ERROR
>> [INFO]
>> ------------------------------------------------------------------------
>> [INFO] Error during page generation
>>
>> Embedded error: Error rendering Maven report: Exit code: 1 -
>> G:\apache\maven\trunks\doxia\doxia-1.0.x\doxia-modules\doxia-module-con
>> fluence\src\test\java\org\apache\maven\doxia\module\confluence\ConfluenceParserTest.java:30:
>> cannot resolve symbol
>> symbol : class ConfluenceParser
>> location: class
>> org.apache.maven.doxia.module.confluence.ConfluenceParserTest
>> private ConfluenceParser parser;
>> ^
>> G:\apache\maven\trunks\doxia\doxia-1.0.x\doxia-modules\doxia-module-twiki\src\test\java\org\apache\maven\doxia\module\twiki\parser\A
>> bstractBlockTestCase.java:24: cannot resolve symbol
>> symbol : class TWikiParser
>> location: package twiki
>> import org.apache.maven.doxia.module.twiki.TWikiParser;
>> ^
>> G:\apache\maven\trunks\doxia\doxia-1.0.x\doxia-modules\doxia-module-twiki\src\test\java\org\apache\maven\doxia\module\twiki\parser\A
>> bstractBlockTestCase.java:38: cannot resolve symbol
>> symbol : class SectionBlockParser
>> location: class
>> org.apache.maven.doxia.module.twiki.parser.AbstractBlockTestCase
>> protected final SectionBlockParser sectionParser = new
>> SectionBlockParser();
>> ^
>> G:\apache\maven\trunks\doxia\doxia-1.0.x\doxia-modules\doxia-module-twiki\src\test\java\org\apache\maven\doxia\module\twiki\parser\A
>> bstractBlockTestCase.java:42: cannot resolve symbol
>> symbol : class ParagraphBlockParser
>> location: class
>> org.apache.maven.doxia.module.twiki.parser.AbstractBlockTestCase
>> protected final ParagraphBlockParser paraParser =
>> ^
>> G:\apache\maven\trunks\doxia\doxia-1.0.x\doxia-modules\doxia-module-twiki\src\test\java\org\apache\maven\doxia\module\twiki\parser\A
>> bstractBlockTestCase.java:47: cannot resolve symbol
>> symbol : class GenericListBlockParser
>> location: class
>> org.apache.maven.doxia.module.twiki.parser.AbstractBlockTestCase
>> protected final GenericListBlockParser listParser =
>> ^
>> G:\apache\maven\trunks\doxia\doxia-1.0.x\doxia-modules\doxia-module-twiki\src\test\java\org\apache\maven\doxia\module\twiki\parser\A
>> bstractBlockTestCase.java:52: cannot resolve symbol
>> symbol : class FormatedTextParser
>> location: class
>> org.apache.maven.doxia.module.twiki.parser.AbstractBlockTestCase
>> protected final FormatedTextParser formatTextParser =
>> ^
>> G:\apache\maven\trunks\doxia\doxia-1.0.x\doxia-modules\doxia-module-twiki\src\test\java\org\apache\maven\doxia\module\twiki\parser\A
>> bstractBlockTestCase.java:57: cannot resolve symbol
>> symbol : class TextParser
>> location: class
>> org.apache.maven.doxia.module.twiki.parser.AbstractBlockTestCase
>> protected final TextParser textParser = new TextParser();
>> ^
>> G:\apache\maven\trunks\doxia\doxia-1.0.x\doxia-modules\doxia-module-twiki\src\test\java\org\apache\maven\doxia\module\twiki\parser\A
>> bstractBlockTestCase.java:61: cannot resolve symbol
>> symbol : class HRuleBlockParser
>> location: class
>> org.apache.maven.doxia.module.twiki.parser.AbstractBlockTestCase
>> protected final HRuleBlockParser hruleParser = new HRuleBlockParser();
>> ^
>> G:\apache\maven\trunks\doxia\doxia-1.0.x\doxia-modules\doxia-module-twiki\src\test\java\org\apache\maven\doxia\module\twiki\parser\A
>> bstractBlockTestCase.java:65: cannot resolve symbol
>> symbol : class TableBlockParser
>> location: class
>> org.apache.maven.doxia.module.twiki.parser.AbstractBlockTestCase
>> protected final TableBlockParser tableParser = new TableBlockParser();
>> ^
>> G:\apache\maven\trunks\doxia\doxia-1.0.x\doxia-modules\doxia-module-twiki\src\test\java\org\apache\maven\doxia\module\twiki\parser\A
>> bstractBlockTestCase.java:69: cannot resolve symbol
>> symbol : class TWikiParser
>> location: class
>> org.apache.maven.doxia.module.twiki.parser.AbstractBlockTestCase
>> protected final TWikiParser twikiParser = new TWikiParser();
>> ^
>> G:\apache\maven\trunks\doxia\doxia-1.0.x\doxia-modules\doxia-module-twiki\src\test\java\org\apache\maven\doxia\module\twiki\parser\W
>> ordsTest.java:36: cannot resolve symbol
>> symbol : class Block
>> location: class org.apache.maven.doxia.module.twiki.parser.WordsTest
>> private static final Block [] TOARRAY = new Block[]{};
>> ^
>> G:\apache\maven\trunks\doxia\doxia-1.0.x\doxia-modules\doxia-module-fml\src\test\java\org\apache\maven\doxia\module\fml\FmlParserTes
>> t.java:22: cannot resolve symbol
>> symbol : class FmlParser
>> location: package fml
>> import org.apache.maven.doxia.module.fml.FmlParser;
>> ^
>> G:\apache\maven\trunks\doxia\doxia-1.0.x\doxia-modules\doxia-module-twiki\src\test\java\org\apache\maven\doxia\module\twiki\parser\A
>> bstractBlockTestCase.java:38: cannot resolve symbol
>> symbol : class SectionBlockParser
>> location: class
>> org.apache.maven.doxia.module.twiki.parser.AbstractBlockTestCase
>> protected final SectionBlockParser sectionParser = new
>> SectionBlockParser();
>> ^
>> G:\apache\maven\trunks\doxia\doxia-1.0.x\doxia-modules\doxia-module-twiki\src\test\java\org\apache\maven\doxia\module\twiki\parser\A
>> bstractBlockTestCase.java:43: cannot resolve symbol
>> symbol : class ParagraphBlockParser
>> location: class
>> org.apache.maven.doxia.module.twiki.parser.AbstractBlockTestCase
>> new ParagraphBlockParser();
>> ^
>> G:\apache\maven\trunks\doxia\doxia-1.0.x\doxia-modules\doxia-module-twiki\src\test\java\org\apache\maven\doxia\module\twiki\parser\A
>> bstractBlockTestCase.java:48: cannot resolve symbol
>> symbol : class GenericListBlockParser
>> location: class
>> org.apache.maven.doxia.module.twiki.parser.AbstractBlockTestCase
>> new GenericListBlockParser();
>> ^
>> G:\apache\maven\trunks\doxia\doxia-1.0.x\doxia-modules\doxia-module-twiki\src\test\java\org\apache\maven\doxia\module\twiki\parser\A
>> bstractBlockTestCase.java:53: cannot resolve symbol
>> symbol : class FormatedTextParser
>> location: class
>> org.apache.maven.doxia.module.twiki.parser.AbstractBlockTestCase
>> new FormatedTextParser();
>> ^
>> G:\apache\maven\trunks\doxia\doxia-1.0.x\doxia-modules\doxia-module-twiki\src\test\java\org\apache\maven\doxia\module\twiki\parser\A
>> bstractBlockTestCase.java:57: cannot resolve symbol
>> symbol : class TextParser
>> location: class
>> org.apache.maven.doxia.module.twiki.parser.AbstractBlockTestCase
>> protected final TextParser textParser = new TextParser();
>> ^
>> G:\apache\maven\trunks\doxia\doxia-1.0.x\doxia-modules\doxia-module-twiki\src\test\java\org\apache\maven\doxia\module\twiki\parser\A
>> bstractBlockTestCase.java:61: cannot resolve symbol
>> symbol : class HRuleBlockParser
>> location: class
>> org.apache.maven.doxia.module.twiki.parser.AbstractBlockTestCase
>> protected final HRuleBlockParser hruleParser = new HRuleBlockParser();
>> ^
>> G:\apache\maven\trunks\doxia\doxia-1.0.x\doxia-modules\doxia-module-twiki\src\test\java\org\apache\maven\doxia\module\twiki\parser\A
>> bstractBlockTestCase.java:65: cannot resolve symbol
>> symbol : class TableBlockParser
>> location: class
>> org.apache.maven.doxia.module.twiki.parser.AbstractBlockTestCase
>> protected final TableBlockParser tableParser = new TableBlockParser();
>> ^
>> G:\apache\maven\trunks\doxia\doxia-1.0.x\doxia-modules\doxia-module-twiki\src\test\java\org\apache\maven\doxia\module\twiki\parser\A
>> bstractBlockTestCase.java:69: cannot resolve symbol
>> symbol : class TWikiParser
>> location: class
>> org.apache.maven.doxia.module.twiki.parser.AbstractBlockTestCase
>> protected final TWikiParser twikiParser = new TWikiParser();
>> ^
>>
>> --
>> Dennis Lundberg
>>
>

--
Dennis Lundberg

Re: Unable to stage the site for trunk or 1.0.x branch

2009-02-04T17:38:13Z

Hi Dennis,

Clirr plugin doesnt support ${reactorProjects} or aggregate so it is a
normal behaviour IMHO (and javadoc plugin 2.5 is correct).

As a workaround, you could create a reporting-aggregate similar to [1].

Cheers

Vincent

[1] https://svn.apache.org/repos/asf/maven/components/branches/maven-2.0.x/pom.xml

2009/2/4 Dennis Lundberg <dennisl@...>:

> Hi guys
>
> The "just adding a Clirr report" turned out to be a little more than that...
>
> When I run 'mvn -Preporting site:stage' on either doxia trunk or
> doxia-1.0.x branch I get the following errors. They happen when the
> javadoc plugin is creating its aggregated report. I have tried
> everything I can think of, but am still unable to solve this. Can
> someone please give me a helping hand?
>
>
> [ERROR] BUILD ERROR
> [INFO]
> ------------------------------------------------------------------------
> [INFO] Error during page generation
>
> Embedded error: Error rendering Maven report: Exit code: 1 -
> G:\apache\maven\trunks\doxia\doxia-1.0.x\doxia-modules\doxia-module-con
> fluence\src\test\java\org\apache\maven\doxia\module\confluence\ConfluenceParserTest.java:30:
> cannot resolve symbol
> symbol : class ConfluenceParser
> location: class
> org.apache.maven.doxia.module.confluence.ConfluenceParserTest
> private ConfluenceParser parser;
> ^
> G:\apache\maven\trunks\doxia\doxia-1.0.x\doxia-modules\doxia-module-twiki\src\test\java\org\apache\maven\doxia\module\twiki\parser\A
> bstractBlockTestCase.java:24: cannot resolve symbol
> symbol : class TWikiParser
> location: package twiki
> import org.apache.maven.doxia.module.twiki.TWikiParser;
> ^
> G:\apache\maven\trunks\doxia\doxia-1.0.x\doxia-modules\doxia-module-twiki\src\test\java\org\apache\maven\doxia\module\twiki\parser\A
> bstractBlockTestCase.java:38: cannot resolve symbol
> symbol : class SectionBlockParser
> location: class
> org.apache.maven.doxia.module.twiki.parser.AbstractBlockTestCase
> protected final SectionBlockParser sectionParser = new
> SectionBlockParser();
> ^
> G:\apache\maven\trunks\doxia\doxia-1.0.x\doxia-modules\doxia-module-twiki\src\test\java\org\apache\maven\doxia\module\twiki\parser\A
> bstractBlockTestCase.java:42: cannot resolve symbol
> symbol : class ParagraphBlockParser
> location: class
> org.apache.maven.doxia.module.twiki.parser.AbstractBlockTestCase
> protected final ParagraphBlockParser paraParser =
> ^
> G:\apache\maven\trunks\doxia\doxia-1.0.x\doxia-modules\doxia-module-twiki\src\test\java\org\apache\maven\doxia\module\twiki\parser\A
> bstractBlockTestCase.java:47: cannot resolve symbol
> symbol : class GenericListBlockParser
> location: class
> org.apache.maven.doxia.module.twiki.parser.AbstractBlockTestCase
> protected final GenericListBlockParser listParser =
> ^
> G:\apache\maven\trunks\doxia\doxia-1.0.x\doxia-modules\doxia-module-twiki\src\test\java\org\apache\maven\doxia\module\twiki\parser\A
> bstractBlockTestCase.java:52: cannot resolve symbol
> symbol : class FormatedTextParser
> location: class
> org.apache.maven.doxia.module.twiki.parser.AbstractBlockTestCase
> protected final FormatedTextParser formatTextParser =
> ^
> G:\apache\maven\trunks\doxia\doxia-1.0.x\doxia-modules\doxia-module-twiki\src\test\java\org\apache\maven\doxia\module\twiki\parser\A
> bstractBlockTestCase.java:57: cannot resolve symbol
> symbol : class TextParser
> location: class
> org.apache.maven.doxia.module.twiki.parser.AbstractBlockTestCase
> protected final TextParser textParser = new TextParser();
> ^
> G:\apache\maven\trunks\doxia\doxia-1.0.x\doxia-modules\doxia-module-twiki\src\test\java\org\apache\maven\doxia\module\twiki\parser\A
> bstractBlockTestCase.java:61: cannot resolve symbol
> symbol : class HRuleBlockParser
> location: class
> org.apache.maven.doxia.module.twiki.parser.AbstractBlockTestCase
> protected final HRuleBlockParser hruleParser = new HRuleBlockParser();
> ^
> G:\apache\maven\trunks\doxia\doxia-1.0.x\doxia-modules\doxia-module-twiki\src\test\java\org\apache\maven\doxia\module\twiki\parser\A
> bstractBlockTestCase.java:65: cannot resolve symbol
> symbol : class TableBlockParser
> location: class
> org.apache.maven.doxia.module.twiki.parser.AbstractBlockTestCase
> protected final TableBlockParser tableParser = new TableBlockParser();
> ^
> G:\apache\maven\trunks\doxia\doxia-1.0.x\doxia-modules\doxia-module-twiki\src\test\java\org\apache\maven\doxia\module\twiki\parser\A
> bstractBlockTestCase.java:69: cannot resolve symbol
> symbol : class TWikiParser
> location: class
> org.apache.maven.doxia.module.twiki.parser.AbstractBlockTestCase
> protected final TWikiParser twikiParser = new TWikiParser();
> ^
> G:\apache\maven\trunks\doxia\doxia-1.0.x\doxia-modules\doxia-module-twiki\src\test\java\org\apache\maven\doxia\module\twiki\parser\W
> ordsTest.java:36: cannot resolve symbol
> symbol : class Block
> location: class org.apache.maven.doxia.module.twiki.parser.WordsTest
> private static final Block [] TOARRAY = new Block[]{};
> ^
> G:\apache\maven\trunks\doxia\doxia-1.0.x\doxia-modules\doxia-module-fml\src\test\java\org\apache\maven\doxia\module\fml\FmlParserTes
> t.java:22: cannot resolve symbol
> symbol : class FmlParser
> location: package fml
> import org.apache.maven.doxia.module.fml.FmlParser;
> ^
> G:\apache\maven\trunks\doxia\doxia-1.0.x\doxia-modules\doxia-module-twiki\src\test\java\org\apache\maven\doxia\module\twiki\parser\A
> bstractBlockTestCase.java:38: cannot resolve symbol
> symbol : class SectionBlockParser
> location: class
> org.apache.maven.doxia.module.twiki.parser.AbstractBlockTestCase
> protected final SectionBlockParser sectionParser = new
> SectionBlockParser();
> ^
> G:\apache\maven\trunks\doxia\doxia-1.0.x\doxia-modules\doxia-module-twiki\src\test\java\org\apache\maven\doxia\module\twiki\parser\A
> bstractBlockTestCase.java:43: cannot resolve symbol
> symbol : class ParagraphBlockParser
> location: class
> org.apache.maven.doxia.module.twiki.parser.AbstractBlockTestCase
> new ParagraphBlockParser();
> ^
> G:\apache\maven\trunks\doxia\doxia-1.0.x\doxia-modules\doxia-module-twiki\src\test\java\org\apache\maven\doxia\module\twiki\parser\A
> bstractBlockTestCase.java:48: cannot resolve symbol
> symbol : class GenericListBlockParser
> location: class
> org.apache.maven.doxia.module.twiki.parser.AbstractBlockTestCase
> new GenericListBlockParser();
> ^
> G:\apache\maven\trunks\doxia\doxia-1.0.x\doxia-modules\doxia-module-twiki\src\test\java\org\apache\maven\doxia\module\twiki\parser\A
> bstractBlockTestCase.java:53: cannot resolve symbol
> symbol : class FormatedTextParser
> location: class
> org.apache.maven.doxia.module.twiki.parser.AbstractBlockTestCase
> new FormatedTextParser();
> ^
> G:\apache\maven\trunks\doxia\doxia-1.0.x\doxia-modules\doxia-module-twiki\src\test\java\org\apache\maven\doxia\module\twiki\parser\A
> bstractBlockTestCase.java:57: cannot resolve symbol
> symbol : class TextParser
> location: class
> org.apache.maven.doxia.module.twiki.parser.AbstractBlockTestCase
> protected final TextParser textParser = new TextParser();
> ^
> G:\apache\maven\trunks\doxia\doxia-1.0.x\doxia-modules\doxia-module-twiki\src\test\java\org\apache\maven\doxia\module\twiki\parser\A
> bstractBlockTestCase.java:61: cannot resolve symbol
> symbol : class HRuleBlockParser
> location: class
> org.apache.maven.doxia.module.twiki.parser.AbstractBlockTestCase
> protected final HRuleBlockParser hruleParser = new HRuleBlockParser();
> ^
> G:\apache\maven\trunks\doxia\doxia-1.0.x\doxia-modules\doxia-module-twiki\src\test\java\org\apache\maven\doxia\module\twiki\parser\A
> bstractBlockTestCase.java:65: cannot resolve symbol
> symbol : class TableBlockParser
> location: class
> org.apache.maven.doxia.module.twiki.parser.AbstractBlockTestCase
> protected final TableBlockParser tableParser = new TableBlockParser();
> ^
> G:\apache\maven\trunks\doxia\doxia-1.0.x\doxia-modules\doxia-module-twiki\src\test\java\org\apache\maven\doxia\module\twiki\parser\A
> bstractBlockTestCase.java:69: cannot resolve symbol
> symbol : class TWikiParser
> location: class
> org.apache.maven.doxia.module.twiki.parser.AbstractBlockTestCase
> protected final TWikiParser twikiParser = new TWikiParser();
> ^
>
> --
> Dennis Lundberg
>