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