xwiki-devs

xwiki-devs@xwiki.org

9400 discussions

Re: [xwiki-devs] dyssmetric cluster... what's up?

by Paul Libbrecht

Thank you Thomas, so it turned out an elementary configuration bit caused the test with titles to fail: the presence of a cache folder in WEB-INF containing various cache configs. Removing that made the test with titles and contents succeed. However, the test with collections still fails, and now I finally had it to fail on my sever as well: two tomcats, joined through a tcp channel, ... What I observe is that after a revision is cached in a server, a change of objects only on the other does not propagate. The event and history frame comes up, not the added object. Let me understand: jgroups just does the communication, and listeners include a cache listener which invalidate the entry when the document-event is fired. Is it correct? thanks in advance Paul

12 years, 3 months

[xwiki-devs] Call Fan Out computation algorithm

by Vincent Massol

Hi devs, I wanted to understand how Checkstyle computes the Class Fan out so I debugged it. Here are my findings: * Some classes are excluded by default: mIgnoredClassNames.add("boolean"); mIgnoredClassNames.add("byte"); mIgnoredClassNames.add("char"); mIgnoredClassNames.add("double"); mIgnoredClassNames.add("float"); mIgnoredClassNames.add("int"); mIgnoredClassNames.add("long"); mIgnoredClassNames.add("short"); mIgnoredClassNames.add("void"); mIgnoredClassNames.add("Boolean"); mIgnoredClassNames.add("Byte"); mIgnoredClassNames.add("Character"); mIgnoredClassNames.add("Double"); mIgnoredClassNames.add("Float"); mIgnoredClassNames.add("Integer"); mIgnoredClassNames.add("Long"); mIgnoredClassNames.add("Object"); mIgnoredClassNames.add("Short"); mIgnoredClassNames.add("String"); mIgnoredClassNames.add("StringBuffer"); mIgnoredClassNames.add("Void"); mIgnoredClassNames.add("ArrayIndexOutOfBoundsException"); mIgnoredClassNames.add("Exception"); mIgnoredClassNames.add("RuntimeException"); mIgnoredClassNames.add("IllegalArgumentException"); mIgnoredClassNames.add("IllegalStateException"); mIgnoredClassNames.add("IndexOutOfBoundsException"); mIgnoredClassNames.add("NullPointerException"); mIgnoredClassNames.add("Throwable"); mIgnoredClassNames.add("SecurityException"); mIgnoredClassNames.add("UnsupportedOperationException"); * All classes in java.lang.* are excluded too * Annotation classes are not counted * Classes in the same package are counted (they won't appear in import since it's in the same package so don't count imports to get class fan out) * Static method calls are not counted. So for example StringUtils from Commons Lang never counts for class Fan out * Enums are not counted (no new XXX() done. That's why static method calls are not counted too BTW) * Classes used in class extend or implement are not counted too. Hope it helps -Vincent

12 years, 3 months

[xwiki-devs] MailArchive app feedback

by Vincent Massol

Hi Jeremie, I've tried using version 0.1 this week end and I've found that it doesn't work and is missing things. For example, it requires the tab macro which isn't specified as a dependency. And some pages have velocity macro failures. I've then tried to build the mailarchive app from git in the hope that some more recent commits fixed the issues but I couldn't built it. The build fails with: "Results : Failed tests: decodeMailContentForHtmlAndNoBodyAndCut(org.xwiki.contrib.mailarchive.internal.MailUtilsTest): To be implemented Tests in error: extractTypesWithLimitValues(org.xwiki.contrib.mailarchive.internal.DefaultMailArchiveTest): Failed to lookup component [org.xwiki.contrib.mailarchive.internal.DefaultMailArchive] for role [org.xwiki.contrib.mailarchive.IMailArchive] and hint [default] extractTypesForNominalCases_OtherType(org.xwiki.contrib.mailarchive.internal.DefaultMailArchiveTest): Failed to lookup component [org.xwiki.contrib.mailarchive.internal.DefaultMailArchive] for role [org.xwiki.contrib.mailarchive.IMailArchive] and hint [default] extractTypesForMultiplePatternsAndTypes(org.xwiki.contrib.mailarchive.internal.DefaultMailArchiveTest): Failed to lookup component [org.xwiki.contrib.mailarchive.internal.DefaultMailArchive] for role [org.xwiki.contrib.mailarchive.IMailArchive] and hint [default] Tests run: 10, Failures: 1, Errors: 3, Skipped: 0 " I've also noticed that on master the core dep is 3.5.1 which is pretty old. I'd like to update this to 4.3-SNAPSHOT and when you perform a release you resolve the snapshot to whatever version is the latest released (ATM that would be 4.2 and later on that would be 4.3-milestone-1 for ex). If you still need to depend on 3.5.1, it should be done on a branch of the mail archive app IMO. It would be nice for ex to be able to use the Application panel extension point. WDYT? I'm now going to try building with -DskipTests and pray it's going to run ;-) Thanks -Vincent PS: I'm still very eager to see it in action!

