Re: What's the status of doxia-tools trunk?
Hi This plugin works and was used by Maven site itself http://maven.apache.org/linkcheck.html So I think it could be released Cheers, Vincent 2010/7/27 Dennis Lundberg : > Hi > > I'm looking at releasing a first version of maven-linkcheck-plugin, to > get some mileage on it and get feedback from our users. The plugin has a > dependency on doxia-tools/doxia-linkcheck 1.1-SNAPSHOT, so I guess we > need to release that first. > > Does anyone know the status of doxia-tools (trunk)? > Is it releasable? I've fixed a couple of minor things. > > -- > Dennis Lundberg >
Re: TOC from .confluence files
Should be but I dont think we have a test case for this.
Could you create an issue so I could have a glance?
Cheers,
Vincent
2010/7/13 nsowatsk :
> Hi
>
> I am trying to get a TOC in the pages generated from .confluence files, like
> the one I get from the %{toc} macro in .apt files.
>
> I have tried various permutations on this:
>
> {toc:style=disc|indent=20px}
>
> But all I get is the same, literal, text in the web pages.
>
> Should this, or something like it, actually work?
>
> Many thanks
>
> Nathan
> --
> Nathan Sowatskey (nsowa...@cisco.com) - Technical Leader, ScanSafe -
> +34-638-083-675
>
>
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/X
Hi Lukas, 2009/8/19 Lukas Theussl : > IIUC, according to the xdoc schema it is perfectly legal to specify a > in both and , 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: r799837 - in /maven/doxia/doxia-tools/trunk/doxia-linkcheck/src/main/java/org/apache/maven/doxia/linkcheck/validation: LinkValidatorManager.java OnlineHTTPLinkValidator.java
Hi Dennis, 2009/8/2 Dennis Lundberg : > 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: 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/apac
Hi Dennis, 2009/5/19 Dennis Lundberg : > 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: entities: text or rawText?
Hi Lukas, 2009/5/4 Lukas Theussl : > > 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 ). > > 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 ). 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: 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-con
Be sure to do a svn update before running maven BTW you could always reprepare the process. Cheers, Vincent 2009/4/29, Lukas Theussl : > > 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/d...@maven.apache.org/msg80254.html > > > > ltheu...@apache.org 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
Go ahead. Cheers, Vincent 2009/4/3 Lukas Theussl : > > Hi, > > Is there any reason why we have this setting in the doxia parent pom: > > > maven-surefire-plugin > > never > > > > > > 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: Fwd: [ANN] Maven Doxia 1.1 Released
Hi 2009/3/8 Hervé 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
Fwd: [ANN] Maven Doxia 1.1 Released
-- Forwarded message -- From: Vincent Siveton Date: 2009/3/7 Subject: [ANN] Maven Doxia 1.1 Released To: annou...@maven.apache.org, us...@maven.apache.org 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] - 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
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
It is awesome! Thanks Hervé! Cheers, Vincent PS: Hope to see the same for doxia itself :) 2009/2/21, hbout...@apache.org : > 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 @@ > + > + > + > + > + > +Doxia Sitetools > +Hervé Boutemy > + > + > + > + > + > + > + Doxia Sitetools generates sites, consisting of static and dynamic > content that was generated by Doxia. > + > + > + > + > + tag='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); > + > + > + href="doxia-site-renderer/" /> > + href="doxia-doc-renderer/" /> > + href="doxia-decoration-model/" /> > + href="http://velocity.apache.org"; /> > + href="http://maven.apache.org/doxia/doxia/doxia-modules/doxia-module-xhtml/"; > /> > + href="http://maven.apache.org/doxia/doxia/doxia-modules/doxia-module-fo/"; /> > + href="http://maven.apache.org/doxia/doxia/doxia-modules/doxia-module-itext/"; > /> > + href="http://maven.apache.org/doxia/doxia/doxia-modules/"; /> > + href="http://plexus.codehaus.org/"; /> > + > + > + > + > + > + > + > + > > 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: svn commit: r740156 - /maven/doxia/doxia/trunk/doxia-book/src/main/resources/book-renderer_fr.properties
Hi Benjamin, 2009/2/3 Benjamin Bentmann : > I didn't have a closer look at the code that reads these properties but > assuming it's Properties.load(InputStream) [0], this should be ISO-8859-1 or > maybe only ASCII (cf. MSITE-287), shouldn't it? You right. Initially, the code used the plateform encoding, I started to fix it in r740164 using Reader/WriterFactory classes. This commit could be revert now. Cheers, Vincent
Re: Merging with XWiki and WikiModel
Hi Jason, 2009/1/29 Jason van Zyl : > 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? 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 > > -- > Jason van Zyl > Founder, Apache Maven > jason at sonatype dot com > -- > > People develop abstractions by generalizing from concrete examples. > Every attempt to determine the correct abstraction on paper without > actually developing a running system is doomed to failure. No one > is that smart. A framework is a resuable design, so you develop it by > looking at the things it is supposed to be a design of. The more examples > you look at, the more general your framework will be. > > -- Ralph Johnson & Don Roberts, Patterns for Evolving Frameworks > >
Re: Unable to find the mojo 'org.apache.maven.doxia:doxia-maven-plugin:1.0-beta-1-SNAPSHOT:render-books'
Hi Paul, It is related to MNG-3402 You need to build Maven with beta-1 (ie to update maven-reporting-api) and uses maven-project-info-reports-plugin-doxia-beta-1 maven-site-plugin-doxia-beta-1 from the plugins branches. Cheers, Vincent 2008/11/24, Paul Spencer : > I just checked out and build doxia from the source, and I get the following > stack trace from the goal doxia:render-books. I do not get > then error with 1.0-alpha-11. > > o The book is composed on 2 chapters with section of apt document > o apt documents contain only text bocks, not figures or links. > o excerpt of plugin configuration in pom is below. > o book.xml is below. > > > *** > * Stack Trace > *** > > + Error stacktraces are turned on. > [INFO] Scanning for projects... > [INFO] Searching repository for plugin with prefix: 'doxia'. > [INFO] > > [INFO] Building Database Backup Scripts > [INFO]task-segment: [doxia:render-books] > [INFO] > > - > this realm = > app0.child-container[org.apache.maven.doxia:doxia-maven-plugin] > urls[0] = file:/C:/Documents and > Settings/paul/.m2/repository/org/apache/maven/doxia/doxia-maven-plugin/1.0-beta-1-SNAPSHOT/doxia-maven-plugin-1.0-beta-1-SNAPSHOT.jar > urls[1] = file:/C:/Documents and > Settings/paul/.m2/repository/org/apache/maven/doxia/doxia-book/1.0-beta-1-SNAPSHOT/doxia-book-1.0-beta-1-SNAPSHOT.jar > urls[2] = file:/C:/Documents and > Settings/paul/.m2/repository/org/apache/maven/doxia/doxia-core/1.0-beta-1-SNAPSHOT/doxia-core-1.0-beta-1-SNAPSHOT.jar > urls[3] = file:/C:/Documents and > Settings/paul/.m2/repository/org/apache/maven/doxia/doxia-logging-api/1.0-beta-1-SNAPSHOT/doxia-logging-api-1.0-beta-1-SNAPSHOT.jar > urls[4] = file:/C:/Documents and > Settings/paul/.m2/repository/org/codehaus/plexus/plexus-utils/1.5.6/plexus-utils-1.5.6.jar > urls[5] = file:/C:/Documents and > Settings/paul/.m2/repository/xerces/xercesImpl/2.8.1/xercesImpl-2.8.1.jar > urls[6] = file:/C:/Documents and > Settings/paul/.m2/repository/xml-apis/xml-apis/1.3.03/xml-apis-1.3.03.jar > urls[7] = file:/C:/Documents and > Settings/paul/.m2/repository/org/apache/maven/doxia/doxia-module-xdoc/1.0-beta-1-SNAPSHOT/doxia-module-xdoc-1.0-beta-1-SNAPSHOT.jar > urls[8] = file:/C:/Documents and > Settings/paul/.m2/repository/org/apache/maven/doxia/doxia-module-xhtml/1.0-beta-1-SNAPSHOT/doxia-module-xhtml-1.0-beta-1-SNAPSHOT.jar > urls[9] = file:/C:/Documents and > Settings/paul/.m2/repository/org/apache/maven/doxia/doxia-module-apt/1.0-beta-1-SNAPSHOT/doxia-module-apt-1.0-beta-1-SNAPSHOT.jar > urls[10] = file:/C:/Documents and > Settings/paul/.m2/repository/org/apache/maven/doxia/doxia-module-itext/1.0-beta-1-SNAPSHOT/doxia-module-itext-1.0-beta-1-SNAPSHOT.jar > urls[11] = file:/C:/Documents and > Settings/paul/.m2/repository/com/lowagie/itext/1.4/itext-1.4.jar > urls[12] = file:/C:/Documents and > Settings/paul/.m2/repository/org/apache/maven/doxia/doxia-module-latex/1.0-beta-1-SNAPSHOT/doxia-module-latex-1.0-beta-1-SNAPSHOT.jar > urls[13] = file:/C:/Documents and > Settings/paul/.m2/repository/org/apache/maven/doxia/doxia-module-docbook-simple/1.0-beta-1-SNAPSHOT/doxia-module-docbook-simple-1.0-beta-1-SNAPSHOT.jar > urls[14] = file:/C:/Documents and > Settings/paul/.m2/repository/org/codehaus/plexus/plexus-i18n/1.0-beta-6/plexus-i18n-1.0-beta-6.jar > urls[15] = file:/C:/Documents and > Settings/paul/.m2/repository/org/codehaus/plexus/plexus-cli/1.0/plexus-cli-1.0.jar > Number of imports: 6 > import: org.codehaus.classworlds.en...@4891bb28 > import: org.codehaus.classworlds.en...@f8e44ca4 > import: org.codehaus.classworlds.en...@c51bc9e7 > import: org.codehaus.classworlds.en...@bece5185 > import: org.codehaus.classworlds.en...@3fee8e37 > import: org.codehaus.classworlds.en...@3fee19d8 > > > this realm = plexus.core > urls[0] = > file:/c:/apache/apache-maven-2.0.9/lib/maven-2.0.9-uber.jar > Number of imports: 6 > import: org.codehaus.classworlds.en...@4891bb28 > import: org.codehaus.classworlds.en...@f8e44ca4 > import: org.codehaus.classworlds.en...@c51bc9e7 > import: org.codehaus.classworlds.en...@bece5185 > import: org.codehaus.classworlds.en...@3fee8e37 > import: org.codehaus.classworlds.en...@3fee19d8 > - > [INFO] > > [ERROR] BUILD ERROR > [INFO] > > [INFO] Internal error in the plugin manager executing goal > 'org.apache.maven.doxia:doxia-maven-plugin:1.0-beta-1-SNAPSHOT:render-books': > Unable to find the mojo > 'org.apache.maven.doxia:doxia-maven-plugin:1.0-beta-1-SNAPSHOT:render-books' > in the plugi > n 'org.apache.maven.doxia:doxia-maven-plugin' > org/apache/maven/doxi
Re: Doxia Versioning (WAS Preparation of Doxia 1.0-beta-1 release)
Hi Brett, I think we could have the following: Doxia 1.0 should be for Maven 2.0.x Doxia 1.1 should be for Maven 2.1.x/3.x with a fix for MNG-3402 Cheers, Vincent 2008/12/18 Brett Porter : > I have a question about this... > > Does this mean that MNG-3402 should be rescheduled for 2.1.0 now, instead of > 2.0.11? > > I have updated the wiki - and have pushed the upgrade to beta-1 out to > 2.1.0-M3 so that we can push out another milestone in the mean time. > > Cheers, > Brett > > 2008/12/16 Vincent Siveton > Hi Dennis, > > I renamed branches, did an external on the branches, updated some poms. > I leave you Jira and the 1.0 release. > > Cheers, > > Vincent > > 2008/12/14 Vincent Siveton : >> Hi Dennis, >> >>> 2. Rename >>> >>> http://svn.eu.apache.org/repos/asf/maven/doxia/doxia-sitetools/branches/doxia-sitetools-1.0-alpha-x/ >>> to >>> >>> http://svn.eu.apache.org/repos/asf/maven/doxia/doxia-sitetools/branches/doxia-sitetools-1.0.x/ >> >> I didn't remember this branch... Thanks to refresh my memory :) >> >> So, I suggest also to create an external on these branches. I propose: >> https://svn.apache.org/repos/asf/maven/doxia/1.0-x with >> doxia >> https://svn.apache.org/repos/asf/maven/doxia/doxia/branches/doxia-1.0.x/ >> doxia-sitetools >> https://svn.apache.org/repos/asf/maven/doxia/doxia-sitetools/branches/doxia-1.0.x/ >> >> Also, think to update the scm tag in the poms :) >> >>>> - apply new versioning in pom >>> >>> Yes, either before the release or during release:prepare, for both the >>> branch and trunk. >> >> Before is better IMHO >> >>>> What else? >>> >>> For the 1.0 release I think that covers it. >>> >>> Shall we divide up the work between us Vincent? >>> If I do the 1.0 release can you do the 1.1 release? >> >> Sounds good for me. >> >> Cheers, >> >> Vincent >> > > > > -- > Brett Porter > http://blogs.exist.com/bporter/ >
Re: Removed org.codehaus.doxia.sink.Sink for 1.0
Hi Brett, 2008/12/14 Brett Porter : > You will need to at least introduce the overloaded method into 2.0.x and > deprecate the old one... but again this might cause problems for anyone > using the interface and not the AbstractMavenReport. We have already a coupling pb between Maven and Doxia. See MNG-3402. > Perhaps a better approach can be found that can isolate the classloading of > different versions in the Core so that the change can be made directly. Sounds like better for me. It is a Maven pb, not a Doxia one. Cheers, Vincent
Re: Removed org.codehaus.doxia.sink.Sink for 1.0
2008/12/14 Benjamin Bentmann : > Vincent Siveton wrote: > >> I proposed to remove officially org.codehaus.doxia.sink.Sink for the >> 1.0 (DOXIA-146). >> WDYT? > > This interface is still referenced by MavenReport from the > maven-reporting-api. Hence it seems removing it would require a new > reporting API when Doxia 1.0 is integrated into Maven. Not sure how much > havoc that causes to all the reporting Maven plugins out there. Agree with you for maven 2.0.x but for maven 2.1.x I think it is possible. Vincent > > Benjamin >
Re: Removed org.codehaus.doxia.sink.Sink for 1.0
Sorry, I did a mistake due the new versioning :) I speak to remove it in doxia 1.1 for Maven 2.1.x (with Doxia 1.1.x). Vincent 2008/12/14 Vincent Siveton : > Hi guys, > > I proposed to remove officially org.codehaus.doxia.sink.Sink for the > 1.0 (DOXIA-146). > WDYT? > > Vincent >
Removed org.codehaus.doxia.sink.Sink for 1.0
Hi guys, I proposed to remove officially org.codehaus.doxia.sink.Sink for the 1.0 (DOXIA-146). WDYT? Vincent
Re: Doxia Versioning (WAS Preparation of Doxia 1.0-beta-1 release)
Some actions items: - rename the actual doxia branch to 1.0.x and create a new branch for sitetools (and probably for tools) I propose to use the alpha tag code to do this. Create a new branch 1.0.x for all doxia projects sounds better. - apply new versioning in pom - update jira What else? Cheers, Vincent 2008/12/13 Vincent Siveton : > Hi Dennis, > > 2008/12/12 Dennis Lundberg : >> Hi Vincent >> >> Can we have a quit poll about version numbering. We have had discussions >> about this in the past and I'd like to come to a conclusion now that the >> release is getting closer. >> >> The proposal that was made earlier was this: >> >> 1. Create an Doxia 1.0 release from the current doxia-1.0-alpha-x branch > > +1 > >> >> 2. Release the current trunk as version 1.1 (currently labeled as >> 1.0-beta-1 in JIRA) > > +1 > >> >> One reason for this change would be to get out of the alpha/beta mess. > > +1 > >> It would also align version numbers nicely with Maven and the Site Plugin. > > hehe it's about dumb luck :) > >> >> We would the have two parallel tracks: >> >> Track one: Maven 2.0.x + Doxia 1.0.x + Site Plugin 2.0.x >> >> Track two: Maven 2.1.x + Doxia 1.1.x + Site Plugin 2.1.x >> >> This also ties in with the Doxia Release Plan [1] >> >> I will have some time off from work during the holidays and will be able >> to help. >> >> >> WDYT? > > Two releases rather one, good xmas presents! > > If no objections, I will start to prepare these releases, jump in when > you are free. > > Cheers, > > Vincent > >> >> [1] http://docs.codehaus.org/display/MAVEN/Doxia+Release+Plan >
Doxia Versioning (WAS Preparation of Doxia 1.0-beta-1 release)
Hi Dennis, 2008/12/12 Dennis Lundberg : > Hi Vincent > > Can we have a quit poll about version numbering. We have had discussions > about this in the past and I'd like to come to a conclusion now that the > release is getting closer. > > The proposal that was made earlier was this: > > 1. Create an Doxia 1.0 release from the current doxia-1.0-alpha-x branch +1 > > 2. Release the current trunk as version 1.1 (currently labeled as > 1.0-beta-1 in JIRA) +1 > > One reason for this change would be to get out of the alpha/beta mess. +1 > It would also align version numbers nicely with Maven and the Site Plugin. hehe it's about dumb luck :) > > We would the have two parallel tracks: > > Track one: Maven 2.0.x + Doxia 1.0.x + Site Plugin 2.0.x > > Track two: Maven 2.1.x + Doxia 1.1.x + Site Plugin 2.1.x > > This also ties in with the Doxia Release Plan [1] > > I will have some time off from work during the holidays and will be able > to help. > > > WDYT? Two releases rather one, good xmas presents! If no objections, I will start to prepare these releases, jump in when you are free. Cheers, Vincent > > [1] http://docs.codehaus.org/display/MAVEN/Doxia+Release+Plan
Re: Preparation of Doxia 1.0-beta-1 release
Hi Paul, 2008/12/10 Paul Spencer <[EMAIL PROTECTED]>: > Vincent, > The project doxia-test-docs should contain the documents and the document > should be maintained in the projects source repository so they can be > release by the project, i.e. mvn release... The version of this project It is exactly what this new project does. Have a look inside the project, you could see several Doxia docs (i.e. [1] ) which will be maintained there. > should change whenever the source documents change, i.e when you need to > reload them from the "svn copy", and their is a doxia release. The tests Maybe I confused you when I spoke of "svn copy". To be more clear, all docs are initially copied from their own spaces (see [2]). The test code doesn't use SCM anymore. > using doxia-test-docs may need to extract the documents from the > doxia-test-doc artifact/jar, for which their are maven tools to do the > unpacking. It is exactly what the tests do. See [2] > > Keep in mind, one of the reasons for Maven is enable any user at any time > the ability to successfully rebuild the project. Sure and I think the build is now reproducible. Cheers, Vincent [1] https://svn.apache.org/repos/asf/maven/doxia/doxia/trunk/doxia-test-docs/src/main/resources/maven-ant-plugin/fml/ [2] http://svn.apache.org/viewvc?rev=725511&view=rev [3] https://svn.apache.org/repos/asf/maven/doxia/doxia/trunk/doxia-core/src/test/java/org/apache/maven/doxia/xsd/AbstractXmlValidatorTest.java > > Paul Spencer > > On Dec 10, 2008, at 8:19 PM, Vincent Siveton wrote: > >> Hi Benjamin and Paul, >> >> According your comments, I created a new module doxia-test-docs which >> includes svn copy on several documents. I also updated tests to fetch >> these changes. >> Any comments are welcome! >> >> Cheers, >> >> Vincent >> >> >> 2008/12/8 Benjamin Bentmann <[EMAIL PROTECTED]>: >>> >>> Vincent Siveton wrote: >>> >>>> The tests are to perform XSD validations under our current >>>> documentation. Since we add new XSD files in this release, I think >>>> these tests are useful. >>> >>> No doubt, tests are useful but I feel we mix two different test targets >>> here: >>> >>> a) correctness of the XSDs >>> b) correctness of the currently available Maven documentation >>> >>> IMHO, only point a) should be a concern of Doxia, the rest is just >>> outside >>> world. The day we have a validating Doxia under the hood of the Site >>> Plugin >>> and it detects errors in our docs, we can simply fix them when be try to >>> build the corresponding site, not when building Doxia. >>> >>>> Instead of svn co, we could link to relative doc path, ie from >>>> doxia-module-fml using ../../../plugins/maven-ant-plugin/src/site >>> >>> -1 on hard-coding inter-module or even worse inter-project paths. This >>> introduces tight coupling where none should be. Imagine a contributor to >>> Doxia who wants to try out patching it would end up checking out Maven >>> plugins to test Doxia. >>> >>> Also, both "svn co" and the relative path to a local checkout make the >>> idea >>> of a reproducible build unreachable, as Paul already pointed out. >>> >>> To realize test target a), it is surely a nice idea to just grab samples >>> of >>> existing and presumable good docs and check whether the validator doesn't >>> freak out. To do so, how about if we just collect all the doc files of >>> interest from the Maven/plugin sites and copy them to a new Doxia module >>> (doxia-test-docs or whatever). This module would mimic a "svn co" of a >>> locked SVN revision and is also under Doxia control, i.e. one could also >>> create artifical input documents to check more complex syntax structures >>> that are currently not in use on the Maven sites. The other Doxia modules >>> like XDoc etc. could depend on this test module and extract the input >>> files >>> from the test class path or from local file system after unpacking with >>> the >>> Dependency Plugin. Wouldn't that work? >>> >>> >>> Benjamin >>> > >
Re: Preparation of Doxia 1.0-beta-1 release
Hi Benjamin and Paul, According your comments, I created a new module doxia-test-docs which includes svn copy on several documents. I also updated tests to fetch these changes. Any comments are welcome! Cheers, Vincent 2008/12/8 Benjamin Bentmann <[EMAIL PROTECTED]>: > Vincent Siveton wrote: > >> The tests are to perform XSD validations under our current >> documentation. Since we add new XSD files in this release, I think >> these tests are useful. > > No doubt, tests are useful but I feel we mix two different test targets > here: > > a) correctness of the XSDs > b) correctness of the currently available Maven documentation > > IMHO, only point a) should be a concern of Doxia, the rest is just outside > world. The day we have a validating Doxia under the hood of the Site Plugin > and it detects errors in our docs, we can simply fix them when be try to > build the corresponding site, not when building Doxia. > >> Instead of svn co, we could link to relative doc path, ie from >> doxia-module-fml using ../../../plugins/maven-ant-plugin/src/site > > -1 on hard-coding inter-module or even worse inter-project paths. This > introduces tight coupling where none should be. Imagine a contributor to > Doxia who wants to try out patching it would end up checking out Maven > plugins to test Doxia. > > Also, both "svn co" and the relative path to a local checkout make the idea > of a reproducible build unreachable, as Paul already pointed out. > > To realize test target a), it is surely a nice idea to just grab samples of > existing and presumable good docs and check whether the validator doesn't > freak out. To do so, how about if we just collect all the doc files of > interest from the Maven/plugin sites and copy them to a new Doxia module > (doxia-test-docs or whatever). This module would mimic a "svn co" of a > locked SVN revision and is also under Doxia control, i.e. one could also > create artifical input documents to check more complex syntax structures > that are currently not in use on the Maven sites. The other Doxia modules > like XDoc etc. could depend on this test module and extract the input files > from the test class path or from local file system after unpacking with the > Dependency Plugin. Wouldn't that work? > > > Benjamin >
Re: Preparation of Doxia 1.0-beta-1 release
2008/12/8 Paul Spencer <[EMAIL PROTECTED]>: > > On Dec 8, 2008, at 7:17 AM, Vincent Siveton wrote: > >> 2008/12/8 Lukas Theussl <[EMAIL PROTECTED]>: >>> >>> I just noticed that the fml module now takes ~5min to build instead of a >>> few >> >> Same for xdoc module. >> >>> secs for all other modules. There are some svn checkouts during testing, >>> are >>> those necessary? Does it mean you can't build doxia off-line? >> >> The tests are to perform XSD validations under our current >> documentation. Since we add new XSD files in this release, I think >> these tests are useful. >> >> About off-line build, we need to be sure that latest Maven doc is >> again valid (and BTW doxia needs external dependencies) >> Instead of svn co, we could link to relative doc path, ie from >> doxia-module-fml using ../../../plugins/maven-ant-plugin/src/site >> This approach has pros/cons like svn co. >> >> WDYT? > > Why are you not using a dependency? A "svn co" does not insure a > reproduceable build. Using a separate dependency or a given test folder insures that the documentation is valid, right. But how to be sure that the *latest* doc is still valid under our xsd? Is it a reasonable test case? Vincent > Paul Spencer > >
Re: Preparation of Doxia 1.0-beta-1 release
2008/12/8 Lukas Theussl <[EMAIL PROTECTED]>: > > I just noticed that the fml module now takes ~5min to build instead of a few Same for xdoc module. > secs for all other modules. There are some svn checkouts during testing, are > those necessary? Does it mean you can't build doxia off-line? The tests are to perform XSD validations under our current documentation. Since we add new XSD files in this release, I think these tests are useful. About off-line build, we need to be sure that latest Maven doc is again valid (and BTW doxia needs external dependencies) Instead of svn co, we could link to relative doc path, ie from doxia-module-fml using ../../../plugins/maven-ant-plugin/src/site This approach has pros/cons like svn co. WDYT? Vincent > > -Lukas > > > Vincent Siveton wrote: >> >> Hi guys, >> >> IMHO Doxia 1.0-beta-1 could be release soon, ideally for xmas! >> So, do you think we are missing issues? >> Any other comments? >> >> Cheers, >> >> Vincent >> >
Re: svn commit: r723989 - /maven/doxia/doxia/trunk/doxia-core/src/main/java/org/apache/maven/doxia/parser/AbstractXmlParser.java
Hi Benjamin,
Right and I fixed it in r724309.
Thanks!
Vincent
2008/12/6 Benjamin Bentmann <[EMAIL PROTECTED]>:
> Hi Vincent,
>
>> Author: vsiveton
>> Date: Sat Dec 6 06:41:44 2008
>> New Revision: 723989
>>
>> URL: http://svn.apache.org/viewvc?rev=723989&view=rev
>> Log:
>> DOXIA-265: Add an EntityResolver in AbstractXmlParser#getXmlReader()
>>
>> o added a simple cached file mechanism
>>
>> Modified:
>>
>>
>> maven/doxia/doxia/trunk/doxia-core/src/main/java/org/apache/maven/doxia/parser/AbstractXmlParser.java
>> [...]
>> +byte[] res = (byte[]) cache.get( systemId );
>> +// already cached?
>> +if ( res == null )
>> +{
>> +File temp =
>> +new File( System.getProperty( "java.io.tmpdir" ),
>> FileUtils.getFile( systemId ).getName() );
>> +// maybe already as a temp file?
>> +if ( !temp.exists() )
>> +{
>> +res = IOUtil.toByteArray( new URL( systemId
>> ).openStream() );
>> +IOUtil.copy( res, WriterFactory.newPlatformWriter(
>> temp ) );
>> +}
>> +else
>> +{
>> +res = IOUtil.toByteArray(
>> ReaderFactory.newPlatformReader( temp ) );
>> +}
>> +
>> +cache.put( systemId, res );
>> +}
>> +
>> +InputSource is = new InputSource( new ByteArrayInputStream(
>> res ) );
>> +is.setPublicId( publicId );
>> +is.setSystemId( systemId );
>> +
>
> Is it safe to use a reader here, especially a platform reader? Byte streams
> that don't match the intended encoding get crippled but is the encoding of
> the data known here? Should this maybe just use
> IOUtil.copy( byte[], OutputStream )
> and
> IOUtil.toByteArray( InputStream )
> i.e. simply move bytes around instead of thinking about characters?
>
>
> Benjamin
>
Preparation of Doxia 1.0-beta-1 release
Hi guys, IMHO Doxia 1.0-beta-1 could be release soon, ideally for xmas! So, do you think we are missing issues? Any other comments? Cheers, Vincent
Re: (output) encoding support in doxia-sink-api
2008/11/7 Benjamin Bentmann <[EMAIL PROTECTED]>: > Vincent Siveton wrote: > >>> Then I think "Sink createSink( Writer writer )" should be removed. >> >> I prefer deprecated for backward compatibility issue. > > The source code says "@since 1.0-beta-1", i.e. this method was never part of > a released Doxia version, right? Then we should be able to safely removed > it. Having both "@since 1.0-beta-1" and "@deprecated since 1.0-beta-1" on a > method would be quite strange ;-) mmh seems logical :) Vincent > > Benjamin >
Re: (output) encoding support in doxia-sink-api
Other comments which maybe related to this thread: * Parser needs at least 2 parsing: one for macro and another one for processing, and now a third one to validate XML (DOXIA-263) * Sink uses some time StringWriter to play with the writed content and to create a valid content (DOXIA-177) So, maybe it will more easy to have directly String in input/output instead of stream. Cheers, Vincent 2008/11/7 Vincent Siveton <[EMAIL PROTECTED]>: > Hi, > > 2008/11/7 Hervé BOUTEMY <[EMAIL PROTECTED]>: >> Hi folks, >> >> For the next 1.0-beta-1 version, 2 methods have been added to SinkFactory >> interface to improve encoding support: >> - Sink createSink( File outputDir, String outputName, String encoding ) >> - Sink createSink( Writer writer ) >> See [1] for the full interface. > > +1 > >> >> I worked with Vincent to implement output encoding in Doxia, and we faced >> problems that lead us think that forcing a fixed encoding was the right >> approach to have something simple and reliable: with UTF-8 as this fixed >> encoding, this didn't limit end-users from any country in the world. >> >> But now, I'm convinced it's not the right approach and API: >> 1. some formats need to output the encoding (like HTML, or XML): we need an >> encoding parameter, as we can't get it from a Writer instance > > see also DOXIA-185 > >> 2. some formats embed images, like RTF or PDF, then need direct stream access >> to write binary data >> >> Then I think "Sink createSink( Writer writer )" should be removed. > > I prefer deprecated for backward compatibility issue. > >> Or if we want an API without filename, this method could be transformed into >> Sink createSink( OutputStream output ) + Sink createSink( OutputStream >> output, String encoding ). > > +1 > > Thanks Hervé for that. > > Vincent > >> Any objection or idea? >> >> Hervé >> >> [1] >> http://svn.apache.org/viewvc/maven/doxia/doxia/trunk/doxia-sink-api/src/main/java/org/apache/maven/doxia/sink/SinkFactory.java?view=markup >> >
Re: (output) encoding support in doxia-sink-api
Hi Benjamin 2008/11/7 Benjamin Bentmann <[EMAIL PROTECTED]>: [SNIP] > It might however be convenient to create an AbstractTextSinkFactory from > which all/most text-based sinks could inherit. For instance, > XhtmlSinkFactory and XdocSinkFactory look pretty much the same. In more > detail, how about +1 too Vincent
Re: (output) encoding support in doxia-sink-api
Hi, 2008/11/7 Hervé BOUTEMY <[EMAIL PROTECTED]>: > Hi folks, > > For the next 1.0-beta-1 version, 2 methods have been added to SinkFactory > interface to improve encoding support: > - Sink createSink( File outputDir, String outputName, String encoding ) > - Sink createSink( Writer writer ) > See [1] for the full interface. +1 > > I worked with Vincent to implement output encoding in Doxia, and we faced > problems that lead us think that forcing a fixed encoding was the right > approach to have something simple and reliable: with UTF-8 as this fixed > encoding, this didn't limit end-users from any country in the world. > > But now, I'm convinced it's not the right approach and API: > 1. some formats need to output the encoding (like HTML, or XML): we need an > encoding parameter, as we can't get it from a Writer instance see also DOXIA-185 > 2. some formats embed images, like RTF or PDF, then need direct stream access > to write binary data > > Then I think "Sink createSink( Writer writer )" should be removed. I prefer deprecated for backward compatibility issue. > Or if we want an API without filename, this method could be transformed into > Sink createSink( OutputStream output ) + Sink createSink( OutputStream > output, String encoding ). +1 Thanks Hervé for that. Vincent > Any objection or idea? > > Hervé > > [1] > http://svn.apache.org/viewvc/maven/doxia/doxia/trunk/doxia-sink-api/src/main/java/org/apache/maven/doxia/sink/SinkFactory.java?view=markup >
Re: svn commit: r712146 - /maven/doxia/doxia/trunk/doxia-core/src/test/java/org/apache/maven/doxia/sink/SinkTestDocument.java
Hi again, I reverted this in 712235 and fix the pb of invalid bytes. Hope that it is correct now. Vincent 2008/11/7 Vincent Siveton <[EMAIL PROTECTED]>: > Hi, > > 2008/11/7 Hervé BOUTEMY <[EMAIL PROTECTED]>: >> -1: please revert this change >> >> String.valueOf( '\u00a9' ) represents the Copyright symbol: there is no >> encoding notion available here. >> => the code was perfectly correct and did what was expected > > Not sure since I got exception with the original code (BTW it is weird > since everything should be in UTF-8...) > You are our encoding expert so feel free to fix it. > > --- > Test set: org.apache.maven.doxia.module.xhtml.XhtmlIdentityTest > --- > Tests run: 1, Failures: 0, Errors: 1, Skipped: 0, Time elapsed: 1.657 > sec <<< FAILURE! > testIdentity(org.apache.maven.doxia.module.xhtml.XhtmlIdentityTest) > Time elapsed: 1.625 sec <<< ERROR! > org.apache.maven.doxia.parser.ParseException: Error validating the > model: Fatal error: > Public ID: null > System ID: null > Line number: 2 > Column number: 1701 > Message: Invalid byte 1 of 1-byte UTF-8 sequence. >at > org.apache.maven.doxia.parser.AbstractXmlParser.validate(AbstractXmlParser.java:554) >at > org.apache.maven.doxia.parser.AbstractXmlParser.parse(AbstractXmlParser.java:105) >at > org.apache.maven.doxia.module.AbstractIdentityTest.testIdentity(AbstractIdentityTest.java:112) > and so one > > Cheers > > Vincent >
Re: svn commit: r697524 - in /maven/doxia/doxia/trunk/doxia-modules/doxia-module-docbook-simple/src/main/java/org/apache/maven/doxia/module/docbook: DocBookParser.java DocBookSiteModule.java
Hi Lukas,
I forgot to commit the Plexus component file. Done in r698133.
Cheers,
Vincent
2008/9/22 Lukas Theussl <[EMAIL PROTECTED]>:
> Hi Vincent,
>
> Is there any special reason for this 'innocent' change? I am concerned about
> backward compatibility (yes, really! ;) ). As illustrated by the problem
> that Arnaud encountered [1], these things are hard to track down...
>
> -Lukas
>
> [1] http://www.nabble.com/Adding-a-module-td14997185.html
>
>
> [EMAIL PROTECTED] wrote:
>>
>> Author: vsiveton
>> Date: Sun Sep 21 07:29:52 2008
>> New Revision: 697524
>>
>> URL: http://svn.apache.org/viewvc?rev=697524&view=rev
>> Log:
>> o unify docbook lookup
>>
>> Modified:
>>
>>
>> maven/doxia/doxia/trunk/doxia-modules/doxia-module-docbook-simple/src/main/java/org/apache/maven/doxia/module/docbook/DocBookParser.java
>>
>>
>> maven/doxia/doxia/trunk/doxia-modules/doxia-module-docbook-simple/src/main/java/org/apache/maven/doxia/module/docbook/DocBookSiteModule.java
>>
>> Modified:
>> maven/doxia/doxia/trunk/doxia-modules/doxia-module-docbook-simple/src/main/java/org/apache/maven/doxia/module/docbook/DocBookParser.java
>> URL:
>> http://svn.apache.org/viewvc/maven/doxia/doxia/trunk/doxia-modules/doxia-module-docbook-simple/src/main/java/org/apache/maven/doxia/module/docbook/DocBookParser.java?rev=697524&r1=697523&r2=697524&view=diff
>>
>> ==
>> ---
>> maven/doxia/doxia/trunk/doxia-modules/doxia-module-docbook-simple/src/main/java/org/apache/maven/doxia/module/docbook/DocBookParser.java
>> (original)
>> +++
>> maven/doxia/doxia/trunk/doxia-modules/doxia-module-docbook-simple/src/main/java/org/apache/maven/doxia/module/docbook/DocBookParser.java
>> Sun Sep 21 07:29:52 2008
>> @@ -42,7 +42,7 @@
>> * @author mailto:[EMAIL PROTECTED]">Jason van Zyl
>> * @version $Id$
>> * @since 1.0
>> - * @plexus.component role="org.apache.maven.doxia.parser.Parser"
>> role-hint="doc-book"
>> + * @plexus.component role="org.apache.maven.doxia.parser.Parser"
>> role-hint="docbook"
>> */
>> public class DocBookParser
>> extends AbstractXmlParser
>> @@ -734,10 +734,10 @@
>> /*
>> * NOTE: Don't do any whitespace trimming here. Whitespace
>> normalization has already been performed by the
>> * parser so any whitespace that makes it here is significant.
>> - */ + */
>> if ( StringUtils.isNotEmpty( text ) )
>> {
>> -// Emit separate text events for different lines, e.g. the
>> input +// Emit separate text events for different lines, e.g.
>> the input
>> // "\nLine1\n\nLine2\n\n" should deliver the event sequence
>> "\n", "Line1\n", "\n", "Line2\n", "\n".
>> // In other words, the concatenation of the text events must
>> deliver the input sequence.
>> // (according to section 2.11 of the XML spec, parsers must
>> normalize line breaks to "\n")
>>
>> Modified:
>> maven/doxia/doxia/trunk/doxia-modules/doxia-module-docbook-simple/src/main/java/org/apache/maven/doxia/module/docbook/DocBookSiteModule.java
>> URL:
>> http://svn.apache.org/viewvc/maven/doxia/doxia/trunk/doxia-modules/doxia-module-docbook-simple/src/main/java/org/apache/maven/doxia/module/docbook/DocBookSiteModule.java?rev=697524&r1=697523&r2=697524&view=diff
>>
>> ==
>> ---
>> maven/doxia/doxia/trunk/doxia-modules/doxia-module-docbook-simple/src/main/java/org/apache/maven/doxia/module/docbook/DocBookSiteModule.java
>> (original)
>> +++
>> maven/doxia/doxia/trunk/doxia-modules/doxia-module-docbook-simple/src/main/java/org/apache/maven/doxia/module/docbook/DocBookSiteModule.java
>> Sun Sep 21 07:29:52 2008
>> @@ -25,7 +25,7 @@
>> * @author mailto:[EMAIL PROTECTED]">Emmanuel Venisse
>> * @version $Id$
>> * @since 1.0
>> - * @plexus.component role="org.apache.maven.doxia.module.site.SiteModule"
>> role-hint="doc-book"
>> + * @plexus.component role="org.apache.maven.doxia.module.site.SiteModule"
>> role-hint="docbook"
>> */
>> public class DocBookSiteModule
>> extends AbstractSiteModule
>>
>>
>>
>
Re: svn commit: r659507 - in /maven/doxia/doxia/trunk: doxia-core/src/main/java/org/apache/maven/doxia/util/ doxia-modules/doxia-module-apt/src/main/java/org/apache/maven/doxia/module/apt/
Hi Lukas,
Since the code in AptUtils#isExternalLink() ==
DoxiaUtils#isExternalLink(), I suggest to remove the first one.
Cheers,
Vincent
2008/5/23, [EMAIL PROTECTED] <[EMAIL PROTECTED]>:
> Author: ltheussl
> Date: Fri May 23 04:38:39 2008
> New Revision: 659507
>
> URL: http://svn.apache.org/viewvc?rev=659507&view=rev
> Log:
> Better definition of external/internal/local links and adaptation in the apt
> case.
>
> Modified:
>
> maven/doxia/doxia/trunk/doxia-core/src/main/java/org/apache/maven/doxia/util/DoxiaUtils.java
>
> maven/doxia/doxia/trunk/doxia-modules/doxia-module-apt/src/main/java/org/apache/maven/doxia/module/apt/AptParser.java
>
> maven/doxia/doxia/trunk/doxia-modules/doxia-module-apt/src/main/java/org/apache/maven/doxia/module/apt/AptUtils.java
>
> Modified:
> maven/doxia/doxia/trunk/doxia-core/src/main/java/org/apache/maven/doxia/util/DoxiaUtils.java
> URL:
> http://svn.apache.org/viewvc/maven/doxia/doxia/trunk/doxia-core/src/main/java/org/apache/maven/doxia/util/DoxiaUtils.java?rev=659507&r1=659506&r2=659507&view=diff
>
> ==
> ---
> maven/doxia/doxia/trunk/doxia-core/src/main/java/org/apache/maven/doxia/util/DoxiaUtils.java
> (original)
> +++
> maven/doxia/doxia/trunk/doxia-core/src/main/java/org/apache/maven/doxia/util/DoxiaUtils.java
> Fri May 23 04:38:39 2008
> @@ -39,6 +39,9 @@
> *
> * @param link The link to check.
> * @return True if the link starts with "#".
> + *
> + * @see #isExternalLink(String)
> + * @see #isLocalLink(String)
> */
> public static boolean isInternalLink( String link )
> {
> @@ -48,13 +51,16 @@
> /**
> * Checks if the given string corresponds to an external URI,
> * ie is not a link within the same document nor a relative link
> - * to another document (a local link).
> + * to another document (a local link) of the same site.
> *
> * @param link The link to check.
> - * @return True if the link (ignoring case) starts with either of the
> - * following: "http:/", "https:/", "ftp:/", "mailto:";, "file:/".
> + * @return True if the link (ignoring case) starts with either "http:/",
> + * "https:/", "ftp:/", "mailto:";, "file:/", or contains the string
> "://".
> * Note that Windows style separators "\" are not allowed
> * for URIs, see http://www.ietf.org/rfc/rfc2396.txt , section 2.4.3.
> + *
> + * @see #isInternalLink(String)
> + * @see #isLocalLink(String)
> */
> public static boolean isExternalLink( String link )
> {
> @@ -62,14 +68,19 @@
>
> return ( text.indexOf( "http:/" ) == 0 || text.indexOf( "https:/" )
> == 0
> || text.indexOf( "ftp:/" ) == 0 || text.indexOf( "mailto:"; ) == 0
> -|| text.indexOf( "file:/" ) == 0 );
> +|| text.indexOf( "file:/" ) == 0 || text.indexOf( "://" ) != -1
> );
> }
>
> /**
> - * Checks if the given string corresponds to a relative link to another
> document.
> + * Checks if the given string corresponds to a relative link to another
> document
> + * within the same site, ie it is neither an [EMAIL PROTECTED]
> #isInternalLink(String) internal}
> + * nor an [EMAIL PROTECTED] #isExternalLink(String) external} link.
> *
> * @param link The link to check.
> * @return True if the link is neither an external nor an internal link.
> + *
> + * @see #isExternalLink(String)
> + * @see #isInternalLink(String)
> */
> public static boolean isLocalLink( String link )
> {
>
> Modified:
> maven/doxia/doxia/trunk/doxia-modules/doxia-module-apt/src/main/java/org/apache/maven/doxia/module/apt/AptParser.java
> URL:
> http://svn.apache.org/viewvc/maven/doxia/doxia/trunk/doxia-modules/doxia-module-apt/src/main/java/org/apache/maven/doxia/module/apt/AptParser.java?rev=659507&r1=659506&r2=659507&view=diff
>
> ==
> ---
> maven/doxia/doxia/trunk/doxia-modules/doxia-module-apt/src/main/java/org/apache/maven/doxia/module/apt/AptParser.java
> (original)
> +++
> maven/doxia/doxia/trunk/doxia-modules/doxia-module-apt/src/main/java/org/apache/maven/doxia/module/apt/AptParser.java
> Fri May 23 04:38:39 2008
> @@ -25,6 +25,7 @@
> import org.apache.maven.doxia.parser.AbstractTextParser;
> import org.apache.maven.doxia.sink.Sink;
> import org.apache.maven.doxia.sink.SinkAdapter;
> +import org.apache.maven.doxia.sink.SinkEventAttributeSet;
> import org.apache.maven.doxia.util.DoxiaUtils;
>
> import org.codehaus.plexus.util.IOUtil;
> @@ -433,7 +434,7 @@
> linkAnchor = getTraversedLink( text, i + 1,
> end );
> }
>
> -if ( !AptUtils.isExternalLink( linkAnchor ) )
> +
Re: Twiki Module Enhancements
Hi Abhijit, I recommend you to provide a patch under the trunk and not under alpha tag. The trunk is Doxia beta-1. Thanks, Vincent 2008/5/23, Abhijit Bagri <[EMAIL PROTECTED]>: > Hi, > > I am Abhijit and work in a platform team at Yahoo! We recently moved > documentation of our project from our Twiki web to mvn, primarily so that we > could maintain our documentation more effectively and keep it in sync with > rapidly changing feature set of our platform. > > I tried using the twiki module. I found it quite a bit done, but there were > a bunch of features we needed for us to use it. I have enhanced/modified the > twiki module for the following features: > > 1. Enable doxia macros in twiki-module. The syntax I have chosen for this > is %MACRO_NAME|param=value|param2=value2% > This was most important for the toc macro. A related change which was > needed is #2 > > 2. Since toc needed the whole doc source to be supplied, I had to modify > ByLineSource implementation to have the entire source. Since changing the > whole line based implementation was taknig too much, I just emulated whole > source reading and supporting the getLine method in the new implementation. > > 3. Enable linking of wiki words. > > Earlier a [[MyWikiWord]] would get likned to ./MyWikiWord. I am not sure > why it was this way. Some light on this? I needed it to point it to > ./MyWikiWord.html to be useful. Similarly for linking up wikiwords in > [[][]]. > > 4. Enable HTML tags. I saw a JIRA on this. Its not assigned so I guess I > can put in my patch there > > 5. Enabling verbatim and blockquote. verbatim did not seem to work properly > for me. > > We are currently using a patched version of alpha-9 successfully at Yahoo! > (for internal usage only). However, We though that the community may benefit > from this and decided to contribute back. > > I see that the current tag is 11-alpha. I would appreciate if someone could > let me know progress on these issues. I will create necessary JIRA for this > and add my patch after that. > > Thanks > Abhijit > > >
Re: [VOTE] Release doxia-sitetools-1.0-alpha-11
+1 Thanks Dennis! Vincent 2008/5/15, Dennis Lundberg <[EMAIL PROTECTED]>: > Hi, > > This vote is to release doxia-sitetools-1.0-alpha-11. > > The Release Notes show only 1 issue solved, but there are a few other > minor changes as well: > http://jira.codehaus.org/secure/ReleaseNote.jspa?projectId=11624&styleName=Html&version=13908 > > Tags: > https://svn.apache.org/repos/asf/maven/doxia/doxia-sitetools/tags/doxia-sitetools-1.0-alpha-11/ > > Staged at: > http://people.apache.org/~dennisl/staging-repository/ > > The vote will be open for 72 hours. > > > Here is my +1 > > -- > Dennis Lundberg > >
Re: fml id's
Hi Lukas, 2008/5/13, Lukas Theussl <[EMAIL PROTECTED]>: > > Another doubt about faq id's: in m1 an id had to be a valid HTML id, in m2 > fml files I see frequently things like [1] > > > > which is internally converted to . I think the faq > id should be valid in the first place, correct? In theory yes, but I think this logic is more useful and intuitive for users. Cheers, Vincent > -Lukas > > > [1] > https://svn.apache.org/repos/asf/maven/site/trunk/src/site/fml/general.fml > >
Re: link/anchors in apt
+1
Vincent
2008/5/13, Lukas Theussl <[EMAIL PROTECTED]>:
> Hi,
>
> I'd like to fix http://jira.codehaus.org/browse/DOXIA-208
> in beta-1 still to avoid possible breaking changes later on. I am a bit
> confused about APT though as we seem to have a lot of different standards
> floating around in our own docs. Just to make sure I am on the right track,
> this is how I understand that things should work, which we should enforce in
> beta-1:
>
>
> 1) external links are links that start with http:/ , https:/ , ftp:/ ,
> file:/ , mailto: , ../ , or ./ (Windows-style ..\ and .\ are NOT allowed
> contrary to the original apt docs).
>
> This means in particular that links to other source documents have to start
> with ./ or ../, ie something like {{getting-started/index.html}} is NOT
> valid, you nee to pre-pend ./ (just to be clear: this is APT specific, the
> above link would be valid in an xdoc).
>
> 2) internal links are links to anchors within the same source document, eg
> "Link to {{anchor}}". Anchors have to be valid id's as defined in the Sink
> javadocs for anchor() [1].
>
> This means in particular that links to anchors must not start with "#", eg
> all the links in the beginning of [2] are NOT valid.
>
>
>
> Does that sound reasonable? The alternative would be to handle links a la
> HTML, ie to mark internal links with "#" as suggested at DOXIA-208, this
> would render the examples at [2] valid.
>
> Any comments/objections?
> -Lukas
>
>
> [1]
> https://svn.apache.org/repos/asf/maven/doxia/doxia/trunk/doxia-sink-api/src/main/java/org/apache/maven/doxia/sink/Sink.java
>
> [2]
> https://svn.apache.org/repos/asf/maven/site/trunk/src/site/apt/pom.apt
>
Re: MNG-3402
Hi Lukas, 2008/5/13, Lukas Theussl <[EMAIL PROTECTED]>: > > I am not sure I understand correctly the implications of MNG-3402 [1] wrt > the beta-1 release plan. Is the following correct? > > - in order for the site plugin to use doxia-beta-1, we need to resolve > MNG-3402 AFAIK yes > - MNG-3402 can be resolved in three different ways: 1) release maven-2.0.10 > with doxia bumped to beta-1, 2) remove the sink-api filtering as proposed by > Vincent, 3) both of the two 1) is the easiest solution and as you said, site plugin will have a prerequisite on 2.0.10 2) or 3) seems to work but over a period of time, the risk of multiple side effects will exist, specially for report plugins using old Doxia version (ie alpha-7) > > - however it is resolved, the site plugin would have a prereq on > maven-2.0.10, is that right? Correct > - we will have to release a couple of other things together with the site > plugin (PIR, plugin-plugin at least) also with deps bumped to doxia-beta-1. site PIR are core plugins to produce documentation. Plugin plugin is a report plugin as others. It sounds reasonable to release it with beta-1, but I think we need to release all report plugins like PMD checkstyle... > Any more insight would be welcome... No more ;) Cheers, Vincent > Cheers, > -Lukas > > > [1] http://jira.codehaus.org/browse/MNG-3402 >
Re: [VOTE] Release doxia-1.0-alpha-11
+1 Thanks Dennis! Vincent 2008/5/11, Dennis Lundberg <[EMAIL PROTECTED]>: > Hi, > > This vote is to release doxia-1.0-alpha-11, which will be followed by > another vote for doxia-sitetools-1.0-alpha-11. > > The Release Notes show only 1 issue solved, but there are a few other minor > changes as well: > http://jira.codehaus.org/secure/ReleaseNote.jspa?projectId=10780&styleName=Html&version=14265 > > Tags: > https://svn.apache.org/repos/asf/maven/doxia/doxia/tags/doxia-1.0-alpha-11/ > > Staged at: > http://people.apache.org/~dennisl/staging-repository/ > > The vote will be open for 72 hours. > > > Here is my +1 > > -- > Dennis Lundberg >
Re: releasing 1.0
Hi, [SNIP] Your plan sounds good for me. > > Here's what I'd like to do: > > - Release a last 1.0-alpha of Doxia, from the alpha branch > - Update the Site plugin to use that released alpha of Doxia > - Release maven-doxia-tools 1.0 and use that in the Site plugin > - Release Site plugin 2.0-beta-7, moving the other issues slated for beta-7 > to beta-8 > - Switch the Site plugin (2.0-beta-8-SNAPSHOT) over to use Doxia beta-1 > SNAPSHOT > - Release Doxia beta-1 A this point, you forgot MNG-3402, so we need to release maven 2.0.10 before to use beta-1 in plugins > - Release Site plugin beta-8 using Doxia beta-1 > - Start collecting a list of issues that blocks a Doxia 1.0 release > - Push that list down to 0 > - Release Doxia 1.0 > - Release Site plugin 2.0 > > The beta-7 release of the Site plugin is to make the releases smaller. > Currently beta-7 already has 17 issues fixed. > > I'm volunteering to do the Doxia alpha release and all the Site plugin > releases. Thanks for this. > We also need someone to release maven-doxia-tools (a shared component) and I started this but due to the outage, I did not finish it. I will do this week. > Doxia beta-1 and 1.0. Count me in. Cheers, Vincent
Discuss about next Doxia
Hi, Following recent threads, I started a wiki proposal: http://docs.codehaus.org/display/DOXIA/Proposal+On+Next+Doxia Cheers, Vincent
Re: The need for multiple passes over a document
2008/4/28 Jason van Zyl <[EMAIL PROTECTED]>: > I was looking at the TOC macro and I feel what it's doing is wrong insofar > as requiring a second pass to get the structure of the document. Agree but we did it as best that we can :) > There are definitely cases where you need to make multiple passes and the > TOC macro is clearly one of them. Having to pass in the the whole source > document and the parser to make the TOC macro work seem extreme to me. > > I think that we should declaratively say, or determine, that the structure > of the document is required by something in the page. Preprocess the page in > a general way and not require passing in the whole document and parser again > as that's pretty cumbersome for the implementor of a parser. > > I also noticed that the parsers are not threadsafe, I don't believe this > was always the case and we should make them threadsafe again if it's true > they aren't. I just looked at the APT parser and it doesn't look threadsafe > to me but wouldn't take much to make it threadsafe. DefaultDoxia as a comment about thread safe... > > I would like to take a pass at making the document structure requirement > more general to avoid things like we're doing in the TOC macro. I would also > like to take a pass at making the parsers threadsafe. > > I think we should also just release 1.0 for the sake of the site plugin and > then move on with the next version of Doxia. We need to remove the coupling > of doxia to the site plugin and move the core back to a simple set of > parsers and sinks. Sounds like a Doxia 2.0 :) I think Doxia has several limitations, specially for style. DOXIA-204 solved several of them but I think we could do more. Cheers, Vincent > > Thanks, > > Jason > > -- > Jason van Zyl > Founder, Apache Maven > jason at sonatype dot com > -- > > A language that doesn't affect the way you think about programming is not > worth knowing. > > -— Alan Perlis > > > >
Re: releasing 1.0
Hi Jason, 2008/4/28 Jason van Zyl <[EMAIL PROTECTED]>: > Hi, > > After chatting with Lukas and Vincent on IRC I think if we want to continue > with changes to Doxia then we should release the 1.0 for the site plugin and > move on. > > I know that changes Vincent Massol would like to make are important, and I > have started to fully decouple the site notions from the core of doxia. Move > it toward a set of parsers and sinks. Let client code deal with sites, > parser managers, sink managers and whatever else. Tools like the macro > manager can also be added in a more flexible way where those tools are > plugins to the system. DEFINITELY agree on that! I have in mind a plugin way for macro things. > > So how about we release 1.0 and then hack away on the future? Always agree on it but IMHO we need to follow our process, i.e. beta-1 soon and 1.0. Beta-1 seems very easy to make according Jira and 1.0 is mainly about schema or DTD. After that, we need to support correctly the site-plugin and thus release it as 2.0. Same things for PIR. I don't think there is any rush to release Doxia. After all, Doxia has around 3 years of alpha ;) Finally, I will be confident to start on Doxia 2.0 :) Cheers, Vincent > Thanks, > > Jason > > -- > Jason van Zyl > Founder, Apache Maven > jason at sonatype dot com > -- > > A language that doesn't affect the way you think about programming is not > worth knowing. > > -— Alan Perlis > > > >
Re: Review Link Handling in APT
2008/4/12, Benjamin Bentmann <[EMAIL PROTECTED]>:
> > Not sure. Take a look to the renderer [1] and the source [2]. Link are
> > external for {{{guide-testing-releases.html} test releases}}
> >
>
> I just stumbled upon this in r647420 [0]. After some other tries I figured
> out:
> - {{{foo.html}baa}} is external
> - {{{foo.txt}baa}} is internal
> i.e. the linking behaviour depends on the file extension.
>
> That's the kind of black magic for which Maven is blamed by users.
>
Same tricks that dev forgot ;)
Cheers,
Vincent
>
> Benjamin
>
>
> [0] http://svn.apache.org/viewvc?view=rev&revision=647420
>
Re: Review Link Handling in APT
Hi Benjamin,
2008/4/12, Benjamin Bentmann <[EMAIL PROTECTED]>:
> Hi,
>
> According to the APT Reference [0] and the output delivered by the Maven
> Site Plugin 2.0-beta-6, the construct
>
> {{{foo}baa}}
>
> denotes an internal link to the anchor "foo" in the current document. I
> believe this kind of linking is inconsistent/unintuitive and hence
> error-prone.
>
> For example, {{{dir/doc.pdf}baa}} will render an external link as expected.
> Now let's move doc.pdf up one directory. The appealing snippet
> {{{doc.pdf}baa}} will not give you the desired external link but out of a
> sudden an internal link. To get the desired link, users need to write
> {{{./doc.pdf}baa}}.
Not sure. Take a look to the renderer [1] and the source [2]. Link are
external for {{{guide-testing-releases.html} test releases}}
Cheers,
Vincent
[1] http://maven.apache.org/guides/development/guide-helping.html
[2]
https://svn.apache.org/repos/asf/maven/site/trunk/src/site/apt/guides/development/guide-helping.apt
> Wouldn't it be easier, both for users and the parser, if APT would handle
> links just like the well-known HTML format? I.e. a link is internal if and
> only if it starts with '#'.
>
> What do you think?
>
>
> Benjamin
>
>
> [0]
> http://maven.apache.org/doxia/references/apt-format.html
>
Re: additions to sink api
+1 My only interrogation is why keys *and* values needs to be in lower case... I refer to style which could contains both. Cheers, Vincent 2008/2/28, Lukas Theussl <[EMAIL PROTECTED]>: > Hi, > > Following the discussions around DOXIA-204 [1] I have implemented the > idea there, ie added a SinkEventAttributes parameter to all the relevant > sink methods, for instance > > public void figure( SinkEventAttributes attributes ); > > I am still testing it with the little time I have available currently > but it seems to work and I'd be ready to commit it on beta-1 trunk. As > noted at DOXIA-204, this will solve (or allow to solve) a whole bunch of > issues, but brings us one step further away from backward compatibility > with the alpha branch (which is however already broken in current trunk > anyway). > > I have deployed my javadocs of doxia-sink-api [2], let me know if you > have any comments on the design or if I can go ahead. > > Thanks, > -Lukas > > > [1] http://jira.codehaus.org/browse/DOXIA-204 > [2] > http://people.apache.org/~ltheussl/staging-sites/doxia-sink-api/site/apidocs/ >
Re: how to customize sections markup?
Hi Catalin, 2008/1/22, Catalin Kormos <[EMAIL PROTECTED]>: > Hi there, > > I tried this question on the maven users lists first, but got no answer > there yet, sorry for the possible double post, but this list actually seems > more appropriate now. > > What i'm after is the possibility to customize the markup of the first level > sections, that i require for a custom maven skin. As we're trying to have > some image based borders around those sections, nicely expandable, we need a > couple of more surrounding tags, not just one with class="section". I > would greatly appreciate if somebody could put me on the right direction > with this. Any ideas? There is no way to customize markup (except a fork). Your issue seems to be related to DOXIA-63, if not, create a new one. Thanks! Vincent > > Thanks in advance, > Catalin >
Re: Committing XWiki implementation on trunk?
Yes, go ahead in the sandbox Vincent 2008/1/8, Brett Porter <[EMAIL PROTECTED]>: > It sounds fine - though there's also the sandbox if you wanted > somewhere out of the way to work on it? > > On 08/01/2008, at 5:30 PM, Vincent Massol wrote: > > > Hello, > > > > I'd like to commit the first version of the XWiki Sink that I have > > (I have started a XWiki parser but I'm not ready yet to commit that > > on - I should have a first version in about 3-4 days though). > > > > Is it ok for me to commit it in trunk in a doxia-module-xwiki? Since > > I'm not touching any existing code, I thought it might be ok. > > > > If not, let me know where I could commit it. > > > > Note that I'd like to commit what I have ASAP since Jason is also > > interested in working on it/testing it. > > > > Thanks a lot > > -Vincent > > > >
Re: [VOTE] Release doxia-sitetools-1.0-alpha-10
+1 Vincent 2007/11/3, Dennis Lundberg <[EMAIL PROTECTED]>: > Hi, > > Here comes the follow up to the doxia-1.0-alpha-10 release. This time > the vote is for releasing doxia-sitetools-1.0-alpha-10. > > Release Notes: > None. > The only real change is that this release uses doxia-1.0-alpha-10 > instead of alpha-9. > > Tags: > https://svn.apache.org/repos/asf/maven/doxia/doxia-sitetools/tags/doxia-sitetools-1.0-alpha-10/ > > Staged at: > http://people.apache.org/~dennisl/staging-repository-doxia-sitetools/ > > The vote will be open for 72 hours. > > > Here is my +1 > > -- > Dennis Lundberg >
Re: [VOTE] Release doxia-1.0-alpha-10
+1 Vincent 2007/10/29, Dennis Lundberg <[EMAIL PROTECTED]>: > Hi, > > Due to a couple of issues we need to release doxia-1.0-alpha-10, before > we can start using it in the plugins. This time I will release doxia and > doxia-sitetools separately, so that we don't confuse Continuum this > time. A vote for doxia-sitetools-1.0-alpha-10 will follow. > > Release Notes: > http://jira.codehaus.org/secure/ReleaseNote.jspa?projectId=10780&styleName=Html&version=13770 > > Tags: > https://svn.apache.org/repos/asf/maven/doxia/doxia/tags/doxia-1.0-alpha-10/ > > Staged at: > http://people.apache.org/~dennisl/staging-repository-doxia/ > > The vote will be open for 72 hours. > > > Here is my +1 > > -- > Dennis Lundberg >
Re: What should go into doxia 1.0-alpha-10?
Hi, 2007/10/21, Jason van Zyl <[EMAIL PROTECTED]>: > > On 20 Oct 07, at 3:36 PM 20 Oct 07, Dennis Lundberg wrote: > > > Hi > > > > As you might have seen from the commit messages, I have created > > branches in doxia and doxia-sitetools for future alpha releases. > > The branches were created from 1.0-alpha-9. On the branches the > > following stuff has been merged in from trunk: > > > > - DOXIA-156 > > - DOXIA-161 > > - The dependency cleanup in the poms > > > > Do we need anything else? > > > > Why don't you just release 1.0, or are there changes to the APIs you We have several major issues before releasing 1.0, like logging or xsd/dtd. FYI Lukas improved the sink api to support comments. Cheers, Vincent > want to make? I know that Vincent wanted to add some things but I > don't understand making branches from the alphas. > > > -- > > Dennis Lundberg > > Thanks, > > Jason > > -- > Jason van Zyl > Founder, Apache Maven > jason at sonatype dot com > -- > > > >
Re: What should go into doxia 1.0-alpha-10?
Hi, 2007/10/21, Wendy Smoak <[EMAIL PROTECTED]>: > On 10/20/07, Dennis Lundberg <[EMAIL PROTECTED]> wrote: > > > As you might have seen from the commit messages, I have created branches > > in doxia and doxia-sitetools for future alpha releases. The branches > > were created from 1.0-alpha-9. On the branches the following stuff has > > been merged in from trunk: > > I haven't been following Doxia closely, but I don't understand > branchign for 'future alpha releases'. Branching for 1.0 makes sense > to me if trunk is moving on to 1.1 or 2.0. What's happening? I guess that Dennis wants to release site and MPIR plugin in a near future. Alpha-9 is buggy to renderer beauty reports and beta-1 is not ready. So, branch seems a good compromise to release plugins quickly. Cheers, Vincent > > -- > Wendy >
Re: svn commit: r578418 - /maven/doxia/doxia-sitetools/trunk/pom.xml
2007/9/24, Dennis Lundberg <[EMAIL PROTECTED]>: > Vincent Siveton wrote: > > Hi Dennis, > > > > 2007/9/24, Dennis Lundberg <[EMAIL PROTECTED]>: > >> If we are going to get the two doxia projects properly separated any > >> time soon, we need to make sure that we only update the cross > >> dependencies when it is necessary, i.e. when code changes that > >> *requires* the newer version. > > > > Of course it is :) > > It is a requirement for the module-fo due to r577691. > > Well, It wasn't clear to me reading the commits. It might have been more > clear if the files had been committed at the same time, but then again > they are in different projects :-( Not as easy as I first thought... > > Hmm, perhaps a reference to the requiring commit? Done Vincent > > > > > Cheers, > > > > Vincent > > > >> [EMAIL PROTECTED] wrote: > >>> Author: vsiveton > >>> Date: Sat Sep 22 05:35:21 2007 > >>> New Revision: 578418 > >>> > >>> URL: http://svn.apache.org/viewvc?rev=578418&view=rev > >>> Log: > >>> o using the doxia:1.0-beta-1-SNAPSHOT instead of the release > > > > > -- > Dennis Lundberg >
Re: svn commit: r578418 - /maven/doxia/doxia-sitetools/trunk/pom.xml
Hi Dennis, 2007/9/24, Dennis Lundberg <[EMAIL PROTECTED]>: > If we are going to get the two doxia projects properly separated any > time soon, we need to make sure that we only update the cross > dependencies when it is necessary, i.e. when code changes that > *requires* the newer version. Of course it is :) It is a requirement for the module-fo due to r577691. Cheers, Vincent > [EMAIL PROTECTED] wrote: > > Author: vsiveton > > Date: Sat Sep 22 05:35:21 2007 > > New Revision: 578418 > > > > URL: http://svn.apache.org/viewvc?rev=578418&view=rev > > Log: > > o using the doxia:1.0-beta-1-SNAPSHOT instead of the release
Re: [vote] promote doxia-module-fo
+1 Also, we could update several interfaces in the doc-renderer to handle 2 pdfs implementations: itext and fo. Vincent 2007/9/20, Lukas Theussl <[EMAIL PROTECTED]>: > Hi, > > I'd like to promote the fo module from sandbox/doxia to > doxia/doxia/doxia-modules. It has some basic docs and tests, has 0 bugs > :) and it's needed by the (sandbox) pdf plugin (which can already be > used to test it, but beware, it's a bit rough still). > > A stage site is here: > > http://people.apache.org/~ltheussl/doxia-module-fo/ > > Vote is open for 72 hrs. > > +1 > > -Lukas >
Re: [VOTE] Release doxia-1.0-alpha-9 and doxia-sitetools-1.0-alpha-9
+1 Vincent 2007/9/10, Lukas Theussl <[EMAIL PROTECTED]>: > +1 > > -Lukas > > Dennis Lundberg wrote: > > Hi, > > > > Finally we have arrived at the vote to release doxia-1.0-alpha-9 and > > doxia-sitetools-1.0-alpha-9. Technically it is two releases, but they > > are done simultaneously this time. > > > > Release Notes showing 50 issues solved: > > http://jira.codehaus.org/secure/ReleaseNote.jspa?projectId=10780&styleName=Html&version=13220 > > > > > > Tags: > > https://svn.apache.org/repos/asf/maven/doxia/doxia/tags/doxia-1.0-alpha-9/ > > https://svn.apache.org/repos/asf/maven/doxia/doxia-sitetools/tags/doxia-sitetools-1.0-alpha-9/ > > > > > > Staged at: > > http://people.apache.org/~dennisl/staging-repository-doxia/ > > http://people.apache.org/~dennisl/staging-repository-doxia-sitetools/ > > > > The vote will be open for 72 hours. > > > > > > Here is my +1 > > >
Re: svn commit: r574034 - in /maven/doxia/doxia/trunk: ./ doxia-book/ doxia-core/ doxia-maven-plugin/ doxia-modules/ doxia-modules/doxia-module-apt/ doxia-modules/doxia-module-confluence/ doxia-module
Hi, Shouldn't be 1.0-beta-1 instead of 1.0-alpha-10-SNAPSHOT? Cheers, Vincent 2007/9/9, [EMAIL PROTECTED] <[EMAIL PROTECTED]>: > Author: dennisl > Date: Sun Sep 9 10:24:41 2007 > New Revision: 574034 > > URL: http://svn.apache.org/viewvc?rev=574034&view=rev > Log: > [maven-release-plugin] prepare for next development iteration > > Modified: > maven/doxia/doxia/trunk/doxia-book/pom.xml > maven/doxia/doxia/trunk/doxia-core/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-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/pom.xml > > Modified: maven/doxia/doxia/trunk/doxia-book/pom.xml > URL: > http://svn.apache.org/viewvc/maven/doxia/doxia/trunk/doxia-book/pom.xml?rev=574034&r1=574033&r2=574034&view=diff > == > --- maven/doxia/doxia/trunk/doxia-book/pom.xml (original) > +++ maven/doxia/doxia/trunk/doxia-book/pom.xml Sun Sep 9 10:24:41 2007 > @@ -24,7 +24,7 @@ > > org.apache.maven.doxia > doxia > -1.0-alpha-9 > +1.0-alpha-10-SNAPSHOT > >doxia-book >Doxia :: Book Component > > Modified: maven/doxia/doxia/trunk/doxia-core/pom.xml > URL: > http://svn.apache.org/viewvc/maven/doxia/doxia/trunk/doxia-core/pom.xml?rev=574034&r1=574033&r2=574034&view=diff > == > --- maven/doxia/doxia/trunk/doxia-core/pom.xml (original) > +++ maven/doxia/doxia/trunk/doxia-core/pom.xml Sun Sep 9 10:24:41 2007 > @@ -24,7 +24,7 @@ > > doxia > org.apache.maven.doxia > -1.0-alpha-9 > +1.0-alpha-10-SNAPSHOT > >doxia-core >Doxia :: Core > > 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=574034&r1=574033&r2=574034&view=diff > == > --- maven/doxia/doxia/trunk/doxia-maven-plugin/pom.xml (original) > +++ maven/doxia/doxia/trunk/doxia-maven-plugin/pom.xml Sun Sep 9 10:24:41 > 2007 > @@ -24,7 +24,7 @@ > > org.apache.maven.doxia > doxia > -1.0-alpha-9 > +1.0-alpha-10-SNAPSHOT > >doxia-maven-plugin >maven-plugin > > Modified: maven/doxia/doxia/trunk/doxia-modules/doxia-module-apt/pom.xml > URL: > http://svn.apache.org/viewvc/maven/doxia/doxia/trunk/doxia-modules/doxia-module-apt/pom.xml?rev=574034&r1=574033&r2=574034&view=diff > == > --- maven/doxia/doxia/trunk/doxia-modules/doxia-module-apt/pom.xml (original) > +++ maven/doxia/doxia/trunk/doxia-modules/doxia-module-apt/pom.xml Sun Sep 9 > 10:24:41 2007 > @@ -23,7 +23,7 @@ > > doxia-modules > org.apache.maven.doxia > -1.0-alpha-9 > +1.0-alpha-10-SNAPSHOT > >4.0.0 >doxia-module-apt > > Modified: > maven/doxia/doxia/trunk/doxia-modules/doxia-module-confluence/pom.xml > URL: > http://svn.apache.org/viewvc/maven/doxia/doxia/trunk/doxia-modules/doxia-module-confluence/pom.xml?rev=574034&r1=574033&r2=574034&view=diff > == > --- maven/doxia/doxia/trunk/doxia-modules/doxia-module-confluence/pom.xml > (original) > +++ maven/doxia/doxia/trunk/doxia-modules/doxia-module-confluence/pom.xml Sun > Sep 9 10:24:41 2007 > @@ -22,7 +22,7 @@ > > doxia-modules > org.apache.maven.doxia > -1.0-alpha-9 > +1.0-alpha-10-SNAPSHOT > >doxia-module-confluence >Doxia :: Confluence Module > > Modified: > maven/doxia/doxia/trunk/doxia-modules/doxia-module-docbook-simple/pom.xml > URL: > http://svn.apache.org/viewvc/maven/doxia/doxia/trunk/doxia-modules/doxia-module-docbook-simple/pom.xml?rev=574034&r1=574033&r2=574034&view=diff > == > --- maven/doxia/doxia/trunk/doxia-modules/doxia-module-docbook-simple/pom.xml > (original) > +++ maven/doxia/doxia/trunk/doxia-modules/doxia-module-docbook-simple/pom.xml > Sun Sep 9 10:24:41 2007 > @@ -22,7 +22,7 @@ > > doxia-modules >
Re: [vote] Promote doxia-book and doxia-maven-plugin
+1 john, trygve, vincent, lukas +0 brett, emmanuel, dennis -1 We have now a majority of +1, so I will promote them shortly. Thanks, Vincent 2007/9/7, Lukas Theussl <[EMAIL PROTECTED]>: > You've been a bit too quick for me... :) > > As mentioned, I have added javadocs, some basic site docs and some test > enhancements (though the maven-plugin still has no tests). Satisfied > with my work, I change my vote into a +1 :) > > I think we could promote it now, so we can release it with alpha-9, > which should be doxia's last alpha... > > Cheers, > -Lukas > > > Vincent Siveton wrote: > > +1 john, trygve, vincent > > +0 brett, emmanuel, dennis > > -1 Lukas (due to lack of docs) > > > > For the record, Lukas added lots of javadoc and documentation this week. > > > > We had not a lazy consensus so we will promote them after the Doxia release. > > > > Thanks, > > > > Vincent > > > > 2007/9/4, Vincent Siveton <[EMAIL PROTECTED]>: > > > >>Hi, > >> > >>Doxia is near to be released and I would like to promote doxia-book > >>and doxia-maven-plugin. They will be moved to doxia/doxia/trunk/ > >> > >>Please vote [+1,0,-1], vote is open for 72 hrs. > >> > >>Thanks, > >> > >>Vincent > >> >
Re: 1.0-alpha-9 release checklist
2007/9/7, Vincent Siveton <[EMAIL PROTECTED]>: > Hi, > > Mainly for Dennis who kindly suggests to do the release, here are some > doc issues: > > * publish the site decoration descriptor XSD and the associated doc. > Actually, it is decoration-1.0.0.xsd but I would prefer to name it > decoration-1.0.0-alpha-9.xsd. WDYT? > Moreover, where to publish it? in http://maven.apache.org/xsd/ ? or > http://maven.apache.org/doxia/xsd/ ? IMHO, the second one seems to be > the right place. > > * since fml descriptor is buggy (DOXIA-136), we shouldn't publish it. > > * we need (short) reference pages for FML and xdoc [1]. I didn't see that Lukas already did it. Thanks Lukas! > * We need to publish also the dev sites of doxia and doxia-sitetools. > I suggest to put them at http://maven.apache.org/doxia/ref/ like on > the maven site. WDYT? > > Cheers, > > Vincent > > [1] http://maven.apache.org/doxia/references/index.html > > 2007/9/4, Dennis Lundberg <[EMAIL PROTECTED]>: > > Hi all > > > > Just trying to sum up all remaining issues for the release. This is what > > I have left on my checklist: > > > > - Await [vote] to include doxia-book and doxia-maven-plugin. The vote > > ends on friday the 7th. > > > > If someone has something else please speak up now. > > > > Vincent, if the vote passes, when will you have time to promote the them > > from the sandbox? > > > > I can prepare the proposed release bits over the weekend if we are done > > by then. > > > > -- > > Dennis Lundberg > > >
Re: 1.0-alpha-9 release checklist
Hi, Mainly for Dennis who kindly suggests to do the release, here are some doc issues: * publish the site decoration descriptor XSD and the associated doc. Actually, it is decoration-1.0.0.xsd but I would prefer to name it decoration-1.0.0-alpha-9.xsd. WDYT? Moreover, where to publish it? in http://maven.apache.org/xsd/ ? or http://maven.apache.org/doxia/xsd/ ? IMHO, the second one seems to be the right place. * since fml descriptor is buggy (DOXIA-136), we shouldn't publish it. * we need (short) reference pages for FML and xdoc [1]. * We need to publish also the dev sites of doxia and doxia-sitetools. I suggest to put them at http://maven.apache.org/doxia/ref/ like on the maven site. WDYT? Cheers, Vincent [1] http://maven.apache.org/doxia/references/index.html 2007/9/4, Dennis Lundberg <[EMAIL PROTECTED]>: > Hi all > > Just trying to sum up all remaining issues for the release. This is what > I have left on my checklist: > > - Await [vote] to include doxia-book and doxia-maven-plugin. The vote > ends on friday the 7th. > > If someone has something else please speak up now. > > Vincent, if the vote passes, when will you have time to promote the them > from the sandbox? > > I can prepare the proposed release bits over the weekend if we are done > by then. > > -- > Dennis Lundberg >
Re: [vote] Promote doxia-book and doxia-maven-plugin
+1 john, trygve, vincent +0 brett, emmanuel, dennis -1 Lukas (due to lack of docs) For the record, Lukas added lots of javadoc and documentation this week. We had not a lazy consensus so we will promote them after the Doxia release. Thanks, Vincent 2007/9/4, Vincent Siveton <[EMAIL PROTECTED]>: > Hi, > > Doxia is near to be released and I would like to promote doxia-book > and doxia-maven-plugin. They will be moved to doxia/doxia/trunk/ > > Please vote [+1,0,-1], vote is open for 72 hrs. > > Thanks, > > Vincent >
Re: head element in site.xml?
Hi, 2007/9/7, Lukas Theussl <[EMAIL PROTECTED]>: > Hi, > > I just noticed that the site descriptors for the doxia (and maven) site > contain a element, apparently to include a javascript snippet in > all created site pages. I was not aware that this was possible, it's not > mentioned anywhere in the docs and google didn't help me either. Exactly. A small doc is in the description of the head field in decoration.mdo (doxia-decoration-model). > Problem is: 1st, it causes a bug that makes all maven generated pages > invalid XHTML [1], and 2nd I have already told a user that it's illegal > [also 1]. > > So question: should it be supported officially? If yes, whoever knows > more, please document! :) We need it, as brett said. For your first point, it due to a non-desired behaviour in p-u. Have a glance to the comment in org.codehaus.plexus.util.xml.Xpp3Dom#toString() I will fix the default-site.vm with a small workaround. Cheers, Vincent > > -Lukas > > [1] http://jira.codehaus.org/browse/MSITE-230 >
Re: The return of Velocity verbosity
I moved plexus-maven-plugin in doxia-decoration-model. I have no verbosity when I call mvn site or mvn install in doxia-site-renderer Cheers, Vincent 2007/9/6, Vincent Siveton <[EMAIL PROTECTED]>: > Hi Dennis, > > I could reproduce your pb with the following steps: > trunks\doxia\doxia-sitetools>m2 clean install > trunks\site>m2 site > => no verbosity > > trunks\doxia\doxia-sitetools>m2 install (without clean) > trunks\site>m2 site > => verbosity :( > > Same thing with: > trunks\doxia\doxia-sitetools\doxia-site-renderer>m2 clean install => > no verbosity > trunks\doxia\doxia-sitetools\doxia-site-renderer>m2 install => verbosity > > I built maven-site-plugin and maven-project-info-reports-plugin from > svn. Could you confirm it on your side? > > Moreover, PLXCOMP-80 doesn't seem to remove System.out.println(). I > guess it is due to maven-project-info-reports-plugin which uses > doxia-site-renderer:1.0-alpha-8 > > Cheers, > > Vincent > > 2007/8/31, Dennis Lundberg <[EMAIL PROTECTED]>: > > That's the one I tried as well. > > Seems I just need to go to sleep... > > > > Vincent Siveton wrote: > > > Hi Dennis, > > > > > > I tried what you did: delete my repo and rebuild all. > > > FYI I had no Velocity warns in doxia site/maven site but I got them > > > only if I did mvn site in doxia-site-renderer. It seems due to > > > surefire report. > > > Which projects have you tried? > > > > > > Cheers, > > > > > > Vincent > > > > > > 2007/8/31, Dennis Lundberg <[EMAIL PROTECTED]>: > > >> Hi > > >> > > >> Previously Vincent did something to remove all these WARNINGs from > > >> Velocity: > > >> > > >> [WARNING] Velocimacro : VM addition rejected : poweredByLogo : inline > > >> not allowed to replace existing VM > > >> [WARNING] Failed to add macro: #poweredByLogo( poweredBy ) : source = > > >> default-site.vm > > >> > > >> > > >> Yesterday I nuked doxia and the site-plugin from my local repo and built > > >> everything from scratch from svn, and now the warnings are back again. > > >> > > >> Is it just for me or is anybody else seeing this? > > >> > > >> -- > > >> Dennis Lundberg > > >> > > > > > > > > > -- > > Dennis Lundberg > > >
Re: The return of Velocity verbosity
Hi Dennis, I could reproduce your pb with the following steps: trunks\doxia\doxia-sitetools>m2 clean install trunks\site>m2 site => no verbosity trunks\doxia\doxia-sitetools>m2 install (without clean) trunks\site>m2 site => verbosity :( Same thing with: trunks\doxia\doxia-sitetools\doxia-site-renderer>m2 clean install => no verbosity trunks\doxia\doxia-sitetools\doxia-site-renderer>m2 install => verbosity I built maven-site-plugin and maven-project-info-reports-plugin from svn. Could you confirm it on your side? Moreover, PLXCOMP-80 doesn't seem to remove System.out.println(). I guess it is due to maven-project-info-reports-plugin which uses doxia-site-renderer:1.0-alpha-8 Cheers, Vincent 2007/8/31, Dennis Lundberg <[EMAIL PROTECTED]>: > That's the one I tried as well. > Seems I just need to go to sleep... > > Vincent Siveton wrote: > > Hi Dennis, > > > > I tried what you did: delete my repo and rebuild all. > > FYI I had no Velocity warns in doxia site/maven site but I got them > > only if I did mvn site in doxia-site-renderer. It seems due to > > surefire report. > > Which projects have you tried? > > > > Cheers, > > > > Vincent > > > > 2007/8/31, Dennis Lundberg <[EMAIL PROTECTED]>: > >> Hi > >> > >> Previously Vincent did something to remove all these WARNINGs from > >> Velocity: > >> > >> [WARNING] Velocimacro : VM addition rejected : poweredByLogo : inline > >> not allowed to replace existing VM > >> [WARNING] Failed to add macro: #poweredByLogo( poweredBy ) : source = > >> default-site.vm > >> > >> > >> Yesterday I nuked doxia and the site-plugin from my local repo and built > >> everything from scratch from svn, and now the warnings are back again. > >> > >> Is it just for me or is anybody else seeing this? > >> > >> -- > >> Dennis Lundberg > >> > > > > > -- > Dennis Lundberg >
Re: 1.0-alpha-9 release checklist
Hi Dennis, 2007/9/4, Dennis Lundberg <[EMAIL PROTECTED]>: > Hi all > > Just trying to sum up all remaining issues for the release. This is what > I have left on my checklist: > > - Await [vote] to include doxia-book and doxia-maven-plugin. The vote > ends on friday the 7th. > > If someone has something else please speak up now. Nothing to say more here, only everybody did a great job :) > Vincent, if the vote passes, when will you have time to promote the them > from the sandbox? Sounds like the promotion will be in the next release... Anyway, I could do it friday or this we. > > I can prepare the proposed release bits over the weekend if we are done > by then. Thanks! Cheers, Vincent > -- > Dennis Lundberg >
[vote] Promote doxia-book and doxia-maven-plugin
Hi, Doxia is near to be released and I would like to promote doxia-book and doxia-maven-plugin. They will be moved to doxia/doxia/trunk/ Please vote [+1,0,-1], vote is open for 72 hrs. Thanks, Vincent
Re: svn commit: r571452 - /maven/doxia/doxia/trunk/pom.xml
2007/8/31, Dennis Lundberg <[EMAIL PROTECTED]>: > Vincent Siveton wrote: > > Hi again, > > > > 2007/8/31, Dennis Lundberg <[EMAIL PROTECTED]>: > >> Is there a non-SNAPSHOT release of these taglets in sight soon? > > > > no idea so I will comment them. > > Good. Is their purpose to generate javadoc for the plexus specific > annotations? Yep. See PLXUTILS-41 > >> I was hoping to start to prepare for releasing doxia this weekend. > > > > Before that, I want to know what we decide about doxia-book: promotion > > or not? I think it is enough mature to be promoted as alpha. WDYT? > > It doesn't matter to me. I haven't used doxia-book myself, so I'm fine > with whatever its users say. Ok I will start a promote vote soon. Cheers, Vincent > > Cheers, > > > > Vincent > > > > [SNIP] > > > > -- > Dennis Lundberg >
Re: svn commit: r571452 - /maven/doxia/doxia/trunk/pom.xml
Hi again, 2007/8/31, Dennis Lundberg <[EMAIL PROTECTED]>: > Is there a non-SNAPSHOT release of these taglets in sight soon? no idea so I will comment them. > I was hoping to start to prepare for releasing doxia this weekend. Before that, I want to know what we decide about doxia-book: promotion or not? I think it is enough mature to be promoted as alpha. WDYT? Cheers, Vincent [SNIP]
Re: The return of Velocity verbosity
Hi Dennis, I tried what you did: delete my repo and rebuild all. FYI I had no Velocity warns in doxia site/maven site but I got them only if I did mvn site in doxia-site-renderer. It seems due to surefire report. Which projects have you tried? Cheers, Vincent 2007/8/31, Dennis Lundberg <[EMAIL PROTECTED]>: > Hi > > Previously Vincent did something to remove all these WARNINGs from Velocity: > > [WARNING] Velocimacro : VM addition rejected : poweredByLogo : inline > not allowed to replace existing VM > [WARNING] Failed to add macro: #poweredByLogo( poweredBy ) : source = > default-site.vm > > > Yesterday I nuked doxia and the site-plugin from my local repo and built > everything from scratch from svn, and now the warnings are back again. > > Is it just for me or is anybody else seeing this? > > -- > Dennis Lundberg >
Re: Releasing Doxia
2007/8/22, Dennis Lundberg <[EMAIL PROTECTED]>: > Jason van Zyl wrote: > > > > On 21 Aug 07, at 6:05 PM 21 Aug 07, Brett Porter wrote: > > > >> To date, I have always been in favour of one trunk, and one version. > >> > >> I understand the need for a clear separate and for Doxia to be useful > >> without the site tools, but I don't think separating the releases was > >> the right way to do it. > >> > > > > I use them completely separately. I barely touch the site generation > > stuff in my integration. The site tools are completely layered upon the > > core. If they are going to be clear and separate then they are released > > separately and have separate trunks. I think people who currently work > > on them have never used them for anything other then the site plugin. > > It's also not hard to create another JIRA project. > > > > I don't particularly care if people want to glob them back together but > > they are functionally separate. I can use the core without the site > > tools, one is clearly and extension of the other. In this alpha state > > changes in the site tools require changes in the core but that should > > not be the case for very long. > > I don't have a need to bring them back together again. They are separate > if you look at their respective use cases. What I would like to do, for > this release at least, is to align the version numbering. That way we > can release the code that we have now, and all the 49 closed issues in > JIRA with "fix for" 1.0-alpha-9 will be correct, version-wise. > > In short: we release doxia:doxia:1.0-alpha-9 and > doxia:doxia-sitetools:1.0-alpha-9, separately but simultaneously. > > After the releases we can create a new JIRA project for doxia-sitetools > and move sitetools issues there from DOXIA. And let each project have > their own versions. +1 for your proposal. Cheers, Vincent > > > >> - Brett > >> > >> On 22/08/2007, at 6:07 AM, Dennis Lundberg wrote: > >> > >>> Creating a separate thread for release questions... > >>> > >>> Do we have two releases in reality? On one hand we have doxia:doxia > >>> (currently slated for alpha-9) and on the other we have > >>> doxia:doxia-sitetools (currently slated for 1.0). Is everybody OK > >>> with those versions? > >>> > >>> I am not. Having two different versions for these two will totally > >>> mess up JIRA. Therefor I'd like to use 1.0-alpha-9 for both, this > >>> time. If we want separate releases for them in the future, then we > >>> need two separate projects for doxia and doxia-sitetools in JIRA. > >>> > >>> In order for the maven-site-plugin to be able to use the new > >>> doxia:doxia we need to release doxia:doxia-sitetools. > >>> > >>> Are there any other questions regarding the release? > >>> > >>> -- > >>> Dennis Lundberg > > > > Thanks, > > > > Jason > > > > -- > > Jason van Zyl > > Founder and PMC Chair, Apache Maven > > jason at sonatype dot com > > -- > > > > > > > > > > > -- > Dennis Lundberg >
Re: Releasing Doxia
2007/8/21, Dennis Lundberg <[EMAIL PROTECTED]>: > Creating a separate thread for release questions... > > Do we have two releases in reality? On one hand we have doxia:doxia > (currently slated for alpha-9) and on the other we have > doxia:doxia-sitetools (currently slated for 1.0). Is everybody OK with > those versions? > > I am not. Having two different versions for these two will totally mess > up JIRA. Therefor I'd like to use 1.0-alpha-9 for both, this time. If we > want separate releases for them in the future, then we need two separate > projects for doxia and doxia-sitetools in JIRA. > > In order for the maven-site-plugin to be able to use the new doxia:doxia > we need to release doxia:doxia-sitetools. > > Are there any other questions regarding the release? Another point: what do we do with doxia-book? Promote it? Cheers, Vincent > -- > Dennis Lundberg >
Re: Releasing Doxia
2007/8/21, Dennis Lundberg <[EMAIL PROTECTED]>: > Creating a separate thread for release questions... > > Do we have two releases in reality? On one hand we have doxia:doxia > (currently slated for alpha-9) and on the other we have > doxia:doxia-sitetools (currently slated for 1.0). Is everybody OK with > those versions? > > I am not. Having two different versions for these two will totally mess > up JIRA. Therefor I'd like to use 1.0-alpha-9 for both, this time. If we > want separate releases for them in the future, then we need two separate > projects for doxia and doxia-sitetools in JIRA. > > In order for the maven-site-plugin to be able to use the new doxia:doxia > we need to release doxia:doxia-sitetools. > > Are there any other questions regarding the release? I also add one thing about Markup interfaces. Is everyone agree with them? Jason? Cheers, Vincent > -- > Dennis Lundberg >
Re: Releasing Doxia
Hi, I agree with Dennis and Brett's comments. I also prefer one version of doxia, with a parent pom. But if we want to go with two projects, we need two jira projects. Cheers, Vincent 2007/8/21, Jason van Zyl <[EMAIL PROTECTED]>: > > On 21 Aug 07, at 6:05 PM 21 Aug 07, Brett Porter wrote: > > > To date, I have always been in favour of one trunk, and one version. > > > > I understand the need for a clear separate and for Doxia to be > > useful without the site tools, but I don't think separating the > > releases was the right way to do it. > > > > I use them completely separately. I barely touch the site generation > stuff in my integration. The site tools are completely layered upon > the core. If they are going to be clear and separate then they are > released separately and have separate trunks. I think people who > currently work on them have never used them for anything other then > the site plugin. It's also not hard to create another JIRA project. > > I don't particularly care if people want to glob them back together > but they are functionally separate. I can use the core without the > site tools, one is clearly and extension of the other. In this alpha > state changes in the site tools require changes in the core but that > should not be the case for very long. > > > - Brett > > > > On 22/08/2007, at 6:07 AM, Dennis Lundberg wrote: > > > >> Creating a separate thread for release questions... > >> > >> Do we have two releases in reality? On one hand we have > >> doxia:doxia (currently slated for alpha-9) and on the other we > >> have doxia:doxia-sitetools (currently slated for 1.0). Is > >> everybody OK with those versions? > >> > >> I am not. Having two different versions for these two will totally > >> mess up JIRA. Therefor I'd like to use 1.0-alpha-9 for both, this > >> time. If we want separate releases for them in the future, then we > >> need two separate projects for doxia and doxia-sitetools in JIRA. > >> > >> In order for the maven-site-plugin to be able to use the new > >> doxia:doxia we need to release doxia:doxia-sitetools. > >> > >> Are there any other questions regarding the release? > >> > >> -- > >> Dennis Lundberg > > Thanks, > > Jason > > -- > Jason van Zyl > Founder and PMC Chair, Apache Maven > jason at sonatype dot com > -- > > > >
Re: svn commit: r567233 - /maven/doxia/doxia/trunk/doxia-core/src/test/java/org/apache/maven/doxia/sink/SinkTestDocument.java
Thanks Lukas for the follow up.
Cheers,
Vincent
2007/8/18, Lukas Theussl <[EMAIL PROTECTED]>:
> Hi Vincent,
>
> I've been thinking about the tableCaption() call: this doesn't solve the
> problem. The pdf generation will still fail if a specific parser emits
> the tableCaption within the table. This is currently still the case in
> particular for the AptParser, whose behavior the SinkTestDocument is
> supposed to mimick. As long as we don't have a mechanism to enforce the
> order of parsing events (see DOXIA-132), any sink must be flexible
> enough to deal with any (reasonable) order of events. In the current
> case, the ItextSink has to cache the tableCaption while it is parsed and
> emit it only at the end of the table.
>
> Even though it doesn't really matter where the caption is emitted (as
> long as it's the same for all parsers), I think it's more logical within
> the table, since in general a tableCaption is part of a table (just not
> for itext, nor for fo btw).
>
> I'll test and provide a fix soon.
>
> -Lukas
>
>
> [EMAIL PROTECTED] wrote:
> > Author: vsiveton
> > Date: Fri Aug 17 22:10:45 2007
> > New Revision: 567233
> >
> > URL: http://svn.apache.org/viewvc?view=rev&rev=567233
> > Log:
> > o fixed tableCaption() call
> > o used the UTF-8 charset for the copyright (safety)
> >
> > Modified:
> >
> > maven/doxia/doxia/trunk/doxia-core/src/test/java/org/apache/maven/doxia/sink/SinkTestDocument.java
> >
> > Modified:
> > maven/doxia/doxia/trunk/doxia-core/src/test/java/org/apache/maven/doxia/sink/SinkTestDocument.java
> > URL:
> > http://svn.apache.org/viewvc/maven/doxia/doxia/trunk/doxia-core/src/test/java/org/apache/maven/doxia/sink/SinkTestDocument.java?view=diff&rev=567233&r1=567232&r2=567233
> > ==
> > ---
> > maven/doxia/doxia/trunk/doxia-core/src/test/java/org/apache/maven/doxia/sink/SinkTestDocument.java
> > (original)
> > +++
> > maven/doxia/doxia/trunk/doxia-core/src/test/java/org/apache/maven/doxia/sink/SinkTestDocument.java
> > Fri Aug 17 22:10:45 2007
> > @@ -19,6 +19,8 @@
> > * under the License.
> > */
> >
> > +import java.io.UnsupportedEncodingException;
> > +
> > import org.apache.maven.doxia.parser.Parser;
> > import org.apache.maven.doxia.sink.Sink;
> >
> > @@ -365,11 +367,11 @@
> >
> > sink.tableRows_();
> >
> > +sink.table_();
> > +
> > sink.tableCaption();
> > sink.text( "Table caption" );
> > sink.tableCaption_();
> > -
> > -sink.table_();
> > }
> >
> > /**
> > @@ -595,10 +597,17 @@
> > sink.paragraph_();
> >
> > sink.paragraph();
> > -String copyright = String.valueOf( '\u00a9' );
> > +String copyright;
> > +try
> > +{
> > +copyright = new String( String.valueOf( '\u00a9' ).getBytes(
> > "UTF-8" ) );
> > +}
> > +catch ( UnsupportedEncodingException e )
> > +{
> > +throw new IllegalArgumentException( e.getMessage() );
> > +}
> > sink.text( "Copyright symbol: " + copyright + ", "
> > + copyright + ", " + copyright + "." );
> > sink.paragraph_();
> > }
> > -
> > }
> >
>
Re: Doxia core clean up
Jason, Any comments? Cheers, Vincent 2007/8/3, Vincent Siveton <[EMAIL PROTECTED]>: > Hi, > > 2007/8/3, Jason van Zyl <[EMAIL PROTECTED]>: > > +1 > > > > What about the other changes you were going to make? Are we going to > > leave the names as "Parser" and not "Markup". > > If I understand you as well, you recommend to put all constants > defined in Markup interfaces in AbstractParser, AbstractTextParser and > AbstractXmlParser and other XXXParser. > > My only point is that XXXSink should uses XXXParser.CONSTANTS inside. > Thoughts? > > Cheers, > > Vincent > > > And did you get anywhere using the single Plexus JAR? > > > > On 3 Aug 07, at 8:29 AM 3 Aug 07, Vincent Siveton wrote: > > > > > Hi, > > > > > > Several utility classes in Doxia are few used or unused. > > > org.apache.maven.doxia.util.StringUtil (used only in > > > XmlWriterXdocSink, which is not maintained) > > > org.apache.maven.doxia.util.FileUtil (used only in DocBookSink) > > > org.apache.maven.doxia.util.WrappedException (unused) > > > > > > I propose to remove them and to use Plexus-utils instead of. It would > > > be a part of DOXIA-56. > > > > > > Also, I propose to rename the following package > > > org.apache.maven.doxia.site.module.manager > > > to > > > org.apache.maven.doxia.module.manager > > > > > > WDYT? > > > > > > Vincent > > > > Thanks, > > > > Jason > > > > -- > > Jason van Zyl > > Founder and PMC Chair, Apache Maven > > jason at sonatype dot com > > -- > > > > > > > > >
Re: Solving links and anchors
2007/8/11, Dennis Lundberg <[EMAIL PROTECTED]>: > Hi > > As you probably saw on [EMAIL PROTECTED] we had some problems yesterday with > links being rendered in the wrong way by doxia. I have made a temporary > fix for this, but I feel that we need to do more to get a stable solution. > > The issues which are related to these problems are > - http://jira.codehaus.org/browse/DOXIA-47 > - http://jira.codehaus.org/browse/DOXIA-131 > > My temporary fix reverses the logic. Instead of trying to see if a text > is an "external link", I try to determine if a text is *not* an > "internal link". With a few minor adjustments (see my comment on > DOXIA-131) I think that this would be a more stable solution. > > What do you think? Sounds goods. IMHO, the ideal solution will be to not change the util encodeId() (which respects HTML spec) to disallow dot. Cheers, Vincent > -- > Dennis Lundberg >
Re: svn commit: r564180 - in /maven/doxia: doxia-sitetools/trunk/doxia-site-renderer/src/main/java/org/apache/maven/doxia/siterenderer/ doxia/trunk/doxia-core/src/main/java/org/apache/maven/doxia/ dox
Hi Dennis,
2007/8/9, Dennis Lundberg <[EMAIL PROTECTED]>:
> Shouldn't FmlParser extend AbstractXmlParser?
Yes! It is on my todo list ;)
Cheers,
Vincent
> [EMAIL PROTECTED] wrote:
> > Author: vsiveton
> > Date: Thu Aug 9 05:15:44 2007
> > New Revision: 564180
> >
> > URL: http://svn.apache.org/viewvc?view=rev&rev=564180
> > Log:
> > DOXIA-133: default XML encoding (UTF-8) or XML encoding set in XML files is
> > ignored: inputEncoding is used instead
> > Submitted by: Herve Boutemy
> > Reviewed by: Vincent Siveton
> >
> > o applied with modifications discussed on this issue
> > o added/updated javadoc
> >
> > Modified:
> >
> > maven/doxia/doxia-sitetools/trunk/doxia-site-renderer/src/main/java/org/apache/maven/doxia/siterenderer/DefaultSiteRenderer.java
> >
> > maven/doxia/doxia/trunk/doxia-core/src/main/java/org/apache/maven/doxia/DefaultDoxia.java
> >
> > maven/doxia/doxia/trunk/doxia-core/src/main/java/org/apache/maven/doxia/Doxia.java
> >
> > maven/doxia/doxia/trunk/doxia-core/src/main/java/org/apache/maven/doxia/parser/AbstractParser.java
> >
> > maven/doxia/doxia/trunk/doxia-core/src/main/java/org/apache/maven/doxia/parser/AbstractTextParser.java
> >
> > 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/parser/Parser.java
> >
> > maven/doxia/doxia/trunk/doxia-modules/doxia-module-confluence/src/main/java/org/apache/maven/doxia/module/confluence/ConfluenceParser.java
> >
> > maven/doxia/doxia/trunk/doxia-modules/doxia-module-fml/src/main/java/org/apache/maven/doxia/module/fml/FmlParser.java
> >
> > maven/doxia/doxia/trunk/doxia-modules/doxia-module-twiki/src/main/java/org/apache/maven/doxia/module/twiki/TWikiParser.java
> >
> > Modified:
> > maven/doxia/doxia-sitetools/trunk/doxia-site-renderer/src/main/java/org/apache/maven/doxia/siterenderer/DefaultSiteRenderer.java
> > URL:
> > http://svn.apache.org/viewvc/maven/doxia/doxia-sitetools/trunk/doxia-site-renderer/src/main/java/org/apache/maven/doxia/siterenderer/DefaultSiteRenderer.java?view=diff&rev=564180&r1=564179&r2=564180
> > ==
> > ---
> > maven/doxia/doxia-sitetools/trunk/doxia-site-renderer/src/main/java/org/apache/maven/doxia/siterenderer/DefaultSiteRenderer.java
> > (original)
> > +++
> > maven/doxia/doxia-sitetools/trunk/doxia-site-renderer/src/main/java/org/apache/maven/doxia/siterenderer/DefaultSiteRenderer.java
> > Thu Aug 9 05:15:44 2007
> > @@ -22,6 +22,7 @@
> > import org.apache.maven.doxia.Doxia;
> > import
> > org.apache.maven.doxia.module.xhtml.decoration.render.RenderingContext;
> > import org.apache.maven.doxia.parser.ParseException;
> > +import org.apache.maven.doxia.parser.Parser;
> > import org.apache.maven.doxia.parser.manager.ParserNotFoundException;
> > import org.apache.maven.doxia.site.decoration.DecorationModel;
> > import org.apache.maven.doxia.module.site.SiteModule;
> > @@ -53,10 +54,9 @@
> > * @since 1.0
> > * @plexus.component role-hint="default"
> > */
> > -public class
> > -DefaultSiteRenderer
> > -extends AbstractLogEnabled
> > -implements Renderer
> > +public class DefaultSiteRenderer
> > +extends AbstractLogEnabled
> > +implements Renderer
> > {
> > //
> > --
> > // Requirements
> > @@ -92,6 +92,7 @@
> > // Renderer implementation
> > //
> > --
> >
> > +/** [EMAIL PROTECTED] */
> > public void render( Collection documents,
> > SiteRenderingContext siteRenderingContext,
> > File outputDirectory )
> > @@ -106,6 +107,7 @@
> > }
> > }
> >
> > +/** [EMAIL PROTECTED] */
> > public Map locateDocumentFiles( SiteRenderingContext
> > siteRenderingContext )
> > throws IOException, RendererException
> > {
> > @@ -278,6 +280,7 @@
> > }
> > }
> >
> > +/** [EMAIL PROTECTED] */
> > public void renderDocument( Writer writer,
> > RenderingContext renderingContext,
> >
Re: Doxia core clean up
Hi, 2007/8/3, Dennis Lundberg <[EMAIL PROTECTED]>: > Vincent Siveton wrote: > > Hi, > > > > Several utility classes in Doxia are few used or unused. > > org.apache.maven.doxia.util.StringUtil (used only in > > XmlWriterXdocSink, which is not maintained) > > org.apache.maven.doxia.util.FileUtil (used only in DocBookSink) > > org.apache.maven.doxia.util.WrappedException (unused) > > > > I propose to remove them and to use Plexus-utils instead of. It would > > be a part of DOXIA-56. > > Sounds good to me. > > > Also, I propose to rename the following package > > org.apache.maven.doxia.site.module.manager > > to > > org.apache.maven.doxia.module.manager > > What would be the benefit of that move? The JavaDoc says that it is a > hook for doxia site tools, so the package "site" makes sense to me. > Perhaps change it to org.apache.maven.doxia.sitetools.module.manager > instead? Typo, I would say o.a.m.doxia.module.SITE.manager. As you said, site makes sense. By convention, all modules use o.a.m.d.module.XXX as package name, and several of them implements SiteModule. IMHO the site package should be in the module package because it is module specific. Thoughts? Vincent > > WDYT? > > > > Vincent > > > -- > Dennis Lundberg >
Re: Doxia core clean up
Hi, 2007/8/3, Jason van Zyl <[EMAIL PROTECTED]>: > +1 > > What about the other changes you were going to make? Are we going to > leave the names as "Parser" and not "Markup". If I understand you as well, you recommend to put all constants defined in Markup interfaces in AbstractParser, AbstractTextParser and AbstractXmlParser and other XXXParser. My only point is that XXXSink should uses XXXParser.CONSTANTS inside. Thoughts? Cheers, Vincent > And did you get anywhere using the single Plexus JAR? > > On 3 Aug 07, at 8:29 AM 3 Aug 07, Vincent Siveton wrote: > > > Hi, > > > > Several utility classes in Doxia are few used or unused. > > org.apache.maven.doxia.util.StringUtil (used only in > > XmlWriterXdocSink, which is not maintained) > > org.apache.maven.doxia.util.FileUtil (used only in DocBookSink) > > org.apache.maven.doxia.util.WrappedException (unused) > > > > I propose to remove them and to use Plexus-utils instead of. It would > > be a part of DOXIA-56. > > > > Also, I propose to rename the following package > > org.apache.maven.doxia.site.module.manager > > to > > org.apache.maven.doxia.module.manager > > > > WDYT? > > > > Vincent > > Thanks, > > Jason > > -- > Jason van Zyl > Founder and PMC Chair, Apache Maven > jason at sonatype dot com > -- > > > >
Re: svn commit: r561199 - /maven/doxia/doxia-sitetools/trunk/pom.xml
Hi Jason, I got now this following exception in doxia-site-renderer project. Cheers, Vincent testRender(org.apache.maven.doxia.siterenderer.DefaultSiteRendererTest) Time elapsed: 0.171 sec <<< ERROR! java.lang.NoSuchMethodError: org.codehaus.plexus.component.repository.ComponentDescriptor.setSource(Ljava/lang/String;)V at org.codehaus.plexus.component.discovery.DefaultComponentDiscoverer.createComponentDescriptors(DefaultComponentDiscoverer.java:68) at org.codehaus.plexus.component.discovery.AbstractComponentDiscoverer.findComponents(AbstractComponentDiscoverer.java:107) at org.codehaus.plexus.container.initialization.ComponentDiscoveryPhase.discoverComponents(ComponentDiscoveryPhase.java:83) at org.codehaus.plexus.container.initialization.ComponentDiscoveryPhase.execute(ComponentDiscoveryPhase.java:45) at org.codehaus.plexus.DefaultPlexusContainer.initializePhases(DefaultPlexusContainer.java:900) at org.codehaus.plexus.DefaultPlexusContainer.initialize(DefaultPlexusContainer.java:844) at org.codehaus.plexus.DefaultPlexusContainer.construct(DefaultPlexusContainer.java:820) at org.codehaus.plexus.DefaultPlexusContainer.(DefaultPlexusContainer.java:204) at org.codehaus.plexus.PlexusTestCase.setUp(PlexusTestCase.java:94) at org.apache.maven.doxia.siterenderer.DefaultSiteRendererTest.setUp(DefaultSiteRendererTest.java:66) 2007/7/30, [EMAIL PROTECTED] <[EMAIL PROTECTED]>: > Author: jvanzyl > Date: Mon Jul 30 17:29:39 2007 > New Revision: 561199 > > URL: http://svn.apache.org/viewvc?view=rev&rev=561199 > Log: > o updating to release of plexus-utils, plexus (the single jar) > [SNIP]
Re: Design thoughts
Hi, 2007/7/30, Dennis Lundberg <[EMAIL PROTECTED]>: > Brett Porter wrote: > > I haven't been keeping track unfortunately, so maybe I'm missing a piece > > of the puzzle. > > > > How does a 'Markup' relate to a 'Parser', which is what I thought the > > terminology was for this? > > The Markup classes contain utility constants/methods for handling > markup. Constants like these would go into XmlMarkup >String START_MARKUP = "<"; >String END_MARKUP = ">"; > > General stuff that used only in parser and module sink. > > > The only caution I urge is that anything that changes doxia-sink-api > > might limit the ability to use it across different versions of Maven. > > Other than that, I think it'd be good to decide the target public API, > > write it up and then refactor towards it... it might be easier to > > understand holistically. > > Yup, we need to be careful not to move too much to the API, but I think > Vincent is only talking about the really general stuff here. Exactly. Cheers, Vincent > > Thanks guys! > > > > Cheers, > > Brett > > > > On 30/07/2007, at 7:06 AM, Vincent Siveton wrote: > > > >> Hi, > >> > >> As you know, Doxia modules need to be more consistents. Dennis pointed > >> the EOL problem today. > >> > >> I recently added several markup interfaces. I see 2 types of markup > >> languages handles by Doxia: text (like APT) and xml (like xdoc). I > >> propose to encapsulate these things with the following interfaces: > >> Markup (core) > >> |_ TextMarkup (core) > >> |_ AptMarkup (module) > >> |_ XmlMarkup (core) > >> |_ XdocMarkup (module) > >> > >> In a second step, I propose to create abstract TextSink and XmlSink to > >> encapsulate writer. With this, we will remove inconsistencies in the > >> output like LineBreaker (docbook, xdoc) vs PrintWriter (xhtml). > >> > >> Thoughts? > >> > >> Vincent > > > -- > Dennis Lundberg >
Design thoughts
Hi, As you know, Doxia modules need to be more consistents. Dennis pointed the EOL problem today. I recently added several markup interfaces. I see 2 types of markup languages handles by Doxia: text (like APT) and xml (like xdoc). I propose to encapsulate these things with the following interfaces: Markup (core) |_ TextMarkup (core) |_ AptMarkup (module) |_ XmlMarkup (core) |_ XdocMarkup (module) In a second step, I propose to create abstract TextSink and XmlSink to encapsulate writer. With this, we will remove inconsistencies in the output like LineBreaker (docbook, xdoc) vs PrintWriter (xhtml). Thoughts? Vincent
Re: svn commit: r560737 [1/2] - in /maven/doxia/doxia/trunk/doxia-modules: doxia-module-xdoc/src/main/java/org/apache/maven/doxia/module/xdoc/ doxia-module-xdoc/src/test/java/org/apache/maven/doxia/mo
Hi Dennis, 2007/7/29, Dennis Lundberg <[EMAIL PROTECTED]>: > A couple of thoughts on the changes to xdoc, and in some cases also xhtml: > > - From what I can tell the output of EOL chars in XdocSink and XhtmlSink > has changed with this commit. Was that intended? After this commit only > "simple" tags and end tags get an EOL. Actually intended but need to be improved. See below. > - Changing the tests to ignore EOL chars might be dangerous if we care > about where the EOLs are put. A lot of modules use EOL or \n inside. We need to review them to be more consistent and use only system EOL. About testing, the new AbstractSinkTest class has this convenience method but like you said, we need to take care about EOL in the future. > - I think we should try to pretty print the sink output to the best of > our capabilities. Totally agree with you. I think we need to use the PrettyPrintXMLWriter class from Plexus utils (or other) to correctly indent the output.I didn't want to change it with this commit, to be sure to not have side effects. Thoughts? Thanks, Vincent > > [EMAIL PROTECTED] wrote: > > Author: vsiveton > > Date: Sun Jul 29 08:40:13 2007 > > New Revision: 560737 > > > > URL: http://svn.apache.org/viewvc?view=rev&rev=560737 > > Log: > > o Put all hardcoded markups in an interface > > o using javax.swing.text.html.HTML.Tag and > > javax.swing.text.html.HTML.Attribute instead of harcoded tags/attributes > > o updated javadocs > > [SNIP]
Re: svn commit: r560370 - /maven/doxia/doxia/trunk/doxia-modules/doxia-module-apt/src/main/java/org/apache/maven/doxia/module/apt/AptParser.java
Nice catch Dennis!
Thanks
Vincent
2007/7/27, [EMAIL PROTECTED] <[EMAIL PROTECTED]>:
> Author: dennisl
> Date: Fri Jul 27 13:15:56 2007
> New Revision: 560370
>
> URL: http://svn.apache.org/viewvc?view=rev&rev=560370
> Log:
> o Use more high-level markup constants.
>
> Modified:
>
> maven/doxia/doxia/trunk/doxia-modules/doxia-module-apt/src/main/java/org/apache/maven/doxia/module/apt/AptParser.java
>
> Modified:
> maven/doxia/doxia/trunk/doxia-modules/doxia-module-apt/src/main/java/org/apache/maven/doxia/module/apt/AptParser.java
> URL:
> http://svn.apache.org/viewvc/maven/doxia/doxia/trunk/doxia-modules/doxia-module-apt/src/main/java/org/apache/maven/doxia/module/apt/AptParser.java?view=diff&rev=560370&r1=560369&r2=560370
> ==
> ---
> maven/doxia/doxia/trunk/doxia-modules/doxia-module-apt/src/main/java/org/apache/maven/doxia/module/apt/AptParser.java
> (original)
> +++
> maven/doxia/doxia/trunk/doxia-modules/doxia-module-apt/src/main/java/org/apache/maven/doxia/module/apt/AptParser.java
> Fri Jul 27 13:15:56 2007
> @@ -1144,23 +1144,23 @@
>
> if ( monospaced )
> {
> -throw new AptParseException( "missing '" + GREATER_THAN_MARKUP +
> GREATER_THAN_MARKUP + GREATER_THAN_MARKUP + "'" );
> +throw new AptParseException( "missing '" + MONOSPACED_END + "'"
> );
> }
> if ( bold )
> {
> -throw new AptParseException( "missing '" + GREATER_THAN_MARKUP +
> GREATER_THAN_MARKUP + "'" );
> +throw new AptParseException( "missing '" + BOLD_END + "'" );
> }
> if ( italic )
> {
> -throw new AptParseException( "missing '" + GREATER_THAN_MARKUP +
> "'" );
> +throw new AptParseException( "missing '" + ITALIC_END + "'" );
> }
> if ( link )
> {
> -throw new AptParseException( "missing '" +
> RIGHT_CURLY_BRACKET_MARKUP + RIGHT_CURLY_BRACKET_MARKUP + "'" );
> +throw new AptParseException( "missing '" + LINK_END + "'" );
> }
> if ( anchor )
> {
> -throw new AptParseException( "missing '" +
> RIGHT_CURLY_BRACKET_MARKUP + "'" );
> +throw new AptParseException( "missing '" + ANCHOR_END + "'" );
> }
>
> flushTraversed( buffer, sink );
>
>
>
Re: APTEditor + Doxia
Hi Math, 2007/7/26, Mathieu Avoine <[EMAIL PROTECTED]>: > Thanks to all of you for the answers. Now more questions! ;) > > I've been reading through some code in Doxia lately to understand how HTML > site generation is done, however foreign code is always hard to read and I > was hoping someone would digest it a little bit for me (like I always say, > saving time requires to be lazy :P). > > What I need to know is if it's still possible to call a "Driver" to have the > contents generated in a given place? Let me explain. If I try to make a > parallel with what I have done with Pixware's parser to achieve my goal, I > only extended the class fr.pixware.apt.convert.Driver ( > apteditor.drivers.APTEditorDriver) and called the appropriate method. A bit I was not aware about this but it sounds very useful for a book playing > of code explains always better, so take a look at the following link, on > line 200, this is where all the magic happens in APT Editor: > > http://apteditor.cvs.sourceforge.net/apteditor/APTEditor/src/apteditor/editors/MultiPageEditor.java?revision=1.3&view=markup > > I wish I could do the same with Doxia and let it do the dirty work: finding > the css, figures and other, execute macros, etc, so I can concentrate on > adding nice features to the UI of APT Editor. Actually, no style exists in the AptSink. It is the renderer that pushes style. Cheers, Vincent > If anyone knows the answer let me know. In the mean time, I will have a look > at Trygve's code (thanks for the links by the way) to see how he's done it. > Trygve, if you want to contribute some code (in one way or the other) let me > know, I'm sure we can help each other, we seem to have the same goal! > > Thanks, > Math > > On 7/26/07, Trygve Laugstøl <[EMAIL PROTECTED]> wrote: > > > > Lukas Theussl wrote: > > > > > > > > > Vincent Siveton wrote: > > >> Hi Math! > > >> > > >> I recently add a pointer on your tool, so I am aware about your tool. > > >> > > >> 2007/7/25, Mathieu Avoine <[EMAIL PROTECTED]>: > > >> > > >>> Hi everyone, > > >>> > > >>> I'm developing an Eclipse plugin called APT Editor which, like its > > name > > >>> suggests, is an editor/viewer for APT files. Basically, it offers an > > >>> "edit" > > >>> pane to update the contents of the document, and a "view" pane to > > >>> preview > > >>> the formatted version of the document in HTML. > > >> > > >> > > >> It is a great tool for dev. We could have a live renderer. > > >> > > >>> The project page is http://apteditor.sf.net > > >>> > > >>> Some people asked me if it was possible to offer the possibility to > > use > > >>> Maven Doxia's parser/renderer instead of the original code from > > pixware. > > >>> Sounds like a good idea to me, however not being a Doxia developer > > >>> (not even > > >>> a Maven user to be honest) I wouldn't know where to look. > > >>> > > >>> I'd appreciate if someone could give me some pointers as to how I > > could > > >>> integrate Doxia with the APT Editor. To summarize, I'd need to know > > what > > >>> libraries to load and what methods to invoke to generate an HTML > > >>> version of > > >>> a given APT file into a chosen directory. > > >> > > >> > > >> First, I suggest you to do a smart co of the doxia site > > >> http://svn.apache.org/repos/asf/maven/doxia/site > > >> We added lot of documentations these days. > > > > > > Would be nice if we could publish the new docs already (for people who > > > are not familiar with maven to build the site themselves), at least > > > somewhere on a stage site, or even live, since the main site is just > > > user docs. WDYT? > > > > > >> > > >> And another co from the full doxia project > > >> > > >> The apt parser is here: > > >> > > https://svn.apache.org/repos/asf/maven/doxia/doxia/trunk/doxia-modules/doxia-module-apt > > > > > > > > > Another link that might be useful is Trygve's doxia-editor: > > > > > > https://svn.apache.org/repos/asf/maven/sandbox/trunk/doxia/doxia-editor/ > > > > > > It's still in the sandbox and not very much advanced (it currently only > > > does apt -> xdoc conversion, and that not correctly... :( ), but from > > > what I understand, it's supposed to be a stand-alone editor/renderer for > > > any doxia-supported format. > > > > The biggest problem with creating an editor for Doxia is that Doxia has > > no object model, it is all about events which is a major PITA. The only > > thing that is usable from the editor I made is the stuff that builds the > > objects. > > > > -- > > Trygve > > >
Re: svn commit: r558543 - /maven/doxia/doxia-sitetools/trunk/doxia-site-renderer/src/test/java/org/apache/maven/doxia/siterenderer/DefaultSiteRendererTest.java
Hi again, 2007/7/22, Lukas Theussl <[EMAIL PROTECTED]>: I have reverted part of my commit, tests are passing now again, however, Thanks! I had to comment out a few asserts in DefaultSiteRendererTest.java. I am not quite sure how these tests could ever have passed: eg for the following html segment Item 1. Item 11. Item 12. Item 13. Item 14. IIRC, this html snippet was generated like this in the past. Now, it is without well done indentation on my side, ie Item 1. Item 11.Item 12. Item 13. Item 14. the expression ul.getFirstChild().asText() returns "Item 1. Item 11. Item 12. Item 13. Item 14." , which is correct if I understand the htmlunit javadocs correctly. But the test asserted an empty string. Am I still missing something? Agree but if you confirm the indentation pb on your side, I think that httpunit doesnt handle the carriage return well. Cheers, Vincent Cheers, -Lukas [EMAIL PROTECTED] wrote: > Author: ltheussl > Date: Sun Jul 22 13:38:24 2007 > New Revision: 558543 > > URL: http://svn.apache.org/viewvc?view=rev&rev=558543 > Log: > Comment out failing tests, - need to clarify. > > Modified: > maven/doxia/doxia-sitetools/trunk/doxia-site-renderer/src/test/java/org/apache/maven/doxia/siterenderer/DefaultSiteRendererTest.java > > Modified: maven/doxia/doxia-sitetools/trunk/doxia-site-renderer/src/test/java/org/apache/maven/doxia/siterenderer/DefaultSiteRendererTest.java > URL: http://svn.apache.org/viewvc/maven/doxia/doxia-sitetools/trunk/doxia-site-renderer/src/test/java/org/apache/maven/doxia/siterenderer/DefaultSiteRendererTest.java?view=diff&rev=558543&r1=558542&r2=558543 > == > --- maven/doxia/doxia-sitetools/trunk/doxia-site-renderer/src/test/java/org/apache/maven/doxia/siterenderer/DefaultSiteRendererTest.java (original) > +++ maven/doxia/doxia-sitetools/trunk/doxia-site-renderer/src/test/java/org/apache/maven/doxia/siterenderer/DefaultSiteRendererTest.java Sun Jul 22 13:38:24 2007 > @@ -176,7 +176,8 @@ > > HtmlUnorderedList ul = (HtmlUnorderedList) elementIterator.next(); > assertNotNull( ul ); > -assertEquals( ul.getFirstChild().asText(), "" ); > +// TODO: how can this be? > +//assertEquals( ul.getFirstChild().asText(), "" ); >
Re: svn commit: r558696 - in /maven/doxia/site: ./ src/site/ src/site/apt/ src/site/apt/developers/ src/site/apt/macros/ src/site/apt/modules/ src/site/apt/references/ src/site/fml/ src/site/resources
Hi Lukas, 2007/7/24, Lukas Theussl <[EMAIL PROTECTED]>: Yeah! Now let anybody say that we can't write docs! (well, why couldn't you do that before I started getting familiar with doxia?... ;) ) Two comments: - I never quite understood the (apparently general) maven philosophy of separating the site from the rest of the project. I would at least like to have a link to the project pages, where you have all the javadocs, code reports etc. Could I suggest to leave the current doxia-site as a user documentation site, and use the project sites for developer docs? WDYT? Sounds good for me: doxia-site => user documentation core/modules/tools site => dev documentation - in the "Using A Doxia Module" example, you make reference to plexus, I think this is not necessary and might be confusing. Even though doxia uses plexus, it is not necessary to be familiar with it in order to use doxia. The simplest way to convert eg apt to xdoc with doxia is: FileReader source = new FileReader( new File( "test.apt" ) ); XdocSink sink = new XdocSink( new FileWriter( new File( "test.xml" ) ) ); AptParser parser = new AptParser(); parser.parse( source, sink ); We need to lookup the parser with Plexus. If not, the macromanager in the AbstractParser is not instantiated (and a NPE is throw...). Cheers, Vincent Thanks for all that anyway! -Lukas Dennis Lundberg wrote: > This is excellent stuff Vincent! > > I'm only missing one thing, that have been puzzling me since I got > involved with Doxia: > > What is a Sink? >
Re: svn commit: r557051 - in /maven/doxia/doxia/trunk/doxia-modules/doxia-module-xdoc/src/main/java/org/apache/maven/doxia/module/xdoc: XdocParser.java XdocSink.java
Hi Lukas, Could you correct it or revert it? Thanks, Vincent 2007/7/19, Dennis Lundberg <[EMAIL PROTECTED]>: I've gotten 3 messages informing of failures in org.apache.maven.doxia.siterenderer.DefaultSiteRendererTest but when I look in the mail-archive I see 5 messages. Subject: [continuum] BUILD FAILURE: Doxia Site Renderer Component I have missed several (Maven-mailing-list) messages lately, but I thought it was something wrong with my mail-provider, since the messages are available in the archives. Lukas Theussl wrote: > I know, I am subscribed, did I miss it? > > -Lukas > > > Dennis Lundberg wrote: >> Lukas Theussl wrote: >> >>> It seems like I did break something after all: the site-renderer test >>> now fails (btw, I only noticed it by accident on the continuum page, >>> there was no notification sent?). >> >> >> The notifications are sent to [EMAIL PROTECTED] >> >> >> >> -- Dennis Lundberg
Re: svn commit: r555559 - /maven/doxia/doxia/trunk/doxia-modules/doxia-module-apt/src/main/java/org/apache/maven/doxia/module/apt/AptSink.java
2007/7/12, Lukas Theussl <[EMAIL PROTECTED]>: well, ^L (Control-L) is the symbol for a form feed character, which is the only sequence that aptconvert recognizes as a page break (not "^L" as a string, nor "\f"), so I think the docs are correct. Ok I'd prefer to leave the page at http://maven.apache.org/guides/mini/guide-apt-format.html, just remove everything after "Document structure" and add a link instead to the doxia site, after the short introductory paragraph that explains what apt is. Agree but a lot of license header in APT files use the following link http://maven.apache.org/guides/mini/guide-apt-format.html So I think a redirection is better. Cheers, Vincent [SNIP]
Re: svn commit: r555559 - /maven/doxia/doxia/trunk/doxia-modules/doxia-module-apt/src/main/java/org/apache/maven/doxia/module/apt/AptSink.java
Hi Lukas,
We need also to update the APT format docu for \f in Doxia site.
Moreover, we have 2 docs which describe the apt format: one in maven
and one in doxia. WDYT to remove the doc from the maven site and to
add an Apache rule to go to the doxia one?
Cheers,
Vincent
2007/7/12, [EMAIL PROTECTED] <[EMAIL PROTECTED]>:
Author: ltheussl
Date: Thu Jul 12 03:03:51 2007
New Revision: 59
URL: http://svn.apache.org/viewvc?view=rev&rev=59
Log:
Use \f for pagebreak
Modified:
maven/doxia/doxia/trunk/doxia-modules/doxia-module-apt/src/main/java/org/apache/maven/doxia/module/apt/AptSink.java
Modified:
maven/doxia/doxia/trunk/doxia-modules/doxia-module-apt/src/main/java/org/apache/maven/doxia/module/apt/AptSink.java
URL:
http://svn.apache.org/viewvc/maven/doxia/doxia/trunk/doxia-modules/doxia-module-apt/src/main/java/org/apache/maven/doxia/module/apt/AptSink.java?view=diff&rev=59&r1=58&r2=59
==
---
maven/doxia/doxia/trunk/doxia-modules/doxia-module-apt/src/main/java/org/apache/maven/doxia/module/apt/AptSink.java
(original)
+++
maven/doxia/doxia/trunk/doxia-modules/doxia-module-apt/src/main/java/org/apache/maven/doxia/module/apt/AptSink.java
Thu Jul 12 03:03:51 2007
@@ -332,8 +332,7 @@
public void pageBreak()
{
- // TODO: APT parse defect... pagebreak is never used.
- write( EOL + "^L" + EOL );
+write( EOL + "\f" + EOL );
}
public void paragraph()
Re: java.lang.LinkageError in itext module
Hi Lukas, Just for the record, you need to bump to a new release of Surefire, i.e. 2.3. Cheers, Vincent 2007/6/1, Lukas Theussl <[EMAIL PROTECTED]>: I have discussed this with Vincent on IRC, but after one night of trying, I still can't seem to get the doxia-itext-module to work. 'mvn test' fails with the stacktrace below. I'm running maven 2.0.6 from the command line, java 1.4.2, and no special settings. Vincent cannot reproduce it and it works for me if I run the same sequence of commands (as in the failing test) in a separate test project, ie outside maven, with the same deps on the classpath. I have upgraded to newer versions of itext (those buggers are changing their API with every release!), I have forked the tests and I have even re-built itext from sources. No light. Any ideas? -Lukas testGeneratingPDFFromITextXml(org.apache.maven.doxia.module.itext.ITextSinkTestCase) Time elapsed: 2.606 sec <<< ERROR! [ stdout ] --- [ stderr ] --- [ stacktrace ] --- java.lang.LinkageError: Class org/xml/sax/InputSource violates loader constraints at org.apache.crimson.parser.InputEntity.init(InputEntity.java:187) at org.apache.crimson.parser.Parser2.parseInternal(Parser2.java:638) at org.apache.crimson.parser.Parser2.parse(Parser2.java:337) at org.apache.crimson.parser.XMLReaderImpl.parse(XMLReaderImpl.java:448) at javax.xml.parsers.SAXParser.parse(SAXParser.java:345) at com.lowagie.text.xml.XmlParser.go(Unknown Source) at com.lowagie.text.xml.XmlParser.parse(Unknown Source) at com.lowagie.text.xml.XmlToXXX.parse(Unknown Source) at org.apache.maven.doxia.module.itext.ITextUtil.writePdf(ITextUtil.java:118) at org.apache.maven.doxia.module.itext.ITextSinkTestCase.testGeneratingPDFFromITextXml(ITextSinkTestCase.java:117) at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39) at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25) at java.lang.reflect.Method.invoke(Method.java:324) at junit.framework.TestCase.runTest(TestCase.java:154) at junit.framework.TestCase.runBare(TestCase.java:127) at junit.framework.TestResult$1.protect(TestResult.java:106) at junit.framework.TestResult.runProtected(TestResult.java:124) at junit.framework.TestResult.run(TestResult.java:109) at junit.framework.TestCase.run(TestCase.java:118) at junit.framework.TestSuite.runTest(TestSuite.java:208) at junit.framework.TestSuite.run(TestSuite.java:203) at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39) at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25) at java.lang.reflect.Method.invoke(Method.java:324) at org.codehaus.surefire.battery.JUnitBattery.executeJUnit(JUnitBattery.java:246) at org.codehaus.surefire.battery.JUnitBattery.execute(JUnitBattery.java:220) at org.codehaus.surefire.Surefire.executeBattery(Surefire.java:204) at org.codehaus.surefire.Surefire.run(Surefire.java:153) at org.codehaus.surefire.Surefire.run(Surefire.java:77) at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39) at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25) at java.lang.reflect.Method.invoke(Method.java:324) at org.codehaus.surefire.SurefireBooter.run(SurefireBooter.java:104) at org.apache.maven.test.SurefirePlugin.execute(SurefirePlugin.java:309) at org.apache.maven.plugin.DefaultPluginManager.executeMojo(DefaultPluginManager.java:443) at org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoals(DefaultLifecycleExecutor.java:539) at org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoalWithLifecycle(DefaultLifecycleExecutor.java:480) at org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoal(DefaultLifecycleExecutor.java:459) at org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoalAndHandleFailures(DefaultLifecycleExecutor.java:311) at org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeTaskSegments(DefaultLifecycleExecutor.java:278) at org.apache.maven.lifecycle.DefaultLifecycleExecutor.execute(DefaultLifecycleExecutor.java:143) at org.apache.maven.DefaultMaven.doExecute(DefaultMaven.java:334) at org.apache.maven.DefaultMaven.execute(DefaultMaven.java:125) at org.apache.maven.cli.MavenC
Re: svn commit: r542363 - /maven/doxia/doxia/trunk/doxia-modules/doxia-module-xdoc/src/main/java/org/apache/maven/doxia/module/xdoc/XmlWriterXdocSink.java
np!
Cheers,
Vincent
2007/5/28, Jason van Zyl <[EMAIL PROTECTED]>:
Sorry about that, thought I was building with 1.4. We need the
enforcer plugin :-)
On 28 May 07, at 8:11 PM 28 May 07, [EMAIL PROTECTED] wrote:
> Author: vsiveton
> Date: Mon May 28 17:11:44 2007
> New Revision: 542363
>
> URL: http://svn.apache.org/viewvc?view=rev&rev=542363
> Log:
> DOXIA-113: Can't build doxia with jdk1.4 in rev 542303
> Submitted by: Olivier Lamy
> Reviewed by: Vincent Siveton
>
> o patch applied
>
> Modified:
> maven/doxia/doxia/trunk/doxia-modules/doxia-module-xdoc/src/
> main/java/org/apache/maven/doxia/module/xdoc/XmlWriterXdocSink.java
>
> Modified: maven/doxia/doxia/trunk/doxia-modules/doxia-module-xdoc/
> src/main/java/org/apache/maven/doxia/module/xdoc/
> XmlWriterXdocSink.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/XmlWriterXdocSink.java?
> view=diff&rev=542363&r1=542362&r2=542363
> ==
>
> --- maven/doxia/doxia/trunk/doxia-modules/doxia-module-xdoc/src/
> main/java/org/apache/maven/doxia/module/xdoc/XmlWriterXdocSink.java
> (original)
> +++ maven/doxia/doxia/trunk/doxia-modules/doxia-module-xdoc/src/
> main/java/org/apache/maven/doxia/module/xdoc/XmlWriterXdocSink.java
> Mon May 28 17:11:44 2007
> @@ -1,4 +1,4 @@
> -package org.codehaus.doxia.module.xdoc;
> +package org.apache.maven.doxia.module.xdoc;
>
> /*
> * Licensed to the Apache Software Foundation (ASF) under one
> @@ -19,11 +19,12 @@
> * under the License.
> */
>
> -import org.apache.maven.doxia.util.HtmlTools;
> -import org.apache.maven.doxia.sink.SinkAdapter;
> +import org.apache.maven.doxia.parser.Parser;
> +import org.apache.maven.doxia.sink.SinkAdapter;
> import org.apache.maven.doxia.sink.StructureSink;
> +import org.apache.maven.doxia.util.HtmlTools;
> +import org.apache.maven.doxia.util.StringUtil;
> import org.codehaus.plexus.util.xml.XMLWriter;
> -import org.apache.maven.doxia.parser.Parser;
>
> /**
> * A doxia Sink which produces an xdoc document.
> @@ -54,7 +55,6 @@
> throw new IllegalArgumentException("argument can't be
> null");
> }
> this.writer = writer;
> -
> }
>
> protected void resetState()
> @@ -81,8 +81,8 @@
> public void head_()
> {
> headFlag = false;
> -
> -writer.endElement(); // properties
> +
> +writer.endElement(); // properties
> }
>
> public void title_()
> @@ -402,7 +402,6 @@
> }
> }
>
> -
> writer.startElement("t" + ( headerRow ? 'h' : 'd' ));
> if ( justif != null )
> writer.addAttribute("align", justif);
> @@ -535,7 +534,7 @@
> {
> buffer.append( text );
> }
> -else if ( sectionTitleFlag )
> +else if ( sectionTitleFlag )
> {
> buffer.append( text );
> }
> @@ -564,7 +563,7 @@
>
> protected void verbatimContent( String text )
> {
> -writer.writeText( text.replace(" ", " "));
> +writer.writeText( StringUtil.replaceAll( text, " ",
> " " ) );
> }
>
> public static String escapeHTML( String text )
>
>
>
Thanks,
Jason
--
Jason van Zyl
Founder and PMC Chair, Apache Maven
jason at sonatype dot com
--
Re: doxia not compilable?
Hi Martin,
Recently, Jason did some reorganization in the scm.
Fresh co :
* http://svn.apache.org/repos/asf/maven/doxia (rev 535613)
mvn clean install => no error
* https://svn.apache.org/repos/asf/maven/sandbox/trunk/doxia (rev 535614)
mvn clean install => error
So, I tried to consolidate the trunk (rev 535632). Hope that
everything is correct.
Cheers,
Vincent
2007/5/4, MartinAhrer <[EMAIL PROTECTED]>:
I was trying to compile doxia to get a working doxia-maven-plugin. Various
modules were not compile since HtmlTools.java has been moved in the alpha-9
snapshot. To get around temporarily I put a copy of HtmlTools into its old
location.
Further I had to add dependencies to doxia-book, namely:
${project.groupId}
doxia-module-xdoc
1.0-alpha-9-SNAPSHOT
${project.groupId}
doxia-module-latex
1.0-alpha-9-SNAPSHOT
With these changes I was able to compile it though it is just not running,
some tests fail, etc...
I know I'm working with a snapshot, but eventually somebody can help me
check if I am working with the proper checkouts!
I checked out from
* http://svn.apache.org/repos/asf/maven/doxia
* https://svn.apache.org/repos/asf/maven/sandbox/trunk/doxia
Thanks for helping
Martin
--
View this message in context:
http://www.nabble.com/doxia-not-compilable--tf3694292.html#a10330527
Sent from the Doxia - dev mailing list archive at Nabble.com.
Re: Feature Request: Additional tags to ease custom site.css
Hi Minto, It sounds good for me Also, have a look to DOXIA-63 Cheers, Vincent 2006/10/27, [EMAIL PROTECTED] <[EMAIL PROTECTED]>: Postbus 2287 1000 CG Amsterdam Telefoon 0900 8844 Fax 020 5594466 . Amsterdam-Amstelland Hi folks, I'd like to spice up a genarated faq, by using some fancy CSS stuff. What I want is adding a Q image in front of every question and an A image in front of every answer. The easiest way to achieve this would be some additional tag in the rendered faq, like … … However to give web designers even more freedom in creating fancy looking FAQs, some more tags would be welcome. I have come up with the following list: … … … … … Would a change like this be accepted? Kind regards, Minto van der Sluis DISCLAIMER De informatie in deze e-mail is vertrouwelijk en uitsluitend bestemd voor de geadresseerde. Indien u niet de geadresseerde bent, wordt u er hierbij op gewezen, dat u geen recht heeft kennis te nemen van de rest van deze e-mail, deze te gebruiken, te kopiëren of te verstrekken aan andere personen dan de geadresseerde. Indien u deze e-mail abusievelijk hebt ontvangen, brengt u dan alstublieft de afzender op de hoogte, waarbij u bij deze gevraagd wordt het originele bericht te vernietigen. Politie Amsterdam-Amstelland is niet verantwoordelijk voor de inhoud van deze e-mail en wijst iedere aansprakelijkheid af voor en/of in verband met alle gevolgen en/of schade van een onjuiste of onvolledige verzending ervan. Tenzij uitdrukkelijk het tegendeel blijkt, kunnen aan dit bericht geen rechten worden ontleend. Het gebruik van Internet e-mail brengt zekere risico´s met zich. Daarom wordt iedere aansprakelijkheid voor het gebruik van dit medium door de Politie Amsterdam-Amstelland van de hand gewezen.
Re: Odd behavior in rendered FAQ
[sorry for the delay] Hi Minto, mm it seems a bug. Feel free to open an issue about that and better, provide a patch! Thanks Vincent 2006/10/27, [EMAIL PROTECTED] <[EMAIL PROTECTED]>: Postbus 2287 1000 CG Amsterdam Telefoon 0900 8844 Fax 020 5594466 . Amsterdam-Amstelland Hi folks, I discovered some unexpected behaviour in a rendering .fml file when generating my site. I have had a look in the fml parser code and can not discover what the actual cause is. Here is what happened. My fml file contains the following snippet ... General Q1? a1 Configuration Q2? a2 ... When generating the site the previous snippet results in the following. Again just a snippet. The snippet is about the summary of the questions on top of the page. ... Frequently Asked Questions General NOTE THE TAG Q1? Configuration NOTE THE MISSING TAG Q2? ... It seems like only the first fml in my fml file gets transformed into an hmtl tag. All subsequent fml 's lack the html tag. To me this seems like inconsistent behaviour. However the odd thing is when looking at the sourcecode in FmlParser.java it includes a sink.paragraph() around every fml part. Is someone able to shed some light on this? I need this fixed to be able to have my custom site.css display the FAQ correctly/consistently. Kind regards, Minto van der Sluis DISCLAIMER De informatie in deze e-mail is vertrouwelijk en uitsluitend bestemd voor de geadresseerde. Indien u niet de geadresseerde bent, wordt u er hierbij op gewezen, dat u geen recht heeft kennis te nemen van de rest van deze e-mail, deze te gebruiken, te kopiëren of te verstrekken aan andere personen dan de geadresseerde. Indien u deze e-mail abusievelijk hebt ontvangen, brengt u dan alstublieft de afzender op de hoogte, waarbij u bij deze gevraagd wordt het originele bericht te vernietigen. Politie Amsterdam-Amstelland is niet verantwoordelijk voor de inhoud van deze e-mail en wijst iedere aansprakelijkheid af voor en/of in verband met alle gevolgen en/of schade van een onjuiste of onvolledige verzending ervan. Tenzij uitdrukkelijk het tegendeel blijkt, kunnen aan dit bericht geen rechten worden ontleend. Het gebruik van Internet e-mail brengt zekere risico´s met zich. Daarom wordt iedere aansprakelijkheid voor het gebruik van dit medium door de Politie Amsterdam-Amstelland van de hand gewezen.
Re: svn commit: r426203 - in /maven/doxia/trunk/doxia-sandbox/doxia-book: ./ src/main/java/org/apache/maven/doxia/book/services/indexer/ src/main/java/org/apache/maven/doxia/book/services/renderer/ sr
> [snip] > >> >> I like these, they are separators between logical parts of the method. >> > >> > It is not a Maven standard style thus I removed it. Is it for Doxia? >> > If yes, we need a developping guide. >> >> They are very much a standard part of the Maven code, we (at least I) >> use it all the time. > > > I will do Will you put back the comments that was removed? Done. Thanks! Vincent
Re: svn commit: r426203 - in /maven/doxia/trunk/doxia-sandbox/doxia-book: ./ src/main/java/org/apache/maven/doxia/book/services/indexer/ src/main/java/org/apache/maven/doxia/book/services/renderer/ sr
[snip]
>> These comments are pretty useless, I'd rather not sprinkle the code with
>> obvious comments.
>
> Agree but if no comment, nobody thinks to had comment, specially for
> new and important updates. my2cents ;)
Not sure what you mean, please explain again.
We know that writing good and informative comments is hard and bad
comments are just a waste... My point is that a class without a
minimum of comments is likely to remain like this in the future:
nobody thinks or "dares" to add new comments.
For instance, the Sink interface and its implementations dont have a
lot of useful documentation even if several developers worked on it.
WDYT?
> IMHO I think that Doxia needs to be review at large to add comment.
Agreed, we need to document the important parts.
yep
[snip]
>> > +//
>> > +//public void tableCaption()
>> > +//{
>> > +//type = TYPE_TABLE;
>> > +//}
>>
>> Any special reason for this other than you identing it by accident?
>
> Well, it is not an accident: it is the Eclipse formatter with the
> Maven Code Style
> (http://maven.apache.org/guides/development/guide-m2-development.html)
> Promise, I will try idea ASAP ;)
That has never been a standard that I can recall. Comment blocks always
start on column 1.
I know that it is not a standard! It is an Eclipse issue ;)
https://bugs.eclipse.org/bugs/show_bug.cgi?id=34552
[snip]
>> I like these, they are separators between logical parts of the method.
>
> It is not a Maven standard style thus I removed it. Is it for Doxia?
> If yes, we need a developping guide.
They are very much a standard part of the Maven code, we (at least I)
use it all the time.
I will do
Thanks,
Vincent
> [snip]
>
>> > +
>> > +//
>> ---
>> > // Private
>> > //
>> ---
>> >
>> > +/**
>> > + * Render the book, ie the book index and all chapter index
>> > + *
>> > + * @param book
>> > + * @param context
>> > + * @throws BookDoxiaException if any
>> > + */
>> > private void renderBook( BookModel book, BookContext context )
>> > throws BookDoxiaException
>> > {
>> > -//
>> ---
>> > -// Render the book index.xml page
>> > -//
>> ---
>> > -
>> > File index = new File( context.getOutputDirectory(),
>> "index.xml" );
>> >
>> > try
>> > @@ -86,12 +137,6 @@
>> > }
>> >
>> > //
>> ---
>> > -// Render the index.html files for each chapter
>> > -//
>> ---
>> > -
>> > -// TODO: Implement
>> > -
>> > -//
>> ---
>> > // Render all the chapters
>> > //
>> ---
>>
>> Ditto here about the commends. They explain the flow in the code.
>
> IMHO javadoc should provide it ;) developing guide...?
No, javadoc is not the same thing as inline comment. This is documenting
the _code itself_ not what the class/method is supposed to do.
[snip]
--
Trygve
Re: svn commit: r426618 - in /maven/doxia/trunk/doxia-core/src/main/java/org/apache/maven/doxia/module: xdoc/XdocSink.java xhtml/XhtmlSink.java
Hmm, it seems to work for me. I will review it. Thanks, Vincent 2006/7/28, Trygve Laugstøl <[EMAIL PROTECTED]>: Vincent Siveton wrote: > 2006/7/28, Trygve Laugstøl <[EMAIL PROTECTED]>: >> [EMAIL PROTECTED] wrote: >> > Author: vsiveton >> > Date: Fri Jul 28 10:55:37 2006 >> > New Revision: 426618 >> > >> > URL: http://svn.apache.org/viewvc?rev=426618&view=rev >> > Log: >> > o Changed itemFlag type to boolean instead of int thus no need to >> throw a RuntimeException >> >> Are you sure this will work? What happens when it's nesting items? > > I'm not sure what you mean. > > BTW here is a small example, hope this helps > http://people.apache.org/~vsiveton/MSITE-153/ Sorry, I don't understand the relation here. Isn't the itemFlag supposed to be incremented and decremented when you nest more item lists? Like this: -- Trygve
Re: svn commit: r426635 - in /maven/doxia/site/src/books: example-book.xml example-book/aegis-binding.apt example-book/castor.apt example-book/jms-transport.apt
Background: "bindings" was used as id for a chapter and a section. Now, we create a chapter index page with id as filename. During the renderer execution, chapter index page is overrided by the section file so we need a unique id and more validation... Cheers, Vincent 2006/7/28, Trygve Laugstøl <[EMAIL PROTECTED]>: [EMAIL PROTECTED] wrote: > Author: vsiveton > Date: Fri Jul 28 11:13:01 2006 > New Revision: 426635 > > URL: http://svn.apache.org/viewvc?rev=426635&view=rev > Log: > o Fixed typo in the example-book > o Fixed unique id for chapter/section > > Modified: > maven/doxia/site/src/books/example-book.xml > maven/doxia/site/src/books/example-book/aegis-binding.apt > maven/doxia/site/src/books/example-book/castor.apt > maven/doxia/site/src/books/example-book/jms-transport.apt > > Modified: maven/doxia/site/src/books/example-book.xml > URL: http://svn.apache.org/viewvc/maven/doxia/site/src/books/example-book.xml?rev=426635&r1=426634&r2=426635&view=diff > == > --- maven/doxia/site/src/books/example-book.xml (original) > +++ maven/doxia/site/src/books/example-book.xml Fri Jul 28 11:13:01 2006 > @@ -4,7 +4,7 @@ >XFire User Manual > > > - bindings > + bind >Bindings > > Why? The id and title should be similar. -- Trygve
