xwiki-devs March 2015

xwiki-devs@xwiki.org

22 participants
55 discussions

[xwiki-devs] [Proposal] Change script macro to return JSR223's eval value

by vincent＠massol.net

Hi devs, I’ve implemented http://jira.xwiki.org/browse/XWIKI-11961 However it’s causing several tests to fail, proving that it’s changing the script behaviors. For example if you have: {{groovy}} var = "toto" {{/groovy}} {{velocity}} $var {{/velocity}} Then you’ll see “toto” printed twice. Once for the groovy macro. The right way to not output content is to use output=false as in: {{groovy output="false"}} var = "toto" {{/groovy}} {{velocity}} $var {{/velocity}} So we need to decide if we’re ok to go with this even though it changes the behavior. I don’t completely master the full gamut of consequences this will have but I have the feeling that from a logical point of view, it’s the best thing to have. WDYT? Thanks -Vincent

9 years, 9 months

[xwiki-devs] [Proposal] Removal of XWiki.RequiredRightClass page

by vincent＠massol.net

Hi devs, In xwiki-enteprise we have XWiki.RequiredRightClass. We’ve started discussing it in the past in the “Split XE pages” mail thread and I’d like to move forward. So we need to decide what to do about it. Several options: * We discussed moving it to xwiki-platform-administration but it shouldn’t go there IMO since we’re trying to make this module almost empty (just providing the extension points mechanism) and have admin features dispatched in the modules providing them. Also it would mean forcing unnecessary dependencies on xwiki-platform-administration from several modules (6-7 right now). * It could go in a new xwiki-platform-security-ui module. * It could be moved to Java but we don’t have a clear policy nor decision if we want to favor xclasses written in java or opposite, decide that we don’t want that and move away from XClasses in Java. So we’d need to decide this first. * We could also simply remove it! Rationale: ** I don’t think we’re using that information much and its need is supposed to go away once signed scripts is there ** There’s no way to force pages requiring PR to add such an XObject and thus it’s not done consistently ** We don’t even have a page listing all pages requiring PR and even if we had one I’m not exactly what it would bring. I guess the idea was to make it simpler to install/upgrade XWiki but we’ve fixed this already in the Wiki Creation Wizard for example so the need is less now. So overall I’m more in favor of dropping this experiment which IMO wasn’t very successful. WDYT? Thanks -Vincent

9 years, 9 months

[xwiki-devs] [contrib] Automated tests and changing module IDs

by Ecaterina Moraru (Valica)

