xwiki-devs February 2012

xwiki-devs@xwiki.org

26 participants
58 discussions

[xwiki-devs] [VOTE] Component hint naming rule

by Sergiu Dumitriu

Hi devs, I noticed that we don't have a standard rule for naming component hints. So far we have: A) nestedscriptmacrovalidator -> concatenated word list B) extension.cluster -> dot separated word list C) CommentEventGeneratorListener -> CamelCase word list D) legacyEventDispatcher -> camelCase with lowercase first letter E) componentManagerBridge -> same, but getName returns the space separated version F) document-content-annotation-updater -> dash separated word list, but getName returns the CamelCase version G) register-macros-on-import -> same, but an active voice is used instead There are probably other versions as well, I just looked at EventListener implementations. So, which one should we use? Personally I'd vote for F) Second vote: For EventListeners, should the getName() always return the same thing as the component hint, or return a more user friendly description? If we're returning a different thing, then we could return a space separated description. -- Sergiu Dumitriu http://purl.org/net/sergiu/

12 years, 6 months

[xwiki-devs] How can I just use some modules?

by jinlong liu

If I build my project on Xwiki, I just want to use some of the modules , page editing ,for example . How can I do that ,Do I need to build all the source in Xwiki platform .

12 years, 6 months

[xwiki-devs] [Proposal] Roadmap for 4.0

by Vincent Massol

Hi devs, It's time to prepare the roadmap for 4.0. I know we haven't defined the Theme for 4.x yet but we've started the user survey at http://www.xwiki.org/xwiki/bin/view/Main/SurveyXWikiFeatures2012 and we need to wait a bit to get some relevant feedback. I'll get a summary of what we have so far in a few days. After having brainstormed with some of you here's what I have found so far below for 4.0 (Caleb, Denis, I haven't put your items below since I wasn't sure what you'd like to work on so please free to add them yourself in reply). If you have your name mentioned below please confirm that you can do it for 4.0 in the defined time frame. If you wish to do some other stuff please add them in reply. After a few days I'll move this on xwiki.org as our official roadmap for 4.0. Dates ===== - 4.0M1: 12 March 2012 - 4.0M2: 26 March 2012 - 4.0RC1: 9 April 2012 - 4.0 Final: 16 April 2012 Items ===== * App Within Minutes improvements - Assignee: Marius - Marius can you list specific items in some priority order? * Extension Manager improvements - Assignee: Thomas and Marius (UI) - Thomas can you list specific items in some priority order too? - One that I know of is improved XAR merging and a nice UI for it - One nice goal to have for 4.0 and 4.1 (I think we need 2 releases) is: "Be able to upgrade a XWiki Farm in 5 minutes". This is without the WAR upgrade, only the XAR part. This means upgrading the default XE and any installed extensions, for XE and for a farm. * Hidding Technical Content (especially on Home Page) - Assignee: Jean-Vincent and Vincent - My idea is to implement http://markmail.org/thread/jupn22fdk4nnqj6p but we need to brainstorm with JV and we'll send a proposal on the list soon about it * Getting Started Guide on XE/XEM Home page - Assignee: Jean-Vincent - JV to make a proposal to the list * LDAP Admin UI - Assignee: Jerome Velociter * Various Important JIRAs to fix: - Backend Stuff -- Page creation date should be the date of the installation - XWIKI-7058 -- Reduce the likelihood of having duplicate (hibernate) id for different documents and objects - XWIKI-6990 -- When using filesystem attachments with attachment versioning disabled, deleted attachments are duplicated on the hard disk. - XWIKI-6951 -- Deleted attachments duplication in recycle bin while File Storage is on - XWIKI-6917 -- Renaming a page should also rename the title of it - XWIKI-6743 -- Be able to rename a space from the UI - XWIKI-6722 -- Problems displaying the correct attachment version when using a proxy - XWIKI-6569 -- Performance of blog category panel is still not enough - XWIKI-6363 -- Change stylesheet and javascript extension filename when a modification is done on those - XWIKI-6073 -- Auto-create Space.WebHome when creating a page in an underfined space - XWIKI-5399 -- OpenOffice Issues on Windows (bug) Jira to be created - XWIKI-7510 -- OpenOffice automatic connection to external daemon - XWIKI-7509 - Frontend stuff -- Add more/all configuration parameters in the wiki administration - XWIKI-7066 -- Log-in automatically on registration - XWIKI-6892 -- Limit dragable width of textareas in FF4 and Chrome - XWIKI-6304 -- WebSearch should only display spaces with view right - XWIKI-6227 -- Auto-suggest doesn't work for global users - XWIKI-6207 -- Activity Stream doesn't show Image Profile change - XWIKI-5930 -- Cannot filter using "/" on a Date column in the livetable - XWIKI-5889 -- Better placement of the documentation link - XE-1031 -- New XWiki Syntax Guide - XE-880 -- Occasionally the livetable fails to load on index pages XE-844 -- Add option to 'show more entries' on displaying the Activity Stream XE-748 -- Timezone Setting by User - Jira to be created * Investigations: - Home Page Changes Proposals - Assignee: Caty and JV - Search Investigation (Improvements to current or SOLR) - Assignee: Need volunteer Thanks -Vincent

