xwiki-devs June 2012

xwiki-devs@xwiki.org

35 participants
107 discussions

[xwiki-devs] [VOTE] Add right related method to the wikimacro/oldcore bridge

by Thomas Mortagne

Hi devs, Despite what the documentation is saying anyone can register a wiki macro for the whole wiki so I'm about to fix it. See http://jira.xwiki.org/browse/XWIKI-7880. But to fix it properly IMO I need to add a right checking method to the wikimacro/oldcore own bridge. Right now the right check is a pile of hacks using various APIs (WikiModel for edit, DocumentAccessBridge for programming) and there is no way to test admin right in existing bridges and APIs anyway. Instead of adding more hacks to the current wiki macro right checking I find it better to move the check itself to its existing own model bridge and test it there using the rightservice directly. It also make more sense to have this check at the wiki macro model bridge level than the wiki macro component itself. This is a pretty hidden API that noone is supposed to use except the wiki macro and oldcore but since it's a public interface it makes CLIRR complains so according to our rule here is the vote for adding this new method. WDYT ? Here is my +1. Since the master is now on 4.2 branch I'm committing it right now. Will revert it if anyone gives a veto. -- Thomas Mortagne

12 years, 6 months

[xwiki-devs] [GSoC] [SOLR]: search and XWiki rights

by Paul Libbrecht

Dear Savitha, Dear XWiki community, that I know of, there's two major flaws in the current lucene plugin: - It stores and indexes everything which makes it a big memory eater. This will be fixed by Savitha using Solr's schema.xml and hopefully other admin-configurred classes. - Each of the search results' list has to be skimmed through so that the count only covers documents one has access to (this is done in SearchResults.java in getRelevantResults). This has the direct consequence that a search for all documents basically goes through all documents which is quite annoying. In general, the practice of going through many documents, one could say the practice of pre-processing the search-results' list, is a catastrophe. There are very many times when a user inputs a query that matches way too many documents. That means also that Savitha should avoid this skimming in her SOLR module and this needs some skills and probably some help: - the skills to understand completely the rights model. As far as I know it is based on XWikiRights objects in each document and can talk about users (a list of users) and groups. but this needs to be deeply observed and asked many times about. - the skills to map this model into something that is executable by Solr/Lucene queries. In Curriki or i2geo and in many other specific applications, this is much easier because the rights model is simpler (owner is defined, only three rights possible). But this has to be done in a generic way and might include the requirement to reindex a large part of documents if a user joins or leaves a group. I am thinking this can be implemented: include fields such as "prohibitedFor" "prohibitedForGroup", "allowedFor", "allowedForGroup" and use the current users' identity and groups when querying. I note that it is important to care for the user that requests the documents when indexing as well (which probably needs to be admin). Savitha, I think this is the hardest part of your project. Are you up to it? paul

12 years, 6 months

Re: [xwiki-devs] [GSoC] Responsive Skin

by Jonathan Solichin

Hello friends, So here is a clearer illustration of what I am aiming for: http://sdrv.ms/LO70JI The font being used in these design is Arial (with changes to make it more unique). I was wondering whether the community would like a more regular looking font, or a bolder and unique one? I would be glad to hear the community's feedback. I tried to bring into account all the comments, but let me know if I missed something. Thanks again, Jonathan Solichin p,s almost done with school (one week), will be able to push faster and better soon. Sorry about that!

12 years, 6 months

[xwiki-devs] [UX] [Iteration] Improve History Diff

by Ecaterina Moraru (Valica)

Hi, As you know Thomas and Marius are working on a Diff API and there are also some conflict resolution improvements for the Extension Manager [1]. Marius asked me to think about our current history diff and make some improvements suggestions based on their work. I've made a mockup with some ideas that could improve the History Diff UI http://incubator.myxwiki.org/xwiki/bin/view/Improvements/DiffHistory The UI is mostly based and inspired from GitHub. Let me know what you think. Thanks, Caty [1] http://www.xwiki.org/xwiki/bin/view/ReleaseNotes/ReleaseNotesXWikiEnterpris…

12 years, 6 months

[xwiki-devs] [VOTE] Merge feature-diff-display branch into commons master

by Marius Dumitru Florea

