xwiki-devs May 2014

xwiki-devs@xwiki.org

28 participants
73 discussions

[xwiki-devs] [Proposal] Cleaning our POM deps by explicitly listing used dependencies?

by Vincent Massol

Hi devs, Running mvn dependency:dependency-analyze produces interesting results. For example: [INFO] --------------------------------------------------------------------------------------------------------------------------------------------------------------------------- [INFO] Building XWiki Commons - Properties 3.2-SNAPSHOT [INFO] --------------------------------------------------------------------------------------------------------------------------------------------------------------------------- … [INFO] --- maven-dependency-plugin:2.3:analyze (default-cli) @ xwiki-commons-properties --- [WARNING] Used undeclared dependencies found: [WARNING] org.slf4j:slf4j-api:jar:1.6.1:compile [WARNING] javax.inject:javax.inject:jar:1:compile [WARNING] Unused declared dependencies found: [WARNING] org.xwiki.commons:xwiki-commons-component-api:jar:3.2-SNAPSHOT:compile [WARNING] org.xwiki.commons:xwiki-commons-test:jar:3.2-SNAPSHOT:test [WARNING] org.hibernate:hibernate-validator:jar:4.2.0.Final:test [WARNING] org.hamcrest:hamcrest-core:jar:1.1:test [WARNING] org.jmock:jmock:jar:2.5.1:test The question is (for this module but more generally for all others): * Should we add slf4j and javax.inject reps in the pom.xml for this module? (for ex today slf4j and javax.inject are found in the component-api dep) I think we should, wdyt? Note that the "Unused declared dependencies found:" doesn't always generate correct results as is the case here. This is mostly because it's a static byte code check so any dep used at runtime will be considered unused. See http://www.sonatype.com/books/mvnex-book/reference/optimizing-sect-dependen… Thanks -Vincent

10 years, 3 months

[xwiki-devs] Users are in need of a reusable Tree view of pages, what can we do?

by vincent＠massol.net

Hi devs, I’ve noticed a recurring trend from our users: a lot of them seem to wish to display Tree views/navigation view of their wiki pages either in page content or in a panel. When they go to e.x.o, there’s a lot of extensions listed (showing that other users had this need previously) but none really work well: http://extensions.xwiki.org/xwiki/bin/view/Extension/WebHome#|t=extensions&… We do have a tree view in AllDocs but it’s not perfect and it’s not easily reusable. Thus I believe we need to find an official solution to this tree view issue. The easiest solution could be to create a wiki macro based on our current tree view so that it can be reused in wiki pages and more importantly in a panel. Having a “spaces” parameter to restrict the list of spaces to display would be nice too. WDYT? Any other idea? Thanks -Vincent

10 years, 3 months

[xwiki-devs] [Proposal] New Mail Sender module + API

by vincent＠massol.net

Hi devs, I’ve worked with Lyes to define a new mail sender API. We’ve put it here: http://design.xwiki.org/xwiki/bin/view/Proposal/MailModule Our idea is to: - implement this in XWiki Platform in xwiki-platform-core/xwiki-platform-mail/xwiki-platform-mail-sender. In the future we’ll be able to have xwiki-platform-core/xwiki-platform-mail/xwiki-platform-mail-reader if we want. At some point we should also move the Mail configuration UI in xwiki-platform-core/xwiki-platform-mail/xwiki-platform-mail-ui. - deprecate the mailsender plugin and once all our code has been updated to use this new API, move the plugin to xwiki-contrib. Please let us know what you think about both the API and the plan. Thanks -Vincent

10 years, 3 months

[xwiki-devs] Admin tools

by walid yaich

Hi Community, I'm migrating all our content from XWIKI 4.4 to XWIKI 5.4.5. I use admin tools to export/import large content, it's a very good tool, almost all documents are imported successfully. but now in order to have the approved revision functionality i must have the version "1.1" for all imported document. Can i tell Admin tools to override version to "1.1" ? Thanks in advance :)

10 years, 3 months

[xwiki-devs] [Brainstorming] Best practices for storing Application pages

by vincent＠massol.net

