- xwiki-devs@xwiki.org - lists.xwiki.org

[xwiki-devs] JIRA cleanup for missing fixversion
by Vincent Massol 11 Feb '13

11 Feb '13

Hi guys, Can you help me fix all those issues that are missing fixfor? http://jira.xwiki.org/secure/IssueNavigator.jspa?reset=true&jqlQuery=status… Thanks -Vincent

3 5

[xwiki-devs] [VOTE] Skip tests while building a release
by Eduard Moraru 09 Feb '13

09 Feb '13

Hi devs, Well, the subject pretty much sums it up. I am proposing to skip any testing while building a release, since that is the job of the CI infrastructure and, it happened more than once for the build of the release to fail because of a flickering test. This is really annoying for a release manager that has to start over the entire build (since right now it's a real pain to alter the scripts to continue the build). Besides this, tests (specially the functional ones added into platform) uselessly delay the build, thus, the release. Note: We are already skipping tests for enterprise and manager. This vote is actually about skipping tests for commons, rendering and platform as well. Here's my +1. Thanks, Eduard

5 8

[xwiki-devs] Provide translations in JAR extensions
by Thomas Mortagne 09 Feb '13

09 Feb '13

Hi devs, The last piece missing to the new localization framework for 4.x is to allow providing translations in a jar extension. Here are some ideas: 1) Continue with ApplicationResources_*.properties files but loads it from everywhere instead of taking the first one we find like now 2) Same that 1) but place it somewhere a bit "cleaner" like org/xwiki/localization/translation_*.properties 3) Completely different system. I looked a bit if any simple de facto standard was already existing but was not obvious. Keep in mind the localization framework allow providing any source so it's easy to move/add a new way to get translations in jar extensions later without touching the API so while it would be better to do something good it's mostly implementation details and whatever we choose we are not going to be stuck with it forever. WDYT ? I would go for 2) (I'm +0 for 1)) with org/xwiki/localization/translation_*.properties for 4.x and keep 3) for later when we have some time to work on it a bit more. -- Thomas Mortagne

4 7

[xwiki-devs] Fwd: [xwiki-infra] vxwikiorgfarm: wiki is not responding!(real URL)
by Caleb James DeLisle 09 Feb '13

09 Feb '13

20 threads blocked on: at com.xpn.xwiki.render.DefaultVelocityManager.getVelocityEngine(DefaultVelocityManager.java:177) - waiting to lock <0x637cbe38> (a com.xpn.xwiki.render.DefaultVelocityManager) at com.xpn.xwiki.render.XWikiVelocityRenderer.evaluate(XWikiVelocityRenderer.java:105) https://github.com/xwiki/xwiki-platform/blob/master/xwiki-platform-core/xwi… The holder of this lock calls context.getWiki().getSkinFile("macros.vm", skin, context); and context.getWiki().exists(skin, context), both of which potentially access the database while holding a global lock. Looks like some delicious low hanging fruit to me. Thanks, Caleb Original message removed because it is too big for the list. See it here: https://ezcrypt.it/4H5n#8mjU1voDtZsANw9vsLa8WM8Y

2 1

[xwiki-devs] [Contrib] Classification Extension
by Thomas Delafosse 08 Feb '13

08 Feb '13

Hi devs, I would need a contrib repo for an extension I've developped for USH. It is called Classification and enables to create easily a classification plan with categories and sub-categories. Apparently such a feature is often needed on client project, so I hope it could be useful. Thanks, Thomas

3 3

[xwiki-devs] [VOTE] Get rid of Portlet API in oldcore
by Thomas Mortagne 08 Feb '13

08 Feb '13

Hi guys, oldcore contains references to Portlet API 1.0 in various API. There is several issues: 1) Thoses API are useless since most of the code expect a servlet and would never work inside a Portlet so that make this API totally useless 2) It's a real pain for things like https://github.com/xwiki-contrib/sandbox/tree/master/xwiki-portlet (a portlet proxy/translator in front of XWiki) since it makes impossible to use Portlet API 2.0 (we had to create our own special branch were we remove all reference to 1.0 API in oldcore) 3) XWiki cannot work without the portlet jar even when used as Servlet which is quite ugly Since we are starting a new major version and it's a breaking change I propose to do it now. Here is my +1 -- Thomas Mortagne

4 5

