- xwiki-devs@xwiki.org - lists.xwiki.org

[xwiki-devs] [Proposal] Roadmap for XWiki 9.6-9.7

by Vincent Massol

Hi devs, Here’s a proposal for the new roadmap (for 2 months: 9.6 and 9.7). Note that it’s summer and several will be on holidays. Dates ===== * 9.6: July * 9.6RC1: 12th July (2w + 2 days) * 9.6Final: 20th of July but we need to start releasing on 17th to be sure we're done before the XWiki SAS seminar (it starts on the 21st till the 28th and during this period the committers from XWiki SAS won’t be very active! :)) * 9.7: August * 9.7RC1: 21st of August (3w) * 9.7Final: 28th of August Topics to tackle ============ * PDF Export - we need to be able to export multiple pages into one pdf file, with no errors and the best rendering possible - Vincent? * Livetable improvements - Who: Pierre + Marius ** Implement bulk actions on livetable items ** Allow List of Users filtering also by entering first and last name, not just the user id ** Displaying a livetable list filter for a non-static list field is not scalable ** Support LiveTable text filtering on DBListclass columns * Administration: Default values - Marius? ** XWIKI-14157 Display the default and inherited values in the Administration ** XWIKI-9663 Show default value for date format in administration * Save button more visible. XWIKI-14162 Position Save buttons on a fixed-bottom area. - Pierre * Notifications - Continue work - Who: Guillaume + Clement ** Replace Watchlist (missing: realtime notifications, RSS feed, Watch this page/space/wiki) ** Replace Activity Stream ** Easy to add notifications from contrib apps ** Add notifications for the Product-team supported apps (see https://products.xwikisas.com/xwiki/bin/view/Applications/) * Get rid of old WYSIWYG - Marius? * Be able to remove help, tour, blog extensions - Thomas? * Improve XWiki Upgrades ** Display a notification when there’s a newer version available - ? ** Warnings when editing extension pages (same as for delete) - https://jira.xwiki.org/browse/XWIKI-14377 - ? If time permits =========== * Add support for Maven `<exclusions>` in Extension Manager * Performance work ** Finish stuff to make filesystem attachment/history content the default (automatic migration, broken deleted attachments UI, etc.) ** Store the job status in separated files (XCOMMONS-1121) ** Live storage of the job log instead of at the end of the job execution(XCOMMONS-764) ** Async macros, panels, ui extensions, etc. ** ... * Tour improvements ** add UI to use of `reflex` atrribute (TOUR-57) WDYT? Thanks -Vincent

8 years, 2 months

3
4
0 0

[xwiki-devs] Glossary Application [GSoC][Update]

by Sarthak Gupta

Hi all, This mail is regarding the status of the project Glossary Application. I have developed the basic UI for the application which enables a user to add a glossary application and also search the already existing glossary item in the glossary space. The UI is still not very user-friendly as I had decided to finish off the leftover designing part after adding more features and just before the release of the first version. The next part of the project was "adding transformations". I have written the code for basic transformation but still facing some errors in it. Hope the errors may be rectified after some code review. The task that will be left before releasing the first basic version will be "the ability to add glossary items from the wiki pages by selecting the words on Wiki pages". More details on http://design.xwiki.org/xwiki/bin/view/Proposal/GlossaryApplication <http://design.xwiki.org/xwiki/bin/view/Proposal/GlossaryApplication>. Also, tests are to be written for each fo the above. Rest of the features which are to be added (See Design Page) will be implemented after the release of the first version. :) Thanks Sarthak Gupta

8 years, 2 months

2
2
0 0

[xwiki-devs] [ANN] XWiki 9.5 released

by Vincent Massol

The XWiki development team is proud to announce the availability of XWiki 9.5. Lots of usability improvements: improved Livetable filtering (Date filters, Multilist filters, DBList filters), Page Templates can now be auto-selected based on the current location, simplified way of adding a logo to a Color Theme and a lot more. In addition, the new Notifications feature has been worked on too: grouping of related notifications, ability to send emails, configuration of locations and sending diffs in emails. Last but not least: XWiki Enterprise is dead! We now have a new XWiki distribution that asks you at startup what Flavor you'd like to use for your wiki, and we're providing a default Flavor called the Standard Flavor (the closest to the previous XWiki Enterprise distribution). In the future there should be more Flavors offered. 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/Data/XWiki/9.5 Thanks for your support -The XWiki dev team

