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 denn...@apache.org: 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 nsowa...@cisco.com:
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 ltheu...@apache.org: IIUC, according to the xdoc schema it is perfectly legal to specify a title in both properties and head, so throwing an Exception is not the right solution IMO. I would prefer one of the following two alternatives: Yes both are legal, but the doc doesn't specify which one is the official title of a xdoc. 1) define and document which title gets used if both are specified and emit a warning that the other is ignored I was thinking about this idea but due to the parser impl, it will be always head/title which emits a warn due to the exception actually. IMHO head/title should be the right title, properties/title is more for backward compatibility reasons. WDYT? Cheers, Vincent
Re: svn commit: 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 denn...@apache.org: 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: entities: text or rawText?
Hi Lukas, 2009/5/4 Lukas Theussl ltheu...@apache.org: 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 AElig; will become #198; by XmlPullParser) XhtmlBaseSink#text() escapes chars and XhtmlBaseSink#rawText() not. So using rawText() is to be sure to not escape text with entities. I think they should be emitted as text: First, custom entities can be used to simply define some replacement text inside documents (eg !ENTITY version 1.0). Second, the resulting events should be consumable by all sinks, not just x(ht)ml based ones. Consider for instance the text amp;AElig; (where AElig is defined as !ENTITY AElig #198;). Currently it is emitted by the XhtmlBaseParser as one text event and one rawText event #198;. 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 amp; 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: surefire forkMode setting
Go ahead. Cheers, Vincent 2009/4/3 Lukas Theussl ltheu...@apache.org: Hi, Is there any reason why we have this setting in the doxia parent pom: plugin artifactIdmaven-surefire-plugin/artifactId configuration forkModenever/forkMode /configuration /plugin I just noticed that this is the cause of cobertura reporting 0% coverage everywhere, see eg [1] (this is the same as reported at [2]). Leaving the forkMode at once (the default), cobertura works correctly. Any objections to remove that part? -Lukas [1] http://maven.apache.org/doxia/doxia/doxia-core/cobertura/index.html [2] http://jira.codehaus.org/browse/MCOBERTURA-70
Fwd: [ANN] Maven Doxia 1.1 Released
-- Forwarded message -- From: Vincent Siveton vsive...@apache.org 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] - param tags are always parsed as macro parameters * [DOXIA-212] - There is no way to include images using relative urls * [DOXIA-215] - Trailing spaces after table definition causes exception * [DOXIA-216] - Linkcheck broken * [DOXIA-221] - Fix ArrayIndexOutOfBoundsException in XhtmlBaseSink * [DOXIA-222] - XhtmlBaseParser swallows significant whitespace * [DOXIA-225] - DocBookParser swallows significant whitespace * [DOXIA-227] - [regression] attributes stripped from img tags * [DOXIA-230] - Review Doxia generation for Apt and Docbook * [DOXIA-235] - Confluence parser doesn't strip leading spaces for list items * [DOXIA-240] - NPE when building documentation * [DOXIA-241] - Xdoc/XhtmlBaseParser doesn't close sections properly * [DOXIA-242] - Echo macro outputs internal params * [DOXIA-246] - TOC macro: higher entries are ignored * [DOXIA-247] - unable to parse document when the last character is '}' * [DOXIA-250] - Xml parser should handle entities defined in doctype * [DOXIA-251] - The AbstractXmlParser should take care of EOL * [DOXIA-257] - APT local anchor / link doesn't work when there is a whitespace in the anchor name * [DOXIA-259] - Source code snippets are not indented automatically * [DOXIA-261] - The Twiki noautolink is not used at all * [DOXIA-270] - Review doxia-converter artefact to respect ASF rules * [DOXIA-273] - Broken link in External Resources page * [DOXIA-274] - Broken link in What is Doxia? page * [DOXIA-291] - Wrong classid in SwfMacro * [DOXIA-292] - Be sure to call tableRows(int[], boolean) to be backward compatible with Doxia 1.0 ** Improvement * [DOXIA-78] - Doxia XDOC parser and XHTML renderer ignore rowspan and colspan attributes for tables * [DOXIA-137] - Add comments to sink API * [DOXIA-142] - Allow snippet macro contents to be output as-is, instead of verbatim * [DOXIA-144] - Review signature methods * [DOXIA-153] - HTML tags in twiki not rendered correctly * [DOXIA-154] - Xdoc parser should recognize script tag * [DOXIA-155] - AbstractXmlParser should recognize CDATA, entities and comments * [DOXIA-163] - Add support for underscores * [DOXIA-164] - Add
Re: Fwd: [ANN] Maven Doxia 1.1 Released
Hi 2009/3/8 Hervé BOUTEMY herve.bout...@free.fr: I worked on the overview schema: see the new version attached to this mail. Please comment if you think other changes are needed before I commit it and update everyhting (the .png and imagemap). +1 go for it I have one question though: if I export the schema as an image with OpenOffice 2.4, I et an image that is a lot bigger than the current one. How did you create the .png? Is it a discepency between our versions of OpenOffice (I'm working with 2.4 on Linux)? It seems that it is no longer possible with 2.4. Cheers, Vincent
Re: Merging with XWiki and WikiModel
Hi Jason, 2009/1/29 Jason van Zyl ja...@maven.org: 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: 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 br...@apache.org: 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 vincent.sive...@gmail.com 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 vincent.sive...@gmail.com: 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: 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 pau...@apache.org: 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/doxia/sink/SinkEventAttributes [INFO]
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: 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 vincent.sive...@gmail.com: Hi guys, I proposed to remove officially org.codehaus.doxia.sink.Sink for the 1.0 (DOXIA-146). WDYT? Vincent
Re: Removed org.codehaus.doxia.sink.Sink for 1.0
2008/12/14 Benjamin Bentmann benjamin.bentm...@udo.edu: 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
Hi Brett, 2008/12/14 Brett Porter br...@apache.org: 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: 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 vincent.sive...@gmail.com: Hi Dennis, 2008/12/12 Dennis Lundberg denn...@apache.org: 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 denn...@apache.org: 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=725511view=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=723989view=rev
Log:
DOXIA-265: Add an EntityResolver in AbstractXmlParser#getXmlReader()
o added a simple cached file mechanism
Modified:
maven/doxia/doxia/trunk/doxia-core/src/main/java/org/apache/maven/doxia/parser/AbstractXmlParser.java
[...]
+byte[] res = (byte[]) cache.get( systemId );
+// already cached?
+if ( res == null )
+{
+File temp =
+new File( System.getProperty( java.io.tmpdir ),
FileUtils.getFile( systemId ).getName() );
+// maybe already as a temp file?
+if ( !temp.exists() )
+{
+res = IOUtil.toByteArray( new URL( systemId
).openStream() );
+IOUtil.copy( res, WriterFactory.newPlatformWriter(
temp ) );
+}
+else
+{
+res = IOUtil.toByteArray(
ReaderFactory.newPlatformReader( temp ) );
+}
+
+cache.put( systemId, res );
+}
+
+InputSource is = new InputSource( new ByteArrayInputStream(
res ) );
+is.setPublicId( publicId );
+is.setSystemId( systemId );
+
Is it safe to use a reader here, especially a platform reader? Byte streams
that don't match the intended encoding get crippled but is the encoding of
the data known here? Should this maybe just use
IOUtil.copy( byte[], OutputStream )
and
IOUtil.toByteArray( InputStream )
i.e. simply move bytes around instead of thinking about characters?
Benjamin
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
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
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
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: 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=697524view=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=697524r1=697523r2=697524view=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 a href=mailto:[EMAIL PROTECTED]Jason van Zyl/a
* @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=697524r1=697523r2=697524view=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 a href=mailto:[EMAIL PROTECTED]Emmanuel Venisse/a
* @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: 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: 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=659507view=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=659507r1=659506r2=659507view=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=659507r1=659506r2=659507view=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 ) )
+if ( AptUtils.isInternalLink( linkAnchor ) )
{
linkAnchor = # + linkAnchor;
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=11624styleName=Htmlversion=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: 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=10780styleName=Htmlversion=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: 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] faq id=What is a Mojo which is internally converted to a name=What_is_a_Mojo. 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: 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
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: 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 div 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-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=10780styleName=Htmlversion=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
[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: 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: 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
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.3view=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: 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=revrev=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=diffrev=59r1=58r2=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: 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 ... part id=Set up titleGeneral/title faq id=a1 questionQ1?/question answerpa1/p/answer /faq /part part id=Config titleConfiguration/title faq id=a2 questionQ2?/question answerpa2/p/answer /faq faq id=a3 ... 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. ... h2a name=topFrequently Asked Questions/a/h2 pbGeneral/b/p NOTE THE p TAG ol type=1 li lia href=#a1Q1?/a/li /li /ol bConfiguration/b NOTE THE MISSING p TAG ol type=1 li lia href=#a2Q2?/a/li ... It seems like only the first fml part in my fml file gets transformed into an hmtl p tag. All subsequent fml part's lack the html p 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: 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=426618view=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: ol li ol li/li li/li /ol /li li ol li/li li/li /ol /li /old -- Trygve
Re: autodetecting format instead of using subdirectories
+1 Vincent 2006/7/20, Brett Porter [EMAIL PROTECTED]: Hi, I Was wondering what folks thought of deprecating the src/site/*/ in favour of, say, src/site/docs which contains all the docs. Instead of processing by directory name, we'd need to detect each file's type (by extension, and possibly content/doctype for things like xml). The reason I suggest this is that I keep going to look for docs in src/site/apt, and they aren't there because they are in xdoc. I remember the structure of the site, not the format of the individual docs. Thoughts? - Brett -- Apache Maven - http://maven.apache.org/ Better Builds with Maven - http://library.mergere.com/
svn commit: r384684 - in /maven/doxia/trunk/doxia-core/src/main/java/org/apache/maven/doxia/module: xdoc/XdocParser.java xhtml/XhtmlSink.java
Hi, The correction doesn't call the closing method for: sink.anchor( ... ); IMHO, we need to add also: sink.anchor_(); Cheers, Vincent Author: brett Date: Thu Mar 9 18:47:31 2006 New Revision: 384684 URL: http://svn.apache.org/viewcvs?rev=384684view=rev Log: [MNG-2099] fix anchor generation Submitted by: Olivier Lamy
[jira] Created: (DOXIA-52) Improve the FmlParser class
Improve the FmlParser class --- Key: DOXIA-52 URL: http://jira.codehaus.org/browse/DOXIA-52 Project: doxia Type: Improvement Components: Core Versions: 1.0-alpha-8 Reporter: Vincent Siveton Attachments: FmlParser.diff This patch provides: * escapeHTML() for the value of an attribute * support of the CDATA sections * improve top anchor -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.codehaus.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
