xwiki-devs December 2012

xwiki-devs@xwiki.org

25 participants
57 discussions

[xwiki-devs] Fwd: [xwiki-infra] vxwikiorgfarm: wiki is not responding!(real URL)

by Caleb James DeLisle

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

11 years, 10 months

[xwiki-devs] [Contrib] xwiki-application-mailarchive

by Jeremie BOUSQUET

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

11 years, 10 months

[xwiki-devs] [PROPOSAL] Include require.js in XWiki by default and make jQuery available through require.js.

by Caleb James DeLisle

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

11 years, 10 months

[xwiki-devs] [UX][Proposal] Skin 4.x

by Ecaterina Moraru (Valica)

Hi devs, I've been working in the 4.3 Roadmap for a new skin proposal. You can see it at http://incubator.myxwiki.org/xwiki/bin/view/Improvements/Skin4x I recommend looking at the "Annotations Overview" gallery in order to see the different elements of the skin and some explanations. I've made also separate pages for different components of the skin. For example, you can see more information about how the menus work at http://incubator.myxwiki.org/xwiki/bin/view/Improvements/Skin4xMenus For each component you can also see how the elements scale and see the responsive layout. For the record, the proposal is made by using Bootstrap ( http://twitter.github.com/bootstrap/). Thanks, Caty

11 years, 10 months

[xwiki-devs] [PROPOSAL] So what do we do for our Maven projects names

by Thomas Mortagne

Hi devs, In order to automate the update of extensions imported from https://github.com/xwiki/ we need to have nothing to modify when an import is done. The last remaining thing is the name on which there is a debate is the name. Right now the name we have in our maven project looks like "XWiki Commons - Extension - Repository - Maven" so that's what we get when importing this project or when viewing it in EM UI. Some of us want to keep this idish name for Maven build but don't like it when displaying extension. I recently introduced a way to overwrite some extension related informations like the name based on properties. So here are the choices we have: 1) Do nothing which mean display "XWiki Commons - Extension - Repository - Maven" in EM UI and extensions.xwiki.org 2) Change our naming in Maven <name> property for it to be more a name than an id that would looks good in EM UI 3) Keep the same naming for Maven <name> and overwrite it everywhere using <xwiki.extension.name> property So, WDYT ? The one that makes the more sense to me is 2) so my +1 goes to this one. Frankly I don't care too much having the current id based display of the summary of built modules in Maven build and I personally won't have any issue to know what name correspond to what project (but that's because I know them well, I can understand new dev could be a bit more lost). Then: * +0 for 3) to +0 (I don't like too much having this special case everywhere in our Maven pom.xml) * -0 for 1) (I agree that it does not looks very nice as a display name). -- Thomas Mortagne

11 years, 11 months

[xwiki-devs] [Reminder] Bug Fixing Day #8 this Thursday 6th of December

by Vincent Massol

Just a reminder. See http://dev.xwiki.org/xwiki/bin/view/Community/DevelopmentPractices#HXWikiDa… Thanks -Vincent

11 years, 11 months

[xwiki-devs] [VOTE] Start using Mockito instead of JMock

by Vincent Massol

Hi devs, This week end I've been (at last) experimenting with Mockito (http://docs.mockito.googlecode.com/hg/latest/org/mockito/Mockito.html) and it's been successful so far :) I've converted a first test to use it as a demonstrator of its power (http://jira.xwiki.org/browse/XCOMMONS-316): https://github.com/xwiki/xwiki-commons/commit/7b45b48de1c6915294736dfddda74… I'd like to propose to start using it and start writing our tests with it since: * It's very easy to use. I was able to very simply migrate an existing test to it * It makes our tests much more readable to read and maintain IMO because 1) there's less boilerplate code, 2) it provides default values for mocks and 3) no more of ugly expectations syntax * It's powerful, just see http://docs.mockito.googlecode.com/hg/latest/org/mockito/Mockito.html * It's actively maintained and developed, see http://code.google.com/p/mockito/downloads/list and http://code.google.com/p/mockito/source/list and http://code.google.com/p/mockito/people/list After we've written/converted a few tests (let's say in 1 month or so) we can really decide if we like it and make it our official mocking tool or if we should go back to JMock (but I have little doubts ;)). WDYT? Thanks -Vincent

11 years, 11 months

[xwiki-devs] [Contrib] Repository request: multipagepdfexport-application-spaceexport

by Anca Luca