8 years, 2 months

2
1
0 0

[xwiki-devs] Status on scope of XWiki GitHub organization and its implementation

by Vincent Massol

Hi devs, Part 1 ===== I was looking at http://dev.xwiki.org/xwiki/bin/view/Community/DevelopmentPractices#HTopLeve… and found the thread where it was voted in July 2014: http://markmail.org/message/4hglttljiio5v2km Does anyone remember the thread were we decided to not do it? I also found this VOTEd thread from 21st June 2016: http://markmail.org/message/rb5xuex3mpzg3lsm This new thread is not contradictory with http://markmail.org/message/4hglttljiio5v2km so it doesn’t supersedes it. Thus there really must be some other thread where we decided to not implement http://dev.xwiki.org/xwiki/bin/view/Community/DevelopmentPractices#HTopLeve…. Part 2 ===== Now, about http://markmail.org/message/4hglttljiio5v2km we have almost implemented it. We’re just missing one point: “ * The Default Flavor would have at least the same release cycle as the base flavor but it could have more releases (if some of the bundled third-party extensions has some important bug fixes or new features that we want to offer quickly without waiting for the next base flavor release). “ And later on: “ Technically this means putting the Default Flavor in a separate github repo (same as xwiki-enterprise being in a separate repo). We need to discuss how we do it: - consider it’s XE for now and just add the 2 deps of Tour and CK to XE - introduce a new repo for the default flavor and do the build for it and deprecate XE in favor of it. For now we probably need to hardcode the flavor id in the platform WAR till we’re ready to have the flavor selection screen at startup (and for HSQLDB/Jetty packaging we need a hard-coded flavor anyway). " Right now we’ve put the “Standard Flavor” (that’s the new name) inside xwiki-platform but we discussed back then move it to a separate repo in the xwiki github organization and have only the base flavor in platform. Should we do what we decided? Thanks -Vincent

8 years, 2 months

3
6
0 0

[xwiki-devs] (no subject)

by Sarthak Gupta

Hello, I have written some java code on 'transformations'. https://pastebin.com/CCHsg0hq In order to navigate to the required page, I am using the method 'ResourceReference' (highlighted region-line 86,87). Now I want to navigate to the page named 'Glossary.doc' which is located in XWiki. I know my current implementation is wrong and I have been struggling for 2 days to find the right implementation/method. Is there any method that I can use which can return me the String 'Glossary.doc' so that I can create a linkReference to the same page in XWiki? Thanks Sarthak Gupta

8 years, 2 months

2
4
0 0

[xwiki-devs] [GSoC] Extension Repository Connector - Bintray 1.0 released.

by Krzysiek Płachno

Hello everybody! I'm very happy and quite proud to announce that 1.0 version of "Extension Repository Connector - Bintray" is released. I kindly encourage everybody to check it out: http://extensions.xwiki.org/xwiki/bin/view/Extension/Extension%20Repository… (installable with Extension Manager) I'd very grateful for any feedback ;) Best, Krzysztof Płachno

8 years, 2 months

3
2
0 0

[xwiki-devs] [Proposal] Make users list readonly?

by Vincent Massol

Hi devs, Now that our forum is working well I’d like to propose to make the users list readonly and move all users to the forum. So the plan I’m proposing is: * On Monday, make the users list readonly * Send a last message on it, inviting users to move to the forum Note that we’ve already been putting a notice to all messages sent on the users lists inviting users to move to the forum and this has been running for 2 weeks already. My feeling is that we need to finalize the move now and prevent too much scattering of user posts both on the users list and on the forum and have them all on the forum ASAP. WDYT? Thanks -Vincent

8 years, 2 months

5
17
0 0

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

by Eduard Moraru

The XWiki development team is proud to announce the availability of XWiki 9.5 Release Candidate 1. This release features a major restructuring of the XWiki Enterprise distribution by converting it into the XWiki Standard Flavor. User features cover notifications by email, attachments list showing icons and image previews, recommended template at page creation, LiveTable date and multilist filters, and minor visual improvements. Admins can more easily customize the look and feel by the extended use of Icon Themes and the improvements done to setting the wiki logo. Finally, devs have a new API for working with wiki components, new icon theme mappings and notifications API improvements. 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/Data/XWiki/9.5RC1 Thanks for your support -The XWiki dev team

