On Fri, Aug 13, 2010 at 18:39, Kirst Martin Wolfgang <[email protected]> wrote: >> > [...] >> > Interesting point. >> > I've watch at it, but it seems to be a different approach to me. >> > Cause, I've had a more complete batch migration in mind, not so much >> > focussed on having a fancy wizard for. >> >> I don't understand what you mean here, wiki importer goal is to import >> complete wikis. The UI part is just on the framework side and when you >> wriite a wiki importer module you don't really care about that and >> just declare what you want to get as parameter (the file containing an >> exported wiki, the URL of a wiki to import using REST, etc...), then >> you do whatever you want with this. > Oh, than I misunderstood this importer project. Sorry about that. > >> >> IMO both project could use the exact same code for the MediaWiki -> >> XWiki convertion which is what is in the MediaWiki module of wiki >> importer, then the UI and the way to store the produced documents >> depends of the tool. >> >> > Additionally setting up my Eclipse workspace with just XMLRPC-API > and >> > wikimodel was way easier ;-) So it was simpler to patch/enhance >> > wikimodel >> > for my tasks. >> >> With M2Eclipse it's very easy to use XWiki Rendering in a new project. > Hmm, not to my experience. I've tried maven a couple of times for > different open source projects I've worked on. > I'm willing to learn about, but most often I was disappointed. > Even after reading the XWiki building instructions it tooks me hours > to brought up an error free workspace.
I do that all the time when we create a new branch of XWiki and it is always very easy. > Even 'svn co xwiki core && mvn install' is not possible without > manually importing some unresolved JARs - easy to solve, but annoying. This should never happen and when it does weusually see and fix it very quickly. > After all, I've ended up with problems regarding missing dependencies > of XWiki's own DI framework. Oh ... I'm drifting away ;-) > >> > But as I read on page 'RenderingModel' your importer also uses >> > wikimodel. >> > Thus my patches also benefit your project :-) >> >> Actually wiki importer use XWiki Rendering which use WikiModel >> specifically for the MediaWiki parser but use it's own XWiki 2.0 >> serializer, use Doxia for other languages etc... > My patches also targeting the parser code ... > Writing my own serializer was more a need because wikimodel doesn't have > one > and I didn't want to have xwiki code base in my dependencies (see > above). Again using XWiki Rendering is like using any other independent tool like wikimodel. It has been designed to be used outside of XWiki core, the only other XWiki module it really depends on is the XWiki Component Manager module which is also independent and pretty small. Basically you make your project depends on http://maven.xwiki.org/snapshots/org/xwiki/platform/xwiki-core-rendering-syntax-wikimodel/ and see what dependencies you get. It will be more dependencies than wikimodel of course but not so much and it would be a lot better to use the official XWiki serializer and is a big work and is a well tested. > > I would really give the importer framework a try, but currently I don't > know where to start actually - and POC or not, it shouldn't be take > any skilled Java developer more than 2 hours to bring it up and running. > > It would be easier for me and others, when there would be > a documentation "how to setup (sandbox) xwiki importer framework". > Then, most likely my starting point would have been a different one. Sure, thing is there is still crappy things in the wiki importer framework I really don't like and that I would like to change when i have some time before putting it in standard with the MediaWiki module, then i will write some documentation for people to add more importers. > > Regards > Martin > _______________________________________________ > devs mailing list > [email protected] > http://lists.xwiki.org/mailman/listinfo/devs > -- Thomas Mortagne _______________________________________________ devs mailing list [email protected] http://lists.xwiki.org/mailman/listinfo/devs
