xwiki-devs

xwiki-devs@xwiki.org

9400 discussions

RC1/1.0 release and strategy going forward

by Vincent Massol

Hi, I'd like to propose the following: * Release RC1 by end of next week with as many important bugs fixed as possible * Wait for 1 week after RC1 is released and declare RC1 to be 1.0 final is no critical/blocking bugs are found * Dedicate the XWIKI 1.0 branch to contain ONLY bug fixes going forward * Put new features/improvements ONLY on trunk * Release 1.0.1 2 to 3 weeks after 1.0 is released with bug fixes * Define a roadmap for 1.1 in term of what we want in it. It should be achievable within 3 months. * Change the version on trunk to be 1.1-beta-1 and release after 2-3 weeks. Increase to 1.1-beta-2 and repeat, etc. till we either reach something close so the initial roadmap for 1.1 in term of features or we reach the 3 months delay. In any case, release 1.1 at that time. * I propose to NOT create a branch for 1.1 till the final 1.1 is released and when it is I propose we don't release 1.0.x releases any more and instead release 1.1.x bug fixes releases (we don't have enough manpower to support more than 2 releases in parallel, it's already going to stretch us a lot). WDYT? Thanks -Vincent

17 years, 7 months

Latest WikiModel released

by Stéphane Laurière

Hi everyone, The WikiModel project has been mentionned a few times on the list already: WikiModel is a wiki parser and a wiki page model that has been designed within the Nepomuk European Research project. WikiModel is authored by M. Kotelnikov from Cognium Systems. This email is for announcing the public release of the latest version of WikiModel, now available from the URLs below under the Eclipse Public License. You will get an overview of the project from there: http://nepomuk.semanticdesktop.org/xwiki/bin/view/Components/WikiModel See also these notes by Vincent on the reasons why WikiModel is of interest to the XWiki project: http://www.xwiki.org/xwiki/bin/view/Idea/WikiModelIntegration http://www.xwiki.org/xwiki/bin/view/GoogleSummerOfCode/WikiModel+Integration There's an open mailing-list for discussing the project, you are welcome to subscribe: https://nepomuk.semanticdesktop.org/wws/info/wikimodel The code: https://dev.nepomuk.semanticdesktop.org/repos/trunk/java/org.semanticdeskto… https://dev.nepomuk.semanticdesktop.org/repos/trunk/java/org.semanticdeskto… Cheers Stéphane

17 years, 7 months

[Proposal] New Importer Architecture

by Vincent Massol

Hi, I had some time in the train yesterday so I thought about what a new Importer architecture would look like. First the reason for changing the current one (which is located in the Package plugin): * "bad" design (everything is mixed up in one big class, not modular) and too complex to maintain * cannot import HTML, plain text, etc * cannot convert from one wiki syntax to another Proposal ======= * A Importer interface to represent the different importers o import(Converter converter, DocumentImportFactory factory) o setFilter(ImportFilter filter) : to decide what document to import * A Converter interface to convert original content before it's imported into a page o OutputStream convert(InputStream originalContent) * A DocumentImportFactory interface for delegating how pages are created. This is important as there are different strategies for finding out the following data from the original content: o Language o Target Space o Target Page name o Objects to attach o Attachments o Versions o Author o API: + XWikiDocument createDocument(String originalFileName, InputStream contentAfterConversion) + setMode(REPLACE || APPEND): whether to create a new version or replace any existing doc Examples of implementations: * For Importer: FileImporter, DirectoryImporter, ZIPImporter, ZipURLImporter, JARImporter * For Converter: PlainTextConverter, HTMLConverter, TWikiConverter, ConfluenceConverter, XWikiXMLConverter (for converting documents in XWiki XML format) * For DocumentImportFactory: XARDocumentImportFactory, ExpandedXARDocumentImportFactory, DefaultDocumentImportFactory (uses the file name as page name and parent directory as space, etc) Examples of using it ================ * A XAR file o new ZipImporter(new File(".../.xar"), new XWikiXMLConverter(), new XARDocumentImportFactory(new File(".../.xar"))) * A single HTML file o new FileImporter(new File(".../.html"), new HTMLConverter (), new DefaultDocumentImporterFactory()) * A zip file containing TWiki pages o new ZipImporter(new File(".../.zip"), new TWikiConverter (), new DefaultDocumentImporterFactory()) * An expanded directory of HTML files o new DirectoryImporter(new File(".../somedir"), new HTMLConverter(), new DefaultDocumentImporterFactory()) I've put all this on http://www.xwiki.org/xwiki/bin/view/Idea/ NewImporterArchitecture but I think it's better to discuss it here as email is better for discussions... Note: I'm not planning to implement this yet as our first priority is still the 1.0 release but once it's released, I'm volunteering for implementing it, using a component strategy (cf new V2 architecture). WDYT? Thanks -Vincent