12 years, 3 months

[xwiki-devs] [Proposal] Remove 'future' version in JIRA

by Vincent Massol

Hi devs, It seems we've never really used the "future' version in jira. I'd like like to propose to remove it. The idea was that issues that had been reviewed and marked for later were supposed to use "future" but in practice we are not doing it. WDYT? Thanks -Vincent

12 years, 3 months

[xwiki-devs] [Proposal] Bug Fixing Day #6 on October 4 + BFD every first Thursday of the Month

by Vincent Massol

Hi devs and contributors, It's been a long since we last organized a Bug Fixing Day. I've published all our last results about XWiki Days at http://dev.xwiki.org/xwiki/bin/view/Community/DevelopmentPractices#HXWikiDa… I've also created a dashboard for listing all issues fixed during all our past Bug Fixing Days at http://jira.xwiki.org/secure/Dashboard.jspa?selectPageId=11196 Our total score is 97 issues. We can do better! Well done to Sergiu who has the high score by far with 49 issues fixed. I'd like to propose the 6th BFD since we're deriving quite a lot on our bug count. For the past 365 days 824 bugs were created and we solved 734 which means we're behind by 90 bugs just for that rolling period… See http://jira.xwiki.org/secure/Dashboard.jspa?selectPageId=10000#Created-vs-R… This means we're loosing the battle every day since every day more bugs are created than solved (our total unclosed bug count is 793, see http://jira.xwiki.org/secure/Dashboard.jspa?selectPageId=10000#Issue-Statis… ). What we should be doing instead is have the green line just slightly above the red bar on http://jira.xwiki.org/secure/Dashboard.jspa?selectPageId=10000#Created-vs-R… This would mean we're catching up slowly on the bug count. I'd like to propose the date of the **4th of October **for our sixth BFD and more generally I'd like to propose having a BFD every month on the first Thursday of every month, with the goal of reducing drastically this roving bug count! WDYT? Thanks -Vincent

12 years, 3 months

[xwiki-devs] The future of platform-legacy-oldcore.

by Karel Gardas

Hello, first of all, sorry, I've tried to google for it, but have not got any meaningful answer so I'm asking here. I'm curious what is the future of platform-legacy-oldcore modules for few another releases or let say a year or two. I'm asking since in 3.x release this module was called platform-oldcore ("old" kind of warned me already), but now in 4.2 it's already called with a connection of "old" and "legacy" words so I'm curious if this is going to change into "old" and "deprecated" and then be removed one of future releases (just my current fear!). The reason I'm asking is since we've extended this base by simple two or three classes to support lists based on supplied SPARQ queries. If however, this should be implemented anywhere else please let me know and I'll fix our extension to be more in line with what XWiki expects before I go to submit it here for more discussion about this feature. I'm not sure at all if you will be interested in integrating this into xwiki code base or it should be implemented anywhere else in kind of semantic module support for xwiki or something like that so if you do have some advice with regarding to this topic, it's also highly appreciated. Thanks! Karel

12 years, 3 months

[xwiki-devs] Some thoughts about the new upgrade wizard

by Denis Gervalle

Hi guys, I was just reading the release notes about the latest 4.2 release, and I would like to share my thoughts about the new experimental upgrade wizard: 1) During the first step, I found the labels of the button "Skip" and "Cancel" to be potentially misleading. I quickly make the analogy with a typical application upgrade wizard on my Mac, which say "Skip this version" or "Remind me later". But this is exactly the contrary, "Skip" here means "Remind me later", and "Cancel" means "Skip this version". So I propose to use more explicit labels, either those proposed above or any other that avoid the confusion. 2) During the second step, the extensions that are incompatible but do not have a potential update seems to not be listed. Once again, this could be misleading, since you naturally expect the wizard to have proposed the whole solution for your upgrade. I think that the wizard should also tell you which extension has been disabled for incompatibilities during this step. WDYT ? -- Denis Gervalle SOFTEC sa - CEO eGuilde sarl - CTO

12 years, 3 months

