February 2014 - xwiki-devs@xwiki.org

[xwiki-devs] [Contrib] Request repository for integration between XWiki and Activiti
by Sorin Burjan 06 Mar '14

06 Mar '14

Hello, Last year I worked for my master thesis on a integration between XWiki and Activiti. Activiti is a popular open-source workflow execution engine. ( http://activiti.org/) I'd like to commit my work so others can use and improve it. For this, I'd like a repository called application-activiti for the source code, and also a JIRA project called Activiti Application with the key ACTIVITI. Thanks in advance, Sorin B.

6 11

[xwiki-devs] Maven-based naming best practices
by coldserenity 03 Mar '14

03 Mar '14

Hello, Does XWiki have conventions documented regarding * directory layout and naming * groupId name * artifactId name * project name (briefly scanned http://dev.xwiki.org and did not find anything) Regards, Roman -- View this message in context: http://xwiki.475771.n2.nabble.com/Maven-based-naming-best-practices-tp75892… Sent from the XWiki- Dev mailing list archive at Nabble.com.

4 3

[xwiki-devs] [Reminder] BFD#56
by vincent＠massol.net 28 Feb '14

28 Feb '14

Hi devs, Today is Bug Fixing Day #56. We're currently at -27 bugs for the 1600 days period (we were at -23 two weeks ago): http://jira.xwiki.org/secure/Dashboard.jspa?selectPageId=10352 Here's the BFD#56 dashboard to follow the progress during the day: http://jira.xwiki.org/secure/Dashboard.jspa?selectPageId=12093 Happy BFD! -Vincent

1 1

[xwiki-devs] [Restrospective] Deprecation Fixing Day #2 issues...
by vincent＠massol.net 28 Feb '14

28 Feb '14

Guys, Last week we’ve had a deprecation-fixing day. I was worried about one thing and it seems it happened unfortunately. My worry was about breaking the build and introducing regressions. I’ve just started testing XE very quickly and I’ve noticed in the course of few minutes 2 regressions already :( * Regression 1: CSRF issue leading to a NPE when you execute XE. This wasn’t noticed for a full week! Correction was done today by GuillaumeD after I reported it (see https://github.com/xwiki/xwiki-platform/commit/bd007f28ee8c079d481c49455ceb…) Caused by https://github.com/xwiki/xwiki-platform/commit/77ebad8c6390dc4389d2de690ab5… * Regression 2: Incude macro doesn’t work anymore when using the “document” parameter. The problem is that we’re still using that.. For example in Panels.NewPage: {{include document="Panels.PanelSheet"/}}. I’ve just fixed it in https://github.com/xwiki/xwiki-platform/compare/09528b3e668a...4c2da3bf843b and https://github.com/xwiki/xwiki-enterprise/compare/96b63c62a637...7e8188d568… . Caused by https://github.com/xwiki/xwiki-platform/commit/ade4046 (caused by me!! yuck!). There are possibly more issues that we haven’t discovered yet. Thus IMO we have 2 problems here: * Fixing deprecation is something dangerous and if we don’t have automated tests for them we won’t notice regressions * We’re all not monitoring the build enough since this breakage has been lasting for 1 week. However this may be a consequence of the jenkins stability issue we’re currently experiencing. I’m not sure what we can to mitigate the risks but we need to think about something for the next time we’ll a Deprecation Fixing Day. Maybe we should only issue Pull Requests for that day and force that a committer doesn’t push the change himself and instead some other dev would need to review the code before pushing it? Any idea? Thanks -Vincent PS: Obviously the real solution is to have a stronger automated test suite but that doesn’t happen overnight and we currently don’t have a strategy for catching up with missing tests...

3 3

[xwiki-devs] [ANN] XWiki 5.4.2 released
by Guillaume "Louis-Marie" Delhumeau 27 Feb '14

27 Feb '14

The XWiki development team is proud to announce the availability of XWiki 5.4.2. This is a bugfix release. 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/ReleaseNotesXWiki542 Thanks -The XWiki dev team

1 0

[xwiki-devs] [Vote] Deprecation of Prototype.js and the usage of JQuery as our default JS framework
by Ecaterina Moraru (Valica) 27 Feb '14

27 Feb '14

Hi devs, This has been brought into discussion several times so this thread is intended for this particular topic. Thanks, Caty

8 17

[xwiki-devs] A problem of secret with jobs
by Jeremie BOUSQUET 27 Feb '14

27 Feb '14

Hello, I use the Job Module [1] for an extension, and discovered something that could be a concern ... Logs of job execution are stored in permanent directory, which is good. But when using the "{}" notation for writing logs as recommended, the following is output in the "status.xml" file: <org.xwiki.logging.event.LogEvent> <level>DEBUG</level> <message>blablabla</message> <argumentArray> [[ dump of arguments ]] <argumentArray> Inside <ArgumentArray>, all attributes of the object passed as argument to the logger method seem to be dumped - not just a toString(). Currently, in my case sometimes the object I pass contain a password ... I thought I prevented this password from being output in logs by taking care of printing "***" in the related toString, but in fact this way it gets in clear in the status.xml ... I see those possibilities: a- store this password encrypted and decrypt it only when used b- have a possibility to filter what is output in this <argumentArray> (blacklist some attributes) c- only pass individual attributes as parameter and not my full object Obviously a- is the best solution in terms of security. Would xwiki bring me some helpful methods to implement it (server side) ? c- is the short term efficient workaround of course, but I would still be interested to know if there are some crypto tools provided by xwiki (well, most problematic would be to know where/how to store the secret needed for encryption/decryption in an extension, if I want to do more than some scrambling). WDYT ? Thanks, Jeremie [1] http://extensions.xwiki.org/xwiki/bin/view/Extension/Job+Module

3 6

[xwiki-devs] [Vote][Skin] Keep Colibri look or have another look for 6.x
by Ecaterina Moraru (Valica) 26 Feb '14

26 Feb '14

Hi, As part of the 6.0 Roadmap we have as entry the creation/integration of a new Skin inside XWiki. Currently there are 2 proposals for the new skin: Flamingo http://design.xwiki.org/xwiki/bin/view/Improvements/Skin4x Junco http://design.xwiki.org/xwiki/bin/view/Proposal/JuncoSkin = Similarities = * Both skins have been done using the Twitter's Bootstrap framework ( http://getbootstrap.com) * Both skin are thus responsive = Differences = * Flamingo is just a proposal, while Junco is an extension. The difference is that while for Flamingo I have just a prototype, Junco is functional and installable (with some integration problems/dependencies discussed in another thread). The difference matter just from a development time perspective (if we choose Flamingo it will take longer to implement). * Flamingo provides a new look while Junco offers 'Themes', one of themes being very similar to Colibri, see http://extensions.xwiki.org/xwiki/bin/view/Extension/Junco+Skin#HTheme:Coli… This vote mail is about this difference. What to consider: A. Freshness Advantages of Flamingo is that its interface is centered around Applications (it has a new left panel used for navigation). It will provide a visual difference from Colibri and looks more similar to current applications found in the wild. Advantages of Junco is that it provides Themes. Junco's Themes are very similar to our current ColorThemes, the difference is that they can change also the font used, the colors and can also add some esthetic effects (gradients, borders, shadows, etc. - CSS effects) to Bootstrap's components (buttons, navbars, alerts, tables, etc.). But except minor changes, the layout is similar to Colibri. Improvement consist in using refreshed style for font, forms, buttons, messages, etc. B. Extensions Integration One of the reasons I choose to make Junco similar to Colibri was extensions integration. The advantage of XWiki is that you can extend it how you like. The problem is that because the extensions are developed by our community (and not by a single entity) each application is providing it's own style. On extensions.xwiki.org we have applications that provide an unique style, while others are build around and for Colibri. Adding a new skin with a different style (like Flamingo) will make current extensions not look unitary. This problem is more general than just this Colibri/Junco/Flamingo discussion and it the problem of having extensions that adapt to the skin used (without creating special versions for each skin). Junco was created to look similar to Colibri (preserving layout, style, colors) while updating the 'back-end' (created on Bootstrap, it will put at developer's disposal the Bootstrap's guide style and components). One of the reasons we are having this extensions 'incompatibility' is because we are lacking visual standards and guides (maybe using the ones provided by Bootstrap can improve this area - I will send a separate mail about the CSS Framework selection). So from the style standards perspective having Junco integrated first could represent a transition step between our current Colibri and a new skin with a different look, because the developers might use Bootstrap style/structure guides in their extension development (not guaranteed). C. Parallel skin support Another advantage of Junco is that (by having the same layout) is using the same templates as Colibri. Having just a set of templates to maintain is very important from a development perspective especially if your development resources are limited. This is one of the reasons XWiki is not supporting multiple default skins. Flamingo will need some templates changed, so important from a development time and maintenance perspective. So this vote is about: 1. Keep Colibri's current look which is supported by the Junco skin, or 2. Have another look for 6.x which is proposed in the Flamingo skin Thanks, Caty

4 8

[xwiki-devs] [Contrib] Requesting a project for CAS authentication
by Petr Abrahamczik 25 Feb '14

25 Feb '14

Hello, I would like to request for a project that adds Jasig CAS (http://www.jasig.org/cas) authentication support to the XWiki. We started using XWiki in our organization and we are using a CAS authentication. So I developed CAS authentication module to the XWiki and I would like to share it on XWiki Contrib. I would like to request for GitHub access. My GitHub user name is pabro. Name: XWiki Authenticator CAS Description: XWiki authenticator based on Jasig CAS. It supports CAS 2.0 and SAML 1.1 protocol. SAML protocol can be used for attributes and group membership synchronization. Petr Abrahamczik

2 1

[xwiki-devs] [Discussion][Skin] Less vs. Sass vs. Velocity
by Ecaterina Moraru (Valica) 22 Feb '14

22 Feb '14

Hi, As part of the 6.0 Roadmap we have as entry the creation/integration of a new Skin inside XWiki. Currently there are 2 proposals for the new skin: Flamingo http://design.xwiki.org/xwiki/bin/view/Improvements/Skin4x Junco http://design.xwiki.org/xwiki/bin/view/Proposal/JuncoSkin Both proposals are done using Twitter's Bootstrap framework ( http://getbootstrap.com) Bootstrap officially is written using Less ( http://www.lesscss.org/ ) and is the default pre-processor they support. There is also a Sass ( http://sass-lang.com/ ) version for Bootstrap ( https://github.com/twbs/bootstrap-sass ) so the idea is that the preprocessor variant is not limiting us in integrating Bootstrap. The question we discuss in this thread is what preprocessor we should integrate in platform when we integrate Bootstrap (that in the case we integrate either of these tools). Currently Junco's extension is done with Bootstrap + Less. My decision to use this combination was done after a light research and mostly based on a personal preference of the Less language. We are having this preprocessors discussion so late (they appeared in 2007-2009) because we didn't really need a preprocessor until now. The base functionality they add we solved by using Velocity (we have CSS3 prefix macros defined in macro.vm that are similar to the compatibility mixins provided by Bootstrap, we have also a ColorThemes variables solution for reusing color values and because we can have Velocity code inside our stylesheets we cover most of the functions&operations need). The only downside for us using Velocity to do these kind of things is that the functionality we cover is very basic and was done only if we had a certain need. This is not necessarily a bad thing but it's kind of a limitation for external developers that might want to make more complex things. Less and Sass community members are very active and they make sure their functionality is tested and covers most of the cases. Also there are some features (like extends, etc.) that would be hard for us to duplicate in Velocity. Just as a note, adding Less doesn't mean we are replacing Velocity. We are just replacing the CSS things done in Velocity with Less functionality. Replacing Velocity with another templating engine should be the topic for another thread (in case we are considering this). If we integrate Less, what is currently done with CSS+Velocity will be done using Less(CSS)+Velocity(less code). If we integrate Sass (because Sass also has control directives) we transform CSS+Velocity in Sass(CSS)+Velocity(even less code) but the API calls will still need to be added with Velocity (so still we will not have just Sass). One of the problems with the preprocessors is that they depend on Javascript or Ruby (there are some versions also on Java in case of Sass, but not officially maintained). So first we need to find a solution to compile Less/Scss files into CSS, inside our platform. If you make a Google search you'll see that there are much more 'recommendations' to pick Sass over Less. One remark regarding this is that we need to understand that right now Sass is used on a different technologies stack (mostly for Ruby applications). Sass is very attractive because of its power. But what we need to ask ourselves is if we need the full power of Sass (because some of it is already covered by Velocity). Personally I prefer Less, but that's because of the separation of concerns (structure, presentation, behavior). I prefer the limitations Less has (regarding control structure) in order to not be tempted to write logic with a language that is not supposed to do that (even though it can). Preprocessors should be used exclusively to write CSS and especially to write it more rapid (nesting, mixins). Also Less syntax is more close to default CSS syntax, which IMO is a big plus. But because of its power, Sass could be in the future the new 'JQuery', since right now it has a bigger community. One of the advantages of picking a technology later is that at least you see some clear candidates (and we don't need to consider other preprocessors like Stylus, etc.). Let me know what you think. Thanks, Caty

3 5