April 2012 - xwiki-devs@xwiki.org

[xwiki-devs] [GSOC] Welcoming our GSoC students
by Eduard Moraru 04 May '12

04 May '12

Hello community, Hello Google Summer of Code students, First of all, congratulations on your applications and your activity during the selection period, and welcome in the XWiki development team. Before guiding the accepted students to their next steps, we'd like to thank again all those who showed interest in XWiki for this Summer of Code. We had a lot of good applications this year, with professional approaches and interesting ideas, and it was very difficult to choose only 3. Unfortunately, some very good students, with great potential, were not accepted. So, to those interested in getting involved anyway, without Google's implication, I renew the invitation to put your ideas in practice under the guidance of the community. Even though the money will be missing, you can still take advantage of the other GSoC benefits: learning new things, gaining experience, earning recognition, etc [1]. If you would like to do that, please let us know by replying to this mail. For the accepted students, here are some getting started hints: = Community bonding period = According to the program timeline [2], the next month (until - May 21st) is to be used for community bonding. The first thing to do, sometime this week, is to present yourself and your project on the dev list, so that everyone knows who you are and what to expect from you (a precondition is to be subscribed to the list, which you *need to do ASAP* if you haven't already). Also, you should continue getting acquainted with the code, the practices and the developers. Please make sure you all read and understand the following - very useful - documents: - [3] http://purl.org/xwiki/community/ - [4] http://purl.org/xwiki/dev/ - [5] http://platform.xwiki.org/xwiki/bin/view/Features/ = Mentorship = We prefer open mentorship. While your assigned mentor is the one officially in charge with your guidance, almost all interaction should be done 'in the open' as much as possible, on the IRC channel or on the mailing list. You should choose the communication medium according to the importance of the matters to be discussed: naturally, the less important issues are to be discussed on IRC, while the design decisions, important progress announcements and testing/feedback requests go on the list. This way, the community is informed on the evolution of your project, and other developers can come up any time with useful ideas and suggestions. Moreover, if your mentor is hit by a bus (the bus factor [6]), another developer can take his place with little effort. = Communication = Sitting alone in your room, working secretly on your project is definitely a bad approach. However, please keep in mind that too much communication can also be harmful, as it distracts the others from their own work. You need to be able to communicate just right: - provide meaningful information about your progress, - ask the community's opinion on non-trivial design or implementation decisions - avoid wasting a lot of time on a problem, when a more experienced developer (or a student that fought the same problem) could quickly provide you an answer; however, do try to find the answer yourself at first. Wrong: "Where do I start? What do I do now? And how do I do that? Is this good? It doesn't work, help me!" Right: "Since a couple of hours ago I get a strange exception when building my project, and googling for a solution doesn't seem to help. Looking at the error, I think that there's a wrong setting for the assembly plugin, but nothing I tried works. Can someone please take a look?" Subscribe to the devs list (if you didn't do this already), and start monitoring the discussions. It is also recommended to subscribe to the users list, but not mandatory. The notifications list is a little too high volume and technical for the moment, but it is a great knowledge source. = Development process = The project's lifecycle is NOT design -> implementation -> testing -> documentation. [7] We invite you to adopt a test driven development [8][9][10] approach and to experience agile development [11]. After the first coding week, you must have some code that works. It won't do much, of course, but it will be the seed of your project. Every functionality will be validated by tests. The code must be properly tested and commented at the time of the writing (don't think you'll do that afterwards, because in most cases you won't). Since our code is now hosted on GitHub [12], you should register an account there and fork some xwiki repositories, so that you can try to build XWiki from sources, and be able to contribute bugfixes. We'll add you to the xwiki-contrib organization [13], and we'll create dedicated repositories for each project. We encourage you to do __at least__ weekly commits (ideally, if you are well organized, you should be able to commit code that works daily, so try to aim at daily commits). This way, the code can be properly reviewed, and any problems can be detected before they grow into something too difficult to fix. One big code blob committed at the end, no matter how good it may seem, is a failure at several levels. A simple way of having something functional in the first week is to prepare the maven build for your modules, which will give you the first unit test for the first class. = Next steps, in a nutshell = - Get more familiar with the code and development process and try to master Maven, JUnit, Selenium, component driven development, ... - Continue fixing a few small issues, chosen so that they are __related to your project__. You can ask on IRC for help selecting good issues, or you can pick from the (non-comprehensive) list of easy issues [14] -- This will help you get more familiar with the code your project needs to interact with. - Refine and organize the ideas concerning your project (you can use the Drafts space [15]), and write several use case scenarios. - Start writing the first piece of code for your project. At the end of the community bonding period, you should have a clear vision of the project, well documented on the xwiki.org wiki, you should have the build infrastructure ready, and you should be pretty familiar with the existing code you will need to interact with. And, of course, you should be familiar with the community and the way we communicate. Good luck, and may we all have a great Summer of Code! -The XWiki Development Team ---------- [1] http://www.catb.org/~esr/writings/cathedral-bazaar/homesteading/ [2] http://www.google-melange.com/gsoc/events/google/gsoc2012 [3] http://purl.org/xwiki/community/ [4] http://purl.org/xwiki/dev/ [5] http://platform.xwiki.org/xwiki/bin/view/Features/ [6] http://en.wikipedia.org/wiki/Bus_factor [7] http://www.catb.org/~esr/writings/cathedral-bazaar/cathedral-bazaar/ [8] http://en.wikipedia.org/wiki/Test-driven_development [9] http://www.amazon.com/dp/0321146530/ [10] http://www.amazon.com/dp/0201485672/ [11] http://www.amazon.com/dp/0596527675/ [12] https://github.com/xwiki/ [13] https://github.com/xwiki-contrib/ [14] http://jira.xwiki.org/jira/secure/IssueNavigator.jspa?mode=hide&requestId=1… [15] http://dev.xwiki.org/xwiki/bin/view/Drafts/

7 13

[xwiki-devs] [VOTE] Allow anyone to use org.xwiki.query.Query#setWiki
by Thomas Mortagne 03 May '12

03 May '12

Hi devs, When Query Manager as been introduced by Artem I suggested to add a setWiki to make easier to execute request on another wiki. For me it was supposed to be usable by anyone and I discovered recently that it was allowed only when the user has programming right. Since I really don't see the point I propose to remove this check. * all the users without programming right can do is to list documents names so it's not very dangerous * api;XWiki#searchDocumentsNames(String wikiName, String parameterizedWhereClause, int maxResults, int startOffset, List< ? > parameterValues) does not have any check so what the query manager prevent is doable anyway WDYT ? Here is my +1. -- Thomas Mortagne

4 6

[xwiki-devs] [PROPOSAL] Use relative URLs instead of external URLs with sendRedirect
by Thomas Mortagne 03 May '12

03 May '12

Hi devs, In HTTP specifications a redirect is always absolute URL which is probably why we use absolute URL with sendRedirect. However sendRedirect does not produce direct HTTP response but allows relative URL and delegate to the application server the job of producing proper absolute URL. IMO XWiki should always use relative URL everywhere it can so I propose to change our practice to use relative URL instead of absolute URL with HttpSevletResponse#sendRedirect when possible. The only reasons I see to use external URLs are: * interwiki URL in a domain based multiwiki * html/pdf export for links pointing on not exported pages or non view actions WDYT ? Here is my +1. We very often fix bugs in the way to produce external URL and it's still not OK (see http://jira.xwiki.org/browse/XWIKI-7632) so lets reduce the scope for this need as much as possible. -- Thomas Mortagne

6 20

[xwiki-devs] [Brainstorm] What do we do with the AutoTag plugin?
by Vincent Massol 02 May '12

02 May '12

Hi devs, Sergiu has extracted the AutoTag plugin from oldcore in its own module. That's cool. However he's also marked it @deprecated while doing so. And he's stopped bundling it in XE. This raises several question: 1) Do we consider that what the plugin does it not useful? Because if we consider it's useful we might not want to deprecate it without offering an alternative. It's not because a technology is deprecated that we should deprecate stuff using that technology. Deprecated means: don't use this, instead use that. BTW it should be our rule that when we add the @deprecated tag we also mention what to use instead. 2) If we consider it's not useful anymore. We have 2 choices: 2a) Move it in legacy modules 2b) Move it to retired/contrib My opinion: * It could be useful but I'm not sure the XWiki Dev team wants to support it. IMO it should not be deprecated since it can still be useful and there's no replacement for it. * Since I don't think the XWiki Dev Team should support it, I'd move it to xwiki-contrib/retired and publish it on e.x.o. for users who want to still use it. * Since this is breaking our new rule regarding deprecations/legacy it requires a VOTE to move it to contrib/retired. It also needs to be clearly mentioned in the Release Notes as a breakage and explain how user can add it back to their wikis. Let me know what you think and I'll send a VOTE if you agree with what I said above. Thanks -Vincent