8 years, 2 months

1
0
0 0

[xwiki-devs] [UX][Proposal] Multipage Tours

by Ecaterina Moraru (Valica)

Hi devs, I've made an investigation on what technical problems we have while wanting to provide our beginner users with multipage tours. You can see how the Tours would integrate with the current UI, some tours proposals and issues found at: http://design.xwiki.org/xwiki/bin/view/Proposal/MultiPageTours Let me know what you think and if you have other ideas. Thank you, Caty

8 years, 2 months

1
0
0 0

[xwiki-devs] JIRA, JQL and Release Notes

by Vincent Massol

Hi devs, Almost all our filters on jira.xwiki.org were wrong (all bugs for xwiki committers, all issues for xwiki committers, etc) because they were only filtering on the “top level” category (id = 10000) and thus were forgetting the contrib extensions that we bundled in XE. Thus I’ve renamed the "top level projects” category into “XWiki Enterprise” (and soon we’ll rename it with the name of the flavor replacing it). I’ve also moved the conrib extensions that we bundled into that category. See https://jira.xwiki.org/secure/Dashboard.jspa?selectPageId=10000 As a consequence this fixed https://jira.xwiki.org/secure/Dashboard.jspa?selectPageId=10352 for example, which is now correct. However this leads to a problem: All JQL we wrote that were using things like “category in (“Top Level Projects”)” instead of “category = 10000” are now broken. For example we use this in our Relaese Notes for bug fix releases. I’ve fixed all of them using the Release Application but not old ones yet. Also, in our RN for bug fix releases we need to specify all projects one by one along with versions. Writing the following (as can be seen in http://www.xwiki.org/xwiki/bin/edit/ReleaseNotes/Data/XWiki/9.3.1/WebHome?e…) is wrong for example: category = 10000 AND fixVersion in ("9.3.1") AND resolution in (Fixed) and component not in ("Development Issues only”) FTR in the RN for 8.4.2 I wrote: category = 10000 and fixVersion = "8.4.2" and resolution = Fixed and component != "Development Issues only" OR project = "CKEditor Integration" and fixVersion = "1.10" and resolution = Fixed OR project = "Tour Application" and fixVersion = "1.1" and resolution = Fixed But even that is not correct anymore and we now need to write instead: project IN ("XCOMMONS", "XRENDERING", "XWIKI", "XE") AND fixVersion = "8.4.2" AND resolution = Fixed and component != "Development Issues only" OR project = "CKEDITOR" AND fixVersion = "1.10" AND resolution = Fixed OR project = "TOUR" AND fixVersion = "1.1" AND resolution = Fixed So we need to review: * The filters and dashboard in jira.xwiki.org and fix them (for example GD, in the RN for 9.4 we point to https://jira.xwiki.org/secure/Dashboard.jspa?selectPageId=13894 which is broken now since its filter uses “Top Level Projects” but I can’t fix it since I don’t own it in jira…) * The JQL statements used in xwiki.org and especially in the RNs. We should probably create some scripts/tools to help us write those JQL. Any comment? Any other idea? Thanks -Vincent

8 years, 2 months

1
3
0 0

[xwiki-devs] [Idea] Also save the previous version when upgrading

by Vincent Massol

Hi devs, I’d like to propose that we also save the previous version of XWiki when we upgrade. I can think of 2 use cases for that: * After the user upgrades we display a What’s New (could be something in the notification area, in the Admin UI home page, as a popup on the first connexion after the upgrade, etc) and we take the data from the Release Notes app on xwiki.org using the previous version information to list what’s new. * When a user reports a problem of upgrade, we can ask him to tell us the previous version that is stored. WDYT? Note that the info should probably be stored somewhere in the permanent directory. It could even be stored in the existing status.xml file. EDIT: Actually it could already exist maybe. I’ve just checked distribution/status.xml on xwiki.org and I can see: <previousDistributionExtension> <id>org.xwiki.enterprise:xwiki-enterprise-web</id> <version class="org.xwiki.extension.version.internal.DefaultVersion" serialization="custom"> <org.xwiki.extension.version.internal.DefaultVersion> <string>8.4.4</string> </org.xwiki.extension.version.internal.DefaultVersion> </version> <hashCode>-1</hashCode> </previousDistributionExtension> <previousDistributionExtensionUi> <id>org.xwiki.enterprise:xwiki-enterprise-ui-mainwiki</id> <version class="org.xwiki.extension.version.internal.DefaultVersion" reference="../../previousDistributionExtension/version"/> <hashCode>-1</hashCode> </previousDistributionExtensionUi> <distributionExtension> <id>org.xwiki.enterprise:xwiki-enterprise-web</id> <version class="org.xwiki.extension.version.internal.DefaultVersion" serialization="custom"> <org.xwiki.extension.version.internal.DefaultVersion> <string>8.4.4</string> </org.xwiki.extension.version.internal.DefaultVersion> </version> <hashCode>-1</hashCode> </distributionExtension> @Thomas: Any idea with previous version = new version = 8.4.4? @Thomas: Do we have an API to get that info from a velocity script for example (or from Java)? Thanks -Vincent

8 years, 2 months

2
5
0 0

[xwiki-devs] [Glossary Application] Creating Transformations

by Sarthak Gupta

Hello, The next part of my project is creating transformations i.e displaying words included in glossary differently when a page renders. After going through docs, I understood that I have to write a new rendering transformation. This new transformation will match the words on different pages to the glossary items present in the glossary space, and then create links to the required glossary page. What should be the name of this transformation? glossaryTransformation? Furthermore, I have used the xwiki-rendering-archetype-macro for generating the component using maven [ mvn archetype:generate \ -DarchetypeArtifactId=xwiki-rendering-archetype-macro \ -DarchetypeGroupId=org.xwiki.rendering \ -DarchetypeVersion=9.5-SNAPSHOT ] I am still working on the component implementation. Hope I am going on the right track. Thanks :) Sarthak Gupta