Hi devs, Right now our practice in XWiki Platform for the apps we develop is to move to storing all the pages of an app in a single space. See http://dev.xwiki.org/xwiki/bin/view/Community/ApplicationDevelopmentBestPra…, specifically: “ Generally, put all your pages in a single space dedicated for the application you're developing (e.g. Faq, Scheduler, IRC, AppWithinMinutes, etc). The name must be as short as possible while still being understandable of course and without overusing abbreviations. " Now there are potentially some use cases that may warrant to have 2 spaces: one for the content documents and one for the technical documents: - ability to easily set permissions on all technical pages so that only a group of person can modify them but allow another group of persons to edit the content pages (e.g. for the Blog application) - easier to remove all the content pages of an app but still keep the app working So one idea would be systematically have 2 spaces for apps: - one XXX space (e.g. Blog space) for holding content pages - one XXXCode space (e.g. BlogCode space) for holding technical pages Of course all technical pages are hidden and thus the XXXCode space will not appear in the list of spaces or searches by default. WDYT? Would you be ok to modify all our existing apps to go in that direction? Note: A future solution is to use nested spaces but even with nested spaces the need for 2 spaces would be the same. We would just need to make the XXXCode space a subspace of the XXX space (assuming we can set permissions on subspaces ;)). Thanks -Vincent

10 years, 3 months

[xwiki-devs] Export/Import XAR Admin tool

by walid yaich

Hello, I used admin tool to export the whole wiki from XWIKI 4.4 and i did the import in XWIKI 5.4.5 The result wasn't perfect i have some link which still refer to the old wiki, Please, another tools to try ? should try some other script out there? Thanks in advance :)

10 years, 3 months

[xwiki-devs] [Proposal] Retro-compatibility between Color Theme Application ad Flamingo

by Guillaume "Louis-Marie" Delhumeau

Hi! The current color theme editor is designed for colibri, and does not look like flamingo does. We have several options here: - create a new color theme editor, especially for Flamingo - modify the current one to detect which skin is currenlty used, and change the preview. The application will be splited in 2 sections: 1/ a live preview where you can set some variables (what we currenlty have) 2/ a free textarea where the user can fill LESS code (for example, some code downloaded on bootswatch). But a lot of applications already use the color theme as it is, via the "colorThemeInit.vm" template. So we need a retro-compatibility: a color theme computed by LESS must be usable with old color themes. Concretly, we will map the old color theme variables to the bootstrap ones, example: $theme.notificationSuccessColor = @brand-success But because of the section 2 (the free textarea), we are not able to know what will be the final value of a bootstrap variables without parsing the content of the textarea! What are the options we have: 1/ Implementing our own LESS parser/compiler in Java 2/ Trying to reuse the official LESS Parser through Rhino in a way that we can get the computed variables 3/ Do not parse the input but the ouput: parse the CSS code to get the final values of the variables I'm for 3. The idea is to create some CSS classes like this: .colortheme-bordercolor{ color: @border-color; } which will be converted by LESS to: .colortheme-bordercolor{ color: #000000; } so we can parse it and know the value of $theme.bordercolor. It is quick, simple, but it pollutes the output CSS a little. WDYT? Thanks, Guillaume

10 years, 3 months

[xwiki-devs] What XWiki Day for the 5th of June?

by vincent＠massol.net

Hi devs, We missed last week’s XWiki Day (I just forgot, shame on me!) but we quickly discussed on IRC what could be the content of the next XWiki Day: - Thomas proposed a deprecation fixing day - I proposed a Pull Request day (to review all PRs and ensure we've replied to all and merge the ones we can) And now Danilo is proposing a Doc Day (see users list). So, contributors and committers, what do you wish to do for the following Thursday (the 5th of June since tomorrow is a bank holiday in France and I won’t be able to organize it, if someone is interesting to lead it, please answer here!)? Thanks -Vincent

10 years, 3 months

[xwiki-devs] Requesting rights on xwiki-contrib

by Lyes Bandou

Hi devs. For commit the code of Macro dynamic tree i need to have rights on xwiki-contrib. Github ID : bandoulyes Thank in advance --- Best regards - Cordialement --- Lyes Bandou

10 years, 3 months

[xwiki-devs] [Brainstorming] Improving the rendered quote syntax

by vincent＠massol.net

Hi devs, It’s been raised by a user to me that it’s strange that when they use a quote (using the “>” symbol) we don’t show visually that it’s a quote and that it seems to him that it would make sense to show some quote symbols. Right now on XE it looks like: https://www.evernote.com/shard/s119/sh/5eea60a0-8110-438e-a292-47d395c386bc… On xwiki.org (junco) it looks like this: http://www.xwiki.org/xwiki/bin/view/References/Testimonials It’s true that the XE’s default doesn’t look very much like a quote… It can be confused with a box easily. So WDYT about improving that in our default XE by having something either like junco (is it clear enough that it’s a quote) or adding quotes symbols? Thanks -Vincent

10 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 May 2014