[xwiki-devs] [Contrib] xwiki-application-mailarchive
by Jeremie BOUSQUET 08 Feb '13

08 Feb '13

Dear community, I would like to request for a new contrib project to store the Mail Archive application I'm currently writing. Name: xwiki-application-mailarchive Description: A mailing-list archive application. - For now a GitHub project to store sources should be fine. My username on GitHub is "jbousque". - For Jira it might be useful to have a project once the application is released "officially", that is still not the case. Meanwhile the generic project is ok for me. - There is a specific page in Design space on xwiki.org : http://dev.xwiki.org/xwiki/bin/view/Design/MailArchiveApplication , but for now no extension has been added. I would like if possible to test my extension (automatic install with dependencies) before publishing it The Design page also gives some info about the current state and progress, and some screenshots. There is many remaining work, but it begins to look like something usable. The bad side is the lack of unit tests most of all ... A question : the groupId "org.xwiki.contrib" is to be used, do I have to use this exact groupId or can there be sublevels if needed ? If so I would use org.xwiki.contrib.mailarchive as groupId. Thanks, Jeremie

6 87

[xwiki-devs] [Idea]"Community" flavor
by Jeremie BOUSQUET 07 Feb '13

07 Feb '13

Hi xwiki devs, Don't know if it's really the right place, but something strikes me when re-reading the thread about XWiki development flavor, fosdem feedback from Ludovic, last extensions posted on xwiki.org, and my own requests / use-cases I have in my office ..., and I just wanted to share my thoughts with no particular expectation. At least in my office, the "big thing" these days is community building. The intent to materialize "communities", that could be around subjects as business interests, technical interests, skills, ... Currently our difficulty is that we have some "bricks", but they are spread amongst several tools and not integrated. For example mailing-lists were defined in mail server (in fact, distribution lists with owner), the reason why I created the MailArchive application in first place, to archive these mails somewhere browsable and searchable. But when I see the "Newsletter application", the "Meeting application", the Workspace feature, I can't help but think that ideally all these should/could be linked together to materialize that "community" thing. For example community members could be a ldap or xwiki group of users. Shared space for the community could be a xwiki Workspace, with workspace owner as guardian. Newsletters templates could be automatically generated for that community, using community members as first newsletter target (using a mailing-list address or a list of distinct persons). Other persons of a community could have a "view" access to it (workspace, newsletter targets) if they decide to (or are volunteered into by community owner). The workspace of a community could come from a template, showing configured newsletter, and a default mail archive with view on specific mailing-list(s) for that community. There could be a documentation part (space?) with easy export to .doc/.pdf of multiple pages. The "topics" of that community could be materialized as blog categories, and suggested as tags for othere pages... That "flavor" would not be particularly "social" (meaning, connected with facebook...) nor "dev", still reuse existing components and add some glue between them. As far as I know it could be merely a Workspace template, but I don't know if such workspace template could easily be packaged and contributed as an extension (should be). Comes also the idea that "flavors" could have some hierarchy, for example, the "dev" flavor could be built on top of such "community" flavor, extending it with other specific integrations (jira, ...). Also brings the idea of optional dependencies between extensions. Is there an (easy) way to know, for an extension, if a prerequisite extension is installed ? (something from EM public API for example). Currently I just check for specific page existence, or for specific $service... call, to infer that another extension is already installed. For example you could decide to create meetings from mail archive app, if and only if the Meeting application is already installed. Integration of remote systems is nice, but cross-integration of existing extensions would be even nicer to start with :-) BR, Jeremie

2 2

[xwiki-devs] FOSDEM Feedback
by Ludovic Dubost 07 Feb '13

07 Feb '13

