May 2012 - xwiki-devs@xwiki.org

[xwiki-devs] [GSoc] XDroid Platform
by sasinda rukshan 06 Jun '12

06 Jun '12

Hi all, I am starting this thread for my XWiki Android Platform Project. Please check whether following are OK. [1] INFO I tried to start my new modules with the de.akquinet.android.archetypes: android-quickstart:1.0.8. (added eclipse plugins m2e, m2e-android[a.k.a *Android Configurator* ]). But this seems buggy in eclipse. Any way the earlier project has not followed the above archtype either. So I am going to write pom.xml manually for my each module. [2] ADVICE NEEDED xwiki-rest-model module contains 2 submodules |-- xwiki-rest-model-gson ( gson should be corrected to json) |-- xwiki-rest-model-simplexml I think the xwiki-rest-model-gson is redundant. The classes in xwiki-rest-model-simplexml is added with simple xml annotations, otherwise both modules have same classes. There is no problem with the added annotations for using the same model objects for Json REST web services. And I intend to add my JPA (ORMLite library for persistence) annotations on top of it. Shall I re-factor them to a single module xwiki-rest-model. [3] INFO I had to change some pom.xml s. As the current project at: https://github.com/xwiki-contrib/android-client.git does not build. Error with parent pom.xml coordinates. Thank you Best Regards. Sasinda Rukshan

4 10

[xwiki-devs] Choosing the default component implementation [take 2]
by Sergiu Dumitriu 06 Jun '12

06 Jun '12

Hi devs, Hmm, time flies, I realized that it's been a month and a half since I started this thread, but didn't get to counter-argument so far. Because I wanted to give more compelling reasons after I wrote the initial draft of the original proposal, I got slammed with counter arguments centering mostly on why our current implementation already allows to work around the technical difficulties that I presented, although those technical difficulties were just extra arguments that weren't actually that important. Let's start from scratch. I believe that using "default" as a component hint is in most cases wrong, since it doesn't actually say anything about the particular implementation. Let's take some examples: EntityReferenceSerializer, with its many implementations: - "compact", which creates compact representations that don't repeat the parts that are the same as the current document - "compactwiki" that only skips the wiki part when not needed - "path" which creates references usable as a path on the filesystem or in URLs - "uid" which creates non-ambiguous representations - and "default", which does a... default representation... whatever that means... So, while the meaning of the other hints can be guessed from their name, that's not true for "default". WikiModel, with its only implementation, XWikiWikiModel, labeled as "default". First, this "default" is defined in xwiki-platform instead of xwiki-rendering, like the components that actually use that component, which means that we're defining a component interface without any implementation in our "standalone rendering engine", and thus we're using "exceptions as normal decision code" which is wrong. Second, this "default" actually means "xwiki default". Why can't the hint be "xwiki" instead of "default", since that what that implementation is actually doing: "this is the model used in XWiki", and not "this is the default model that most wiki engines use". When looking up an instance of the WikiModel component, we don't request "the default wiki model", but "the wiki model currently in use, whichever that is". ConfigurationSource and its implementations: - "space" which looks into space preferences - "wiki" which looks into wiki preferences - "user" which looks at user preferences - "xwikiproperties" which looks in xwiki.properties - "all" which looks into all the above - "void" which is always empty - "memory" which stores settings explicitly set by code - and "default" which does... stuff... let me get back at you after I look into its code to check what it actually does. XHTMLLinkTypeRenderer is an example where "default" does make sense, since we have special treatment for "doc"ument, "attach"ment, "mailto", "unc", "interwiki", and then there's a "default" that handles all the others, like "url" and "path". I was writing a component called UploadedFileManager, which is supposed to parse uploaded files from a request, and the implementation for it was called CommonsFileUploadManager, since it used the Apache commons-fileupload library for the actual request parsing. I don't think that calling it "default" is appropriate, since in the 3.0 servlet specification the upload behavior is embedded in the specification, in the ServletRequest interface, and that seems more "default" than using a particular library to do the job. A more appropriate hint is "commons", since that's what it actually does: "this implementation handles file uploads by using the apache commons library that does that", and not "this implementation handles file upload in the default way, which everyone should know what it actually is". So, I strongly feel that what the component manager returns when looking up a component without a hint shouldn't be the implementation labeled "default", but one of the existing implementations, as configured somehow. I'm not yet sure how that configuration takes place, that would be the subject of another discussion, but I'd like to get a consensus on whether we need this change or not. -- Sergiu Dumitriu http://purl.org/net/sergiu/