Hi devs, The feature-diff-display branch provides a new diff module, xwiki-commons-diff-display, with APIs to help displaying diffs. Currently it supports two diff formats: unified (GitHub style, suited for code) and inline (suited for free text). I'm using this module for the merge conflict resolution UI and for an improved document compare UI (when comparing two versions from a document history). I'd like to merge the branch ASAP, before 4.1RC1 is released. Here's my +1. Thanks, Marius

12 years, 6 months

[xwiki-devs] [WARNING] Release 2 days away, branching now, reply here if you need to commit to the release branch.

by Caleb James DeLisle

Hi, I'm going to be starting the stable-4.1.x please tell me if you need to commit against this branch I would like to know what's going to be committed into this branch so we can hopefully avoid the: "late commits - destabilize the build - delaying the release - allowing more late commits" cycle. Of course I also need to know if anyone needs to hold up the release. Thanks, Caleb

12 years, 6 months

[xwiki-devs] [Prooposal] Roadmap for XE 4.1

by Vincent Massol

Hi devs, Roadmap time again for 4.1. Here's a proposal below. If you're a committer/contributor and wish to propose doing something for 4.1 please reply to this thread to have a complete roadmap. For committers who have their names next to tasks below, please confirm you're ok to do that for 4.1. Dates ====== * Started since 16th of April * 4.1M1: 7th of May * 4.1M2: 28th of May * 4.1RC1: 11th of June * 4.1Final: 18th of June Release manager: Caleb, with help from Sergiu/Vincent Content ======= XWiki SAS has had an internal meeting to discuss what it would like to work on and here's the result as a proposal: Top level tasks: * Extension Manager (XEM compatibility, XAR merge UI, full XAR upgrade) - Thomas and Marius ** The goal is to be able to "upgrade a wiki farm in 5 minutes" for 4.1 final * Hidding Technical Content - Jean-Vincent * Important JIRA issues - Sergiu and anyone having some time, see below for the priority list Investigations: * Home Page Changes Proposals - Caty Misc: * GSOC mentoring - All mentors First priority JIRAs (no order): * Add the ability to auto-generate application entry names XWIKI-7374 * Properly display live table columns based on User-type class fields XWIKI-7372 * Be able to rename a space from the UI XWIKI-6722 Second priority JIRAs (no order): * Add Required and Hint meta properties for class fields XWiki-7373 * Generate and register a document bundle for the application XWIKI-7371 * Add document title and document content to the field palette (class editor) XWIKI--7369 * Use suggest input (custom display) for User and Group field types (class editor) XWIKI-7368 * Rename Application (through rename space) XWIKI-6722 * OpenOffice Issues on Windows (bug) XWIKI-7510 * Cannot filter using "/" on a Date column in the livetable XWIKI-5889 * Auto-create Space.WebHome when creating a page in an underfined space XWIKI-5399 * New XWiki Syntax Guide XE-880 * Occasionally the livetable fails to load on index pages XE-844 * tag suggest feature does not work if Main.WebHome is not saved with programming rights XE-539 * Fix XWiki Installer on Windows 7 XE-1051 * XWIKI-6073 Change stylesheet and javascript extension filename when a modification is done on those Unassigned Third priority (no order): * Add more/all configuration parameters in the wiki administration XWIKI-7066 * XWIKI-7510 XWiki is not able to automatically start OpenOffice daemon on Windows Server Unassigned * XWIKI-7509 XWiki automatically connect to an external openoffice daemon Unassigned * XWIKI-7058 Page creation date should be the date of the installation Unassigned * XWIKI-6951 When using filesystem attachments with attachment versioning disabled, deleted attachments are duplicated on the hard disk. CalebJamesDeLisle * XWIKI-6917 Deleted attachments duplication in recycle bin while File Storage is on CalebJamesDeLisle * XWIKI-6892 Log-in automatically on registration Unassigned * XWIKI-6569 Problems displaying the correct attachment version when using a proxy Unassigned * XWIKI-6363 Performance of blog category panel is still not enough Unassigned * XWIKI-6207 Auto-suggest doesn't work for global users Unassigned * XWIKI-5949 Better handling of different timezones for date properties Jean-Vincent Drean * XWIKI-5930 Activity Stream doesn't show Image Profile change Unassigned * XE-1031 Better placement of the documentation link Unassigned * XE-748 Add option to 'show more entries' on displaying the Activity Stream Unassigned WDYT? Thanks -Vincent