4 3

[xwiki-devs] [VOTE] Stop bundling the Event Syntax in XE?
by Vincent Massol 02 May '12

02 May '12

Hi, I've now put the Event Renderer in its own syntax module, same as what we have for other syntaxes. Thus we need to decide if we still want to bundle it in XE or not (it was bundled but only because it was in rendering-api before). IMO there's no reason to bundle it at all since: * it's not used anywhere * I don't see any use case for it (we use it only for tests) * We want to reduce the # of extensions we bundle by default * It can be added by the user in his XE instance should he need it (I doubt it) So here's my +1 to not bundle it and to add this potential backward compat breakage in the RN for 4.1M1 Thanks -Vincent

5 4

[xwiki-devs] [Announcement] XWiki Enterprise 3.5.1 Released
by Sergiu Dumitriu 29 Apr '12

29 Apr '12

The XWiki development team is proud to announce the availability of XWiki Commons, XWiki Rendering, XWiki Platform, XWiki Enterprise and XWiki Enterprise Manager 3.5.1. This is the first bugfix release for the 3.5 series, and, since 3.5 is the final major release in the 3.x cycle, a bugfix release for the whole 3.x cycle. The main focus has been on quality assurance, improving the compatibility with various database systems, polishing the new sheet mechanism, the new extension manager, the skin, the WYSIWYG, and other parts of the XWiki platform. See the full release notes at http://www.xwiki.org/xwiki/bin/ReleaseNotes/ReleaseNotesXWikiEnterprise351 for more details. -- Sergiu Dumitriu http://purl.org/net/sergiu/

