xwiki-devs December 2011

xwiki-devs@xwiki.org

24 participants
49 discussions

[xwiki-devs] [VOTE] Creation of xwiki-platform-uiextension module

by Vincent Massol

Hi devs, I'm implementing the LinkChecker UI and I want to be able to add a Tab in AllDocs. Right now I've coded it with a hardcoded #if but I really hate this. So here's my proposal: * Create the following modules: xwiki-platform-uiextension/ |_ xwiki-platform-uiextension-ui/ |_ xwiki-platform-uiextension-api/ where: * xwiki-platform-uiextension-ui/: contains XWiki.UIExtensionClass page * xwiki-platform-uiextension-api/: contains a ScriptService to get UIExtension data + contains an EventListener that refreshes the UI Extension Cache when an UIExtensionClass object is modified (this is for performance reasons) To start with I'm proposing to have the following fields for UIExtensionClass: * type: String, represents the type of the extension (for example for the AllDocs needs, I'll use a "IndexTab" type (or "AllDocsTab" type) * id: String, the technical name of the extension, which can be used for example as suffix for HTML class or ids. * name: String, the name of the extension, which can be used for displaying. For example for the AllDocs needs, it would be used as the name of the Tab * content: Textarea: the content of the extension. For example for the AllDocs needs, it would be used as the content to display when clicking on a tab I'd like to implement this ASAP and thus stop hardcoding UI Extensions from now on. Here's my +1 Thanks -Vincent PS: If you find a better than "uiextension" I'm all ears. A name without "extension" would be great to not confuse it with our Extensions (and with xwiki-platform-extension).

12 years, 8 months

[xwiki-devs] monitoring the cache: how to get the eviction rate?

by Paul Libbrecht

Hello developers, I have been doing a nifty little cache monitor on www.curriki.org which is still running xwiki 1.5.4. It can show the entries and capacity of the two xwiki caches, pageExistCache and the document cache which sound pretty central. Not surprisingly, they're both full on our production server. name entries capacity pageExistCache 10000 10000 cache 3000 3000 The caches are using OSCache (through "OSCacheCache"). I've been trying to get a real statistical count but there I kind of failed thus far. I can use the StatisticListenerImpl which gives fairly high numbers: > StatisticListenerImpl: Hit = 9583563 / 1320251374, stale hit = 0 / 538, miss = 8541 / 17175236, flush = 27348, entries (added, removed, updates) = 25457741, 0, 7678101 these numbers are integers, and might actually be too small for the 2billions limit of an int, they are static (so count "all the OSCache instances"). What I would like to get is the "eviction rate" but I do not know how to compute it. That is, I wish to read the number of cache-entries which are thrown away because the cache is full and others come in. Once I can have it, I can start tuning (cache size, less greedy algorithms, ...) and measure the effect of such tuning. We have plenty of RAM space to accommodate the cache but we should use this well. The big annoyance with this process is that it can only run on our production server. So thus far I did not dare register a CacheListener in groovy fearing it would suddenly be slow. Has anyone used a different strategy or tool? I'm happy to post my little monitor script. thanks in advance. paul

12 years, 9 months

[xwiki-devs] [VOTE] Naming rules for translation resource properties + deprecated properties

by Vincent Massol

Hi devs, I see that in ApplicationResources.properties we now have some wrongly named properties. For example for the scheduler I find properties of the type xe.scheduler.* but the scheduler is now in the platform. There are also resources named core.* Thus I'd like to propose a simple rule: <short top level projet name>.<short module name>.<propertyName> where: <short top level projet name> = top level projet name without the "xwiki-" prefix, for example: commons, rendering, platform, enterprise, manager, etc <short module name> = the name of the maven module without the <short top level project name> prefix, for example: oldcore, scheduler, activitystream, etc <propertyName> = the name of the property using camel case, ex: updateJobClassCommitComment For example the property core.importer.package.version would be renamed in platform.web.packageVersion The only issue is when we rename modules we need to rename the properties for that module but I don't see any way out of this if we want to have expressive property names. But at least it's an easy and mechanic change I also propose to introduce a different resource property file that will hold deprecated properties and that we can put in the xwiki-platform-legacy module. We could call it DeprecatedApplicationResources*.properties Of course in the future each module should be able to contribute both resource properties (but they would use the same naming scheme!). Even though this is not the topic of this mail this is how I'd implement this in the future: * Implement a TranslationPropertiesConfigurationSource that is initialized by reading all property files found in the classloader under META-INF/translations.properties and META-INF/translations-deprecated.properties. This component would listen to observation events so that when a new jar is installed by the extension manager it can check if it provides some translations and add them. * Have a Translation Manager component which is the main API to be used by other modules wishing to get translations. This manager would use the TranslationPropertiesConfigurationSource component. Here's my +1 Thanks -Vincent

