xwiki-devs September 2011

xwiki-devs@xwiki.org

23 participants
65 discussions

by Karamjit Singh

Hi Team, I am unable to build xwiki from source its source code. I am getting below error message while executing Maven goal:- *[ERROR] Failed to execute goal on project xwiki-platform-rest-server: Could not resolve dependencies for project org.xwiki.platform:xwiki-platform-rest-server:jar:3.2-SNAPSHOT: Could not find artifact org.jboss.cache:jbosscache-core:jar:3.2.5.GA in xwiki-externals (http://maven.xwiki.org/externals) -> [Help 1]* Looks like jboss cache core lib does not exist on maven external repository * * *Please help me. Its very urgent as I am stuck and unable to deploy new changes to our server.* * * *I shall be very thankful.* * * *Thanks* *Karamjit.*

13 years, 3 months

[xwiki-devs] [Proposal] Naming rules for translation resource properties + deprecated properties

by Vincent Massol

Hi devs, I see that in ApplicationResources.properties we now have some wrongly named properties. For example for the scheduler I find properties of the type xe.scheduler.* but the scheduler is now in the platform. There are also resources named core.* Thus I'd like to propose a simple rule: <short top level projet name>.<short module name>.<propertyName> where: <short top level projet name> = top level projet name without the "xwiki-" prefix, for example: commons, rendering, platform, enterprise, manager, etc <short module name> = the name of the maven module without the <short top level project name> prefix, for example: oldcore, scheduler, activitystream, etc <propertyName> = the name of the property using camel case, ex: updateJobClassCommitComment For example the property core.importer.package.version would be renamed in platform.web.packageVersion The only issue is when we rename modules we need to rename the properties for that module but I don't see any way out of this if we want to have expressive property names. But at least it's an easy and mechanic change I also propose to introduce a different resource property file that will hold deprecated properties and that we can put in the xwiki-platform-legacy module. We could call it DeprecatedApplicationResources*.properties Of course in the future each module should be able to contribute both resource properties (but they would use the same naming scheme!). Even though this is not the topic of this mail this is how I'd implement this in the future: * Implement a TranslationPropertiesConfigurationSource that is initialized by reading all property files found in the classloader under META-INF/translations.properties and META-INF/translations-deprecated.properties. This component would listen to observation events so that when a new jar is installed by the extension manager it can check if it provides some translations and add them. * Have a Translation Manager component which is the main API to be used by other modules wishing to get translations. This manager would use the TranslationPropertiesConfigurationSource component. WDYT? Thanks -Vincent

13 years, 3 months

[xwiki-devs] Build improvement actions

by Vincent Massol

Hi devs, We've had a meeting with Marius, Thomas and myself and we brainstormed about what to improve in our builds and we've come up with the following actions: 1- create twitter account for xwiki.org and tweet about releases (basically tweet links to blog posts). Category: Release Process improvement. Who: Vincent Massol 2- Refactor distribution for installers to share more. Who: Thomas Mortagne 3- Check latest version of izpack. Who: Marius 4- Configure nexus to cache other repos → speed improvement. Who: Vincent Massol 5- Add definition xwiki remote repo to top level repos in github. Who: Vincent Massol 6- Define a location for passwords. Who: Thomas Mortagne 7- Publish with commons and rendering on central repo. Who: ? I've started to work on items 4 and 5 and will do 1 soon. Also I've analyzed 7 and there's only 1 external reps not available in the Maven Central Repo: <groupId>org.reflections</groupId> <artifactId>reflections</artifactId> It should be pretty easy to submit it using https://docs.sonatype.org/display/Repository/Uploading+3rd-party+Artifacts+… To publish our artifacts to the central repo I propose to use Sonatype OSS service, see https://docs.sonatype.org/display/Repository/Sonatype+OSS+Maven+Repository+… Thanks -Vincent

13 years, 3 months

[xwiki-devs] DBStringList property and checkbox functionality example.

by Karel Gardas

Hello, is there any example which shows usage of DBStringList property together with support for selecting multiple values of this property (by for example using checkboxes) and also showing how such values are later obtained from the property? I'm asking since I'm not sure if property is able to kind of change into property list (probably) and also I'm fighting with this and I'm still not able to obtain more than one value from returned property object. Thanks! Karel

13 years, 3 months

[xwiki-devs] [VOTE] Remove migrated code from svn.xwiki.org

by Vincent Massol

Hi devs, I'd like that we remove code that we've moved to github from svn.xwiki.org as it's misleading for people arriving there. Secifically: - commons - enterprise - manager - platform - rendering - watch - xeclipse - xoffice Here's my +1 Thanks -Vincent

13 years, 3 months

[xwiki-devs] [VOTE] New thumbnails module

by Jerome Velociter

Hello again, I would like to introduce a new module in platform : xwiki-platform-thumbnails. The idea of the module is to provide means of handling thumbnails in XWiki. Right now the main purpose is to expose APIs to retrieve thumbnails URLs for images stored as attachments. This module first use will be to generate thumbnails of user avatars. In this scenario, it will also introduce a performance improvement compared to today's way of computing avatar URLS, since the module caches both the property values (the fact that user X has set an avatar Z.png) and the thumbnail URL for this avatar. I've already pushed it in a feature branch/. You can check in particular https://github.com/xwiki/xwiki-platform/commit/3f5aa1e24ba00fcc939b73b8f9ba… and all commits in the branch at https://github.com/xwiki/xwiki-platform/commits/feature-thumbnails Let me know what you think. -- Jerome Velociter Winesquare http://www.winesquare.net/

13 years, 3 months

[xwiki-devs] Include macro behavior with respect to sheets

by Marius Dumitru Florea

Hi devs, I think we all agree that the result of {{include document="Space.Page" context="new" /}} must be similar with what we see when we view Space.Page. Now, suppose Space.Page has an object of type Space.Class and Space.Class has a sheet named Space.Sheet. If the sheet is applied to Space.Page using the include macro in the content field like this: {{include document="Space.Sheet" /}} then the result of the first include macro is as expected. If we don't use the content field to apply the sheet (which is the case of the sheet management module I'm working on) then the result of the first include macro is not anymore as expected. The reason is that rendering the content of Space.Page (could be empty) is different than rendering the Space.Sheet in the context of Space.Page. I could modify the include macro to use the sheet module when context=new, but I think it's better to hide the sheet module from the include macro, e.g. by modifying the getRenderedContent() method to use the sheet module instead. WDYT? Thanks, Marius