Hi, I want to write automated tests for some contrib applications, but I need you help on some questions. == Prb 1. Folder Structure + Changing IDs == Currently the majority of applications don't have modules. Also some applications have IDs that don't correspond with the contrib standard: sometimes wrong groupId like 'org.xwiki.contrib.forum', sometimes random artifactId. When wanting to change the groupId for 'org.xwiki.contrib.forum' I was told that we should change it only if we have a very good reason, otherwise changing the ID will resolve in upgrading problems within the Extension Manager. Unfortunately I don't remember exactly the problem with the changing of the ID, I just know I don't need to do it :) (//sorry Thomas) Example: https://github.com/xwiki-contrib/application-forum Theoretically, wanting to add tests I would need to create two modules: - application-forum-test - application-forum-ui, and move the current sources here. Unfortunately this means a change in the ID. Are 'adding tests' a good reason to change the ID? Should I not change the ID, and just add a test module? - application-forum-test - src/main/resources == Prb 2. Naming standards == We have some conventions on contrib.xwiki.org about name of the project. We should add maybe some more examples on groupId and artifactId. Also when looking at the test modules names, some applications have: - {{full-repository-name}}-tests - {{full-repository-name}}-test - {{partial-repository-name}}-test - {{random-repository-name}}-test - test Maybe we should agree also on this and document it. I guess the correct name would be: - {{full-repository-name}}-test -- {{full-repository-name}}-test-pageobjects -- {{full-repository-name}}-test-tests - {{full-repository-name}}-ui Also if we are 'discovering' some applications that don't correspond to the standard, do we change them or do we let them be? Since changing means a change in the ID :P Since in theory we should have automated tests for all our applications, should we add a convention to always create a - {{full-repository-name}}-ui ? Additional question: Also when we will transfer from platform to contrib, are we going to rename the modules? Thanks, Caty

9 years, 9 months

[xwiki-devs] Refer to attached javascript file with $xwiki.jsfx.use

by Hamster

I have a page "Test6" in space "Algemeen". On that page I have uploaded "three.min.js", a javascript file. I want to use that script, but how? {{velocity}} $xwiki.jsfx.use('Algemeen/Test6/three.min.js') {{/velocity}} If I use this and then look at the DOM, then this is what I see: It refers to the colibri skin...but that's not where my "three.min.js" is located. Any help is appreciated! -- View this message in context: http://xwiki.475771.n2.nabble.com/Refer-to-attached-javascript-file-with-xw… Sent from the XWiki- Dev mailing list archive at Nabble.com.

9 years, 9 months

[xwiki-devs] [ANN] XWiki 7.0 Release Candidate 1 released

by Thomas Mortagne

The XWiki development team is proud to announce the availability of XWiki 7.0 Release Candidate 1. The version is mostly about stabilization before 7.0 final. It contains diff UI improvements, Extension Repository improvements, a new component based watchlist module, a new application to edit wiki skins. XWiki also moved to Servlet 3.0.1 which means various old application servers versions are not supported anymore. You can download it here: http://www.xwiki.org/xwiki/bin/view/Main/Download Make sure to review the release notes: http://www.xwiki.org/xwiki/bin/view/ReleaseNotes/ReleaseNotesXWiki70RC1 Thanks -The XWiki dev team

9 years, 9 months

[xwiki-devs] [Contrib] Request for an xwiki contrib project

by Emily Sterenfeld

I'm restarting my request, better following the procedure. Sorry for being imprecise before. Some contexte for my request: I'm an intern at XWiki SAS doing a small application for my internshop which finishes this week and I need a place to deliver my project. I would like a contrib project for the following application: Application Name: "Acquisitions Application" Application Description: "Inventory and Request Management Application. This application allows to do an inventory of any material (computer, phones, accessories) done by a company. It allows includes a request management application to help manage new requests." For this application I would need: - A github repository (my username is EmilySterenfeld) names "application-acquisitionmanagement" - A jira project XAACQUISTIONS (XWiki Application Acquistion Management) One I have this, I will commit the code I have worked on a release the application on extensions.xwiki.org. Thank you Emily -- <http://www.xwiki.com/>*Emily STERENFELD* *Intern Client Team* emily.sterenfeld(a)xwiki.com mobile: 06.09.41.15.38 skype: emily_lucie

9 years, 9 months

[xwiki-devs] [Proposal] Removal of XWiki.RequestsStatus page + agreement to work on integrating Admin Tools in the default flavor

by vincent＠massol.net

Hi devs, Right now we have a XWiki.RequestsStatus page in xwiki-enterprise. This page shows information about the incoming requests if the monitor plugin is active. I’m proposing to remove it on the following basis: * It should be part of the Admin Tools Application (it probably is there already) * We should move the Admin Tools Application from xwiki-contrib to xwiki-platform and bundle it by default. Of course this should be done after having improved it: - following best practices - all pages converted to XWiki 2.1 syntax (several if not all are using XWiki Syntax 1.0!) - integrate it into the Admin UI (and not from the Applications Bar since I believe this is really admin stuff and best accessed from there). Specifically create a “Monitoring”/“Admin Tools” menu section in the Admin with several subsections for the different features. * Future: Deprecate the monitor plugin and replace it with a more recent framework such as Codehale Metrics To summarize, this proposal is about: * Removing that page and ensuring it’s in the Admin Tools app * Agreeing that once Admin Tools is nice enough we’ll move it xwiki-platform and bundle it in the base flavor WDYT? Thanks -Vincent

9 years, 9 months

[xwiki-devs] Xwiki web address offline offen！

by /xin蜗牛

Hi， Xwiki web address usually offline，so i can not read the documents very well。Can you provider offline documets？ Thanks very much！

9 years, 9 months

[xwiki-devs] Repository application_Acquisition

by Emily Sterenfeld

Hello ! It's possible to take an repository for my application please ? Name of repository : application_Acquisition Thank you ! -- <http://www.xwiki.com/>*Emily STERENFELD* *Intern Client Team* emily.sterenfeld(a)xwiki.com mobile: 06.09.41.15.38 skype: emily_lucie

9 years, 9 months

[xwiki-devs] Migration Manager Subsystems

by Marc Sladek

Dear XWiki devs Within the scope of our XWiki-based project called celements, we are using several so-called "modules", which consist of JARs, web resources (VM/CSS/JS files) and hibernate mappings. These modules extend the functionality of the base application and can be optionally added if required. We need to update and migrate these modules independently from XWiki. Therefore we require to store individual migration version numbers in the database for each module. XWiki's single implementation of DataMigrationManager, HibernateDataMigrationManager, isn't intended to store multiple version numbers with specific identifiers in the database. There also doesn't seem to be an evident hook from XWiki to seamlessly add own implementations of the DataMigrationManager to the application to allow migration subsystems. Considering the similarities of XWiki extensions to our modules, is there already a way that we have missed to achieve independent migrations of our modules? If not, are there any future plans from XWiki's side to add this functionality? Thanks in advance Marc Sladek synventis gmbh

9 years, 9 months

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

2005

xwiki-devs March 2015