12 years, 11 months

[xwiki-devs] About 3.2.1 release

by Guillaume Fenollar

Hi devs, I'm still waiting for xwiki 3.2.1 to be released, we have to use this version for some projects. Any news on that? Thanks, -- Guillaume Fenollar XWiki SysAdmin Tel : +33 (0)1.83.62.65.97

12 years, 11 months

[xwiki-devs] [VOTE] New {{display}} macro and changes to the {{include}} macro

by Vincent Massol

Hi devs, As you know in XE 3.0 we've changed the behavior for resolving local links/attachments when they're included using the {{include}} macro (they're now resolved against the included document instead of the including document). Now there might be some use cases (pretty rare IMO but they exist) where you'd want the links to be resolved against the including document. Here's a use case: you have a sheet document that references an image called image.png and you want that the including document provides it (like an Abstract in Java! ;)). So we've brainstormed with Thomas and here's our proposal: * Introduce a new {{display reference="…"/}} macro. This macro will *execute* the passed reference in its own context (it'll do what {{include context="new"…}} was doing before). It'll be located in the new display module. * Deprecate the "context" parameter of the {{include}} macro. The reason is that calling with context=new is not an include, it's a display. * Add a new "resolve" parameter for the {{include}} macro with possible values = "current" | "source", with a default value of "source". resolve=source means that the links/attachments are resolved against the source (ie the document being included). Using resolve=current means that you want the links/attachments resolved against the including document. Pros: * Clearly separate the 2 use cases: display and include * Make the include macro simple (a single "resolve" parameter) * Use the new display module as it should be and start the direction of having displayer macros for displaying all types of entities Note: In the future we'll also want to deprecate the "document" parameter of the include macro in favor of a more generic "reference" parameter, which will allow the macro to include other types of entities (such as an object property for ex). WDYT? Here's my +1 Thanks -Vincent

12 years, 12 months

[xwiki-devs] [VOTE] Release XWiki Syntax 2.1 as official in Rendering 3.4

by Vincent Massol

Hi devs, I'd like to propose releasing XWiki Syntax 2.1 as official (it's currently experimental) for XWiki Rendering 3.4. Rationale ======== * It has useful expanded support for links and images compared to 2.0 * It's been "experimental" for a long time and people are already using it * It would be nice to release it in the 3.x cycle since it was started in that cycle * That would allow us to start XWiki Syntax 2.2 for the 4.x cycle (see outstanding items at http://tinyurl.com/6pdt5oa ) Migration aspects ============== * I don't think we need to mandate moving to 2.1 for users. They can keep using 2.0 if they want * We should make it the default wiki syntax starting in XE 3.4, leaving 2.0 available by default * I believe there's no conversion issue between 2.0 and 2.1 so it shouldn't be an issue for users wanting to switch. * We could provide a migration script on extensions.xwiki.org for users wanting to convert all their 2.0 pages into 2.1 pages Here's my +1 Thanks -Vincent

13 years

[xwiki-devs] [VOTE] Improve the database migration implementation on 3.4

by Denis Gervalle

