September 2013 - xwiki-devs@xwiki.org

[xwiki-devs] [VOTE] Remove all duplicated information from folders names on git repositories
by Thomas Mortagne 20 Mar '14

20 Mar '14

Reviving http://markmail.org/message/hlnqke3igkbec332 for as an official vote. We have waited way too long and I think we really need to find a solution even if none of the committers use Windows since a long time. Every time a Windows dev even think of contributing he is very quickly discouraged... As a reminder the issue is that working on XWiki source code is a pain for MS Windows developers because of the (impossible to understand I agree) limitation on path size. So the idea is to find a new logical rule to drastically shorten our paths and Sergiu proposed the following: remove duplicated information from our paths to maven modules. Here is an example: xwiki-platform-core/xwiki-platform-rendering/xwiki-platform-rendering-transformations/xwiki-platform-rendering-transformation-macro (131 chars) would become core/rendering/transformations/macro (36 chars) So WDYT ? Here is my +1 I also find it nicer when navigating using cd and tab in a unix shell anyway. Planning to do it in 5.1 if everyone agree. -- Thomas Mortagne

9 34

[xwiki-devs] [VOTE] Create reference to macros
by Denis Gervalle 14 Mar '14

14 Mar '14

Hi devs, While building the new signed script solution with Thomas, we have the need to create a new kind of entity references for macros. This will allow us to keep reference to signed macros. Those references will have entityReference as parent, since macros may be contained in document, but also in object properties. Currently we do not need a syntax for those references, since these will only exists as objects. So, no string serializer is planned. So, we need to agree on creating macroReference that will have at this point a unique identifier (to be discussed later) and a parent that could be either a documentReference or an objectPropertyReference. Here is my +1, -- Denis Gervalle SOFTEC sa - CEO eGuilde sarl - CTO

4 8

[xwiki-devs] [Proposal] WebJar integration in XWiki
by Vincent Massol 08 Feb '14

08 Feb '14