13 years, 3 months

[xwiki-devs] velocity script render a List<Block>

by Mark Wallace

I have a macro (implemented in Java) with this interface: public List<Block> execute(InferenceParameter parameters, String content, MacroTransformationContext context) ; I want to call this macro from within a velocity script. When I do, it returns a List<Block>. How do I get the velocity script to render the List<Block> properly? -- Mark Wallace Principal Engineer, Semantic Applications Modus Operandi, Melbourne, FL, USA

13 years, 3 months

[xwiki-devs] [Proposal] Stop Jenkins notifications for 3.1 branch

by Vincent Massol

Hi devs, I'd like to stop sending jenkins emails for the 3.1 builds for the following reason: * We don't have enough time to fix the tests on that branch as we did for the master branch * Almost all (if not all) emails are false positives * We're stabilizing the build and we're trying to reduce all false positive emails and this is not helping us go in the right direction * This branch is supposed to go away in not too long * We don't do many commits on that branch (and we shouldn't) So the idea is that we don't receive emails anymore for that branch **but** it'll be up to the Release Manager when we release this branch to review the failing tests with the other devs when it's time to release it to ensure that we don't have real test failures. WDYT? Thanks -Vincent

13 years, 3 months

[xwiki-devs] [VOTE] Introduce ActionExecutingEvent event

by Thomas Mortagne

Hi devs, I started to move (very) old notification system to legacy but I'm stuck because there is one thing still not supported by new observation system: event sent before executing an action. So here it is: I propose to add it with the name ActionExecutingEvent in the bridge. At the same time I would also like to come with ActionExecutedEvent in the bridge to replace the ActionExecuteEvent which is currently in observation API (and that should never have been there). WDYT ? here is my +1 -- Thomas Mortagne

13 years, 3 months

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

2005

xwiki-devs September 2011