8 years, 2 months

2
3
0 0

[xwiki-devs] [Proposal] New configuration strategy - Take 2

by Vincent Massol

Hi devs, Current Situation ============= In the past we discussed this and even reached some conclusions but it wasn’t implemented. The relevant thread: * Original idea: http://markmail.org/message/yl77mvdtznii263l * Updated idea: http://markmail.org/message/6cvm5hocvtbqtgp6 This thread supersedes these old threads. In the meantime Thomas has also implemented https://jira.xwiki.org/browse/XWIKI-13867 (BTW I added several comments but didn’t get any answer from them ;)). So here’s an updated proposal: Use Cases: ========= - UC1: Easy install: no need to explode the WAR to install XWiki. - UC2: Easy upgrade: no need to take care about backupping specifically the configuration in WEB-INF so that it's not overwritten by an upgrade of the WAR - UC3: Should be possible to have multiple installs on the same machine and running at the same time - UC4: Should be possible to control the location of the configuration files for our automated functional tests (so that we control the configuration used) - UC5: (Future) Make XWiki work without configuration files - UC6: Allow our users of the Docker image to configure XWiki outside of the container (see https://jira.xwiki.org/browse/XDOCKER-20). Implementation Proposal: ==================== * Configuration files = xwiki.cfg, xwiki.poperties and hibernate.cfg.xml * Allow configuring the permanent directory with the XWIKI_DATA_DIR environment variable (in addition to the existing xwiki.data.dir system property, i.e. -Dxwiki.data.dir=…). In Java this is done by using System.getenv() * Load the configuration files in a specific order, each level overwriting the previous level, except for hibernate.cfg.xml since it’s harder to merge XML. The idea is that users will only need to define configuration properties that they want to override. * The order is the following: ** Load from WEB-INF/ ** Load from the location defined by the JNDI property ** Load from [permanent directory]/config/ * For xwiki.properties and xwiki.cfg, if the property is not found, then default to a value provided by the code. * Add some comments at the top of xwiki.cfg, xwiki.properties and hibernate.cfg.xml to explain to the user how they should customize them. Option 1: * Right now if the permanent dir is not defined, we default to using the servlet temporary directory (i.e. “javax.servlet.context.tempdir” system property). One option is check the OS and: ** If on unix, default to /etc/xwiki/ ** If on windows, default to the user home profile (using System.getProperty("user.home”) or System.getenv("USERPROFILE”)) Option 1bis: * Right now if the permanent dir is not defined, we default to using the servlet temporary directory (i.e. “javax.servlet.context.tempdir” system property). One option is to default to the user ome directory instead (using System.getProperty("user.home”)). Note that for UC5 my POV is that in the future: * We should move the database configuration to a step in an Installation Wizard that execues on XWiki’s first run. This would internally generate the Hibernate configuration. * Provide defaults for all xwiki.cfg properties (it’s already the case for xwiki.properties normally). Note: I don’t know where https://jira.xwiki.org/browse/XWIKI-13867 fits; it could maybe fit with Option 1 (which is why I wrote option 1 and 1bis actually). WDYT? Thanks -Vincent