[xwiki-devs] [Contrib] Open a project - MultilingualDBListManager Application

by Guillaume "Louis-Marie" Delhumeau

Hi devs, I want to create a new project, derivated from http://extensions.xwiki.org/xwiki/bin/view/Extension/DBListManager+Applicat… will handle internationalisation. I think it's good to have two distinct projects, because users would be able to have the choice to use the simple extension or the new one, which will be more complicated. Thanks, Louis-Marie.

12 years, 3 months

[xwiki-devs] [Proposal] Implementation for XWIKI-8271 (extensible Hibernate mappings)

by Vincent Massol

Hi devs, I'd like to propose the following to implement http://jira.xwiki.org/browse/XWIKI-8271: * Create a new xwiki-platform-store-hibernate module * Add a Component role: HibernateConfiguration implements Comparable * API: void HibernateConfiguration.configure(Configuration aggregatedConfiguration), where the passed aggregatedConfiguration contains the configuration filled by all the HibernateConfiguration.configure() calls executed before * Add a HibernateConfigurationManager.getConfiguration() component that is in charge of loading the various HibernateConfiguration in the correct order * Have an AbstractHibernateConfiguration implements HibernateConfiguration with 1 API: getDatabaseType(Configuration configuration). It gets the DB type from the connection URL string and returns a DatabaseType object which represents the database type * CoreHibernateMapping (hint = "xwiki") <==> xwiki.hbm.*.xml - highest priority, defines the connection URL among other props * ActivityStreamHibernateMapping (hint = "activitystream") * FeedHibernateMapping (hint = "feeds") Note 1: If a HibernateConfiguration impl needs to load mappings that depend on the DB they call AbstractHibernateConfiguration. getDatabaseType() to get the DB. Note 2: If the user wants to use a different HBM file, he/she just has to put a file with the same name (e.g. xwiki.hbm.xml) in WEB-INF/classes Note 3: This means we won't put any mapping anymore in the hibernate.cfg.xml file since it's not needed anymore (although it would continue to work if you put mappings there). Usage: @Inject HibernateConfigurationManager configurationManager; Configuration configuration = configurationManager.getConfiguration(); SessionFactory sessionFactory = configuration.buildSessionFactory(); Then all that remains to implement http://jira.xwiki.org/browse/XWIKI-8271 is to have a component singleton that will be in charge of returning the SessionFactory and which can be asked to rebuild a new SessionFactory (using a new Configuration). We'll just need to decide how we trigger this. 2 options: * By using an Event Listener listening on HibernateConfiguration registrations and recreating automatically a new SessionFactory when it happens. Cons: if an extension contributes several HibernateConfiguration then Hibernate will be reinitialized several times * By listening to an Event sent by the Extension Manager when an extension has finished loading and somehow find out all the HibernateConfiguration that have been added (several ways of doing this) and recreating the SessionFactory Note: The only issue I can foresee is if a Hibernate call is in progress in one thread when an extension is installed and a new SessionFactory is created at the same time. Either we don't care or we could implement retry at the DB level, or we could introduce some semaphore so that we start the reinit only when nobody has a lock on the SessionFactory, or… WDYT? Of course, the pros is those listed in http://jira.xwiki.org/browse/XWIKI-8271: * Ability for a platform module to contribute Hibernate mappings (static) * Ability for an extension installed at runtime to contribute Hibernate mappings (dynamic) Note that the reason I'm starting all this is because I'd like to implement http://jira.xwiki.org/jira/browse/XWIKI-7953 cleanly in a module separate from oldcore. Thanks -Vincent

12 years, 3 months

[xwiki-devs] [PROPOSAL] Introduce MandatoryDocumentInitializer component

by Thomas Mortagne

Hi devs, In order to fix https://jira.xwiki.org/browse/XWIKI-8180 Extension Manager XAR handler need to access some way a mandatory document as it should be when it's "clean" so that It can then be used as previous version in a 3 ways merge. For that the idea is to introduce a new component based mandatory documents initialization and refactor XWiki#initializeMandatoryClasses to use it. This new MandatoryDocumentInitializer would allow: * provide a new mandatory document initializer from an extension since XWiki#initializeMandatoryClasses would lookup all of them * find a clean mandatory document state for a given document reference in extension manager XAR handler since that's the role hint of those components You can find an example of what a XWikiPreferencesDocumentInitializer would look like in https://github.com/xwiki/xwiki-platform/tree/feature-standardclasses branch. WDYT ? -- Thomas Mortagne

12 years, 3 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