xwiki-devs

xwiki-devs@xwiki.org

9400 discussions

by Vincent Massol

Hi devs, FYI I'm starting a module in xwiki-contrib to hold the 2 xwiki.org flavors (one for the main wiki and one for the subwikis): https://github.com/xwiki-contrib/xwiki-flavor-xwikiorg I'd like to start using the EM/DW on xwiki.org during the next upgrade and for that I'll need these 2 flavors. Thanks -Vincent

11 years, 10 months

[xwiki-devs] Extension Manager memory usage - too much?

by Vincent Massol

Hi devs, I've done some memory analysis with yourkit and it happens that the EM takes a lot of memory, namely: * DefaultCoreExtensionRepository takes 31MB of memory as it caches all extensions found in memory * Out of the 31MB, 29MB is used by org.apache.maven.model.Model with 373 instances (I guess that's the number of extensions we have) * Note that 15MB is taken just by Xpp3Dom objects (42814) for the goals of the plugins of the extensions * 10MB by PluginManagement The question is: are we ok with this? Should we reduce it? On a different note, PyDictionary takes 11MB of memory. Actually the total memory taken by python is much more, I've computed to be 50MB, that's quite a lot just for our code macro… Thanks -Vincent

11 years, 10 months

[xwiki-devs] [Proposal] Backward compatibility strategy w/ young apis included

by Vincent Massol

Hi devs, Here's my effort to try to put together all that has been said… :) The idea is that whenever you change an API (adding a new one or changing an existing one) you go through the list of strategies below, trying to find the first that matches your use case. * Strategy 1 (already in place): Whenever possible don't break backward compatibility and go through a deprecation mechanism: ** Deprecate classes/methods ** Move them to Legacy modules as soon as our code is not using them anymore ** Note: No need to touch CLIRR * Strategy 2 (new): If possible, code defensively, i.e. put code in internal and open up when api is stable later on, either when users ask for it or when someone feels it's the right time ** Note: No need to touch CLIRR * Strategy 3 (new): If not possible (for example complete new modules where you wish to separate what will become stable APIs in the future from internal code) then use the @Unstable annotation at class level (or method level) ** Whenever we work on a new N.0 milestone 1 version, review all existing @Unstable annotation and for those that were added before N-1.0 remove the annotation ** Exclude the classes/methods marked @Unstable from CLIRR * Strategy 4: If the API is stable and the developers wants to break it (change of signature for example) and all other strategies don't apply, then either: ** (new) Just do it and modify the CLIRR exclude. Preferable (but not mandatory) send a NOTICE email to warn others devs that an API is going to be broken in the next release ** If not sure, send a PROPOSAL or VOTE email depending on how important you think the API to be broken is WDYT? Thanks -Vincent

11 years, 10 months

[xwiki-devs] OutOfMemory exception when running extension tests

by Marius Dumitru Florea

I just noticed http://ci.xwiki.org/job/xwiki-enterprise-test-extension/org.xwiki.enterpris… 22:16:29.433 [main] INFO org.xwiki.test.ui.TestDebugger - ExtensionTest-testInstallScriptService started 22:19:55.911 [Thread-2] ERROR o.x.t.i.XWikiLogOutputStream - Exception in thread "qtp850442967-17" java.lang.OutOfMemoryError: PermGen space 22:20:16.643 [Thread-2] ERROR o.x.t.i.XWikiLogOutputStream - Exception in thread "qtp850442967-15" java.lang.OutOfMemoryError: PermGen space 22:20:35.600 [Thread-2] ERROR o.x.t.i.XWikiLogOutputStream - Exception in thread "Lucene Index Updater" java.lang.OutOfMemoryError: PermGen space 22:20:39.197 [Thread-2] ERROR o.x.t.i.XWikiLogOutputStream - Exception in thread "qtp850442967-18" java.lang.OutOfMemoryError: PermGen space 22:20:43.065 [Thread-2] ERROR o.x.t.i.XWikiLogOutputStream - Exception in thread "qtp850442967-642" java.lang.OutOfMemoryError: PermGen space 22:20:46.766 [Thread-2] ERROR o.x.t.i.XWikiLogOutputStream - Exception in thread "qtp850442967-12" java.lang.OutOfMemoryError: PermGen space 22:21:08.863 [main] INFO org.xwiki.test.ui.TestDebugger - ExtensionTest-testInstallScriptService failed What are the qtp threads for? Thanks, Marius

11 years, 10 months

[xwiki-devs] Translation, is there any cache ?

by xrichard

Hello, I've defined custom translations for XWiki standard keys. For some the changes are reflected immediately. For other custom translations I have to wait: the new string is displayed only after "hours" (ie the next day). For instance strings for the 3 following translation keys are not changed immediately: login= logout= core.viewers.comments.add.submit= Can someone explain me why? Is there a cache somewhere? but not for all keys? regards, -- View this message in context: http://xwiki.475771.n2.nabble.com/Translation-is-there-any-cache-tp7583975.… Sent from the XWiki- Dev mailing list archive at Nabble.com.

11 years, 10 months

[xwiki-devs] [NOTICE] New Model Script Service API

by Vincent Massol