8 years, 2 months

1
0
0 0

Re: [xwiki-devs] [PROPOSAL] So, what display name for the new default flavor ?

by daniel glazman

> > * "Base XWiki Flavor” > > * “Classic XWiki Flavor” > > * “Raw XWiki Flavor” > > * “Starter XWiki Flavor” > > * "Default XWiki Flavor” > > * "Generic XWiki Flavor” > > * “Standard XWiki Flavor” > > * "XWiki Flavor” > > * "Vanilla XWiki" Sorry to send this message without the threading references; I just subscribed to the devs(a)xwiki.org mailing-list and I would like to contribute my €0.02 to the discussion The items below are numbered for commenting convenience but are not ordered in any way. 1. The name XWiki already has its first letter at the end of the alphabet. Marketing-wise in the Software ecosystem, lists of apps are most often alphabetically sorted, granting a bonus to apps with a name in A, B or C, and a minus to the end of the alphabet. So all names there have to counterbalance that handicap and I think "self-descriptiveness" does matter. 2. if you except "XWiki Flavor", the word "XWiki" comes in second position in all proposals, and that is not the best thing ever. 3. the name must be chosen wrt the targeted audience and the product's position on the market. I think Olivier has a point when he writes « what is the audience and the objectives ? » 4. more specifically about the proposals above: 4.1. a "flavor" holds the notion of specialization. 4.2. "Classic" can mean "legacy" in the Software world. Use carefully... 4.3. "Vanilla" is a geeky choice. Nobody else but geeks will get it,sorry. IMHO, "XWiki Foundation", "XWiki Core" or "XWiki Starter Kit" represent quite well what this is all about. </Daniel>

8 years, 3 months

4
10
0 0

[xwiki-devs] [Brainstorming] Templates exposure

by Ecaterina Moraru (Valica)

Hi devs, This roadmap we had 2 suggestions: - "Find a way of avoiding to have 2 "Add" entries ("+" and "Add new entry")" in AWM - "Drop down on "+" Menu + Admin UI to select some templates" What we have implemented so far was: http://jira.xwiki.org/browse/XWIKI-14310 "Propose and pre-select "recommended" templates in the create UI based on the current location" So now, if you go to the Blog app and create on the "+" button, since Blog provides a template with a create restriction, the "Blog" template will be preselected. Also, AWM has the option to create a template for each application the users create. So after you created your app with AWM and go to the "+" button, the app template will be preselected. This will allow us in the future to remove the AWM actions area and rely on the "+" button. In the future, we could also separate templates in their own "Recommended" category. A separate category will be necessary for applications that provide multiple related templates (like Forum for example that will contain the Forum, Topic templates) or in the more general case when multiple templates are recommended for the current location. Currently we are doing only sorting and preselecting the first one. In terms of implementation we just need to make sure all our recommended apps provide template providers and after that we could change the UI for AWM and remove the "Add" action from the actions area. Now, I want to ask your opinion on the suggestion to add a dropdown for the "+" button. Some input: - a dropdown will not be scalable: you cannot have more than a few options there; - in a dropdown you cannot specify the page name; - in the dropdown you cannot change or specify another location - you always need to go to the page first and after choose a template from the dropdown list; - you will only see an admin selection of templates - so we invalidate the templates filtering and you cannot even choose another template after your initial selection; - we make the current create step deprecated, since users will not see it anymore. The main reason of this request was to increase visibility and order for the templates. In the user recording sessions I've seen and with the current layout (2 columns, templates on right) users don't have problems seeing the "Templates" section in the Create step. Now, for the ordering / selection - the current mechanism of automatic ordering is a step in that direction - but sure we could implement more (like the separate category I described earlier). Another difference between what was asked and what was currently implemented is that now the selection comes from the Template Provider; while the idea was to allow the Administrator to select the displayed Templates. With the current implementation we can still create an administration UI to select them and save the changes in the Template Providers, in a future iteration. ----- So the question is: - Do you have other ideas on how we could solve the requests? - What do you think about having a dropdown with the templates selection - compared to a recommended category in the creation step? Thanks, Caty

