November 2011 - xwiki-devs@xwiki.org

[xwiki-devs] [VOTE] Codestyle convention: variable used for discarding output
by Sergiu Dumitriu 22 Nov '11

22 Nov '11

Hi devs, Some methods must be captured so that they don't create output when called from velocity, usually with something like: #set ($var = $obj.doSomething()) Where $var is a variable whose content isn't needed and won't be used. And everyone seems to have his favorite name for it: $discard, $ok, $ignore... I'd like to have a single variable name, so that in the end we don't end up creating 5 different variables for the same goal. So, which one do you prefer: 1. $discard 2. $discarded 3. $ignore 4. $ignored 5. $ok 6. $output $ok is the shortest, thus easier to type, faster to parse, and lighter on the total size of the wiki. On the other hand, I prefer $discard since it's more meaningful, it conveys exactly what that line does: "$discard the output of this method call". -- Sergiu Dumitriu http://purl.org/net/sergiu/

12 22

[xwiki-devs] [proposal] Move xwiki-store-datanucleus and Datanucleus-Cassandra-Plugin into xwiki-contrib repository.
by Caleb James DeLisle 22 Nov '11

22 Nov '11

Hi, I'd like to get the XWiki on Cassandra project to be in contrib and get it building on Jenkins as soon as possible. Unfortunately the Jenkins build requires integrating some changes into xwiki-store-filesystem-attachments which are now in the xwiki-store-legacy branch. Todd Nine's Datanucleus-Cassandra-Plugin is nolonger being maintained by him, it is the only existing Datanucleus Cassandra plugin and my fork contains extensive changes. It is licensed under the Apache 2 license and I would like to include it as well. I would like to do this: 1. Move the repositories into contrib. 2. Bring the changes in the xwiki-store-legacy branch up to date and merge them into the trunk. 3. Start automated builds of Datanucleus-Cassandra-Plugin, and xwiki-store-datanucleus. WDYT? Caleb

7 6

[xwiki-devs] Updated Yourkit license
by Vincent Massol 21 Nov '11

21 Nov '11

Hi guys, FYI I've asked for and received new YourKit licenses :) I've updated the protected page: http://dev.xwiki.org/xwiki/bin/view/Community/DevelopmentToolLicenses Thanks -Vincent

1 0

[xwiki-devs] XWiki logo around
by coldserenity 20 Nov '11

20 Nov '11

Hi, I remember once there was a contest for new XWiki logo but due to elections fail (there would have been too many unsatisfied people if any of newly suggested logos had been approved) the process has gracefully ended (which, in my opinion, was a good decision) I also think that it would be worthless to conduct another competition/election amongst users because as the saying goes - tastes differ. The only thing users can contribute are their ideas (which might be accepted or might not which is fair) regarding shapes and symbols to use. Decision about visual design should be made within very very small circle of visual designers probably with one or two people involved in the project to chill down designers' burning imagination :) Having all of the above said, I would suggest to collect a set of shapes and symbols for new XWiki logo each supplied with description of underlying meaning. And then (having revised all of the comments in some of the former posts regarding what new logo should be: symmetric/asymmetric, complex/simple, round/firm) provide all that to a designer to draw several sketches. And then by internal vote (at maximum the development team members involved) choose the new logo. This thread is for storing all of the ideas on the new XWiki logo. At least that's what I (as a user) will be using it for may any ideas to come. Join :) Regards, Roman -- View this message in context: http://xwiki.475771.n2.nabble.com/XWiki-logo-around-tp6074956p6074956.html Sent from the XWiki- Dev mailing list archive at Nabble.com.

1 2

[xwiki-devs] Jetty load time analysis
by Vincent Massol 18 Nov '11

18 Nov '11

Hi devs, I've been finding that Jetty takes a lot of time to start lately. So I've run some profiling on it. Starting Jetty (till the STARTING message) takes 15 seconds on my machine (in debug mode, we win 3 seconds, ie 12s start time), split like this: * 50% of the time spent scanning jars in WEB-INF/lib (JarInputStream.getNextJar()) - 7s * 10% in Jetty itself - 2s * 40% in our code in Extension Manager init (2.5s) and in Component registration from their annotations (2.5s) - 5s If I remove the start of the EM in XWikiServletContextListener, we start in 7 seconds (instead of 15s) If I try to start Jetty without any webapp, it starts in 500ms. If I remove the oldcore legacy jar (2.5MB) we win 1 second in start up time. Note: This is all before XWiki.init() is called on the first request. Analysis of ComponentAnnotationLoader (2.5s): * 1.2s just loading classes from the CL * 1s getDeclaredFields (reflection API) * 800ms initializing SLF4J Analysis of Extension Manager init (2.5s): * In DefaultCoreExtensionScanner.loadExtensions(): ** 500ms URL.toURI() ** 500ms MavenXpp3Reader.read() - POM reading ** 150ms org.Reflections scanning ** 150ms resource loading from CL (getResourceAsStream()) * In DefaultExtensionLicenseManager.initialize() ** 314ms in org.Reflections * 130ms of loading xwiki.properties Conclusion ========= * XWiki's size in number of JARs and their sizes makes it long to start Jetty. * We could make some small optimizations in EM and Component loading but we wouldn't win that much, on the order of 2s in total (i.e. 15% of total load time) Thanks -Vincent