12 years, 6 months

[xwiki-devs] Questions concerning the development of XWiki, Final Round

by Martin Schönberger

Hello again, and let me start once more by thanking everyone who bore with me until now. The answers you gave me so far helped a great deal for me to understand the details of this project's development as an example of open source processes and their underlying structures. In the final round of this extended interview I would like to conclude with a few questions which move a bit outside the box and beyond the horizon. ;) As I explained in one of my earlier posts, I am researching open source development processes in comparison to other approaches of developing software, and trying to find out how they relate to each other in different aspects. Besides examining those aspects, however, I am also interested in your opinion about the process. Do you see similarities to agile methods of development, or to the well-defined processes of software engineering, in your approach? Where can these similarities be found, and where do they end? Finally, may I ask you for a quick outlook into the future of XWiki? Which chances and challenges do you see coming up? In what direction would you like the development of XWiki to go in the following years? Also, do you have any points you would like to additionally mention, some vital aspect of the process I failed to address, or a special emphasis on anything you feel we did not talk about enough? I am glad for further hints and comments. :) Best regards, Martin

12 years, 6 months

[xwiki-devs] Jetty tool maven reorganization

by Vincent Massol

Hi devs, Just some heads up to let you know I'm planning to reorganize the Jetty tool modules today as follows: xwiki-patform-tool-jetty/ |_ xwiki-patform-tool-jetty-listener/ --> JAR |_ xwiki-patform-tool-jetty-configuration/ --> JAR using Remote Resource Bundle plugin |_ xwiki-patform-tool-jetty-resources/ --> ZIP that includes the other 2 modules The goal of introducing xwiki-patform-tool-jetty-configuration is to be able to use the Maven Remote resource plugin to substitute the xwiki data dir value. Thanks -Vincent

12 years, 6 months

[xwiki-devs] [Proposal] XWiki's Permanent Directory Strategy for Installations

by Vincent Massol

Hi devs, Since I'm working on making XE work in Windows7 I've thought more about XWiki's install and configuration. Actually this is not a new topic, I remember starting a discussion about it a few years ago on the devs list but we didn't act on it so here it comes again ;) Rationale ======== The idea is to separate XWiki's binaries from its data. There are several reasons for wanting this: * Some OSes require this and don't allow writing in the binary directory. Windows 7 for example won't allow writing data in \Program Files. * It makes upgrading simpler since you don't need to fish for configuration data and copy them somewhere before unpacking a new distribution over. Or if you unpack in a new directory you don't need to copy the data from the old directory to the new one. * As a consequence of the previous point It allows easier auto upgrades of XE * It makes it simpler to know what to backup: all you need to back is the data directory. Proposal ======= This is the simplest I've found (I've imagine a lot of more complex options which offer other small possibilities but in the end I went for the simpler one for now). So here goes the process when starting up XE: * XE looks for a XWIKI_DATA environment variable and if found it uses it as its environment.permanentDirectory value * If not found, XE looks in the user home directory for an XWiki directory. Now the name of this directory is environment-dependent. On non windows systems it looks for ".xwiki" directory and on Windows systems it looks for a "XWiki" directory. * If not found, then XE stops and prints a message in the console explaining that it couldn't find the location of the XWiki Data dir with explanations on how to set it. The recommendation is thus that users set the XWIKI_DATA environment property. Notes: * At startup XE prints as an INFO log the location of the permanent dir it is using. * For the standalone distribution we would set the XWIKI_DATA env variable in the xwiki start file (start_xwiki.sh and start_xwiki.bat) to point to the data/ dir in the distribution. * One aspect that is not covered here yet (the topic for another email): the installer. I'll prepare another mail for that since it's independent for me. Use cases ========= This allows the following use cases: * Make it easy to upgrade XE * Make it easy to backup XE * MAke it easy to use an existing XE install but point it to a different configuration, for testing purposes for ex * Allow installing XE for all users on a system * Allow installing XE for my user only WDYT? Thanks -Vincent

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 June 2012