4 6

[xwiki-devs] [GSoC] [SOLR]: search and XWiki rights
by Paul Libbrecht 05 Jun '12

05 Jun '12

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

2 3

Re: [xwiki-devs] [GSoC] Responsive Skin
by Jonathan Solichin 05 Jun '12

05 Jun '12

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!

3 2

[xwiki-devs] [Prooposal] Roadmap for XE 4.1
by Vincent Massol 04 Jun '12

04 Jun '12

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

11 16

[xwiki-devs] Questions concerning the development of XWiki, Final Round
by Martin Schönberger 04 Jun '12

04 Jun '12

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

2 3

[xwiki-devs] [Proposal] XWiki's Permanent Directory Strategy for Installations
by Vincent Massol 04 Jun '12

04 Jun '12

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

6 13

[xwiki-devs] context.language having wild values?
by Paul Libbrecht 03 Jun '12

03 Jun '12

Hello developers, We had some (rare) users that had a very bad issue because we told their browser to load the lang_xx.js of their language. And their language was... wild! See: http://jira.xwiki.org/browse/CURRIKI-5694 for a sample of the things that got submitted to us. Sure, we'll now protect against these bizarre languages, still, there might be other things broken. Is there some guarantee on the set of possible languages provided by $context.language? I was expect the possible values of ISO-623-1 but that was clearly not sufficient! paul

3 4

[xwiki-devs] [VOTE] Remove the notion of sending messages from the activity macro
by Eduard Moraru 02 Jun '12

02 Jun '12

Hi devs, We have recently extracted the functionality of sending messages from the activity macro into a new messageSender macro [1][2]. However, for backwards compatibility reasons, the activity macro still uses by default (unless the parameter messageSender='false' is specified) the messageSender macro so the users still see the ability to send messages as a feature of the activity macro. The proposal is that, for 4.1, we follow the original jira [2] issue idea (as seen in the issue's images) and: - Completely remove the messageSender macro call from activity macro (including the recently introduced messageSender=true/false parameter) - Providing instead a "Send Message" gadget for the main Dashboard that will use the new messageSender macro This way we have 2 clear macros, no more mixing: - messageSender for sending messages - activity for displaying messages (and other events) Additionally, it makes it easier for users to remove the ability to send messages from the homepage by editing the Dahsboard and removing the "Send Message" gadget. Here's my +1. Thanks, Eduard ---------- [1] http://xwiki.markmail.org/thread/mxpkpqfplbznfgbd [2] http://jira.xwiki.org/browse/XWIKI-7679

7 7

[xwiki-devs] Expand our support strategy to include a longer support period for the end of each cycle
by Sergiu Dumitriu 31 May '12

31 May '12

Hi devs, Given that each development cycle usually starts with bigger changes and ends with a couple of stabilization releases, IMHO it makes sense to keep the last branch of a cycle maintained for a while longer. Our current strategy is to only support two branches at a time, the one being developed, and the one before it. This means that as soon as [N].0 is released, [N-1].5.x is dropped. However, the [N-1].5.x branch is much more stable and polished than the fresh new start of the cycle, so more people would be interested in using that stable version, especially in enterprise situations. Thus, I propose to amend our support rule to keep the end-of-cycle branch active for, let's say, 6 months. Still, this means only that we backport major or critical issues, which would improve the stability of that branch, without any new features. -- Sergiu Dumitriu http://purl.org/net/sergiu/

8 12