Hi, We were 9 xwikiers at FOSDEM this week-end and I wanted to take the occasion to give some feedback on what I saw there. The Community Dev Room ----------------------------------------- First XWikiers participated in the devroom co-organized by Sergiu: "Community Development and Marketing". The great news is that the room was full quite a big amount of the time. It was not a huge room but well placed (in the "original" area of FOSDEM which is still quite active). I think it shows more and more interest of people for this subjects which are less usual at FOSDEM which is very technological. Kudos to Sergiu for co-organizing this dev room. There was also a keynote from Kohsuke Kawaguchi (creator of jenkins) on how the jenkins community was build which was on a similar subject as the dev room (I'll give some feedback on the talk below). Sergiu has a presentation about "how to cope with a proliferation of tools in your community" which presented how XWiki can be used to be a portal to all the contents of all the tools you have in your community (aka "the dev flavor). The content of the talk was great but to my taste it was really missing screenshots to show practically what happens. There was a mini demo at the end but it was not enough to really make people realize how great xwiki.org is :) But the idea of the presentation is great and if we can spend a bit of time to not necessarly make the flavor, but publish the different pieces of xwiki.org as extensions, including some simple macros we are using (like how we integrate nabble). There was the 1M$ question of if we can migrate existing wikis to which we could have answered a bit better as we do have a few migrators for some specific wikis (Mediawiki, dokuwiki) but nothing fully done and fully generic. This is another area were we could spend some time making some specific migrators easier to use. If there are any contributors that would like to help out improving and publishing the migrators and "dev extensions" on extension.xwiki.org as well as document how other communities could use our tools, it would be very useful to help spread the XWiki work out there. Sergiu should publish his slides and maybe somebody can improve them with screenshots. Vincent and myself had a "devil (business) and angel (open source)" presentation on "Combining Open Source ethics with private interests". 20 minutes was a bit short to cover this subject fully in details but it was great to be able to share our experience on this. The room was quite full when we did this presentation and there were a few questions which I believe showed the interest of participants with this subject. Vincent will publish the slides although it's not easy to follow without the additional "talking". We should definitively try to do this again. MySQL and Security ------------------------------ I attended a few MySQL presentations as well as some security presentations. There seems to be some interesting improvements in InnoDB in MySQL 5.5 and 5.6 (currently RC) and even MariaDB and Percona have some work that improve InnoDB (with XTraDB). As we are planning to work on performance we should look into testing how XWiki behaves on MySQL 5.1 to 5.6 and compare the performance also with Postgres. In any case we should follow what is happening in this area. On security there was a presentation about OWASP ZAP ( https://www.owasp.org/index.php/OWASP_Zed_Attack_Proxy_Project) and attack proxy to test the security of Web Applications. This is something to look at for the Thomas D's coming work on security. Kohshuke presentation on Jenkins community ------------------------------------------------------------------- On the "community" subject there was interesting presentations about "how to cope with assholes in your community" and the presentation of Kohshuke. To summarize very quickly while Kohshuke says part of the big reasons why jenkins has been succesful is "good software" and "being there at the right time" he would like to believe that the way the community is run and the software is architectured has a lot to do with this success. Some important items: - small core with apis, many extensions, extensions are "first-class citizens" of jenkins - very extensible - very open to contribute an extension with almost automatic commit right (with an IRC bot to get a rights) What we can learn for XWiki ----------------------------------------- There are a few things to learn here for XWiki I believe: XWiki has a lot of what is said here, particularly the extensibility but we could "finish" things a bit more with these learnings in mind. XWiki is very extensible in many areas (but not all, like the old core). It is very easy to publish an extension, particularly a XAR file on extensions.xwiki.org and we have extension manager to install this extension. However there are a few things we can do better: 1/ On the java side, contributing is still difficult. The core is still big and not well defined. In the "platform" repository we have many different things, including modules that are not vital to the XWiki core and that could be maintained by contributors. Our development rules and methodologies are very "strict" when it comes to the "platform", "commons" or "rendering" and since many many things are published there it's not easy to participate there. If we separated a bit the "real core" from the additional modules that depend on the core apis but are not as critical to the core, and we move the additional modules to an area with potentially less stricts rules of development and where each developer can decide his own rules, maybe we would greatly improve potential contributions. It's also a question of how we "consider" the extensions and we publish information about them and recognize them when they end up in the default install. More on this below. 2/ On the xar/scripting side, it's "almost" easy to publish something and make it available thanks to EM but there are a few quirks that we need to solve: - Exporting a XAR is not fully supported by the core (we need Admin Tools and it's not enough documented). - Committing your work is not easy which makes it more complicated to get contributors to extend an existing extension. But the good news is that we are quite close: - AppWithinMinutes has an extension to publish an application on Extension Repository - SVN and GitHub app allow to commit XWiki pages - Maven allows to build and release an XWiki app - Admin Tools has ways to export multiple pages - XEM code has an "Application Descriptor" which could be useful for not AWM code If we bind all these together a bit more we can have a killer. Let's image the following: 1/ In an admin area you go to "Extensions" and you have a button to "create a local extension" and can add XWiki pages to your extension which would add your pages to an "Extension descriptor" 2/ AWM would automatically use this extension descriptor. 3/ You would have a way to: - ask for a git repository for your extension - commit your extension from XWiki - release your extension from XWiki and publish it on extensions.xwiki.org - allow another user to install this extension using EM and then decide to fork it, modify it and commit the changes and create a pull request for the changes - finish the contribution loop 4/ On extensions.xwiki.org you could see who the contributors are for the extension and what they committed. Then you have an even more powerful way to contribute to XWiki, wether it is an AWM application or just a snippet of code. Aside from that we should make it a bit easier through documentation or tools mainly) to publish java code as it is still slightly complicated to make it easily installed using EM. More important even would be to continue improving AWM to make it easier to add Javascript, CSS or REST apis to an application but this is another story for more complex applications. This is food for thoughts to allow XWiki to get more help from new committers which is a great solution to help XWiki spread more. On the spreading subject, I also think we should make more effort to publish some "mashup" macros or snippets and publish them both on extensions.xwiki.orgas well on the other projects extensions or plugins pages. This would help show how easy it is to integrate XWiki with other tools. I was quite happy with this year's FOSDEM. It's getting more and more interesting. Open Source is alive and kicking. We could push for happing a "Web Application Dev Room" (we tried to get a "wiki one"), as there is not much on this subject. There was a "web development" track but it was a bit empty. Maybe this is an area to work on to get Wikis, CMS tools, Web and Javascript frameworks presented. Ludovic -- Ludovic Dubost Founder and CEO Blog: http://blog.ludovic.org/ XWiki: http://www.xwiki.com Skype: ldubost GTalk: ldubost

4 4

[xwiki-devs] [PROPOSAL] Include require.js in XWiki by default and make jQuery available through require.js.
by Caleb James DeLisle 07 Feb '13

07 Feb '13

Hi, I'd like to add require.js to XWiki to be included in every page just before prototype.js. I would also like to add jQuery to our resources directory but only make it available to scripts which "pull it in" using require(). I have come to the conclusion that jQuery is a de-facto standard and even if we don't port to it, we should make it available to our users. Require.js is an implementation of the Asynchronous Module Definition standard which will allow us to use both jQuery and prototype relatively harmoniously. I think it's obvious that if javascript rich webapps are going to scale, they need modularity and I've reviewed AMD and the main competitor CommonJS and concluded that AMD will provide the user with better page load time by asynchronously loading modules according to a dependency tree while CommonJS blocks on each call to require(). I would like to see us move away from prototype but it provides more functionality than jQuery including an OOP framework and while there are other libraries which show promise, I don't feel right proposing a best practice without first porting some code to it to see what issues arise so IMO we should begin using require.js but accept that prototype still has it's place. So I propose: Include require in the header vm. Include jQuery but only if a script "require()'s" it. Establish a best practice of using require() and define() instead of global variables but accept that prototype.js still has it's place. WDYT? Caleb miscellany: ------------------------------ require.js vital statistics: Dual licensed BSD and MIT. Latest Release: 2.1.2 1,993 lines before minification 24,621 lines in every .js file in the /tests/ directory. Used by: https://github.com/adobe/brackets/ https://github.com/ajaxorg/cloud9 (https://c9.io/) http://browserquest.mozilla.org/ http://www.bbc.co.uk/frameworks/barlesque/examples/global/requirejs http://www.officejs.org/ ----------------------------- Optimization: require.js comes with a tool for linting, compiling (using Closure Compiler), and linking AMD modules together based on their dependencies. Complex projects with many js files can be can be compiled into a single "statically linked" js file. It supports Rhino so it could be included in the maven build. ----------------------------- My experimentation with require.js: I use the require.js legacy shim to make jquery.sheet function as a require.js module without making any direct changes to jquery.sheet. I was able to move the code from XWiki to the filesystem (file:///) a total change of the directory structure and only needed to change the main example.html file. I was able to include the content in an iframe simply by defining a require.js plugin see: http://requirejs.org/docs/plugins.html for loading through an iframe and changing the require() call to require the iframe'd sheet. https://github.com/cjdelisle/jquery-sheet-amd

5 4