12 years, 6 months

[xwiki-devs] [Discussion] Merge Annotations with Comments

by Eduard Moraru

Hi devs, Based on the work done by Anca and Sorin doring the XWiki 2011 Seminar Hackaton, I`ve made the following pull request [1] to integrate their work with minor changes. A summary of the changes contained by the pull request are described in the jira issue [2]. The problem at the current stage, as Jerome also hinted, is that we need to do a migration script to make the existing annotations (in an upgrade scenario) use the XWikiComments class instead so that they can be picked up by commentsinline.vm. However, this might lose the possibility to provide custom annotations. An alternative would be to make commentsinline.vm use the annotation service and handle and retrieve both Annotation and XWikiComment objects. This way, the current annotations should need no migration script since they are using a class configured in the AnnotationConfig page that the annotation service knows how to handle. WDYT? Thanks, Eduard ---------- [1] https://github.com/xwiki/xwiki-platform/pull/34 [2] http://jira.xwiki.org/browse/XWIKI-7540

12 years, 6 months

[xwiki-devs] [VOTE] Add LDAP UI module in platform

by Jerome Velociter

Hi devs, I've worked on a LDAP administration UI (see http://jira.xwiki.org/browse/XWIKI-2551). It's an improved version of the admin UI that the LDAP admin tools (http://extensions.xwiki.org/xwiki/bin/view/Extension/LDAP+Tools) provides. Compared to the extension, it brings more descriptive labels for each field, and provides rich property editors for mappings (user field mapping and LDAP group mapping), fixing two weak points of the LDAP tools app (the form was too complex to fill in and field mapping format in a textarea not intuitive). You can see it in a branch on github : https://github.com/xwiki/xwiki-platform/compare/master...ldap-ui I would like to add the module in XWiki platform for 4.0. My +1 for it. Now another question is, should we bundle it by default ? Personally I think not. I think we should point to it in xwiki.cfg LDAP section and on xwiki.org documentation. The rationale is that only a small subset of users are interested by this UI, and for the other it is confusing. And now we have a good extension manager, adding this UI is just a couple of clicks away for those interested. Thanks -- Jérôme Velociter Winesquare http://www.winesquare.net/

12 years, 6 months

[xwiki-devs] XWiki Enterprise and XWiki Enterprise Manager 3.5 Released

by Marius Dumitru Florea

The XWiki development team is proud to announce the availability of XWiki Commons, XWiki Rendering, XWiki Platform, XWiki Enterprise and XWiki Enterprise Manager 3.5. This is a stabilization release that brings many improvements to the Extension Manager, a new macro for displaying documents in a live table and quite a few bug fixes. XWiki Enterprise 3.5 is the last major release of the 3.x development cycle (there will still be bugfix releases on the 3.5.x branch, if needed). The next major release is going to be 4.0. See the full release notes at http://www.xwiki.org/xwiki/bin/view/ReleaseNotes/ReleaseNotesXWikiEnterpris… for more details. Thanks -The XWiki dev team

12 years, 6 months

[xwiki-devs] help: How can I build my project on Xwiki?

by jinlong liu

I have read most of the document offered by thie Xwiki site,but I still don't know how to build my project .If I want to write my own projects completely ,what do I need at least? I am sorry that Englist is not my native language ,I hope I have deliver what I want to say to you . A suggest: Download the source is really difficult for a new comer,can we sugges a convient way ? BEST WISHES FOR YOU !

12 years, 6 months

[xwiki-devs] How to deploy XWiki to Jelastic cloud: step-by-step tutorial

by Marina Sprava

If you are a fan of XWiki, here is your chance to see how easy it is to use with Jelastic http://blog.jelastic.com/2012/02/21/how-to-deploy-xwiki-to-jelastic-cloud-s… -- *Marina Sprava* PR manager | *Jelastic* - *Rock-solid Java in the Cloud* | www.jelastic.com *Skype* marina_zt_j |*Twitter* <http://twitter.com/#!/Jelastic> | *Facebook*<http://www.facebook.com/Jelastic> | *YouTube* <http://www.youtube.com/user/JelasticCloud> | *LinkedIn <http://www.linkedin.com/company/hivext-technologies-inc-?goback=%2Efcs_GLHD…> *

12 years, 6 months

[xwiki-devs] [VOTE] Fork wikimodel source code into XWiki codebase

by Vincent Massol

Hi devs, I'd like to propose forking wikimodel (http://code.google.com/p/wikimodel/) and move its source code into our code base in XWiki Rendering as a separate module for now. Motivation ======== * Wikimodel has been inactive for years (since 2009). Actually that's not quite true, there's been one developer working on it regularly, it's Thomas Mortagne… * We heavily depend on wikimodel in the XWiki Rendering module (for our syntax parsers) which is a key module for XWiki * It's more difficult for us to contribute to the wikimodel project since it means: ** committing in a different project with different rules ** there's nobody doing releases on the wikimodel projet and we need the releases to be synced with our releases since otherwise we cannot release on a SNAPSHOT dependency ** there's no community there so it's not fun and doesn't help for quality control/reviews/etc ** since we push XWiki Commons and XWiki Rendering to Maven Central we also need the wikimodel releases to be pushed to Central which is not happening now * The wikimodel project has a different scope than our need. Mikhail (owner and admin of Wikiodel - not active since 2009 - some commits here and there) wanted it to remain only for wiki syntaxes. We added support for HTML parsing in it but Mikhail never liked it and wanted us to move it to XWiki. * We have some impedance mistmatch between the wikimodel model and the xwiki rendering model which causes us to do some circumvolution in the code which leads to issues still beeing open in our JIRA (they've been opened for a long time now) * We believe wikimodel would benefit from a larger and active community within the XWiki ecosystem. Wikimodel has been stagnating for years and we'd like it to live on and evolve. Action Plan ========= Thus Thomas and me are proposing to do the following: * Move the sources in a new rendering module as is and use it as a library (same as now except we rename the module name and release it under the XWiki umbrella). * Modify all header to put our LGPL headers everywhere * We keep the attribution as is recommended by the ASL (see http://www.apache.org/foundation/license-faq.html#Distribute-changes) by adding a comment to all sources explaining where the source come from and in which license it was and who authored the initial code and how XWiki committers have participated to the wikimodel project. We also put that information in the NOTICE file. * We modify the source code slowly over time to integrate it cleanly without our code and remove the hacks we had to do, and we bring improvements * We post a mail on the wikimodel mailing list explaining all this and inviting the current wikimodel committers to become committers on the xwiki rendering module (provided they agree to follow our dev rules). We also explain how contributors can contribute (link to jira, link to github for pull requests, etc) Related question (not part of the vote) ============================= * We could decide to move XWiki Commons and XWiki Rendering under the ASL since they're libraries and as libraries the ASL is the license that makes it the easier possible to use from all other licenses. Right now ASL code cannot use our Rendering module because we're LGPL. Here's my +1 to this plan. I'm also currently +1 to brainstorm about moving XWiki Commons and XWiki Rendering to the ASL. Thanks -Vincent

12 years, 6 months

[xwiki-devs] plugin xwiki

by modularre-333

Hi i'm new using a xwiki. I'm trying to make a plugin that allows me to create users on the wiki. but not where to start, I've read the documentation, but I can not connect anything. would appreciate your help. -- View this message in context: http://xwiki.475771.n2.nabble.com/plugin-xwiki-tp7285335p7285335.html Sent from the XWiki- Dev mailing list archive at Nabble.com.

12 years, 6 months

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

2005

xwiki-devs February 2012