8 years, 3 months

4
6
0 0

[xwiki-devs] [UX][Proposal] Rights

by Ecaterina Moraru (Valica)

Hi devs, I've made a proposal on rights improvements at https://forum.xwiki.org/t/ux-rights-improvements/107 Haven't received much feedback on it so I'm cross posting it here in case you've missed it. Thanks, Caty

8 years, 3 months

1
0
0 0

[xwiki-devs] Handling default values and displaying them in form elements

by Eduard Moraru

Hi, devs, While handling https://jira.xwiki.org/browse/XWIKI-14157 (Display the default and inherited values in the Administration), I`m trying to come up with a solution that is applicable more generally and avoid having to manually patch just the problem at hand. We could think of this as a 2 piece problem: 1) getting or specifying the default value (or maybe it's more correct to say default display value?) 2) displaying a form field and handling the default value (view/edit modes) 1) would be much simpler if we only had to handle a flat level class and its objects, but, for XWikiPreferences, we also have the "space<space<wiki<xwiki.cfg" inheritance to consider. This inheritance is done through the use of various ConfigurationSource implementations that delegate one to another. The problem with ConfigurationSource is that, through its use of getPreference(preferenceName, defaultValue), we end up in proliferating default values throughout the code, each time we just want the value of that preference, resulting in a big mess and not knowing what is the default value for that preference and where it is set. I was thinking of adding some: * <T> T getPropertyDefault(String name) method which would allow a ConfigurationSource to handle by itself the retrieval of the default value for a property and a * <T> T getPropertyOrDefault(String name) convenience method for callers to fallback on the internally-determined default value, without caring what it actually is. As an example, this would be useful when calling $xwiki.getXWikiPreference(...) since we don`t have to specify the default value in the caller, but it will be retrieved by performing the fallbacks mechanism space<space<...<wiki<xwiki.cfg. Still for 1) but for ConfigurableClass sections that rely on a simple configuration class (or any other form that relies on properties defined by a class), one idea would be to add a "defaultValue" meta-property (with associated getter/setter in PropertyClass) in the class that allows specifying the default value of a property when defining it. This would allow a displayer to have the default value and properly display it, instead of weird "---" stuff we do now and all kinds of *fake* values, just so that the user can select them. (We may also need a "defaultPrettyValue" or "defaultDisplayValue", with associated getter/setter, for things like DBList). Reminder: We already have a "defaultValue" meta-property for BooleanClass, so it looks like we had the idea before, just did not take it all the way. So XWikiPreferences goes more into the "specifying the default value at display time" workflow, IMO (because we would have to provide the default value that is retrieved from a "special" mechanism, i.e. $xwiki.getXWikiPreference(...))... and we should use the "getting the default value" (from the class property's "defaultValue) as the default behavior, for simple objects of simple classes. Finally, for 2), I`m thinking that we might need a way to also pass the default value to a display() call, overwriting anything else, in order to support custom fields that get their defaults from external sources or other mechanisms that don`t involve the XClass and the "defaultValue" defined there (like XWikiPreferences does, for example, or other custom stuff). This also introduces the problem that not everybody might want a default value proposed in their form for a certain element, so we should also be able to specify, at display time, if the default value should be proposed or not. These optional additions to the display method ("defaultValue", "defaultDisplayValue", "showDefault", etc.), including the existing ones ("prefix", "wrappingSyntaxId", etc.) should probably be done with a new signature that also takes a map of parameters. The aim is to rely as much as possible on $doc.display(property, parameters) when creating forms in XWiki, while also encapsulating the default value to the location responsible for it, and not to the caller. WDYT? Thanks, Eduard

