xwiki-devs

xwiki-devs@xwiki.org

9400 discussions

[xwiki-devs] [Proposal] Reorganize XWiki Core JIRA components reflecting core/web modules (Take 2)

by Vincent Massol

Hi, Following our previous discussion (see http://markmail.org/thread/5lsaq274tvczr5wd) , I'd like to move this forward. Here's what I propose now: 1) We create a new "XWiki Core" (key: XCORE) jira project which is where we put the new components and where we invite everyone to create new core issues. * In this new jira project we use the rule of one jira component per module, whatever the size of the module. ** For example for the rendering module (which is our largest module right now) this means one jira component only. In order to make it easy for users we should name it with something like "Rendering (wiki syntaxes, macros, ...)" ** Users will simply need to explain what it's about in the issue title. For example instead of having a "Rendering - Macro - RSS" component the issue will be named "Add blahblah feature to the RSS macro" ** Having lots of modules might look better but I think 1) having too many components make it hard for end users to find the right one and 2) I don't see real needs for them. Do you see any? 2) We keep the existing "XWiki Core" (key: XWIKI) jira project but: ** we change its permissions so that no new issues can be created in it ** we change its name to "XWiki Core - Old" ** we change its description to tell people to use the other one with a link to it ** we add a welcome message in the default dashboard to explain the change and point people to the new jira project. ** we slowly move whatever issues we can from it to the new project. For example we can easily move all Rendering 2.0 issues or all GWT WYSIWYG issues. For the rest we can move other time whenever we encounter an issue that should go in the new jira project 3) We change our existing jira filters so that they include both XCORE and XWIKI jira projects. WDYT? If we agree, I can start doing this. Thanks -Vincent

15 years, 4 months

[xwiki-devs] [ANN] XWiki Enterprise 2.0 Release Candidate 2 released

by Thomas Mortagne

The XWiki development team is pleased to announce the release of XWiki Enterprise 2.0 Release Candidate 2. Go grab it at http://www.xwiki.org/xwiki/bin/view/Main/Download This is the last release candidate before the XWiki enterprise 2.0 final version 69 Jira issues has been closed for this release. Changes from 2.0 Release Candidate 1: * New Colibri skin improvements * General UI improvements * WYSIWYG improvements * Rendering 2.0 improvements * New regexp velocity tool * Update translations: de, fr, gl, ru, sk, lv, pl, sv, zh, ro, ua, ko, hi, cs As usual we need the community to heavily test this release before the final release to catch all the remaining issues. For more information see the Release notes at: http://www.xwiki.org/xwiki/bin/view/Main/ReleaseNotesXWikiEnterprise20RC2 Thanks -The XWiki dev team

15 years, 4 months

[xwiki-devs] [VOTE] Release XWiki Enterprise 2.0RC2

by Thomas Mortagne

Hi devs, Here is a vote for the release of the last (hopefully) release candidate of XWiki Enterprise 2.0. The main goal of this release is to introduce the new Colibri skin and new title handling policy by default. It's also supposed to be a real release candidate (meaning that it's supposed to be the final release if nothing critical is found). See http://www.xwiki.org/xwiki/bin/view/Main/ReleaseNotesXWikiEnterprise20RC2 for more details. Here is my +1 -- Thomas Mortagne

15 years, 4 months

[xwiki-devs] [HELP] LiveTable 2.0 Macro

by Asiri Rathnayake

Hi All, I'm working on designing LiveTable 2.0 macro, an xwiki/2.0 macro that is supposed to work similar to current LiveTable (say 1.0) Macro. By looking at LiveTable 1.0 macro code I encountered few problems that confuses me a lot. * First, LiveTable macro is different from other macros (those I have seen / written so far) in which the generated content is "live"... Normally macros replaces the macro block with some other generated content but here LiveTable macro makes use of AJAX to fetch content dynamically. So the question, is LiveTable a macro or is it something else? Stuffing JavaScript/AJAX code inside a rendering 2.0 feels unfamiliar to me. * Second, existing LiveTable macro can be viewed in several ways: 1. Way of presenting a list of documents containing an object of a specific class. 2. Way of presenting a list of documents matching a criterion. 3. Generic way of presenting information mactching a criterion. I'm having a hard time figuring out what should be the exact purpose of LiveTable 2.0 macro, should it be same as LiveTable 1.0 macro? * Third, LiveTable macro uses several resources. 1. XWiki.LiveTableResults 2. XWiki.LiveTableResultsMacros 3. LiveTable JavaScript widget & CSS If we decide that LiveTable 2.0 macro should serve the same purpose as LiveTable 1.0 macro, should these resources be reused? (within the 2.0 rendering macro) Please help me to clarify these issues, I'm a bit lost here. Many thanks. - Asiri

15 years, 4 months

[xwiki-devs] Should we hide changes from superadmin from simple users in Recent Changes?

by Vincent Massol

WDYT? Thanks -Vincent

15 years, 4 months

[xwiki-devs] [Proposal] Stop using $msg.get()

by Vincent Massol