Hi all, I am about to contribute an application I made to provide an UI for multipage pdf export ( http://extensions.xwiki.org/xwiki/bin/view/Extension/Multipage+PDF+Export ) to help export pages in a space, displayed in a hierarchy like UI (using the hierarchy macro), and, after long reflection, I decided to put this application in its own repository (another option would have been to put it in the multipagepdfexport repository already existing). The choice is motivated mainly by the need to version it independently. Repository name: multipagepdfexport-application-spaceexport User name: lucaa Thanks a lot, Anca Luca

11 years, 11 months

[xwiki-devs] [Proposal] Use the XWiki.org JIRA project more

by Vincent Massol

Hi devs, I'd like to propose that we use the XWiki.org JIRA project more: http://jira.xwiki.org/browse/XWIKIORG The idea is to create issues in it whenever we see stuff to improve on xwiki.org. I'm also proposing to do the following actions: * Modify it in JIRA so that this project doesn't have any Affects and Fix for fields. The idea is to simple have a list of issues and no releases. * Add some documentation on the contribution page on xwiki.org to explain that creating jira issues for stuff to improve on xwiki.org is a way to contribute too * Send an email to the users list asking people to create jira issues for stuff to improve on xwiki.org * Modify the xwiki.org feedback form on xwiki.org to ask users to create jira issues for stuff they'd like to see improved * Move documentation located in JIRA Platform project (and possibly others) to the XWiki.org JIRA project Are you ok about this? Once this is all done I'll send another email to propose to start again the Doc Days (say one per month). Thanks -Vincent

11 years, 11 months

[xwiki-devs] Fwd: [ANNOUNCE] Apache Lucene 3.5.0 released

by Vincent Massol

fyi, we might want to upgrade for 3.4 for example. -Vincent Begin forwarded message: > From: Simon Willnauer <simonw(a)apache.org> > Subject: [ANNOUNCE] Apache Lucene 3.5.0 released > Date: November 27, 2011 2:40:07 PM GMT+01:00 > To: announce(a)apache.org > Reply-To: simonw(a)apache.org > > November 27 2011, Apache Lucene™ 3.5.0 available > > The Lucene PMC is pleased to announce the release of Apache Lucene 3.5.0. > > Apache Lucene is a high-performance, full-featured text search engine > library written entirely in Java. It is a technology suitable for nearly > any application that requires full-text search, especially cross-platform. > > This release contains numerous bug fixes, optimizations, and > improvements, some of which are highlighted below. The release > is available for immediate download at: > > http://www.apache.org/dyn/closer.cgi/lucene/java (see note below). > > See the CHANGES.txt file included with the release for a full list of > details. > > Lucene 3.5.0 Release Highlights: > > * Added a very substantial (3-5X) RAM reduction required to hold the > terms index on opening an IndexReader. (LUCENE-2205) > > * Added IndexSearcher.searchAfter which returns results after a > specified ScoreDoc (e.g. last document on the previous page) to > support deep paging use cases. (LUCENE-2215) > > * Added SearcherManager to manage sharing and reopening IndexSearchers > across multiple search threads. Underlying IndexReader instances are > safely closed if not referenced anymore. (LUCENE-3445, LUCENE-3558) > > * Added SearcherLifetimeManager which safely provides a consistent > view of the index across multiple requests (e.g. paging/drilldown). > (LUCENE-3558, LUCENE-3486) > > * Renamed IndexWriter.optimize to forceMerge to discourage use of > this method since it is horribly costly and rarely justified > anymore. (LUCENE-3439) > > * Added NGramPhraseQuery that speeds up phrase queries 30-50% > when n-gram analysis is used. (LUCENE-3426) > > * Added a new reopen API (IndexReader.openIfChanged) that > returns null instead of the old reader if there are no changes > in the index. (LUCENE-3464) > > * Improvements to vector highlighting: support for more queries > such as wildcards and boundary analysis for generated snippets > (LUCENE-1824, LUCENE-1889) > > * IndexSearcher and IndexReader now perform additional checks to > throw AlreadyClosedExceptions if searches are performed on a > closed IndexReader. Performing searches on already closed reader > can cause JVM crashes when invalid memory mapped files are > referenced. > > * Several bugfixes, including a bug where closing an NRT reader > after the writer was closed was incorrectly invoking the > DeletionPolicy. See CHANGES.txt entries for full details. > > Note: The Apache Software Foundation uses an extensive mirroring network for > distributing releases. It is possible that the mirror you are using may not > have replicated the release yet. If that is the case, please try another > mirror. This also goes for Maven access. > > Happy searching, > > Apache Lucene/Solr Developers

11 years, 11 months

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

2005

xwiki-devs December 2012