Hi Devs, In order to change the way we compute document ID to reduce the likelihood of a collision, I need to improve and secure our current data migration system. I have started this works late during 3.2, but it since this is an important refactoring, and after discussion on IRC, it have been decide to wait for 3.4 to commit it, so we have a full cycle to have it carefully test. So I would like your approval now to commit this work. The advantages of these changes are: - Ensure that the hibernate store could not be access without having it migrated in the appropriate version for the running platform - Ensure that the hibernate store is left untouched if the migration have not been allowed - Easy addition of migrations, since migrator are now components - Schema and datamigration are done only once and together - One more step in the isolation of the store from XWiki - Secure enough to allow converting document IDs The impact on API and users are: - deprecate xwiki.store.hibernate.updateschema which is enable by default - xwiki.store.migration.databases=all by default (in place of xwiki) since this is the general UC - XWikiMigrationInterface and XWikiMigratorInterface are removed and new component roles DataMigrationManager and DataMigration should be used instead These improvements consist in: - Replace Migrators by DataMigration components - Replace the MigrationManager by a DataMigrationManager component - Put a "hibernate" hint on hibernate stores (in place of default) to allow the hibernate migrator to access a correctly typed store - inject and call the HibernateDataMigrationManager from the stores (and not from XWiki) - Convert data migration like action done during schema update (yes we have some sql updates during schema update) into a LegacyDataMigration producing data version 1 from data version 0 - Join together schema update and data migration on a unique place (schema update were currently done in several places in XWiki and the store) - XWIKI-1859: Do not start migrations on a clean installation of XWiki - XWIKI-2075: Move all databases upgrades and schema updates to XWiki's initialization instead of doing it lazily (partial fix, since it is still hard to have the store initialized has needed) - data migration is moved to the first access to a store (which is still during first request, but the matter is no more here) - XWIKI-2066: Migrator fails to upgrade sub wiki databases, now properly fixed (previous fix was a hack that do not) - no more excessive synchronization required for schema update, but there is still some mandatory document added lazily - clear reporting of access error when migration does not succeed For more, read http://markmail.org/thread/l3dzx7pj32n5qlqd Here is my +1 -- Denis Gervalle SOFTEC sa - CEO eGuilde sarl - CTO

13 years

[xwiki-devs] [Proposal] Roadmap for XE 3.4

by Vincent Massol

Hi devs and everyone, Here's a proposal for the XE 3.4 roadmap. The idea is to have a short release focused on stabilization and polishing exclusively. This is meant to be the first of 2 stabilization releases (with XE 3.5). Reminder: XE 3.5 is the last release of the 3.x cycle and after it's released we'll start the 4.x cycle. Dates: ===== 3.4M1: 19 December 3.4RC1: 26 December 3.4Final: 5 January (not putting 2 january since it's just after new eve and people might be a bit tired and not in the mood of releasing ;)) Plan for 3.5: 3.5RC1: 23 January 3.5Final: 30 January Must have: ========= * Finish UI for extension manager - Sergiu - more polishing (js, etc) - support for XAR merges and conflicts - whatever is missing (I'm not sure about its exact status - Sergiu, could you give us a precise status of what's missing?) * Fix bugs and continue improving Extension Manager backend and the XWiki Repository application (XR) - Thomas - Thomas, can you list important stuff to do here? * Finish App with Minutes - Marius - Polishing - New auto title/page name feature - Maris, can you list other things that we need to finish in 3.4? * LDAP Admin UI - Jerome Nice to have: =========== Backend: * LDAP group sync need to test group membership before adding user to group XWIKI-7063 Unassigned * Page creation date should be the date of the installation XWIKI-7058 Unassigned * Accessing a store that is not migrated to the lastest data version should not be allowed XWIKI-7006 Denis Gervalle * Reduce the likelihood of having same (hibernate) document id for different documents XWIKI-6990 Denis Gervalle * When using filesystem attachments with attachment versioning disabled, deleted attachments are duplicated on the hard disk. XWIKI-6951 CalebJamesDeLisle * Deleted attachments duplication in recycle bin while File Storage is on XWIKI-6917 CalebJamesDeLisle * Renaming a page should also rename the title of it XWIKI-6743 Unassigned * Be able to rename a space from the UI XWIKI-6722 Unassigned * Be able to delete a space from the UI XWIKI-6687 Marius Dumitru Florea * Use a predefined Space Template like Dashboard, Livetable when creating a new space XWIKI-6684 Unassigned * Problems displaying the correct attachment version when using a proxy XWIKI-6569 Unassigned * Performance of blog category panel is still not enough XWIKI-6363 Unassigned * Change stylesheet and javascript extension filename when a modification is done on those XWIKI-6073 Unassigned * Auto-create Space.WebHome when creating a page in an underfined space XWIKI-5399 Unassigned Front end: * Add more/all configuration parameters in the wiki administration XWIKI-7066 Unassigned * Unable to add users to a group on IE9 XWIKI-7061 Unassigned * When editing a User Profile category, after saving the changes, preserve the category tab XWIKI-7059 Unassigned * Strange behaviour when pressing back and forward on a page that has 2 WYSIWYG editors displayed XWIKI-7028 Marius Dumitru Florea * Log-in automatically on registration XWIKI-6892 Unassigned * Tree from document index does not expand on IE9 XWIKI-6752 Marius Dumitru Florea * Have an auto-complete for the User and Group visibility inputs for the Message Stream XWIKI-6728 Unassigned * Limit dragable width of textareas in FF4 and Chrome XWIKI-6304 Unassigned * WebSearch should only display spaces with view right XWIKI-6227 Unassigned * Auto-suggest doesn't work for global users XWIKI-6207 Unassigned * New floating action menu hides titles in the content of the page when jumping to an anchor XWIKI-6018 Unassigned * Activity Stream doesn't show Image Profile change XWIKI-5930 Unassigned * Cannot filter using "/" on a Date column in the livetable XWIKI-5889 Unassigned * Better placement of the documentation link XE-1031 Unassigned * Cannot access the object editor for documents with XWikiRights objects on wikis with many users XE-1015 Unassigned * New XWiki Syntax Guide XE-880 Unassigned * Occasionally the livetable fails to load on index pages XE-844 Unassigned * Add option to 'show more entries' on displaying the Activity Stream XE-748 Unassigned Please review the items where your name is indicated to make sure you're planning to implement them! Of course if there are some other items that you're planning to do, make sure to add them to the list. WDYT? Thanks -Vincent

