May 2017 - xwiki-devs@xwiki.org

[xwiki-devs] [GSOC] Welcoming our GSoC students
by Thomas Mortagne 06 May '17

06 May '17

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. 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 29th) 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://dev.xwiki.org/xwiki/bin/view/Community/ - [4] http://platform.xwiki.org/xwiki/bin/view/DevGuide/ - [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 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] https://summerofcode.withgoogle.com/dashboard/timeline/ [3] http://dev.xwiki.org/xwiki/bin/view/Community/ [4] http://platform.xwiki.org/xwiki/bin/view/DevGuide/ [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] https://jira.xwiki.org/secure/IssueNavigator.jspa?mode=hide&requestId=10510 [15] http://dev.xwiki.org/xwiki/bin/view/Drafts/

3 3

[xwiki-devs] [XWIKI-14138]
by Krzysiek Płachno 05 May '17

05 May '17

Hi, To start with - many thanks for accepting me for GSoC2017! And now - the case. I'm constantly fighting with https://jira.xwiki.org/browse/XWIKI-14138. The change is almost done but what's missing is test. In particular I want to modify a bit this one: org.xwiki.test.ui.repository.RepositoryTest. I've already set up proper firefox version and other configuration for selenium and now whilst calling test - on running instance of test XWiki i get folling exceptions: https://pastebin.com/dHBLNB0L The first exception (NoSuchFieldError: OBJECT_REFERENCE ) is raised during static initialization of org.xwiki.repository.internal.RepositoryManager and then there is long list of repeating NoClassDefFoundError. I haven't change anything with static fields or static initialization of Repository Manager. I added one injection of service but from module that was already referenced in the test. The code change is here: https://github.com/krisss2121/xwiki-platform/commits/master (unfortunately splited into several commits, but maybe there's some way to view it togheter) I would be very thankful for any hint, how to solve this problem. Best, Krzysztof

2 1

[xwiki-devs] [Brainstorming] Testing responsiveness of XWiki
by Vincent Massol 05 May '17

05 May '17

Hi devs, So far we don’t have automated tests for testing responsiveness. Some tests are done manually on mobile very infrequently and manually but we should think about improving that. I guess that a first level would be to use our selenium setup and have some specific junit tests executed with xvnc on CI with a geometry corresponding to a phone, and verify presence of UI elements in those tests. It should also be possible with pure selenium to verify relative position of WebElement vs one another (e.g. verify that this Panel Div is located below this Content Div. Seems there’s a framework called galen that could help express this in a simpler way. I haven’t tried it yet and I don’t know how easy/hard it is to set it up. See: * http://mindengine.net/post/2014-01-07-layout-testing-for-responsive-website… * http://galenframework.com/docs/reference-java-tests/ Any comment? Thanks -Vincent

1 0

[xwiki-devs] [XWiki Day] Test Day #5
by Thomas Mortagne 05 May '17

05 May '17

Hi devs, The idea today is to do a Test Day with priority to fixing long standing flickering (integration mostly) tests. You can find known flickering tests on http://jira.xwiki.org/issues/?filter=14240. The goal is to really fix them, not just add some random wait here and there ;) If you are not confident with the area around those specific flickering tests here are some other ideas for this kind of Day: * obviously add more tests and increase the code coverage * move tests from enterprise to platform. Needed for the platform flavor and removal of XE * update jacoco covering setup (we often forget to increase it when adding more tests) * move more tests from JMock to Mockito * work on new test setups and tools: ** improve docker containers for packaging XWiki (possibly several for multiple DBs and Servlet containers). ** work on spreading Jenkins platform job into one job per maven module so that build can be spread on various agents (groovy scripting) ** Research/Use Jenkins 2 Pipeline plugin with the new DSL and commit the jenkinsfile in SCM ** Test platform to run contrib extension tests on various versions of XWiki automatically * Speedup existing tests (research xwiki startup time, remove unnecessary modules, etc) When what you fix can be linked to an issue, tag it with "testday" (same idea as "bugfixingday" when doing BFD). If not then answer to this mail to explain what you did. Good Test Day !

1 1

[xwiki-devs] [PROPOSAL] New extensions package
by Thomas Mortagne 04 May '17

04 May '17

Hi devs, I'm currently working on a new package format to package a bunch of extensions into a single file. The first use case is to make offline install easier. We can't count on all in one XAR anymore (plus all in one XAR prduces very crappy extensions) so I was thinking about providing a generic package containing all the extensions you need in it. It will simply be a zip containing extensions in the same format than Extension Manager local repository so that you can unzip it it there (or later use some UI to "import" it). So now I need a name for this new package. Since extension descriptor file extension is "xed" (for "XWiki Extension Descriptor") I was thinking about naming it XEP (for "XWiki Extension Package"). Any better idea ? For now my plan is to provide the following: * a new Maven handler for <packaging>xep</packaging> * a new Maven mojo "xep" in the existing extension Maven plugin * start using it with the new platform flavor which is supposed to replace XE so that people can have something to use for offline installs WDYT ? -- Thomas Mortagne

5 8