xwiki-devs February 2014

xwiki-devs@xwiki.org

26 participants
67 discussions

[xwiki-devs] [ANN] Move to Java 7 is now done

by Thomas Mortagne

I updated all Jenkins agents to use Java 7 to build master branch and moved all references from Java 6 to Java 7 in xwiki-commons root pom. What it means in practice is that you might have issues building XWiki with Java 6 from now on (and will probably be impossible in not long). We don't yet used much Java 7 API but if you don't build everything on your side you will probably have issues when building a project which download on maven repository jars built with Java 7. In short: update your Maven setup to use Java 7 when working with master branch. Thanks, -- Thomas Mortagne

10 years, 10 months

[xwiki-devs] [ANN] XWiki 5.4.1 released

by Guillaume "Louis-Marie" Delhumeau

The XWiki development team is proud to announce the availability of XWiki 5.4.1. This is a bugfix release fixing a security issue among other things. 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/ReleaseNotesXWiki541 Thanks -The XWiki dev team

10 years, 10 months

[xwiki-devs] [Brainstorming] How to define @since when the package changes?

by vincent＠massol.net

Hi devs, I always ask myself this question so I think we need a common agreement. So here’s the question: * I have added some code in version N and this I have a "@since N” in the code * In version M (M > N), I move the class/interface to a new package Question: Do I change the @since annotation to “@since M” or not? 2 possibilities: * Reasoning 1: it’s a new class/interface since the FQN of the class/interface has changed and thus we should use “@since M” * Reasoning 2: even though the FQN has changed it’s still the same code that was moved and from a user POV, it was still introduced in version N and thus we should keep “@since N" WDYT? I’m hesitating. The most technically correct answer is Reasoning 1 IMO but the most useful one is probably Reasoning 2 since the question we wish to answer is probably: “when was this code first introduced?”. Thus reasoning 2 seems slightly better to me. Thanks -Vincent

10 years, 10 months

[xwiki-devs] [Contrib] Reporting extensions issues

by Ecaterina Moraru (Valica)