13 years

[xwiki-devs] First alpha version of the GitHub App

by Ludovic Dubost

Hi devs, As we have moved to GitHub, I've started coding an equivalent of the SVNApp (http://extensions.xwiki.org/xwiki/bin/view/Extension/SVN+Application) for GitHub, which should ease up commiting pages from XWiki to GitHub, and because the GitHub SVN bridge is unfortunately not compatible with SVNKit. The bad news is that it's not a GitApp which seems very difficult to do as it relies on a local clone of the repository which is quite overkill when in an XWiki. The good news is that thanks to the GitHub API and a java wrapper from Eclipse, it seems fully possible to have the same functionnality as the SVNApp. I've made some good progress, as I've been able to check a repository against the Wiki AND I've been able to commit non existant files in an existing repository. The life proof is the commit of the GitHubApp itself which was done with GitHubApp: https://github.com/ldubost/application-githubapp/tree/master/src/main/resou… It's still a prototype as there is a lot of work left. For now every file is commited separately and I've not yet tested updating and other complexities, especially as the GitHub api is not that easy to work with (many times I had no errors but my updates were not showing up. Ludovic -- Ludovic Dubost Founder and CEO Blog: http://blog.ludovic.org/ XWiki: http://www.xwiki.com Skype: ldubost GTalk: ldubost

13 years

[xwiki-devs] [Proposal] Move Selenium2 platform PageObjects to platform

by Vincent Massol

Hi devs, I'd like to move Selenium2 PO classes for platform in xwiki-platform. The rationale is that: 1) it belongs to platform 2) it allows us to write functional tests in platform More precisely here's what I propose: * Move current unit test fwk currently in xwiki-platform-test to xwiki-platform-test-unit * Add a new xwiki-platform-test-functional module and move the PO objects + functional test classes in it FTM (in some future we'll move POs for a given module in that module but we're not quite there yet) I'm starting to work on this in few minutes so please let me know ASAP what you think. Thanks -Vincent

13 years

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

2005

xwiki-devs December 2011