8 years, 3 months

1
0
0 0

[xwiki-devs] [GSoC] More extension repositories [Bintray / Artifactory]

by Krzysiek Płachno

Hey! I investigated a bit Binatray and Artifactory and uploaded relatively short raport: http://design.xwiki.org/xwiki/bin/view/Proposal/MoreextensionrepositoriesAr… Any comments, ideas, relfections - highly appreciated. Best, Krzysztof Płachno

8 years, 3 months

2
14
0 0

[xwiki-devs] [Contrib] GitHub and JIRA project for application-hubot

by Ludovic Dubost

Hi I've created a github repo on https://github.com/xwiki-contrib/application-hubot for a XWiki/Hubot/Matrix integration. I might not have setup the repository completely for this and also did not create Jira project. Could the dev team complete this ? Thanks Ludovic -- *Ludovic Dubost* *Founder and CEO* ludovic(a)xwiki.com skype: ldubost Blog: http://blog.ludovic.org <https://r.clb.pt/r/b13683e7987e2155d687c1636911d8fe?d=http%3A%2F%2Fblog.lud…>Try XWiki on the cloud <https://r.clb.pt/r/b13683e7987e2155d687c1636911d8fe?d=http%3A%2F%2Fwww.xwik…> - Try Cryptpad: Secure realtime Wysiwyg Editing <https://r.clb.pt/r/b13683e7987e2155d687c1636911d8fe?d=https%3A%2F%2Fcryptpa…>

8 years, 3 months

2
1
0 0

[xwiki-devs] [Contrib] RedPen Integration - Request for project

by deshengchuan

Hi, so I'd like to request for a Github repository for my RedPen integration project. As of now, I'd like to name the repository application-document-checker (yeah it's two words instead of one but I feel it is necessary to capture the full meaning of this application) As for description, I think it is enough for now to describe it as a proofreading tool to ensure that the quality standards of a Wiki document is met. My GitHub name is laskjk (It is an old username made a year back and I'd like to keep the history of my commits in one account) As of now this is what I need. I'll request for more hosting tools at a later date, when I am nearer to producing a working application. Thank you for your help! -- View this message in context: http://xwiki.475771.n2.nabble.com/Contrib-RedPen-Integration-Request-for-pr… Sent from the XWiki- Dev mailing list archive at Nabble.com.

8 years, 3 months

2
2
0 0

[xwiki-devs] [PROPOSAL] So, what display name for the new default flavor ?

by Thomas Mortagne