17 years, 7 months

i18n.java class, ok to remove it?

by Vincent Massol

Hi, I noticed that the i18n.java class in the core is not used anywhere (at least I couldn't find any reference to it). Thus I'd like to remove it. Ok with everyone? Note: In addition it's badly named as a class in java should start with an uppercase letter... Thanks -Vincent

17 years, 7 months

xredirect on a confirm delete action

by Arnaud Thimel

Hi all, I tried to use the xredirect functionnality on a confirm delete action I would like the URL : /xwiki/bin/delete/Plans/aaaa?confirm=1&xredirect=/xwiki/bin/view/Plans/bbbb to delete the doc aaaa and then redirect to the doc bbbb If I remove the confirmation (confirm=1) my redirect is OK but, as I don't confirm deletion, my doc aaaa is still here. I patched my own version of XWiki because I need it, but I would like to know if this is volunteer (and so why ?) or if I should submit my patch. Thanks -- Arnaud Thimel Société Code Lutin - http://www.codelutin.com

17 years, 7 months

[ANN] XWiki 1.0 Beta 6 Released

by Vincent Massol

The XWiki development team team is pleased to announce the availability of the 1.0 Beta 6 release. Go grab it on http://www.xwiki.org/xwiki/bin/view/Main/Download This release is the last before the 1.0 RC1, which gets us one step closer to the 1.0 final release planned for mid/end April. The focus for this release was still bug fixing but this release brings other nice improvements: * XWiki skins have been renamed using bird names: the old xwiki10b1 is now albatross, the old default skin is now dodo and the old xwiki10 skin is now finch * New rename feature to rename pages and all backlinks leading the page to rename. * New check box interface for tags. The Tag feature now supports 3 interfaces: a list of tags separated by commas or pipes symbols, a checkbox list of tags to select/unselect and point-and-click list of tags to select/unselect. * New Text Analyzer plugin. * Upgraded to Velocity 1.5 final * Improved PDF output * GraphViz plugin is now off by default and needs to be enabled in xwiki.cfg * Added possibility to restrict the possible languages available on a given wiki * New Blog panel available that lists all blog categories * New footnote macro. In addition the Albatross skin has been modified to display automatically footnotes added with this macro. See the full release notes on http://www.xwiki.org/xwiki/bin/view/ Main/ReleaseNotesXWiki10Beta6 Enjoy -The XWiki development team

17 years, 7 months

[VOTE] Pre-flight check for releasing XWiki 1.0 Beta 6

by Vincent Massol

Hi everyone, I've uploaded the 1.0 Beta 6 binaries on http://193.231.30.155/10b6/. We need a few people to test it out and verify it works fine for them. Then, once we get 3-4 positive answers, I'll do the official release on ObjectWeb and announce the releases. Here are the release notes for 1.0 Beta 6: http://www.xwiki.org/xwiki/bin/view/Main/ReleaseNotesXWiki10Beta6 In short: * Lots of bugs fixed * XWiki skins have been renamed using bird names: the old xwiki10b1 is now albatross, the old default skin is now dodo and the old xwiki10 skin is now finch * New rename feature to rename pages and all backlinks leading the page to rename. There are some known limitations: o backlinks have to be turned on (they are turned on by default but if you have turned them off, rename will not rename backlinks and you'll have to turn them on again to benefit from this feature) o backlinks in objects attached to pages are not currently renamed o backlinks are saved when a page is saved thus it may happen with a clean XWiki database that backlinks are not saved. In this special case, you can call the following in a page to refresh all links (you'll need to be admin to do this): $xwiki.refreshLinks() * New check box interface for tags. The Tag feature now supports 3 interfaces: a list of tags separated by commas or pipes symbols, a checkbox list of tags to select/unselect and point-and-click list of tags to select/unselect. * New Text Analyzer plugin. * Upgraded to Velocity 1.5 final * Improved PDF output * Rename method renamed from Document.renameDocument() to Document.rename() * GraphViz plugin is now off by default and needs to be enabled in xwiki.cfg * Added possibility to restrict the possible languages available on a given wiki * New Blog panel available that lists all blog categories * New footnote macro. In addition the Albatross skin has been modified to display automatically footnotes added with this macro. I've tested it on my side so here's my +1 for releasing it Thanks everyone for your help -Vincent

17 years, 7 months

Right approach for filtering

by Zeljko Trogrlic

Hi, For our department Wiki, I really needed automatic links for acronyms because we have a whole bunch for them. So, after couple of days playing with code and regular expressions I managed to create Radeox filter, which converts acronyms to links. My questions are: 1) Is that the right approach to do that or I should write plug-in? Can you write a plug-in that processes every page, or you have to call it explicitly? 2) What is the right place to attach it to rendering? I attached it to the end, just before link filter, but then I had to struggle with HTML. It will be probably easier to write something that processes pure Wiki or abstract syntax tree, but it seems to me that there is no such place in Wiki. If I do the processing immediately after page is loaded, macros are not evaluated yet, therefore text generated by macros can't be processed (I don't know is this a big deal, though). It seems to me that macros are generating HTML instead of Wiki, which is not very clean. On the other hand it will be hard to write event simple macros with formatted text (e.g. "warning") without generating HTML directly, or introducing some kind of style tags for Wiki markup. 3) Radeox status: What is your experienece with Radeox team? Is there anybody still working on the project? I found some some funny stuff in the source code, which I would like to fix. They "swallowed" exceptions in some places, so if you mis-configure filter, you will not why it doesn't work.