Hi devs, I'd like to make it easy in XWiki to use javascript frameworks required by extensions. I've found the webjars project (http://webjars.org) which packages javascript frameworks in JAR files available in Maven Central. They work out of the box if you drop them in WEB-INF/lib in a Servlet 3.0 container (like Jetty 7). It works because the 3.0 spec says that any files located in META-INF/resources/<path> will be made available by the servlet container as static resources (accessible as <path>). However the servlet 3.0 specs doesn't support adding those JAR dynamically outside of WEB-INF/lib so it doesn't work with our extension mechanism. Thus I'm proposing the following (which I have tested to work): * Add a new WebJarFilter filter to web.xml * The URL to access, for ex, angular.js packaged in the http://repo2.maven.org/maven2/org/webjars/angularjs/1.1.5-1/angularjs-1.1.5… jar would be: /xwiki/webjar/angularjs/1.1.5/angular.js This allows for example to have a dep on: <dependency> <groupId>org.webjars</groupId> <artifactId>angularjs</artifactId> <version>1.1.5-1</version> <scope>runtime</scope> </dependency> Then in a JSX object: require(["/xwiki/webjar/angularjs/1.1.5/angular.js"], function() { … }); WDYT? Thanks -Vincent

5 11

[xwiki-devs] Adding a customer plugin to the wysiwyg editor
by rhierlmeier 06 Dec '13

06 Dec '13

Hi, we studied the source code of the gwt wysiwyg editor but we found no official way to integrate an custom plugin. We have the impression that it should be relatively easy to establish a public API for registering customer plugins. The customer plugin would be delivered as javascript code with a global javascript function that implements PluginFactory interface. The WysiwygEditorConfigClass would have an addition property customerPlugins, containing a comma seperate list of strings of the PluginFactory method names. Do you think that this is doable? Regards Richard -- View this message in context: http://xwiki.475771.n2.nabble.com/Adding-a-customer-plugin-to-the-wysiwyg-e… Sent from the XWiki- Dev mailing list archive at Nabble.com.

4 14

[xwiki-devs] [Vote] Creation of a design wiki and it's purpose
by Ecaterina Moraru (Valica) 18 Nov '13

18 Nov '13

Hi, *Short version* for voting: *A*. Creation of a new wiki on xwiki.org farm that will hold development process details about a specific feature. This wiki will deprecate dev.xwiki.org:Design and incubator.myxwiki.org *B*. Vote on naming alternatives for this new wiki: design.xwiki.org incubator.xwiki.org *C*. UI on how a Proposal will be displayed in this new wiki (example AppWithinMinutes): http://incubator.myxwiki.org/xwiki/bin/view/Improvements/XWikiOrgDesignWiki ------------------------------------------------ *Long version: * Right now development process activities are located in multiple places: - Analysis + Architecture: http://dev.xwiki.org/xwiki/bin/view/Design/ - Analysis + User Interface: http://incubator.myxwiki.org/xwiki/bin/view/Improvements/ - Other: http://xwiki.markmail.org/, http://jira.xwiki.org, chats, git comments, etc. This process can be hard to optimize and information is hard to track if you are looking for specific information. And the worst part of it is that is hard to automatize and lots of the items need manual gathering or search. *Part A. * This mail is about combining http://dev.xwiki.org/xwiki/bin/view/Design/and http://incubator.myxwiki.org/ work in a single place. This has already been discussed several times before ( http://xwiki.markmail.org/thread/kc32dufsf7nyyt6s and http://xwiki.markmail.org/thread/izj6aiyodwqia4vl) and the vote was favorable in this direction. The proposal was to create a new wiki called design.xwiki.org that will contain the combined information and that will target developers. The new wiki will be used to gather only proposal's development process information: requirements, architecture, solutions alternatives, user interface variants, planning, etc. for a specific feature/idea/improvement. After the proposal is implemented it will be properly documented in the right location for users (ex platform.xwiki.org) It is acceptable to have CSS + JS code on this wiki in order to demonstrate the functionality of the proposals, but we should not add experimental/dangerous code (groovy scripts, jars, etc.). For this case it is advisable to use a test machine, share your own instance or use the contrib.xwiki.org repository for hosting. The version upgrades will be handle by a community admin and the wiki gardening by me. The data from incubator.myxwiki.org and dev.xwiki.org:Design will be moved gradually after the new wiki is created. *Part B. * You should state your opinion regarding which name is better for the new wiki: - design.xwiki.org - incubator.xwiki.org - we accept other proposals. *Part C.* I've made a proposal on how a proposal page would look like: http://incubator.myxwiki.org/xwiki/bin/view/Improvements/XWikiOrgDesignWiki The proposal page will gather all the information related to it, making it easier to track it's progress. The entries will be separated depending on 4 categories: Analysis, Architecture, User Interface and Implementation, each category having it's own status, participants, jiras and timeframe. Categories are not mandatory for all proposals, smaller proposals will have just the related pages for certain areas. Each proposal will store it's data in a dedicated space. The implementation of the proposal will be handled by me. Let me know what you think. Thanks, Caty

9 23

[xwiki-devs] [Discussion] Should technical pages hide the bottom tabs?
by Sergiu Dumitriu 24 Oct '13

24 Oct '13

Hi devs, For content pages, the bottom tabs (comments, attachments, history, information) are very useful features. But does it make sense to keep those active for very technical pages? For example, when viewing details about a tag, (Main/Tags?do=viewTag), why should people be allowed to comment? They might wrongly think that they're commenting on a tag, but that's just one complex page that handles almost everything about tags, so a comment like "this tag has a typo" doesn't help at all. Other pages should have no bottom tabs as well: user directory, blog category management, the whole scheduler space, share by email... While the homepage is a technical page (by default), it does make sense to leave the comments active, since it's the entry point for every user (although I think that the messaging system is a better way to send global messages). IMO, the advantage is that we're hiding actions that are rarely useful, but could be misused. The disadvantage is that we're breaking the universality of the UI. I'm +1 for hiding, fewer mis-usable features is always better. -- Sergiu Dumitriu http://purl.org/net/sergiu/

7 11

[xwiki-devs] [Proposal] Roadmap for XWiki 5.3
by Vincent Massol 16 Oct '13

16 Oct '13

Hi devs, Here's some proposal based on discussions with various committers (those from XWiki SAS) and based on our past roadmap leftovers: Content ======= * We need to ensure the SOLR Search is working perfectly well so that it can replace our Lucene search. We've recently found a big limitation (http://jira.xwiki.org/browse/XWIKI-9508) which prevents it from being used in the same way the Lucene search was used before. In addition there are some improvements to make to it (the list of jira issues need to be reviewed). I've discussed with Marius and he's ok to work on this for 5.3. * Continue working on the workspaces integration by default in XWiki Enterprise - Guillaume Delhumeau - integrate creation of "farm mode wiki" (i.e. local users allowed) - internal refactoring to move all wiki-related code to new xwiki-platform-wiki modules - and more… * Finish scalable import/export (and make it the default) - Thomas Mortagne * Implement Confluence import using wikistream - Thomas Mortagne * Improvements on EM/DW - Thomas Mortagne and Marius as time permits (secondary priority compared to SOLR search and import/export+confluence import) * Security: Continue work started by Thomas Delafosse on Script signing - Denis Gervalle * If time permits: AWM improvements (export and publish of applications + others) - Marius Here are also some JIRA issues that were raised as important (in this order of importance): * XWIKI-9117: When upgrading a wiki, do not display what happened (files edited, etc.) in the Activity Stream * XWIKI-9046: Improve document save performance by not loading the full history * XWIKI-6700: Copying a page over an existing one does not warn user * XWIKI-7377: AWM Add the ability to publish an application as an extension * XWIKI-5146: Support LiveTable text filtering on DBListclass columns * XWIKI-9156: The Wiki UIExtensions should check the rights before executing extension points * XWIKI-8763: Improve AWM for it to deal with error messages directly in the edit mode * XWIKI-9227: Extend the link creation feature for XEM * XWIKI-8757: Support 2 roles for users for app within minutes: application creator and data creator * XWIKI-9233: Cannot save a wiki page containing a link towards a page with a full name >255 For committers for whom I've suggested a name next to items above, is it ok for you to work on this in 5.3? Please make sure you create ASAP the full list of JIRAs that you're committing to work on for XWiki 5.3 and that you put them on the roadmap page at http://www.xwiki.org/xwiki/bin/view/Roadmaps/WebHome For committers not listed, anything special you wish to work on for 5.3? Dates ===== 5.3M1: 21st of October (2-3 weeks depending on when we release 5.2 final) 5.3M2: 4th of November (2 weeks) 5.3RC1: 18th of November (2 weeks) 5.3Final: 25th of December (1 week) This allows to keep the November period for 5.3 final as planned initially so that we can have 5.4 in December and 5.5 in January. WDYT? Thanks everyone! -Vincent

3 5

[xwiki-devs] Unable to add user to group after Xwiki update
by echocoder 15 Oct '13

15 Oct '13

I am currently running Tomcat 7.0.39 as well the Xwiki 5.0.3 WAR. I imported the Xwiki database into MySQL from an older version of Xwiki which could be the cause of the problems below... When I enter "Administer Xwiki" and choose "Groups" I am sent to the following which lists the groups as expected. /xwiki/bin/admin/XWiki/XWikiPreferences?editor=globaladmin&section=Groups#|t=groupstable&p=1&l=10&wiki=local When I click on the "pencil icon" to add a user to a group the same page URL is refreshed and shows a lot of white space followed by a list of users in that group at the bottom of the page. There is no option to add the user to a group. So somewhere along the line I believe something became corrupt during my Xwiki update. I tried copying some VMs from the templates subdir back to my main webapp directory but that didn't work. Any suggestions on where to look? Screenshot attached. <http://xwiki.475771.n2.nabble.com/file/n7585667/part2.png> -- View this message in context: http://xwiki.475771.n2.nabble.com/Unable-to-add-user-to-group-after-Xwiki-u… Sent from the XWiki- Dev mailing list archive at Nabble.com.

3 6

[xwiki-devs] Web Viewers
by Ludovic Dubost 14 Oct '13

14 Oct '13

Hi, With Caleb we are working on http://www.webviewers.org/ which documents a new standard for portable javascript web viewer and editors which can be used to view and edit files of supported format (current text, pdf, spreadsheet) in any web applications (starting with XWiki). We are demoing this technology on Friday at the Open World Forum in paris. We would need a mailing list to complement the wiki. There are multiple options for that list: - have it maintained by xwiki.org webviewers(a)xwiki.org - open a google group - open a google plus space - open some other web support space What would you think is better, knowing that the objective will be to have participants from developers working on javascript viewers and developers working on web applications. Ludovic -- Ludovic Dubost Founder and CEO Blog: http://blog.ludovic.org/ XWiki: http://www.xwiki.com Skype: ldubost GTalk: ldubost

2 3

[xwiki-devs] [VOTE] New rule: Put ScriptService implementations out of the internal package
by Vincent Massol 09 Oct '13

09 Oct '13

Hi devs, We need to solve http://jira.xwiki.org/browse/XWIKI-9157 I'm proposing to simply move all ScriptService implementations out of the internal package and make that a rule. These classes are used by introspection and as such as not used as components and thus they should not be in the internal package. Here's my +1 and I'm proposing to handle the move. I can't think of anything that would break except some users who would have had an import in a groovy script on some internal Script Service but that's ok IMO. Thanks -Vincent

5 12