xwiki-devs October 2009

xwiki-devs@xwiki.org

43 participants
147 discussions

Re: [xwiki-devs] [xwiki-notifications] r24360 - platform/core/trunk/xwiki-cache/xwiki-cache-jbosscache/src/main/java/org/xwiki/cache/jbosscache/internal

by Sergiu Dumitriu

On 10/12/2009 03:48 PM, tmortagne (SVN) wrote: > Author: tmortagne > Date: 2009-10-12 15:48:22 +0200 (Mon, 12 Oct 2009) > New Revision: 24360 > > Modified: > platform/core/trunk/xwiki-cache/xwiki-cache-jbosscache/src/main/java/org/xwiki/cache/jbosscache/internal/JBossCacheCacheConfiguration.java > Log: > XWIKI-4452: Upgrade to last JbossCache 3.x version > * fix maximum time to live new handling in LRU (used to be 0 for infinite, it's now -1) Isn't there a constant that can be used instead of a direct number? -- Sergiu Dumitriu http://purl.org/net/sergiu/

15 years, 2 months

[xwiki-devs] [VOTE] XE 2.1 Release Dates

by Vincent Massol

Hi, Following our roadmap definition (now on http://enterprise.xwiki.org/xwiki/bin/view/Main/Roadmap) here are some date proposals for XE 2.1: * 2.1 M1: 26 Oct (that's 4 weeks after the 2.0 release) * 2.1 M2: 16 Nov * 2.1 RC1: 30 Nov * 2.1 Final: 7 Dec Here's my +1 to commit to this schedule. Note that I propose a not too long release (2 months and 2 weeks) since 2.1 is meant to be a stabilization release with not many new things. The new things should be for 2.2 in 2010. Thanks -Vincent

15 years, 2 months

[xwiki-devs] [VOTE] Release XWiki Enterprise 2.0.1

by Thomas Mortagne

Hi devs, I would like to release 2.0.1 today. See the following release notes for the changes: - http://jira.xwiki.org/jira/secure/IssueNavigator.jspa?reset=true&&pid=10010… - http://jira.xwiki.org/jira/secure/IssueNavigator.jspa?reset=true&&pid=10222… - http://jira.xwiki.org/jira/secure/IssueNavigator.jspa?reset=true&&pid=10435… Here is my +1 -- Thomas Mortagne

15 years, 2 months

[xwiki-devs] [PROPOSAL] OfficeImporter API changes for 2.1

by Asiri Rathnayake

Hi Devs, I've been refactoring OfficeImporter code base to make it more modular and maintainable. With these refactorings I believe we can improve the main OfficeImporter API. Currently OfficeImporter component interface exposes following two methods: <code> void importStream(InputStream documentStream, String documentFormat, String targetWikiDocument, Map<String, String> params) throws OfficeImporterException; String importAttachment(String documentName, String attachmentName, Map<String, String> params) throws OfficeImporterException; </code> Problems with these two methods are; * Loosely typed (params) * Both of them perform almost the same task. There is also a problem with how customizations to the normal import process is implemented. So, I propose we deprecate these two methods and introduce following methods: <code> XHTMLOfficeDocument officeToXHTML(byte[] officeFileData, String referenceDocument, boolean filterStyles) throws OfficeImporterException; XDOMOfficeDocument xhtmlToXDOM(XHTMLOfficeDocument xhtmlOfficeDocument) throws OfficeImporterException; XDOMOfficeDocument officeToXDOM(byte[] officeFileData, String referenceDocument, boolean filterStyles) throws OfficeImporterException; XDOMOfficeDocument buildPresentation(byte[] officeFileData) throws OfficeImporterException; Map<TargetPageDescriptor, XDOMOfficeDocument> splitXDOM(XDOMOfficeDocument xdomOfficeDocument, int[] headingLevelsToSplit, String namingCriterionHint, String baseDocumentName) throws OfficeImporterException; </code> As you can see, these methods are more granular and the responsibilities are well defined. Customizing the import process can be done from the client code. For an example: 1. Make the initial import from office to XHTMLOfficeDocument. 2. Perform customizations on the XHTMLOfficeDocument (w3c DOM). 3. Import the XHTMLOfficeDocument into XDOMOfficeDocument. 4. Perform customizations on the XDOMOfficeDocument (XDOM). 5. Split the XDOMOfficeDocument into multiple XDOMOfficeDocument instances. 6. Perform customizations on these child XDOMOfficeDocument instances. 7. Render the XDOMOfficeDocument instances & save them into wiki pages. (saving can be done in client code) I think this interface will make it easy to extend & maintain officeimporter functionality in the future. For an example, a preview function can be implemented with above methods (which is not possible with the previous interface). WDYT? Here's my +1. Thanks. - Asiri

15 years, 2 months

[xwiki-devs] [Vote] New colors for the XWiki.org websites

by Guillaume Lerouge

Hi XWikiers, after a long discussion on the dev list we eventually narrowed down the new colors for XWiki.org to 3 options (see http://markmail.org/thread/2b3io6wv4yzr324q for details): - [1] Pastel: http://incubator.myxwiki.org/xwiki/bin/view/ColorThemes/XWORKSPACES2/#Attac… - [2] Dark borders: http://incubator.myxwiki.org/xwiki/bin/view/ColorThemes/PlainBlue/#Attachme… - [3] Grey borders: http://incubator.myxwiki.org/xwiki/bin/view/ColorThemes/XWATCH7/#Attachments Each of these proposals is a set of colors that would be declined on the various subwikis of the XWiki.org farm. Please vote for the one you like best. I'm +1 for [1] Thanks for your feedback, Guillaume -- Guillaume Lerouge Product Manager - XWiki SAS Skype: wikibc Twitter: glerouge http://guillaumelerouge.com/

15 years, 2 months

[xwiki-devs] Preliminary memory tests

by Vincent Massol

Hi, I've played a bit with Yourkit and a default XE to see the memory requirements. Here are some preliminary results (more tests needed): * After home page loaded: 38MB non-heap, 6377 classes * After code macro execution: 38 --> 52MB non heap, 8629 classes <--- a lot * After groovy macro execution: 52 --> 56MB, 9920 classes * After treeview + opened top level nodes: 56MB --> 63MB, 10960 classes <-- a lot * After Import: 63MB --> 65MB, 13036 classes * After Export: no change * After navigating a bit everywhere at random: heap memory needed: 155MB (used: 132MB), non heap: 65MB, classes: 13078 * After adding attachment of 1.1MB: almost no change * After deletion of 1.1MB attachment: used memory from 98MB to 132MB !! But still within the 155MB allocated heap memory Conclusion so far: ============== * We need around < 80MB non heap memory and < 200MB heap memory for the default XE pages and if the user manipulates attachments less than 1MB. * The default permgen size is 64MB so we're just above it (65MB). That's why some users have reported permgen issues I believe. Jython is eating a lot of it (14MB) * After adding a 7.3MB attachment: heap memory max from 155 to 261 (=>110MB!) * After removing it, need 297MB heap (even more) Second conclusion: ============== * Apart from attachments the memory needs seem reasonable IMO (< 255MB). * I'd still need to make sure I test all features of the wiki to be sure What more should I test? What should we do to reduce our permgen needs? Should we reduce it? Thanks -Vincent

15 years, 2 months

[xwiki-devs] Vote for XWiki at the Enterprise 2.0 Conference Launchpad !!

by Guillaume Lerouge

Hi XWikiers, XWiki has been selected among a set of other candidates to create a video describing what the product does. Winners get a chance to present on stage at the Enterprise 2.0 Conference in San Francisco next November. Please vote for the video at: *http://launchpad.e2conf.com/vote-now/* (XWiki is the last video, at the bottom of the list) and help give XWiki a chance to present on stage at the Enterprise 2.0 Conference ! RT appreciated ;-) Many thanks in advance, Guillaume -- Guillaume Lerouge Product Manager - XWiki SAS Skype: wikibc Twitter: glerouge http://guillaumelerouge.com/

15 years, 2 months

[xwiki-devs] About xwe.onInjectionDone

by Leon Wang

Hi Everyone, Hi Marius, Sorry, last message I have not finished and I pressed the space key mistakenly and it have been sent. Here is the code that I embeded in the Xwiki page, I just only include js/xwiki/mail/mail.nocache.js just once: {{velocity}} $xwiki.jsfx.use("js/xwiki/mail/mail.nocache.js", true) {{html}} <div id="DR_TreeView"></div> {{/html}} {{/velocity}} or {{velocity}} $xwiki.jsfx.use("js/xwiki/mail/mail.nocache.js", true) {{/velocity}} {{html}} <div id="DR_TreeView"></div> {{/html}} This will result at the top of the page that have the clickable Mail example functioning well, at the bottom it follows two unclickable Mail example, just like html displayed. And follows 6 xwe.onInjectionDone('xwe') sep . It seems although I used $xwiki.jsfx.use, the JavaScript code still parsed as wiki syntax and display as text. So what should I do? Marius, you said "to include the JavaScript code so that it ends up in your HTML page's head not body". Could you explain a little what do you mean by page's body and head?" by head do you mean on the top of the page. Thank you for your help! Leon

15 years, 2 months

Re: [xwiki-devs] About xwe.onInjectionDone (Leon Wang)

by Leon Wang

Hi Everyone, Hi Marius, Maybe the last three of unclickable mail html is generated before and saved in the page. I will farther look into this. Thank you. Here is the last email that I sent: Here is the code that I embeded in the Xwiki page, I just only include js/xwiki/mail/mail.nocache.js just once: {{velocity}} $xwiki.jsfx.use("js/xwiki/mail/mail.nocache.js", true) {{html}} <div id="DR_TreeView"></div> {{/html}} {{/velocity}} or {{velocity}} $xwiki.jsfx.use("js/xwiki/mail/mail.nocache.js", true) {{/velocity}} {{html}} <div id="DR_TreeView"></div> {{/html}} This will result at the top of the page that have the clickable Mail example functioning well, at the bottom it follows two unclickable Mail example, just like html displayed. And follows 6 xwe.onInjectionDone('xwe') sep . It seems although I used $xwiki.jsfx.use, the JavaScript code still parsed as wiki syntax and display as text. So what should I do? Marius, you said "to include the JavaScript code so that it ends up in your HTML page's head not body". Could you explain a little what do you mean by page's body and head?" by head do you mean on the top of the page. Thank you. Leon

15 years, 2 months

[xwiki-devs] FYI groovy tuplespaces implementation -- gruple -- multithreaded concurrent programming library

by Niels Mayer

http://code.google.com/p/gruple/ <-- seems potentially useful for use w/ xwiki; distributed/replicated wikis, realtime-collaboration wikis and other future work... This will become more useful once "future release" allows coordinating across processes, not just threads: > A concurrent programming library written in Groovy, providing simple > programming models for complex multi-threaded tasks. Introduction At its core, Gruple provides an in-process tuplespace abstraction to enable a JavaSpaces-style programming model for communication and coordination among threads. (A remote implementation allowing coordination among processes is planned for a future release.) Getting Started The current release implements an in-memory tuplespace, with basic operations (put, get, and take.) See the Overview<http://code.google.com/p/gruple/wiki/Overview> page for an introduction to the project, and the TuplespaceUsage<http://code.google.com/p/gruple/wiki/TuplespaceUsage> page for documentation. Also be sure to try the Demos<http://code.google.com/p/gruple/wiki/Demos> See the Project Roadmap <http://code.google.com/p/gruple/wiki/Roadmap> for other planned features. Niels http://nielsmayer.com

15 years, 2 months

← Newer
1
...
8
9
10
11
12
13
14
15
Older →

Jump to page:

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

2005

xwiki-devs October 2009