4 6

[xwiki-devs] [Release] Status of the release
by Sergiu Dumitriu 18 Nov '11

18 Nov '11

Hi devs, The 3.3 Milestone 2 release was supposed to happen this past Monday, but the codebase hasn't been stable enough for a release (failing tests, hot commits triggering comments, unmerged branches). Proposal 1: Release 3.3 RC 1 next Monday, 21 November, effectively dropping Milestone 2. This respects the initial schedule, although some of the targeted features won't be fully usable. This means that everyone should try to get their code stabilized. Proposal 2: Lengthen the release by another week, releasing: - Milestone 2 next Monday, November 21 - RC1 on November 28 - Final on December 5 I'm fine with either one, if the codebase is stable enough for a RC by next Monday. -- Sergiu Dumitriu http://purl.org/net/sergiu/

6 5

[xwiki-devs] [Proposal] Setting Maven <url> elements
by Vincent Massol 18 Nov '11

18 Nov '11

Hi devs, Since we're going to use Maven POM metadata to display extensions in the Extension Manager UI it's important that we have all data filled and with correct value. Sergiu pointed to me that currently our website <url> are wrong. This is because the top level POM has <url>http://xwiki.org</url> and Maven automatically suffixes it with artifact Ids. For example for Commons Component API this gives us: <url>http://xwiki.org/xwiki-commons-pom/xwiki-commons-core/xwiki-commons-compone…</url> which is not pointing to anything valid. I see 2 ways of fixing this: Solution 1 ======== Do as I started this morning, i.e. set the <url> explicitly. For example I've set PHP Macro module URL this morning to <url>http://extensions.xwiki.org/xwiki/bin/view/Extension/PHP+Macro</url> and Commons Observation API (the 3 modules: parent + api + local) to <url>http://extensions.xwiki.org/xwiki/bin/view/Extension/Observation+Module</url>. Pros: - Easy and we can point to wherever the documentation is located Cons: - Tedious - Fragile. If we rename a page on the wiki then the link is broken Solution 2 ======== Set the top level URL to something like: <url>http://xwiki.org/documentation?id=</url> For example for Commons Component API this will generate: <url>http://xwiki.org/documenation?id=/xwiki-commons-pom/xwiki-commons-core/xwik…</url> Then: * Have an apache redirection for /documentation to some wiki page such as http://xwiki.org/xwiki/bin/view/Main/ModuleDocumentation * Have the logic inside that page to transform paths (such as "/xwiki-commons-pom/xwiki-commons-core/xwiki-commons-component/xwiki-commons-component-api" into proper URLs). Since I don't think we can have a generic logic, I'd simply put a big hashtable to start with. Pros: - Simple, no need to modify all poms. We only need to change the top level pom <url> value - Much easier to keep up to date since when we rename pages all we need to do is edit the ModuleDocumentation page. Actually when we support page renames across wikis we could have the links in that page be automatically renamed ;) With Solution 1, when you rename the URL you need to re-release the module which is a big pain. Cons: - I can't see any really :) We just need to be sure that http://xwiki.org/documentation is available. So I'm definitely for 2, WDYT? Thanks -Vincent

4 10

[xwiki-devs] Multiselect DBList custom mapping
by Edo Beutler 17 Nov '11

17 Nov '11

Hi Today I tried to create a custom mapping for a class. One field of the class is a DBList with the "Multiple Select" option activated. To save the values to the DB I wanted to use a string field like I'm used to with static lists and non multi select DB lists. Now I get the following exception when trying to save a Document with an object attached: "java.util.ArrayList cannot be cast to java.lang.String" How could I custom map a DBList field if String ist not possible? or is there even a simple Solution I missed? A hint in the right direction would be appreciated Edo

2 4

[xwiki-devs] JIRA dashboard for XE/XEM 3.3 - needs update
by Vincent Massol 17 Nov '11

17 Nov '11

Hi Sergiu, Could you update the 3.3 JIRA dashboard: http://jira.xwiki.org/secure/Dashboard.jspa?selectPageId=10590 so that it uses the filter I've shared for 3.3 issues: http://jira.xwiki.org/secure/IssueNavigator.jspa?mode=hide&requestId=11192 Thanks -Vincent

2 3

[xwiki-devs] [VOTE] Add FAQ application (xwiki-platform-faq) module in XWiki Platform
by Vincent Massol 17 Nov '11

17 Nov '11

Hi Devs, I've created a new FAQ application currently located at http://www.xwiki.org/xwiki/bin/view/FAQ/WebHomeNew I'd like to publish it in platform since we need to maintain it anyway for xwiki.org (I'm also ok to maintain it). Here's my +1 Thanks -Vincent

6 9