Re: Merging with XWiki and WikiModel
Hi Herve, On Mar 8, 2009, at 2:53 PM, Hervé BOUTEMY wrote: Vincent, After our discussion on IRC, I perfectly understand how we could benefit from convergence in the domain of document parsing and rendering, with the advantage of not only more developpers, but more users too, then more tests. yep. Regarding tests we have more than 900 unit tests overall for the XWiki Rendering engine. This is absolutely needed because parsing/rendering seems an easy task but it's really complex when you tackle edge cases. We would never have been able to code a strong bi-directional wiki <-- > XHTML conversion without these tests. Vincent Siveton did a great job with an Eclipse plugin that was integrated in m2eclipse, but: - this is only Eclipse-centric, how about other IDE's? - it would still need a lot of work to continue improve it (it actually helps me a lot when editing pages, no show-stopper bugs: only minor things) - our brand new GWT-based WYSIWYG editor Is there something in XWiki to help editing pages that are on local disk (and stored in svn)? There's a Storage interface. Currently we have one implementation for Hibernate and another for JCR. It's possible to add one SVN but nobody has been working on this. Re local disk, I guess the JCR implementation could be used for that. Would this GWT-based WYSIWYG editor help here? Or is it only web-centric? The WYSIWYG editor is a web-based editor of course but it takes its content from any XHTML content (which can be generated by the XWiki Rendering from any source). Thanks -Vincent Regards, Hervé Le lundi 02 février 2009, Vincent Massol a écrit : Hi there, On Jan 31, 2009, at 12:04 AM, Vincent Siveton wrote: Hi Jason, 2009/1/29 Jason van Zyl : Howdy, I've been looking at reporting in Maven 3.x and I've been following the work that Vincent Massol has been doing over at XWiki where he has made some attempts at melding Doxia, the XWiki rendering engine, and WikiModel. You can see the proposal here: http://dev.xwiki.org/xwiki/bin/view/Design/RenderingEngineConvergence I am looking to remove the Doxia dependency from Maven 3.x so that reporting is removed from core and just becomes another set of components. Having I definitely agree to decouple Maven from Doxia, or conversely :) We actually have a lot of problems due to this coupling, see MNG-3402. Doxia coupled to Maven is not very nice so in the next couple releases of the Maven 3.x alphas the hard dependency on Doxia will be removed. This will open the door for anyone who wants to add a different mechanism. Doxia reports will still work, I'm not planning on removing the functionality just unbinding it from the core. But that opens the door for something new! Some questions to clarify what you have in mind: - how do you plan to integrate reporting concretely to Maven 3? - what about the backward compatibility in the reporting plugins? What I personally think the best path would be is to help what Vincent has started. There are really only three people here who work on Doxia, the releases are very slow in coming and I think you would immediately double or Agree but we work when we have time :) @Dennis: what are your availabilities to release the version 1.0? After this release, 1.1 could be out, IMHO all stuffs are there. triple the size of the team merging with the XWiki folks and getting the WikiModel developer as well. This is what the XWiki folks do all the time and I think you would get some more velocity in the progress of the project as a whole. Vincent is using Plexus for his stuff so it's not that wildly different but I think you would get more visibility over there and a higher The xwiki proposal seems to move the Doxia code to the xwiki umbrella, so do you plan to do it? @Vincent, could you clarify why a fork is not possible for you? Let me explain the point of view of the xwiki community (I hope I'm summarizing it well here): * XWiki is not a wiki. It's a platform offering wiki components to develop any type of content-centric web application based on the wiki paradigm. * We've started reorganizing ourselves to implement this vision back in 2007. We've started by decoupling our monolithic code into modules and components (using Plexus). * We're not finding that there are some important pieces that we want to make top level projects, independent of the other xwiki modules/ components. For the moment we have identified 2 pieces: - the rendering engine - our brand new GWT-based WYSIWYG editor * We could propose these under new projects at the ASF for example. These are the reasons preventing us from doing so right now: - we'd like to promote the XWiki project name as the place where to get wiki "components". If we start splitting the rendering engine or the wysiwyg editor we won't achieve this - having to implement and support several projects (the xwiki one + the engine one at ASF + the wysiwyg one wherever else (@co
Re: Merging with XWiki and WikiModel
I'm cross-posting this between Doxia and Maven dev lists, because this has both interests. Le samedi 31 janvier 2009, Jason van Zyl a écrit : > On 30-Jan-09, at 3:04 PM, Vincent Siveton wrote: > > Hi Jason, > > > > 2009/1/29 Jason van Zyl : > >> Howdy, > >> > >> I've been looking at reporting in Maven 3.x and I've been following > >> the work > >> that Vincent Massol has been doing over at XWiki where he has made > >> some > >> attempts at melding Doxia, the XWiki rendering engine, and > >> WikiModel. You > >> can see the proposal here: > >> > >> http://dev.xwiki.org/xwiki/bin/view/Design/RenderingEngineConvergence > >> > >> I am looking to remove the Doxia dependency from Maven 3.x so that > >> reporting > >> is removed from core and just becomes another set of components. > >> Having > > > > I definitely agree to decouple Maven from Doxia, or conversely :) > > We actually have a lot of problems due to this coupling, see MNG-3402. > > > >> Doxia coupled to Maven is not very nice so in the next couple > >> releases of > >> the Maven 3.x alphas the hard dependency on Doxia will be removed. > >> This will > >> open the door for anyone who wants to add a different mechanism. > >> Doxia > >> reports will still work, I'm not planning on removing the > >> functionality just > >> unbinding it from the core. But that opens the door for something > >> new! > > > > Some questions to clarify what you have in mind: > > - how do you plan to integrate reporting concretely to Maven 3? > > As a completely separate execution environment. So the plugin manager > in 3.x will only deal with build plugins. Then a separate plugin > manager can be created for Doxia based reports and those will map to > the current reporting element. Then I would like to create another > execution environment for a more data centric report model. the idea is interesting. Is there something somewhere on this? How can I help? The key plugin is maven-site-plugin: a new branch? Regards, Hervé
Re: Merging with XWiki and WikiModel
Vincent, After our discussion on IRC, I perfectly understand how we could benefit from convergence in the domain of document parsing and rendering, with the advantage of not only more developpers, but more users too, then more tests. Vincent Siveton did a great job with an Eclipse plugin that was integrated in m2eclipse, but: - this is only Eclipse-centric, how about other IDE's? - it would still need a lot of work to continue improve it (it actually helps me a lot when editing pages, no show-stopper bugs: only minor things) >- our brand new GWT-based WYSIWYG editor Is there something in XWiki to help editing pages that are on local disk (and stored in svn)? Would this GWT-based WYSIWYG editor help here? Or is it only web-centric? Regards, Hervé Le lundi 02 février 2009, Vincent Massol a écrit : > Hi there, > > On Jan 31, 2009, at 12:04 AM, Vincent Siveton wrote: > > Hi Jason, > > > > 2009/1/29 Jason van Zyl : > >> Howdy, > >> > >> I've been looking at reporting in Maven 3.x and I've been following > >> the work > >> that Vincent Massol has been doing over at XWiki where he has made > >> some > >> attempts at melding Doxia, the XWiki rendering engine, and > >> WikiModel. You > >> can see the proposal here: > >> > >> http://dev.xwiki.org/xwiki/bin/view/Design/RenderingEngineConvergence > >> > >> I am looking to remove the Doxia dependency from Maven 3.x so that > >> reporting > >> is removed from core and just becomes another set of components. > >> Having > > > > I definitely agree to decouple Maven from Doxia, or conversely :) > > We actually have a lot of problems due to this coupling, see MNG-3402. > > > >> Doxia coupled to Maven is not very nice so in the next couple > >> releases of > >> the Maven 3.x alphas the hard dependency on Doxia will be removed. > >> This will > >> open the door for anyone who wants to add a different mechanism. > >> Doxia > >> reports will still work, I'm not planning on removing the > >> functionality just > >> unbinding it from the core. But that opens the door for something > >> new! > > > > Some questions to clarify what you have in mind: > > - how do you plan to integrate reporting concretely to Maven 3? > > - what about the backward compatibility in the reporting plugins? > > > >> What I personally think the best path would be is to help what > >> Vincent has > >> started. There are really only three people here who work on Doxia, > >> the > >> releases are very slow in coming and I think you would immediately > >> double or > > > > Agree but we work when we have time :) > > @Dennis: what are your availabilities to release the version 1.0? > > After this release, 1.1 could be out, IMHO all stuffs are there. > > > >> triple the size of the team merging with the XWiki folks and > >> getting the > >> WikiModel developer as well. This is what the XWiki folks do all > >> the time > >> and I think you would get some more velocity in the progress of the > >> project > >> as a whole. Vincent is using Plexus for his stuff so it's not that > >> wildly > >> different but I think you would get more visibility over there and > >> a higher > > > > The xwiki proposal seems to move the Doxia code to the xwiki umbrella, > > so do you plan to do it? > > > > @Vincent, could you clarify why a fork is not possible for you? > > Let me explain the point of view of the xwiki community (I hope I'm > summarizing it well here): > > * XWiki is not a wiki. It's a platform offering wiki components to > develop any type of content-centric web application based on the wiki > paradigm. > > * We've started reorganizing ourselves to implement this vision back > in 2007. We've started by decoupling our monolithic code into modules > and components (using Plexus). > > * We're not finding that there are some important pieces that we want > to make top level projects, independent of the other xwiki modules/ > components. For the moment we have identified 2 pieces: >- the rendering engine >- our brand new GWT-based WYSIWYG editor > > * We could propose these under new projects at the ASF for example. > These are the reasons preventing us from doing so right now: >- we'd like to promote the XWiki project name as the place where to > get wiki "components". If we start splitting the rendering engine or > the wysiwyg editor we won't achieve this >- having to implement and support several projects (the xwiki one + > the engine one at ASF + the wysiwyg one wherever else > (@code.google.org for ex)) is going to spread our committer base thin > achieving the opposite as what we want to achieve which is making all > people interested on working on wiki "components" together. >- we have a very good infrastructure team and we completely host > all our tools. We like it this way since it's real fast and it works > real well and we can only complain to ourselves if something is not > right and we can fix it right away. Note that the infra is paid by > XWiki SAS (a company offering servic
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
Re: Fwd: [ANN] Maven Doxia 1.1 Released
great! thank you Vincent. I worked on the overview schema: see the new version attached to this mail. Please comment if you think other changes are needed before I commit it and update everyhting (the .png and imagemap). I have one question though: if I export the schema as an image with OpenOffice 2.4, I et an image that is a lot bigger than the current one. How did you create the .png? Is it a discepency between our versions of OpenOffice (I'm working with 2.4 on Linux)? Regards, Hervé Le dimanche 08 mars 2009, Vincent Siveton a écrit : > -- Forwarded message -- > From: Vincent Siveton > 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 classi
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