1 0

[xwiki-devs] [Reminder] Deprecation day tomorrow (26th of April)
by Vincent Massol 28 Apr '12

28 Apr '12

It's tomorrow, the 26th of April, don't forget! Goal: * Move as many deprecations to legacy modules Who: * All committers and all contributor who wish to help out Metric: * Our score will be the # of APIs moved. Each dev need to report the # of APIs he's moved. Let's make it a success and learn from it. I'll publish a blog post with the result afterwards. Thanks -Vincent

5 13

[xwiki-devs] XWiki databases testing helper script and repository for unreleased but maintained codes
by Denis Gervalle 28 Apr '12

28 Apr '12

Hi devs, Following the numerous database related issues that have/are delayed/ing the 3.5.1 release and the 4.0 release, and seing how it could be long and annoying to put multi-database tests in place, and the hard work Sorin has done in testing these issues again and again, I have taken a couple of hour to write a decent bash script. Here is an excerpt of the usage message of my script: This script can do the following steps easily to help you testing xwiki distribution: - Download a distribution package, either release or snapshot (using mysql/jetty distribution). - Deploy that package, and configure it for a requested database. - Create the needed database. - Import a database dump, previously exported with this same tool. - Launch the configured XWiki with Jetty. - Backup the database after XWiki shutdown. All operations could be done in a multiuser environment, using common databases, without conflict. You may start using it as easy as "xwiktest -v 3.5 -d oracle -w" to have a XWiki release 3.5 downloaded and run with oracle and non-conflicting ports and database. Full options are listed at the end of this thread for the interested. I really hope this script could help in testing more often any changes that may have consequences between versions, or may cause incompatibilities with some databases. It would be nice if a well connected VM (the one from Sorin has all DBs well configured but is badly connected and downloading is really slow :( ) could be available to all committers, avoiding each one to have to setup each database locally. If you find it useful, I will maintain this script as much as possible, and improve it further. I have already some idea like: - automatically import a given XAR - check logs, terminate and report issue automatically (to integrate with Jenkins?) - allow starting multiple version one after each others, testing migration in one run ... This is already more than a simple script (~500 lines), and well documented. However, I do not found a good place to put such script in GitHub. IMO, this script is like release scripts, it will be maintained by the dev team, and it could became essentiel to the project, and I have conform as much as a bash script could to our coding practices. Therefore I do not think that putting it in xwiki-contrib is right. Release scripts should not even be there, and need a place in a xwiki repositories IMO. These are scripts that are never released nor compile or what ever. We have already something similar in xwiki repositories: xwiki-debug-eclipse I do not think it is nice to multiply repositories in xwiki, but there is a need for unreleased but maintained codes like these. I proposed that we create a new repository in XWiki to contains such codes, and to put/move in it: - xwiki-debug-eclipse - xwiki-release-tools (for release scripts) - xwiki-testing-tools (for the above script) We may call this repository: - xwiki-tools - xwiki-utils - xwiki-dev-tools ... WDYT ? -- Denis Gervalle SOFTEC sa - CEO eGuilde sarl - CTO As promised for the curious, the options of my testing script: Usage: xwikitest [OPTIONS] Options: -b backup.sql Backup database to the given file (or folder for oracle) after shutdown. -B backup.sql Backup current database to the given file, same as -b -z -k -n -d database Choose a database (mysql-myisam,mysql-innodb,psql,oracle,hsqldb). Current is mysql-innodb. -e distribution Choose a distribution (enterprise or manager). Current is manager. -i dump.sql Import the given sql dump in the database before startup. -I dump.sql Import the given sql dump in the database without running, same as -i -z -n -h Display this usage message. At the end, it shows your current arguments and alone the defaults. -k Do not clean the database before startup. -n Do not start XWiki. -p port Port for Jetty listening. Current is 7581. -r snapshot Use given snapshot (ie: 20120410.161114-97). Default to use release. -s dbsuffix Database suffix for test isolation. Current is DenisG. -t port Port for Jetty termination. Current is 7501. -v version Choose a XWiki version. Current is 4.1. -w Download from maven.xwiki.org. Default is to search current folder. -z Do not redeploy and reconfigure (use with care).

3 2

[xwiki-devs] jQuery is undefined error for IE7
by Geo Du 26 Apr '12

26 Apr '12

Hi, all, I am using jQuery for javascript, since it is conflicting with prototype, I use the jQuery help extension: http://extensions.xwiki.org/xwiki/bin/view/Extension/jQuery+Helpers, so far everything works fine on Firefox, the problem is the IE7, I got jQuery is undefined error from the UI library: $xwiki.jsx.use("jQuery.jQueryUI"), I can see the javascript code in firebug with last par of the code: .bind("blur",h)})})})(jQuery); I noticed that there is a ";" in the end, but in IE7, I checked the code from Microsoft Script Editor when I debug, it shows no ";", not sure if that is the problem. In IE7, I clicked the jQuery helper extension demo pages: bin/view/jQuery/Demo1 page and bin/view/jQuery/Demo2 page, they both gave me "jQuery is undefined" error. so this error happens to the extension as well. Could anybody help me with is issue? Thanks very much. Dave

1 1

[xwiki-devs] [VOTE] Legacy Module Rules
by Vincent Massol 26 Apr '12

26 Apr '12

Hi devs, In preparation of our Deprecation Day and continuing our vote on the Deprecation strategy I'd like to propose several rules we need to clarify since we need them and I'd like to finish documenting our full deprecation strategy. Rule 1: Where are Legacy modules located? =================================== * Proposal: - Each Git repository needing legacy modules provides a *-legacy module for holding legacy modules. For example: -- For Commons, xwiki-commons-core/xwiki-commons-legacy/ -- For Platform, xwiki-platform-core/xwiki-platform-legacy/ -- For Rendering, xwiki-rendering-legacy/ * Explanation: - It's better to locate them in a specific module (*-legacy) than inside their own module (for ex in xwiki-commons-core/xwiki-commons-component/xwiki-commons-component-legacy/) because legacy modules are something we don't want to see as much as possible since we're must not use them in our code, thus it's logical to park them all together somewhere. * Notes: - This is our current rule but it's never been explicitly defined Rule 2: What do Legacy modules contain? ================================= * Proposal: - Each Legacy module should replace the non-legacy module it corresponds to. This means that the user must have only 1 JAR for a given module: either its legacy version or it's non-legacy version but should never have both. * Explanation: - We need consistency. Right now we have oldcore which acts like this but others don't and it's complex to explain to users that for some they have to swap them and for others they have to keep both side by side - In the very close future, we'll use a lot of Aspects in modules others than legacy-oldcore, and thus we'll need to apply this strategy anyway. * Notes: - Currently, only oldcore acts like this. - The consequence is that we'll have one legacy module per non legacy modules. Right now we sometimes have one legacy module for several non legacy modules which we'll need to fix Here's my +1 to both. Thanks -Vincent

3 7