xwiki-devs

xwiki-devs@xwiki.org

9400 discussions

[xwiki-devs] XWiki.WatchListMessage doesn't have a creator set

by Marius Dumitru Florea

Hi devs, OrphanedPageTest from xmlrpc-tests fails for XWiki.WatchListMessage page from the watchlist application because it doesn't have a creator set. Was the creator field left unset on purpose? See http://hudson.xwiki.org/view/Functional%20Tests/job/xwiki-product-enterpris… Thanks, Marius

13 years, 10 months

[xwiki-devs] [Proposal] Optional Contact Form in the download page

by Vincent Massol

Hi devs and everyone, Emilie has proposed the following content to be added to the Download page (http://www.xwiki.org/xwiki/bin/view/Main/Download): http://dev.xwiki.org/xwiki/bin/view/Drafts/TextDownload The idea is twofold: 1) to get feedback about what people think about our software. 2) some people who download the XWiki software from xwiki.org don't know that XWiki SAS has a commercial offerings and could be interested by it The pros for the community are: 1) XWiki SAS will publish back the result of the feedback it receives from the download form which will allow us to fine tune and improve the software 2) XWiki SAS could get more business (from people who want to buy support, dev work, hosting, etc) which will mean accrued budget for paying developers and resources to work on the XWiki project Note 1: the form would be of course optional Note 2: in the future I'd like to see a not for profit foundation to handle xwiki.org, the xwiki open source project, donations, etc. When this happens we could elect from member for the foundation and have the feedback form sent to that foundation for example, with members of the foundation having access to the data (for example). WDYT? Thanks -Vincent Massol, acting as both CTO of XWiki SAS and XWiki open source developer

13 years, 10 months

[xwiki-devs] [VOTE] Move web modue packages/groupid to org.xwiki instead of com.xpn

by Vincent Massol

Hi, Since we're starting the 3.0 cycle I think it's time to move the web modules to use the org.xwiki groupId and package names. It's not really normal for an open source project such as our to use the package of a company (and that of a company that doesn't exist anymore... xpertnet has been replaced by XWiki SAS a few years ago) and I don't think moving web modules to that package/groupid is going to cause any important problems to anyone. Here's my +1 Thanks -Vincent

13 years, 10 months

[xwiki-devs] XWiki.CopyDocument and copy.vm

by Marius Dumitru Florea

Hi devs, I just noticed that we have two forms for copying a document: Space/Page?xpage=copy and XWiki/CopyDocument?sourcedoc=Space.Page copy.vm has been recently updated to follow the vertical form layout standard and its code was also cleaned. XWiki.CopyDocument wasn't updated and I find its code a bit buggy. Maintaining both of them is wrong so I propose to remove XWiki.CopyDocument from the XE xar and update LiveTableResultsMacros to use xpage=copy for the copy link in the action column (I couldn't find any other usages). I'd like to do this asap. Thanks, Marius

13 years, 10 months

[xwiki-devs] [proposal] tracking status of major features in the current version in development

by Ludovic Dubost

Hi, I took the liberty to update a bit the roadmap page http://enterprise.xwiki.org/xwiki/bin/view/Main/Roadmap to add links to the Design page or the JIRA page when they existed. I also added the Investigations with links in the page. I would like to propose that we increase a bit the visibility on the development of the features. What I would like to suggest is that: All major feature in development or investigations gets a "Design" page and these pages are linked from the Roadmap page. The Design page should include at least: - the use cases that are being implemented - a link to the JIRA issue if it exists. - a link to the UI design proposal. I would also like to suggest that the UI design proposal are moved from myxwiki.org to xwiki.org either on their own wiki or on the dev wiki. - a design document which explains the objetives and implementation strategy (this should be reviewed by the community through the mailing list) - and most importantly an action plan with priorities and status on each element of the action plan (it can list the use cases that are first being implemented or other actions necessary to implement) - the action plan should be updated after each Milestone release. - we should also update the Roadmap page when we know a feature is at risk of not making the final release. We already have a lot of that sometimes a bit disorganized. The objective and design is often in a mail thread. It would be better if the last status is on the Wiki. But more importantly what is more missing is the implementation strategy, the action plan with the priorities and the current status. In order to help out prioritizing development based on what we feel the users more need we need the splitting of priorities and the status. This is particularly important for large features that have a big impact and a lot of potential user interactions (extension manager, dashboards, workspaces) Ludovic -- Ludovic Dubost Blog: http://blog.ludovic.org/ XWiki: http://www.xwiki.com Skype: ldubost GTalk: ldubost

13 years, 10 months

[xwiki-devs] Investigation: App Within Minute

by Ludovic Dubost

Hi, In the 3.0 Roadmap we had an investigation for the "App within minute" feature, which Thibaut Camberlin volunteered to work on. I've reviewed his work and we now have something ready for review by the community. When using XWiki for development of form based application what I and others have found out, is that it's incredibly fast to create a simple application when you know which steps to perform (create a class, create a sheet, create a template, create a livetable, etc..). Quite quickly you have a functionnal application. The objective of "App within minute" is to bring XWiki Application development to non technical users of XWiki. We want to allow an XWiki administrator to create a simple form based application in just a few minutes without to have to "know" the steps but simple by following simple configuration screens. Here is the proposal and an associated action plan: http://dev.xwiki.org/xwiki/bin/view/Design/ApplicationWithinMinutes The next steps are: - review by the community - UI proposals by Caty Please send your feedback on the review so that Caty's work on the UI can be planned. Thanks Ludovic -- Ludovic Dubost Blog: http://blog.ludovic.org/ XWiki: http://www.xwiki.com Skype: ldubost GTalk: ldubost