Hi devs, FYI as part of http://jira.xwiki.org/browse/XWIKI-8848 I've added some new APIs /** * Creates a {@link WikiReference} from a string representing the wiki name. * * @param wikiName the wiki name (eg "xwiki") * @return the reference to the wiki * @since 5.0M1 */ public WikiReference createWikiReference(String wikiName) { return new WikiReference(wikiName); } /** * Creates a {@link SpaceReference} from a string representing the space name. * * @param spaceName the space name (eg "Main") * @param parent the wiki reference in which the space is located * @return the reference to the space * @since 5.0M1 */ public SpaceReference createSpaceReference(String spaceName, WikiReference parent) { return new SpaceReference(spaceName, parent); } /** * Creates any {@link EntityReference} from a string. * * @param name the entity reference name (eg "page") * @param type the entity type (eg "wiki", "space", "document", etc) * @return the created reference * @since 5.0M1 */ public EntityReference createEntityReference(String name, EntityType type) { return new EntityReference(name, type); } /** * Creates any {@link EntityReference} from a string. * * @param name the entity reference name (eg "page") * @param type the entity type (eg "wiki", "space", "document", etc) * @param parent the entity parent * @return the created reference * @since 5.0M1 */ public EntityReference createEntityReference(String name, EntityType type, EntityReference parent) { return new EntityReference(name, type, parent); } The last 2 are generic and allow for more complex use cases. Let me know if you have better ideas. Thanks -Vincent

11 years, 11 months

[xwiki-devs] BFD #9 starts today the 21st of February 2013

by Vincent Massol

Hi devs, Sorry not to have reminded this yesterday: today is BFD #9 and our first weekly BFD! Rules of engagements: * Goal: reduce the open bug count from http://jira.xwiki.org/secure/Dashboard.jspa?selectPageId=10000#Created-vs-R… as much as possible. * Consequence: the goal is to take the lowest hanging fruits. * This is an occasion to close easy bugs that we wouldn't look at otherwise * It also serves as cleaning up our JIRA * Devs are free to chose by themselves the bugs they work on * It is *not* a day to implement important bugs listed in the roadmap, although devs can take some from there if they wish * It's only about bugs, not other type of issues * Make sure to label all bugs closed today with "bugfixingday" ATM we have 913 open bugs, let's how much we're able to close today! :) Thanks -Vincent

11 years, 11 months

[xwiki-devs] [contrib] New repository on xwiki-contrib for a publication workflow application

by Anca Luca

Hi all, I did some sort of an implementation of a publication workflow application, which allows to take a document through various states and finally publish it in a mirror space once it is validated, and subsequent versions of the same document are handled, with distinct rights and comments between the draft version and published version. For now, this application is here https://github.com/lucaa/workflow-publication and I would like to publish it in xwiki-contrib, in a repository called the same, workflow-publication, in order to release it on xwiki maven. Thanks, Anca

11 years, 11 months

[xwiki-devs] What do we do with template field in document ?

by Thomas Mortagne

Hi devs, We have a "template" field in XWikiDocument and in what we export/import in the XAR but it's not part of the database mapping (there is defaultTemplate but no template). See http://jira.xwiki.org/browse/XWIKI-8650. Since it's not saved in the database it's totally useless to have it in the XAR but we do have it in several pages of XE (some Blog pages). So my question is what the hell is this field and what should be do with it ? I can see two possibilities: 1) stop exporting it in the XAR and deprecated related method in XWikiDocument 2) put it back in the database mapping (I guess it used to be there or I don't see how we could have some pages with it on github) WDYT ? Since I have no idea what this field is supposed to do I don't have a strong opinion but since it's totally useless right now and nobody seems to complain I would go for 1). -- Thomas Mortagne

11 years, 11 months

[xwiki-devs] [Proposal] Change save buttons in the editor to improve version management

by Denis Gervalle

Hi devs, Following our recent IRC discussion, I start this discussion to improve our editor workflow. If you agree that: 1) Save & Continue followed by Cancel is misleading, since the document stay saved anyway 2) Checking the minor box is often forgotten, especially for minor change since we do it fast 3) Switching between page view and editor is slow, and maybe useless with a continuous editing session in WYSIWYG. 4) Preview is not always sufficient to ensure all is the way you want, especially if rights is concerned there are minor changes that may improve the workflow: A) Remove the Is Minor checkbox B) Replace the Save & Continue button with a Save minor version button, while keeping the current behavior C) Replace the Save & View button with a Save major version button. D) Change the behavior of "Save major version button" to work like Save & Continue behavior with a major version. E) Replace Cancel by Done, and add a warning allowing to save either minor or major or cancel (with 3 buttons) if any changes are unsaved. With D) and E), we have the same behavior than an editor application, where you File/Save and File/Quit. At the end, we got the same number of buttons, one less checkbox but I agree one more click to save major and view. This additional click is needed so you choose voluntarily to save as a minor version or a major version. If you think it is not good to have that additional click, let leave it as it is... or simply remove the checkbox, it is misuse anyway and cause complexity. WDYT ? -- Denis Gervalle SOFTEC sa - CEO eGuilde sarl - CTO

11 years, 11 months

Jump to page:

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

2005

xwiki-devs