Hi, This mail should be seen as feedback for improving our e.x.o ( extensions.xwiki.org) and our contributions process, while answering some of my questions :) Right now I am playing and testing some XWiki extensions from e.x.o. The problem that I have is that I don't know where is the best place to report bugs and issues. 1. First of all I think we should add a 'Issue Tracker' field in the repository application, where the developer should state where the issues should be reported (what is the preferred way of reporting and even if the developer is available for further iterations of the extension). 2. What issue tracker we should use and how? Right now there are several ways the users can give feedback for a certain extension: A. Direct e-mails to the developers: I've received couple of times e-mails with questions about the extensions I've developed. This approach is not recommended since we are doing open development and other users might have the same question. Usually I suggest to use the mailinglist ( http://dev.xwiki.org/xwiki/bin/view/Community/MailingLists ) if there are additional questions, but an issue tracker could also solve the problem. B. Community mailinglist: We receive many questions about the extensions on the mailinglists. The problem is that the answers are very hard to track and share among other users (you need to know that the question has been asked before and than that an answer has been provided). An issue tracker would improve the process. C. Comments on the extension page: There are several extensions that have comments on their extension page. While this approach is the most accessible, it is hard to know what is the status of a comment and the responsible person for it (was it fixed already? in what version? is the comment still valid?). D. GitHub issue tracker: While some extensions contain just snippet code or local XARs, other have a repository attached to it. I know some extensions that track their issues on github. The advantages of this approach is that you keep total control of your extension and also you don't need approvals from xwiki community to have your repository created or help with the management of it (rights, etc.). You handle your own development while using e.x.o as a publishing platform. The above statements are in case you have a personal repository. The alternative is to have a repository on xwiki-contrib ( https://github.com/xwiki-contrib ), but these repository could also have the github issue tracker activated. E. jira.xwiki.org project: On jira.xwiki.org there is a whole section of Contributed Projects ( http://jira.xwiki.org/secure/BrowseProjects.jspa#all ). There is also a generic XWiki Contrib project ( http://jira.xwiki.org/browse/XCONTRIB ) " to be used by all projects till they achieve a first release or till they grow to a size significant enough to warrant a dedicated JIRA project" (quote taken from http://contrib.xwiki.org/ ) F. IRC: Even harder than mailinglist to reference. G. other? I've written all the ways in order to agree on the recommended way (which I guess is E.) while I don't think there is a way to force the others from happening. 3. Related extensions vs. Branched extensions vs. Forked extensions My problem is like this: Lets say I want to test the Forum Application. Currently there are 3 versions of the Forum application (read more at http://design.xwiki.org/xwiki/bin/view/Proposal/ForumApplication ). - First of all it was hard to know that we have 3 versions for the 'same' functionality. A feature like "Related extensions" would have been great to have on e.x.o. - Then it was difficult to find out where is the place to report issues for each of these applications (see the whole point of this mail). Currently there are 2 JIRA projects created for Forum (XAFORUM and XBB) but there is no place to report for SimpleForumApp. - It was hard to know what version still work and if there is still active development on it (especially if you have just an attached XAR and not a repository). - It is hard to know if the apps are completely different or if they are just forks of the same base code. Do they share the same functionality, do they want to be improved versions or are just completely different things? These questions are important because they give you an answer if the entries should have separate JIRA projects or we could solve the problem by creating just a COMPONENT in the same JIRA project. - Whose responsibility is it to create the issue tracker, to link to the related applications, etc? (the developer? the contrib managers? other members of the community?) The same questions apply for Calendar Application ( http://design.xwiki.org/xwiki/bin/view/Proposal/CalendarApplication ). I have 3 variants with other related extensions. The only extension that has a JIRA project associated with it is the older extension. So, as an user of the extension, where do I report issues? - Do I need to ask for the creation of a separate project? - Do I ask for the creation of a separate component in the existing project? - Do I report in the generic xcontrib project? - Do I need the permission of the developer to have the project created? - Should we enforce the creation of projects for the new extensions? - How we decide if an extension is big enough or important enough to have its own project? - Who should monitor these growth? (since we actually don't know if the extensions are used or downloaded?) Let me know what you think. Thanks, Caty

10 years, 10 months

[xwiki-devs] [ANN] Realtime Collaborative Plain WikiText Editor and WEBSOCKET!

by Caleb James DeLisle

Hi all, I'm very pleased to announce two new extensions to come out of XWikiSAS Research and the RESILIENCE Research project. Number One: WebSockets in XWiki! If you're an extension developer like me, you want events, you want stuff in the browser to be talking to stuff in the wiki and you don't want to be messing around with Jetty and Tomcat and all different kinds of libraries and configuration every time you need to write an application. You just want stuff that works. Here it is: http://extensions.xwiki.org/xwiki/bin/view/Extension/WebSocket Include this as a dependency for your extension and the Extension Manager will automatically include it when users install your extension. In just a few lines of code, your users can be chatting and collaborating through the websocket and it's based on Netty (Special thanks to the Atmosphere project for developing Nettosphere) so it works in all versions of Tomcat and Jetty and does not need any changes to the front-end server, just open a port on the JVM machine and you're done. Number Two: A new Realtime Collaborative WikiText Editor. Indeed this is not the first attempt at Realtime Collaborative editing but perhaps it is the most academically amusing. Really this is a prototype to get a handle on the technology before we make the leap into Realtime WYSIWYG. Whereas the previous Realtime Collaborative WikiText editor had performance issues and was unable to handle large pasted, the new editor uses a completely novel design which is intended to not only port well to WYSIWYG editing but is implemented entirely on the client with the server only relaying messages, making it portable to different web frameworks. Check out the Realtime Collaborative WikiText Editor here: http://extensions.xwiki.org/xwiki/bin/view/Extension/RealTime+Wiki+Editor or install it with the Extension Manager to give it a try for yourself. Disclamer: This is still new and might not work properly on all browsers, it certainly will not work without websocket support. Thanks, Caleb

10 years, 10 months

[xwiki-devs] [Proposal] Action Module revisited - take 2

by vincent＠massol.net

Hi devs, I’m currently revisiting the action module, see http://design.xwiki.org/xwiki/bin/view/Design/ActionModule Let me know what you think and if you have any other idea. I’m going to continue exploring this over the coming couple of days and write a first implementation that I’ll put in a branch in platform. Of course the earlier you can provide feedback the less I’ll have to rewrite ;) Context: I’m ready to commit support for webjars (see http://jira.xwiki.org/browse/XWIKI-9375) but I’d like to do it cleanly without implementing it as a Servlet Filter or as an oldcore XWikiAction… Thanks! -Vincent

10 years, 10 months

[xwiki-devs] [Reminder] Review and removal of @Unstable annotation for 6.x

by vincent＠massol.net

Hi guys, According to your rules since we’re starting a new cycle we need to review all existing @Unstable annotations and remove ones that have been there for at least one cycle (i.e. prior to the 5.x cycle). See http://dev.xwiki.org/xwiki/bin/view/Community/DevelopmentPractices#H40Unsta… It’s also the occasion to check @Unstable APIs that we can consider stable now. Thanks -Vincent

10 years, 10 months

[xwiki-devs] Problem with XWikiLDAPUtils class

by Eric Kimn

Hey all, I managed to view the code for this class by a google search. But i’m noticing a problem with the getGroupMembers logic and I’m experiencing it myself in my 5.4 install of xwiki. Some background: I am using Apple’s open directory as my ldap server. My ldap config is as such (using the LDAP application): Restrict to group: cn=mygroup LDAP base dn: dc=mycompany,dc=com LDAP UID Attribute name memberUid The symptom: When XWiki tries to locate the members of a group, it finds only one, typically the alphabetically first one, and not all. The source of the problem: The entry point is here: public Map<String, String> getGroupMembers(String groupDN, XWikiContext context) which calls with a new map of <String, String> for members, this line -> boolean isGroup = getGroupMembers(groupDN, members, new ArrayList<String>(), context); That method has this signature -> public boolean getGroupMembers(String groupDN, Map<String, String> memberMap, List<String> subgroups, XWikiContext context) which falls to if (searchAttributeList != null) { isGroup = getGroupMembers(fixedDN, memberMap, subgroups, searchAttributeList, context); } But of course there are search attributes, so it calls this-> public boolean getGroupMembers(String groupDN, Map<String, String> memberMap, List<String> subgroups, List<XWikiLDAPSearchAttribute> searchAttributeList, XWikiContext context) And this is where the problem is: It for loops through the search attributes and executes a query, if it gets a response that isn’t a group and the member map doesn’t already contain that key, it will add it: if (!memberMap.containsKey(groupDN)) { memberMap.put(groupDN.toLowerCase(), id == null ? "" : id.toLowerCase()); } But then it RETURNS isGroup, which is now true, And that flows back up the chain, except it never iterates through the rest of the entries. My logs show: 2014-02-08 17:45:22,858 [http://myserver/xwiki/bin/loginsubmit/XWiki/XWikiLogin] DEBUG c.x.x.p.l.XWikiLDAPUtils - Looks like [cn=mygroup] is not a DN, lets try filter or id 2014-02-08 17:45:22,858 [http://myserver/xwiki/bin/loginsubmit/XWiki/XWikiLogin] DEBUG c.x.x.p.l.XWikiLDAPConnection - LDAP search: baseDN=[dc=mycompany,dc=com] query=[cn=mygroup] attr=[[objectClass, uid, memberuid, memberUid]] ldapScope=[2] 2014-02-08 17:45:22,864 [http://myserver/xwiki/bin/loginsubmit/XWiki/XWikiLogin] DEBUG c.x.x.p.l.XWikiLDAPUtils - Found group [cn=mygroup] members [{cn=mygroup,cn=groups,dc=mycompany,dc=com=member1}] 2014-02-08 17:45:22,864 [http://myserver/xwiki/bin/loginsubmit/XWiki/XWikiLogin] DEBUG c.x.x.p.l.XWikiLDAPUtils - Found user dn in user group [null] 2014-02-08 17:45:22,865 [http://myserver/xwiki/bin/loginsubmit/XWiki/XWikiLogin] DEBUG u.i.L.XWikiLDAPAuthServiceImpl - Local LDAP authentication failed. com.xpn.xwiki.XWikiException: Error number 8001 in 8: LDAP user member2 does not belong to LDAP group cn=mygroup. Am I reading the logs or code wrong? If I am, then what am I doing wrong with my ldap configuration? I’m clearly part of mygroup but it consistently fails to find me. Best, Eric Kyungsuk Kimn 김경석 Senior Back End Developer ekimn(a)apple.com

10 years, 10 months

[xwiki-devs] [VOTE] Move to Java 7 as minimum supported version

by Thomas Mortagne

Hi devs, I would like to propose that we move to Java 7 as minimum version in XWiki 6.0. You can look at http://jira.xwiki.org/browse/XCOMMONS-432 for details on why and why not. The only cons basically is that Java 6 may still be used in production but we are talking about a version that won't be used in production before at least 3 months. WDYT ? Here is my +1 -- Thomas Mortagne

10 years, 10 months

[xwiki-devs] [Reminder] BFD#54

by vincent＠massol.net

Hi devs, Today is Bug Fixing Day 54. We're currently at -50 bugs for the 1600 days period: http://jira.xwiki.org/secure/Dashboard.jspa?selectPageId=10352 Here's the BFD#54 dashboard to follow the progress during the day: http://jira.xwiki.org/secure/Dashboard.jspa?selectPageId=12000 Happy BFD! -Vincent

10 years, 10 months

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

2005

xwiki-devs February 2014