13 years, 10 months

[xwiki-devs] Create "Sanity" administration section group / Where to put document rights check UI

by Jerome Velociter

Hi devs, I've added document rights requirements information in documents that needs PR or "edit" in http://jira.xwiki.org/jira/browse/XE-832 I would like to go further and achieve the full vision discussed in the thread at http://xwiki.markmail.org/thread/ercuqiby2oydl2ev, so including a administration UI to offer to check and fix the status of requirements : http://jira.xwiki.org/jira/browse/XAADMINISTRATION-232 I see 3 options where to put such an UI : 1) In the "programming" section. 2) In a new section "document rights" under an existing group, like Content 3) In a "document rights" section under a new group called "Sanity" I don't like 1) too much because it's not really about programming only since it can concern document that require the "edit" right, not the PR. I tend to prefer 3). There is another issue that could go under that group later on : http://jira.xwiki.org/jira/browse/XAADMINISTRATION-222 (about displaying cache statistics / warnings) WDYT ? Jerome

13 years, 10 months

Re: [xwiki-devs] [xwiki-notifications] r35129 - in platform/core/trunk/xwiki-core/src: main/java/com/xpn/xwiki main/java/com/xpn/xwiki/api test/java/com/xpn/xwiki

by Vincent Massol

On Mar 4, 2011, at 12:26 PM, mflorea (SVN) wrote: > Author: mflorea > Date: 2011-03-04 12:26:51 +0100 (Fri, 04 Mar 2011) > New Revision: 35129 > > Modified: > platform/core/trunk/xwiki-core/src/main/java/com/xpn/xwiki/XWiki.java > platform/core/trunk/xwiki-core/src/main/java/com/xpn/xwiki/api/XWiki.java > platform/core/trunk/xwiki-core/src/test/java/com/xpn/xwiki/XWikiTest.java > Log: > XWIKI-3961: Copy feature does not require the proper rights > * Fixed rights check. > * Removed deprecated copyDocument methods. [snip] > /** > + * The object used to serialize entity references into strings. We need it because we have front APIs that work with > + * entity references but have to call older, often internal, methods that still use string references. > + */ > + @SuppressWarnings("unchecked") > + private EntityReferenceSerializer<String> defaultStringEntityReferenceSerialzier = typo: Serializer -Vincent

13 years, 10 months

[xwiki-devs] Where do we put common build tools?

by Vincent Massol

Hi devs, I've started creating the top level commons project and I started moving the top level pom module in there. However that modules requires 2 build tools: license (adds copyright license info to jars) and verifications (checkstyle). We need to decide where we put these 2 build tools. I can think of 3 solutions: Solution 1 ======== * Create a top level tools project in which each tool is released separately (and thus have a separate jira project) Solution 2 ======== * Put them in commons/trunk/xwiki-common-tools/ * Use the same JIRA project for everything in commons/ (ie same release cycles) * Note: we'll have a JIRA component for each module in commons/ Solution 3 ======== * Have commons/xwiki-common-tools/trunk(branches/tags) and commons/xwiki-common-modules/trunk(branches/tags) * Use 1 JIRA for commons/xwiki-common-modules/ and one JIRA per tool in commons/xwiki-common-tools/ * Don't provide a commons/pom.xml file (since otherwise it would be unversionned) * Note: for artifactIds I'd suggest to not show the "modules" part in the name, i.e. xwiki-commons--component-api, and not xwiki-commons-module-component-api I'm hesitating between solutions 2 and 3. Solution 2 is the simplest of all. It just means all common is released together. WDYT? If you don't have any idea I'll just pick the one I think is best. We need to progress since the release is for Monday. Thanks -Vincent

13 years, 10 months

[xwiki-devs] Status of Investigations in 3.0 Roadmap

by Ludovic Dubost

In the 3.0 roadmap there was the following investigations planned (a bit ambitious): - App within minute - Investigation (thibaut, gregory) - Improved page loading - Investigation - (nobody) - IE6 support drop - Investigation (Greg + Ciprian ?) - Icon theme editor - Investigation (Greg + Caty ?) - LDAP admin section - Investigation (Greg + Thomas ?) - XEM HomePage& Workspace - Investigation (Greg + Fabio + Caty ?) The current status is that: A proposal has been just sent for: - App within minute - Investigation (thibaut, gregory) There was a commit for a simple LDAP admin section by Jerome in 3.0 but no investigation: - LDAP admin section - Investigation (Greg + Thomas ?) If I'm correct, nothing yet has been done for: - Improved page loading - Investigation - (nobody) - IE6 support drop - Investigation (Greg + Ciprian ?) - Icon theme editor - Investigation (Greg + Caty ?) - XEM HomePage& Workspace - Investigation (Greg + Fabio + Caty ?) I will try to work a bit on - Improved page loading - Investigation - (nobody) - XEM HomePage& Workspace - Investigation (Greg + Fabio + Caty ?) before the 3.0 cycle is over (very soon) and I suggest will include all of them in the review for the 3.1 roadmap. I don't think we will keep as many investigations as we need to make sure we achieve the objectives we set. Feedback welcome Thanks Ludovic -- Ludovic Dubost Blog: http://blog.ludovic.org/ XWiki: http://www.xwiki.com Skype: ldubost GTalk: ldubost

13 years, 10 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