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

[xwiki-devs] [VOTE] Modify XEM distribution to become a Workspace distribution
by Vincent Massol 24 Nov '11

24 Nov '11

Hi devs, Since Eduard has developed the workspaces module (see http://extensions.xwiki.org/xwiki/bin/view/Extension/Workspace+Application) I'd like to push for using it in our XEM distribution. However there are 2 valid uses cases that exist: 1) Using XE + workspaces, for creating workspaces (technically each workspace being a wiki) 2) Using XE as a wiki farm I think that use case 1) is the main use case for most people and this vote is about keeping the XEM packaging/branding but repurposing so that XEM implements use case 1). Use case 2) exists but it's less frequent and for more technically advanced users. So here's my proposal (and what you should vote on): A) XEM = app manager module + wiki manager module + workspaces module(s). XEM home page becomes the workspaces app home page. We update manager.xwiki.org to align it with the fact that it now boasts the workspaces features. B) On http://platform.xwiki.org/xwiki/bin/view/AdminGuide/Virtualization we keep documenting how to transform XE into a wiki farm C) We create an application in xwiki-platform-core/ that contains the current pages located in XEM (home page + the other pages). We could call it xwiki-platform-multiwiki D) Users who want to install xwiki-platform-multiwiki easily will use the Extension Manager UI when it's ready for general consumption E) Users who want to install xwiki-platform-workspace easily will use the Extension Manager UI when it's ready for general consumption. At this point we'll decide if we want to drop the XEM distribution or keep both ways of installing it. Here'd my +1 Thanks -Vincent

9 17

[xwiki-devs] Update: Release dates for XE 3.3
by Vincent Massol 24 Nov '11

24 Nov '11

Hi devs, Since we've slipped here are the dates I'm proposing to follow (I've updated http://enterprise.xwiki.org/xwiki/bin/view/Main/Roadmap) * XE 3.3RC1 - 30 November * XE 3.3 Final - 5 December ok? Thanks -Vincent

3 2

[xwiki-devs] [Announcement] XWiki Enterprise and XWiki Enterprise Manager 3.3 Milestone 2 Released
by Sergiu Dumitriu 24 Nov '11

24 Nov '11

The XWiki development team is proud to announce the availability of XWiki Commons, XWiki Rendering, XWiki Platform, XWiki Enterprise and XWiki Enterprise Manager 3.3 Milestone 2. The highlights of this release are: * a new user interface for the extension manager * new features for the Application Within Minutes aspect * a new and improved FAQ application has been committed in the platform, although it's not bundled by default in XE * support for exporting PDF documents for CJK languages * a new rendering transformation that can be used to check the status of any link encountered in the wiki And on the developers' front: * support for dependency Providers, as defined in JSR330 * a Disposable interface for singleton components which can be used to release resources when a component is being unregistered See the full release notes at http://www.xwiki.org/xwiki/bin/ReleaseNotes/ReleaseNotesXWikiEnterprise33M2 for more details. -- Sergiu Dumitriu http://purl.org/net/sergiu/

1 0

[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