xwiki-devs July 2013

xwiki-devs@xwiki.org

26 participants
54 discussions

[xwiki-devs] [Proposal] Finding how many active instances of XWiki there are out there

by Vincent Massol

Hi devs, I think it would be great to have some indication of how many active instances of XWiki are out there in the wild. The idea is not so much to know the figure but to see how this figures evolves and thus to see if we're doing things right. It will also give us information about how quickly or slowly our user base upgrades from version to version. Here's my proposal: * When installing XWiki on a clean DB (ie first time install) generate a unique id and store it in the DB (similar to the version we're storing in the DB but using some UUID). Thus when an install is upgraded the same id is preserved. * When the Extension Manager is used and thus connects to extensions.xwiki.org (default extension repository), this unique ID is sent too. * In addition the version of XE is sent too * On extensions.xwiki.org side, we only log the unique ID/XE version **without** logging the IP or any other information thus ensuring that the ID remains completely anonymous * We display a counter on xwiki.org about the # of active instances of XE with a graph about XE versions used WDYT? Thanks -Vincent

11 years, 3 months

[xwiki-devs] [ANN] XWiki Summer 2013 Hackathon

by Vincent Massol

Hi devs and community at large, Every year XWiki SAS (http://xwiki.com) gathers all its employees for a Seminar and every year we have an internal hackathon. For example here are the results of last year: - 2012: http://www.xwiki.com/lang/en/Company/Hackathon2012 - 2011: http://www.xwiki.com/xwiki/bin/view/Company/Hackathon2011 This year the Hackathon will run for 10 days! Thus we thought it could be a good idea to invite the XWiki Community to join us for a mega distributed Hackathon! So here's how I think we could organize it: * Start date: 17th of July. A mail will be posted on this day to announce the start * End date: 25th of July. A mail will be posted on this day to announce the end * Gathering results: from 29 to 6th of August. Everyone who participated should reply to the end of hackathon mail with what they did and post their stuff on http://extensions.xwiki.org or elsewhere * On around the 6th of August we'll have a blog post written on xwiki.org summarizing all that was done by everyone Those who have participated will also get XWiki T-Shirts. Anyone interested in joining the fun? Thanks -Vincent with my XWiki SAS employee hat

11 years, 3 months

[xwiki-devs] [VOTE] Integrate Workspaces by default in XWiki's default XAR

by Vincent Massol

Hi devs, In the Roadmap proposal I've sent for XWiki 5.2 some days ago, there's this time: " * Have Workspace by default in XE + improved home page - Caty + Guillaume Delhumeau. FTR Guillaume is not a committer yet but he's going to work full time on XWiki development and especially on UI aspects from now on. Welcome aboard Guillaume, we need you! :) " Denis told me he didn't know about the proposal of having Workspaces integrated in the default XAR. Thus I'm sending this email to ensure we all agree about this. The rationale is: * It would be nice that when our users download XWiki (standalone version or install the default XAR) they get to see the power of XWiki. One of the very important differentiator of XWiki vs other wikis/solutions is our multi-tenancy feature and most of people downloading and installing XWiki don't see it. * XEM/Wiki Manager are lacking polishing because the committers mostly polish the default which doesn't include those. The UIs of XEM/Wiki Manager need polishing. Having them in default will ensure that we take them into account and make them first class citizens when we develop. Caty started working on the home page/UI improvements required to integrate this by default: http://incubator.myxwiki.org/xwiki/bin/view/Improvements/MultiWiki Here's my +1 Thanks -Vincent

11 years, 3 months

[xwiki-devs] [Proposal] Add CLA for contributions + Foundation

by Vincent Massol

Hi devs, I'd like to propose the following: * That we start asking for a CLA for contributions (and also for current committers) * That we keep the process lightweight in order to not make it harder to contribute to the xwiki project. For this I propose to use http://www.clahub.com/ In order to understand why we need a CLA read: * http://www.oss-watch.ac.uk/resources/cla * http://en.wikipedia.org/wiki/Contributor_License_Agreement If we agree we then need to define our CLA. I think a good starting point could be the Node.js one: http://nodejs.org/cla.html Now I don't think the CLA will have any legal value if we cannot define "the XWiki project" as a legal entity. Thus I believe we need to start by joining some foundation or creating one. I'll list some easy possibilities: * SF Conservancy: http://sfconservancy.org/members/current/ * SPI: http://www.spi-inc.org/projects/ * Create our own Not for profit association Harder possibilities (need to change license, rename project, etc): * Join ASF * Join Eclipse (and be forced to use bugzilla as the issue tracker ;)) We also need to check if OW2 could offer that service of being a legal entity for XWiki. Personally I'm tempted more by our own association (it's quite easy to create one if we don't need to accept money and a bit more complex if we want to accept money but still doable). My second choice goes to SFC. WDYT? Thanks -Vincent

11 years, 3 months

[xwiki-devs] Improving the XWiki Development environment for traditional Java/JS Developers

by Ludovic Dubost

While XWiki has many great advantages as a framework which takes car of persistence, forms, user management, content management and provides tons of APIs, when traditional developers want to extend XWiki there are facing a few difficulties: - they are lost in the myriad of XWiki APIs, and there is no completion - they don't get good visibility of the code available in their application - it is complicated to use editors which have syntax highlighting - they cannot use their favorite IDE On the framework side there are also some improvements which could make XWiki even more killer: - easier integration of advanced JS framework - advanced integration of a high level JS framework that has templating (maybe angular js) - better validation functions - easier way to add REST APIs - more XWiki and better documented javascript apis Here are some proposals to help fix the tools issues. Three approaches can be looked at: 1/ Live Sync between an XWiki Instance and and improved maven xar file structure, allowing to use any local IDE on XWiki code First it should be possible to use any IDE on the maven xar file structure, allowing to open the content and textarea fields of all XML files. For this XWiki XML files should externalize the content and textarea fields in separate files with extensions based on their content type. The maven xar format should be able to clean the maven structure to do this splitting and should also be able to build the XAR from all the files. Finally a program should allow to do a live sync between a local or remote wiki instance and the maven project. Any change in either the wiki or the file system should be replicated to the other party. So if you run "git pull" then your local or remote wiki would be updated. If a change is made in the wiki, the change would show up in the file system and your IDE would refresh it. The sync program would keep a state of the version in the wiki, in order to be able to merge changes if changes occur in both places between two sync. This tool could be easily launched with "mvn xar:sync" Syntax highlighting for XWiki Syntax+Velocity+Groovy would be developped for the most popular editors. When syncing the tool could show syntax checking error messages. 2/ Integration with Eclipse Based on XEclipse, we would build an Eclipse plugin to be able to connect to an XWiki instance and load a specified list of spaces. Then each space would be organized by the type of code in this space. Content and Textarea fields would be made visible as editable content in Eclipse. The plugin should detect the type of code in each of the content or textarea fields (velocity/html, groovy, javascript, css, translations, xwiki syntax) and use the appropriate editor. Finally a completion module could be provided by loading from the server a list of available APIs. The same plugin could also be able to organize the content from a local maven project (based on 1/) and provide completion to such a project. Live syntax checking could be provided. 3/ Integration of a WebIDE in XWiki Based on Javascript WebIDE and web code editor softwares (Orion, Cloud9, exoIDE, codemirror, etc..), we would provide a view on the code inside the XWiki instance. Code would be organized in the same way as in the Eclipse plugin and appropriate editors would be used depending on the code type. Completion could be provided in the velocity and groovy editors and eventually in Javascript Two views should be available, one for each AWM application, and one with all the code in the Wiki. Live syntax checking could be provided. Solution 1/ is very powerful because it let's the user decide which is his development environment, even if the tree structure won't be perfect. Still he can see all the code in the wiki and work on it, including searching. Committing is made very easy. There are some risks involved in the sync process, particularly of you have multiple developers syncing local code with the same dev server. User can switch from local sync (local wiki) to remove sync (remove shared wiki) and can therefore work offline more easily. Editing can be fully done offline. Providing syntax highlighting for many editors might prove difficult. Solution 2/ is providing a nice XWiki environment inside Eclipse, without the need for a local copy of the code. Committing would happen using the browser. Solution 3/ is the long term bet as the future is to have everything in the web. Content is only in one place which makes things a little easier. Development environment needs no setup. However this is more "new" for developers which need to adopt the platform. Live syntax checking is hard to provide but would be quite useful. Alternatively mvn xar:format could also provide syntax checking for XWiki syntax, velocity, groovy, js and css. WDYT ? Which approaches do you believe would be the most promising. Ludovic -- Ludovic Dubost Founder and CEO Blog: http://blog.ludovic.org/ XWiki: http://www.xwiki.com Skype: ldubost GTalk: ldubost

11 years, 3 months

[xwiki-devs] Bug with global user profile in sub wiki and support for empty servlet path

by Christian Meunier

Hi All, I sent 2 emails to the users list without much success and I am hoping that I might find a more suitable audience for my somewhat technical issues with the devs. 1) Global users in sub wiki. In the system I am trying to setup, all the users are created using a custom auth module in the main wiki (Global users), so there will be no local users. The issue is that on a sub wiki, when you click on a user to bring up its profile, you end up on a document not found. From the auth module, the principal returned is prefixed with the 'XWiki.' so the system should be able to differentiate between local and global users and act accordingly. I checked that I could reproduce the issue even if i am not using any custom authentication. Should i log this as a bug in Jira ? 2) Empty servlet path support The second thing I am struggling with is shortening the urls. I am following this guide: > http://platform.xwiki.org/xwiki/bin/view/Main/ShortURLs But no matter what I try, I cannot make it work without the '/bin/ prefix. Please note that the xwiki is running under Jetty as the main context (mapped as '/') so the url I have is: server.com/WebHome which according to the short urls document should work. it appears that the issue comes from StandardXWikiURLFactory: -------------------- String type = extendedURL.getSegments().get(0); if (type.equals("bin") || type.equals(this.configuration.getWikiPathPrefix())) { xwikiURL = this.entityURLFactory.createURL(extendedURL, parameters); } else { throw new UnsupportedURLException(String.format("URL type [%s] are not yet supported!", type)); } ---------------- So basically for server.com/WebHome, what is happening is that type above equals to "WebHome" and so the condition obviously fails and throws the UnsupportedURLException. Given the above code, I am either forgetting something in the xwiki.cfg or it simply cannot work out of the box... If i were to provide my own custom XWikiUrlFactory, would it solve entirely the issue or some other parts of the system will nevertheless fails because they have the same assumption regarding the presence of the bin or the PathPrefix in the url ? Thanks in advance for your help ! -- Chris