Hi, We now used $msg.get() eveywhere in the default XAR. IMO this is bad for the following reasons: * Our search no longer returns hits since it searches on the page content in the database (web search). BTW this is why some REST tests were failing since the content no longer existed for it (it does a hibernate search). * Users get to see $msg.get() everywhere in document titles when they edit XE pages, which is ugly and not understandable for simple users (for ex check Main.WebHome). * It's not a good way to translate apps since we bundle app translations keys in the core jar! Apps should be self-standing What should we do instead? Proposal: * Use the xwiki page translation feature... * Provide a XAR with all languages (and possibly a XAR per language). If the user configures his wiki for one language he'll see only that language (make sure all translations are imported even when in mono language) * Refactor existing pages to separate content from code. Move code to separate pages included from content pages. Never put content in code pages, have it passed to velocity macros for example. On the technical side we need to verify it can work but this is way better and would address the shortcomings listed above. Thanks -Vincent

15 years, 4 months

[xwiki-devs] [VOTE] Title compat flag on for now for 2.0 final

by Vincent Massol

Hi, I'd like to set the compat flag on for now since we haven't converted all page titles yet and this is going to take some time. We should move it back to off when it's all converted. +1 Thanks -Vincent

15 years, 4 months

[xwiki-devs] interesting comparison of scriping languages for Java from JavaOne

by Niels Mayer

Too bad Groovy isn't in here: "Alternative Languages on a JVM" http://www.azulsystems.com/events/javaone_2009/session/2009_J1_JVMLang.pdf ... > Deeper Dive > Clojure - “almost close” ● Good: no obvious subroutine calls in inner loop ● Bad: Massive “ephemeral” object allocation - requires good GC ● But needs Escape Analysis to go really fast ● Ugly: fix-num overflow checks everywhere ● Turn off fix-nums: same speed as Java ● Weird “holes” - ● Not-optimized reflection calls here & there ● Can get reports on generated reflection calls 10 Deeper Dive > Jython - “almost close” ● Also has fix-num issue; massive allocation ● Some extra locks thrown in > JavaScript/Rhino - “almost close” ● All things are Doubles – not 'double' ● Same fix-num allocation issues as Clojure, Jython ● Otherwise looks pretty good (no fix-num checks) > JRuby – Missed The Metal ● Assuming CachingCallSite::call inlines ● Using -XX:+PrintInlining to determine ● But flag is lying: claims method inlined, but it's not 11 Common Issue – Fix-Nums > Huge allocation rate of “fix-nums” ● Allocation is not free ● Setting final fields cost a memory fence ● GC does NOT cost here ● i.e., object pooling would be a big loser > Could do much better with JIT ● Need “ultra-stupid” Escape Analysis ● Need some (easy) JIT tweaking ● e.g. Getting around Integer.valueOf(i) caching 12 JRuby – Missed The Metal > Each minor action dispatches via “call” > Assuming CachingCallSite::call inlines ● (and allows further inlining) > Using -XX:+PrintInlining to determine > But flag is lying: claims inlined, but it's not ● BimorphicInlining is 'guessing' wrong target > Confirmed w/GDB on X86 Java6 > Confirmed w/Azul profiler ● My 1st impression: can't be inlined ever Niels http://nielsmayer.com

15 years, 4 months

[xwiki-devs] Skin TODOs for the 2.0 RC1 release

by Vincent Massol

Hi, Here are skin problems I can see that need to be fixed before the RC1 release: 1) ColorTheme space is not excluded for simple users 2) On admin page the large header is not correctly positioned 3) Colibri is not set to be the skin by default 4) Colibri is not using the voted default colors 5) The colorTheme property is not set in XWikiPreferences 6) There's no theme editor/chooser available from the admin presentation page 7) Ugly (too large) create button on the blog home page 8) Blog title is no longer using the Blog object title value 9) When going to a blog post page there are 2 dup titles that really don't look nice 10) Use profile page has dup titles. XWiki.User does not start directly with the title, but wraps it inside a vcard microformat. 11) Main.WebSearch is not a plain title, but also contains an icon link to the RSS results. The document should be updated. 12) Main.Tags does not have a heading, but a div styled to look like a heading. Also, it is not a simple title, it also incorporates tools for the selected tag. Anything else that is a blocker for the RC1 and 2.0 final release? Can we spread the work amongst ourselves? Please volunteer to take some items. Note1: This means that we're late yet again since today is supposed to be the release day for RC1... This means we need to finish all the items above today at latest. Note2: I haven't looked at existing colibri skin issues already in jira. Please someone have a look and add to the list above if they are blocker for RC1. Let's crack this all together today! Thanks -Vincent

15 years, 4 months

[xwiki-devs] [Proposal] Title compatibility flag

by Vincent Massol

Hi, Following our discussion on the new title behavior we need to define the title compat flag value. I'm proposing: #-# Defines whether title handling should be using the compatyiblity mode or not. When the compatibility #-# mode is active, if the document's content first header (level 1 or level 2) matches the document's title #-# the first header is stripped. xwiki.title.compatibility=0 + we need a way to access this property from contentview.vm so I'm proposing to also add a method to api.XWiki: isTitleInCompatibilityMode() WDYT? Thanks -Vincent

15 years, 4 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