August 2013 - xwiki-devs@xwiki.org

[xwiki-devs] [ANN] XWiki Summer 2013 Hackathon
by Vincent Massol 27 Aug '13

27 Aug '13

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

3 11

[xwiki-devs] [VOTE] Integrate Workspaces by default in XWiki's default XAR
by Vincent Massol 27 Aug '13

27 Aug '13

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

12 46

[xwiki-devs] [Proposal] Add CLA for contributions + Foundation
by Vincent Massol 27 Aug '13

27 Aug '13

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

5 8

[xwiki-devs] Mindmap Sitemap extension
by Volker.Lapczynski 26 Aug '13

26 Aug '13

I tried the Mindmap Sitemap extension in 5.1/2 without luck. It is working in 5.x? It is possible to have a auto-update feature for the Sitemap to make a UpToDate-Sitemap- page? Thanks, Volker from Norway -- View this message in context: http://xwiki.475771.n2.nabble.com/Mindmap-Sitemap-extension-tp7586672.html Sent from the XWiki- Dev mailing list archive at Nabble.com.

2 1

[xwiki-devs] JavaScript dependency... git-module and maven?
by Paul Libbrecht 25 Aug '13

25 Aug '13

Hello fellow developers, At Curriki we are about to take over a new JS library for some assessment specific pages. The library is a GitHub repository which we would like to fork and include in Curriki's webapp. Our intent is to do the following but I would like to know if there is a danger of doing so or if it is indeed best practice. - we fork the GitHub repository - part of the adaptation includes creating a maven project; it would build a (partial) web-application - Curriki's web project depends on that webapp(-part) and thus includes the resources - so as to ensure that recipients of Curriki can also build with it, we make the repository a sub-module (somewhat equivalent to an svn:external) in Git and in maven Thanks in advance for your comments, hints as to possible advantages or dangers. Paul

2 1

[xwiki-devs] Improving the XWiki Development environment for traditional Java/JS Developers
by Ludovic Dubost 24 Aug '13

24 Aug '13

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

8 23

[xwiki-devs] [Reminder] BFD#32
by Marius Dumitru Florea 22 Aug '13

22 Aug '13

Hi everyone, Today is BFD 32. Our goal is to have more bugs closed than created for the past 1400 days! http://jira.xwiki.org/secure/Dashboard.jspa?selectPageId=10352 As of now we're 41 bugs behind! Let's close the gap! Here's the BFD#32 dashboard to follow the progress during the day: http://jira.xwiki.org/secure/Dashboard.jspa?selectPageId=11690 Thanks Marius

1 0

[xwiki-devs] XWiki5 and IE8 support
by Clemens Klein-Robbenhaar 20 Aug '13

20 Aug '13

I am wondering about the support for IE 8 in XWiki5.x There are a few layout bugs in XWiki5 (actually been there in XWiki4 as much as I can remember) that do not directly hamper functionality but simply look ugly, like: - scrollbars around the outer frame of the Editor - tabs for comments, etc at the bottom of the page are stacked on top of each other instead of displayed left to right I am thinking of patching things for my instance so they look better in IE8, and I am wondering if IE 8 is still officially supported, and if yes, if patches for such layout glitches are of any interest. Cheers, Clemens

4 8

[xwiki-devs] [vote] release XEclipse 2.0M1
by Ludovic Dubost 16 Aug '13

16 Aug '13

Hi, We've never released XEclipse 1.2 (it is stil RC1) and we never release XEclipse 2.0 which uses the REST api to connect to XWiki. Additionally to the REST work, a few bugs have been fixed and the following changes have been implemented: - syntax coloring refactoring to support more langues (xwiki syntax, velocity and groovy) - code folding implementation for xwiki macros and velocity - indentation for velocity (macro, foreach, if blocks) I propose to release this work as XEclipse 2.0M1 in order to have developers start using it and provide feedback. In the mean time it would be nice to wire the auto-completion feature (developped in 1.2 but outdates in terms of APIs) to the server auto-completion module implemented by Vincent and Edy. Here is my +1 for an immediate release Ludovic -- Ludovic Dubost Founder and CEO Blog: http://blog.ludovic.org/ XWiki: http://www.xwiki.com Skype: ldubost GTalk: ldubost

6 8

[xwiki-devs] [ANN] XWiki 5.2 Milestone 1 Released
by Marius Dumitru Florea 13 Aug '13

13 Aug '13

The XWiki development team is proud to announce the availability of XWiki 5.2 Milestone 1. This release brings a lot of bug fixes (63) and a few improvements (20), notably the ability to toggle email address obfuscation and a better-looking user profile menu. You can download it here: http://www.xwiki.org/xwiki/bin/view/Main/Download Make sure to review the release notes: http://www.xwiki.org/xwiki/bin/view/ReleaseNotes/ReleaseNotesXWiki52M1 Thanks -The XWiki dev team

1 0