17 years, 7 months

XWiki and SVN as a backend

by Hamish Cunningham

Hi, I'm investigating what it would take to store (or duplicate) some of the data in XWiki's database in Subversion. Rationale: - A plain text version of wiki pages stored in SVN buys you: - off-line edit, merge, etc - access to the pages using other tools, editors and so on - replication options - versionning, branching etc, and version display via e.g. ViewCVS - insulation from database crashes, with easier incremental backup - a kind of poor-man's content management system - SVN is very robust, reliable, and has a mature Java interface (SVNKit) - if Tomcat crashes a static version of the site can still be served - I have a large static site that is managed in SVN (8 Gb in 40,000 files) which I want to migrate to a more dynamic system. This looks like a significant size job, but we have a fair amount of resources in my team, and possibly we might fund some of the work in the XWiki community if anyone is interested. I wonder if this type of idea has been discussed before, and if anyone has comments on the best way to go about the problem? It seems to me that trying to replace the database entirely with a file-based store is too much work and would lead to performance problems, but perhaps it would be possible to have a process which pushed changes from the database into an SVN working copy and vice versa? Where would be good places to start looking at the code from this point of view? I also need to include a JavaCC-based wiki-to-html parser that we have as an option, but I'm betting that's an easier task? Thanks, best, Hamish -- Prof. Hamish Cunningham Department of Computer Science University of Sheffield Regent Court 211 Portobello St. Sheffield S1 4DP United Kingdom http://www.dcs.shef.ac.uk/~hamish/

17 years, 7 months

Re: [xwiki-commits] r2503 - in xwiki/trunk/web/standard/src/main/webapp/skins: albatross dodo finch

by Vincent Massol

On Mar 25, 2007, at 10:22 AM, Marta Girdea wrote: > Author: marta_girdea > Date: 2007-03-25 10:22:52 +0200 (Sun, 25 Mar 2007) > New Revision: 2503 > > Modified: > xwiki/trunk/web/standard/src/main/webapp/skins/albatross/ > contentview.vm > xwiki/trunk/web/standard/src/main/webapp/skins/dodo/view.vm > xwiki/trunk/web/standard/src/main/webapp/skins/finch/contentview.vm > Log: > XWIKI-1006: Add new #footnote macro > Automatic call of #putFootnotes at the end of the page What is this new feature of footnotes at the bottom of pages in our skins? I think that ideally this new feature should have warranted a JIRA issue so that it could have appeared in the release notes and users know to expect this new feature (which some may have been awaiting for). Note that this is different than creating a new footnote macro. Am I missing something? :) Thanks -Vincent

17 years, 7 months

Jump to page:

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

2005

xwiki-devs