11 years, 4 months

[xwiki-devs] [Proposal] Who has the right to create a new subwiki/workspace ?

by Guillaume "Louis-Marie" Delhumeau

Since we are integrating Workspaces to XE, I propose to add a new parameter to set who has the right to create a new subwiki. -------------- Proposal A: -------------- We had a new item in the administration menu. This item is used to know what level of right is needed to create a new wiki. Examples: * any user who have the 'edit' rights on the main wiki also has the right to create new wikis * any user who have the 'admin' rights on the main wiki also has the right to create new wikis -------------- Proposal B: -------------- We create a new right (since we can thanks to Denis) called "SubWiki creation right", and this right is needed to create a new subwiki. Then we can add it to XWikiAllGroup or XWikiAdminGroup. -------------- Proposal C: -------------- We create a new group called 'XWikiAllowSubWikiCreationGroup', and everybody who is on this group can create new wikis. ---- WDYT? Thanks, Louis-Marie

11 years, 4 months

[xwiki-devs] [Proposal] Add new API to ModelConfiguration to get the default syntax

by Vincent Massol

Hi, I'd like to add: public interface ModelConfiguration { … Syntax getDefaultSyntax(); } And the configuration key would be: model.defaultSyntax=xwiki/2.1 This also means deprecating CoreConfiguration.getDefaultDocumentSyntax() in oldcore The goal is to have a clean way for getting the default syntax for documents for example without having to use oldcore. I need this to fix http://jira.xwiki.org/browse/XWIKI-9074 for example. WDYT? Thanks -Vincent

11 years, 4 months

[xwiki-devs] custom struts action rights

by jordiduran

Dear community, I developed a custom action called 'exporttandem', it works well and performs (Java component) a new kind of format export. But this action is allowed by registered users only. Is there any way to open to the rest of users, including unregistered users? Thanks, Jordi Duran -- View this message in context: http://xwiki.475771.n2.nabble.com/custom-struts-action-rights-tp7586458.html Sent from the XWiki- Dev mailing list archive at Nabble.com.

11 years, 4 months

[xwiki-devs] [VOTE] Relax checkstyle rule about javadoc on non-public class members.

by Caleb James DeLisle

Hi, To promote contribution and encourage code brevity, I would like to remove the rule that we fail the build over a missing javadoc on a non-public field. It's important to understand, this is *not* about encouraging developers to skimp on documentation! There are obvious cases such as 'logger' where the role of the field is blatantly clear and forced documentation is at best useless and at worst counterproductive because it creates an information overload for the code reader and hides the comments which the author really wanted to be seen. +1 for dropping this rule Thanks, Caleb

11 years, 4 months

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

2005

xwiki-devs July 2013