Hi devs, I'm getting closer to finish with the hard work around new platform flavor which is going to replace XE. Need to decide what user will see in the Flavor picker when installed XWiki now. As a reminder we decided that this would be a generic flavor, not tied to any specific use case (so forget about "Knwonledge Base Flavor" :)). Here is a few ideas gathered in previous mails: * "XWiki Flavor" * "Default XWiki Flavor" * "Generic XWiki Flavor" * "Base XWiki Flavor" "Generic" is probably a way too technical term. "Base" would be misleading IMO since it's not really a base flavor. Its primary goal is not to be used as a dependency (of course it's fine to have it as dependency if you just want to add pre installed extensions to the default flavor). It's a -1 for me. Frankly I would simply go for "XWiki Flavor". I know, it's not going to be the only flavor for XWiki but it's obvious when you actually see severals of those in the picker anyway and I find it nicer than "Default XWiki Flavor" which basically means the same thing since the XWiki core project does not plan to provide any other flavor. I'm also fine with "Default XWiki Favor" if others think it's a better name. WDYT ? -- Thomas Mortagne

8 years, 3 months

10
22
0 0

[xwiki-devs] [Update 2] RedPen Integration

by deshengchuan

Hi all, this is another weekly update with regards to the work on the RedPen extension. I've more or less created a component + scriptservice that helps to validate an input string of text. How I envision this to work is that an Event Listener would obtain the context of the document when the user saves the page, parse it using the syntax rendering component to plain text, then run it through the component I've made. Hence, the next week would be dedicated to writing the event listener. I have still not designed how I am going to take in the user's validation settings, hence I have an incomplete Java class and will work on it after writing the event listener With that in mind, I think I should request a repository on xwiki-contrib, since I already have some starting code available locally. May I know what are the required steps I need to achieve that? Next, I understand that there are three ways that one can write an event listener, either using an XWiki Component in a jar, a Wiki Component or using Groovy. I am currently considering using Groovy to create the Event Listener directly within a wiki page. Any thoughts on that? Lastly, I am unsure of the report format and details to submit as part of the GSOC programme. Can I get some clarifications with regards to it? Thanks. -- View this message in context: http://xwiki.475771.n2.nabble.com/Update-2-RedPen-Integration-tp7604136.html Sent from the XWiki- Dev mailing list archive at Nabble.com.

8 years, 3 months

2
2
0 0

[xwiki-devs] [VOTE] Move the WebDAV feature to xwiki-contrib

by Vincent Massol

Hi devs, With https://jira.xwiki.org/browse/XE-1527 (http://markmail.org/message/t7khe7ufdtlsf5gl) we’ve removed the WebDAV feature by default in XE. I’d like to propose to go one step further and consider the webdav feature as non-core and move it outside of the xwiki github organization and into xwiki-contrib. I’d also propose that the XWiki Core Dev Team stops supporting it. Rationale: * We haven’t touched it in a long long time * It’s not a feature requested by our users anymore * If any contributor is interested in working on it one day, it’s simpler in xwiki-contrib and it can be released independently of XWiki Here’s my +1 Please cast your vote Thanks -Vincent

8 years, 3 months

8
8
0 0

[xwiki-devs] Fwd: New product from YourKit: monitor CI servers, build tools and tests

by Vincent Massol

Could be interesting… Thanks -Vincent > Begin forwarded message: > > From: YourKit <info(a)yourkit.com> > Subject: New product from YourKit: monitor CI servers, build tools and tests > Date: 12 June 2017 at 09:48:07 GMT+2 > To: vincent(a)massol.net > > Greetings, > > YourKit is proud to announce an early access to the new product codenamed "ProjectX": > monitoring and profiling solution for continuous integration servers, build tools > and testing frameworks. > > With ProjectX you can monitor in runtime how your software project > builds (Ant, Gradle, Maven) and tests (JUnit, TestNG). > > No other tool will such comprehensively tell you what your software build > consists from or give you insight how to optimize it. > > Moreover, a historical data of monitored builds is remembered to immediately detect > any build and test performance regressions, which may indicate a problem or a regression > in your software project itself. > > In particular, you may think that ProjectX automatically makes your existing unit tests > performance tests too. > > You can monitor builds under continuous integration servers (Jenkins, Hudson, TeamCity), > from within your IDE in development (Eclipse, IntelliJ IDEA, NetBeans) or even standalone. > > Find more detail and download at > https://www.yourkit.com/projectx/ > > The first build which is now available provides basic functionality, > but is valuable enough to give it a try. > > More features and improvements to come, stay tuned! > > Kindest regards, > YourKit Team > ____________________________________________________________ > If you would not like to receive any more information about > YourKit products, simply send an email to info(a)yourkit.com > with the subject line "unsubscribe".

8 years, 3 months

1
0
0 0

[xwiki-devs] Error in code. :/

by Sarthak Gupta

Hello all, It's been 2 days that I am stuck in a stupid error. I have a "add glossary" button in my application, and when I click that button, the browser gives me the error: "This page isn’t working, 127.0.0.1 redirected you too many times." Now this is a redirect loop. And it's caused by the statement $response.sendRedirect($xwiki.getURL($newGlossaryReference, 'inline', "$!{request.queryString}&title=${escapetool.url($glossaryItem)}")) in my code I guess. I am not able to figure out why this is looping even if there is no loop. I have tried certain things but there is no progress. Moreover, my title bar appear like this: http://127.0.0.1:8080/xwiki/bin/inline/Glossary/Hello?parent=Glossary.WebHo… Here is my complete code: https://pastebin.com/p95DeHMg Could someone please take some time and help me out? IRC:sarthakg Thanks Sarthak Gupta

8 years, 3 months

2
4
0 0

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

2005

xwiki-devs