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

[xwiki-devs] [Brainstorming] Preparation for XWiki 10.7 aka the "Quality Release"

by Vincent Massol

Hi devs, We’ll soon start XWiki 10.7 (see https://markmail.org/message/qjemnip7hjva2rjd). Goals ===== There are 2 goals for this release: 1) Close as many bugs as possible (note that I didn’t say “fix” ;), the goal is really to reduce the number of open bugs and thus to close won’t fix, duplicates, etc and also to fix low hanging fruits, i.e. easy bugs). The goal is quantity. To try to reduce our "bug lag" Our current status today: * -47 bugs over 120 days (4 months), i.e. we need to close 47 bugs to have created bugs # = closed bugs # * -95 bugs over 365 days (1 year) * -160 bugs over 500 days (between 1 and 2 years) * -331 bugs over 1600 days (4.3 years) A good result would be to close 47 bugs during 10.7 and an excellent goal would be to close 95 bugs during 10.7 (i.e. have as many bugs closed than opened for the past year). 2) Improve our tests and make sure that our global TPC is increasing again and not going down. See * http://markmail.org/message/up2gc2zzbbe4uqgn * http://markmail.org/message/grphwta63pp5p4l7 * http://markmail.org/message/hqumkdiz7jm76ya6 I think the following activities would be good one for 10.7: * Increase coverage especially for modules that have lost coverage. See all the lines in red on https://up1.xwikisas.com/#-GNXv9QYlBWPXTHNnvQD2g which should be high priority modules. * Add tests for modules that don’t have tests yet (for example I added some functional tests last week to the xwiki-platform-menu module which didn’t have any test at all) * Once coverage has been increased, up the jacoco threshold wherever possible ;) * IMPORTANT: Fix known flickering tests * (easy, to relax ;)) Convert JUnit3 and JUnit4 tests to JUnit5 Repartition of Work =============== Ideally we should spend 1/2 on BFD and 1/2 on Tests. We could say that the 1st 15 days are on Tests and the last 15 days on BFD (or the opposite), or just let everyone handle his own time table and just make sure we do roughly half of both activities. I don’t think it would be good to have devs focus only on tests and others only on BFD. I’d really prefer that each dev does 1/2 of both. My preference goes to leave each dev choose when they work on BFD and on tests with an agreement that we will try to do half of each. WDYT? Thanks -Vincent

7 years, 2 months

3
4
0 0

[xwiki-devs] Fwd: [Brainstorm] Notifications filters capabilities and performances.

by Guillaume Delhumeau

I resend this message that was accidentally sent to Sergiu only. ---------- Forwarded message ---------- From: Guillaume Delhumeau <guillaume.delhumeau(a)xwiki.com> Date: 2018-07-02 16:06 GMT+02:00 Subject: Re: [xwiki-devs] [Brainstorm] Notifications filters capabilities and performances. To: Sergiu Dumitriu <sergiu(a)xwiki.org> Hi and thanks you for your answers. 2018-06-29 5:41 GMT+02:00 Sergiu Dumitriu <sergiu(a)xwiki.org>: > The two main problems that I see are that you're mixing two separate > things: > > 1. Tags which are stored in one place, and events which are stored in a > different place > 2. Again tags, and document locations. They may seem similar, but they > are completely different as they are implemented. That's why saying "not > in this wiki, except for this tag" cannot ever be implemented in a sane > way since the exception is on a different plane. > > The logical approach would be to also store the tags in the events, but > this is not a good thing to do. Also, a tag could be added to a page AFTER the event has been triggered. In this case, if you still want to fetch these pages, it won't work. > Where do we stop? For future-proofing > filters, we would have to store the entire document in the event, in > case someone wants to add a filter on "documents with a specific type of > object attached", or "documents with a specific value for a specific > property of a specific object", or "documents with attachments ending in > .extension". > > On 06/28/2018 04:44 PM, Guillaume Delhumeau wrote: > > For the tags filter, I can also: > > > > * perform a query to fetch all documents that correspond to the given > tags > > (it doesn't need to be permanent, but it would be better to cache it) > > * add a HQL filter on these pages (OR document IN :list_of_pages). > > > > It's a little variation of solution A. It's ugly but it could do the job. > > It's the sanest proposal so far, but still impossible. > Apparently it's the way it's done on Activity Stream: https://github.com/xwiki/xwiki-platform/blob/553afe7287dcc4ce8b588276e639bf 283352e805/xwiki-platform-core/xwiki-platform-activitystream/xwiki-platform- activitystream-ui/src/main/resources/Main/Activity.xml#L1008 > > Since "not in LOCATION except WITH TAG" doesn't work because it mixes > two types of information in the same query fragment, how about making > this a one-dimensional query as "only WITH TAG". And since this > information is in a different place, pre-querying it is needed. However, > if there are thousands or tens/hundreds of thousands of documents with a > tag, won't the query crash anyway? > Sure, it won't scale. > > > 2018-06-27 12:58 GMT+02:00 Guillaume Delhumeau < > > guillaume.delhumeau(a)xwiki.com>: > > > >> Hi developers. > >> > >> I am trying to add a new filter to the notifications to be able to > follow > >> pages > >> that are marked with a given tag. And it leads me to some questions > about > >> the > >> technical implementation of the notifications. > >> > >> To remind the context: notifications are computed on top of the events > >> recorded > >> by the event stream (a.k.a activity stream). We take events from the > event > >> stream SQL table, we apply some transformations on them, and we display > >> them to > >> the user. > >> > >> Then we have implemented the ability to filter on these events: for > >> example > >> "don't show events concerning the document A nor the wiki B". Filters > are > >> implemented with 2 distinct ways: > >> > >> 1/ SQL injections: each filter can add SQL elements in the query we > make > >> to > >> fetch the events from the event stream table. We made this > mechanism > >> so we > >> can let the database do a lot of the filtering process. After all, > >> it's its > >> job and it's supposed to perform well. To be precise, Clement has > >> even > >> created an Abstract Syntax Tree (AST) so it's easier to inject some > >> content > >> in the query and it creates an abstraction over the SQL language so > >> we can > >> even consider to change the storage of the event stream someday. > >> > >> The bad thing is that some complex filtering are difficult to write > >> with > >> the SQL language (event with the AST) or even impossible. > >> > >> 2/ Post-filtering: after the events have been fetched from the > database, > >> each > >> filter can still decide to keep or filter them. This is useful for > >> complex filtering that cannot be expressed with the SQL language. > It > >> is > >> also needed by the real-time notification email sender, because it > >> takes > >> the events immediately when they occurs without fetching them in > the > >> database (so SQL filters are bypassed). > >> > >> The bad thing is that some events are loaded in the memory to > finally > >> be > >> rejected, and these filters can perform costly operations such as > >> loading > >> documents. > >> > >> Until now, this double mechanism was working quite well, with each > >> mechanism > >> filling the lacks of the other. > >> > >> However, we still have technical limitations in our design: > >> > >> 1/ Users who have a lot of filter preferences can end up with a giant > >> SQL > >> query that is almost impossible to perform by the database. > Actually > >> we had > >> a user complaining about an OutOfMemory problem in the HQL to SQL > >> translator ! > >> > >> 2/ I cannot implement the tag filter ! > >> > >> The tag filter is supposed to show events that concern pages that hold a > >> given > >> tag, EVEN IF THE PAGE WAS EXCLUDED BY THE USER. Example of use-case: "I > >> don't > >> want to receive notifications about wiki A except for pages marked with > >> the tag > >> T". > >> > >> And it is not working. First because it is difficult to write a SQL > query > >> for > >> that. It requires to make a join clause with the document and the object > >> tables, > >> which our SQL injection mechanism does not support. Even if it were > >> possible, > >> creating a SQL join with the document table will de-facto filter events > >> that do > >> not concern any pages or pages that do not have any objects: so many > other > >> filters will be broken. I also don't consider creating a SQL subquery, I > >> think > >> the whole query would became too big. So I decided to just not inject > any > >> SQL > >> code for this filter and only implement the post-filtering mechanism. > >> > >> But the other filter "EXCLUDE WIKI A" generates a SQL injection such as > >> "WIKI <> 'WIKI A'" so the events concerning the wiki A are not fetched > >> from the > >> database. Consequence: the tag filter never see the events that it is > >> supposed > >> to keep. It would be actually possible to by-pass the first SQL > injections > >> by > >> injecting something like "OR 1=1". But doing something like this is like > >> dropping the all SQL injections mechanism. > >> > >> I see some solutions for this problem: > >> > >> A/ For each tag, create a permanent list of pages that hold it. So I > can > >> inject "OR document IN (that_list)". I think this is heavy. > > Definitely not. You'll have to maintain this list in parallel to the > canonical storage for tags, the xwikidoc table itself, with all the > headaches that data duplication brings. > I agree. > > >> B/ Drop the SQL injection mechanism and only rely on the > post-filtering > >> mechanism. It would require to load from the database A LOT of > events, > >> but maybe we could cache this. > > Nope, filtering millions of events by inspecting them one by one is a > performance nightmare. > > >> C/ Don't drop the SQL injection mechanism completely but use it as > >> little as > >> possible (for example, do not use it for LOCATION filtering). Seems > >> hard to > >> determine when a filter should use this feature or not. > > I think location filtering should still happen in the query itself, > since it is a lot faster. > > >> D/ Don't implement the "tags" filter, since it is the root of the > issue. > >> But > >> it is like sweeping dirt under the carpet! > > Well, not implementing something is always the fastest, least intrusive > solution to any problem... > > Humor aside, I think that in this case it is the best approach. > Thanks for saying it :) > > >> Since we have the OutOfMemory problem with the SQL injections becoming > too > >> huge, > >> I am more in favor of solution B or C. But I'm not sure for now, since I > >> do not > >> know how much it would impact the performances and the scalability of > the > >> whole > >> notifications feature. > >> > >> This is a complex topic, but I hope this message will inspire you some > >> suggestions or things I have not seen with my own eyes. > >> > >> Thanks for your help, > >> > >> Guillaume > >> > > > > > > > Other options: > > E/ Drop SQL altogether, move the event stream into a nosql database, and > do stream filtering; kind of like the B proposal > That's unfortunately out of the scope right now. > > F/ Drop SQL and querying altogether, switch to a pub-sub mechanism where > a subscriber is created for every user and his filters, and matching > events are placed in a queue until they are all sent (consumed) in a > notification. Obviously, this only works for email notifications, not > for browsing past events in a webpage. > Indeed it cannot replace Activity Stream. However, it was my first design attempt: http://design.xwiki.org/xwiki/bin/view/Proposal/ NotificationCenterforAppsImplementation#HIteration1 But then we decided to rely on what we had (the event stream) and to kill 2 birds with the same stones (having notifications + replacing activity stream). Thanks, Guillaume > > -- > Sergiu Dumitriu > http://purl.org/net/sergiu/ > -- Guillaume Delhumeau (guillaume.delhumeau(a)xwiki.com) Research & Development Engineer at XWiki SAS Committer on the XWiki.org project -- Guillaume Delhumeau (guillaume.delhumeau(a)xwiki.com) Research & Development Engineer at XWiki SAS Committer on the XWiki.org project

7 years, 2 months

1
0
0 0

[xwiki-devs] [XWiki Day] BFD#183

by Alex Cotiugă

Hello devs, This Thursday is BFD#183: http://dev.xwiki.org/xwiki/bin/view/Community/XWikiDays#HBugfixingday <http://dev.xwiki.org/xwiki/bin/view/Community/XWikiDays#HBugfixingdays> Our current status is: * -47 bugs over 120 days (4 months), i.e. we need to close 47 bugs to have created bugs # = closed bugs # * -95 bugs over 365 days (1 year) * -160 bugs over 500 days (between 1 and 2 years) * -331 bugs over 1600 days (4.3 years) See https://jira.xwiki.org/secure/Dashboard.jspa?selectPageId=10352 Here's the BFD#183 dashboard to follow the progress during the day: https://jira.xwiki.org/secure/Dashboard.jspa?selectPageId=14308 Happy Bug Fixing Day, Alex

7 years, 2 months

1
0
0 0

[xwiki-devs] [Brainstorm] Notifications filters capabilities and performances.

by Guillaume Delhumeau

Hi developers. I am trying to add a new filter to the notifications to be able to follow pages that are marked with a given tag. And it leads me to some questions about the technical implementation of the notifications. To remind the context: notifications are computed on top of the events recorded by the event stream (a.k.a activity stream). We take events from the event stream SQL table, we apply some transformations on them, and we display them to the user. Then we have implemented the ability to filter on these events: for example "don't show events concerning the document A nor the wiki B". Filters are implemented with 2 distinct ways: 1/ SQL injections: each filter can add SQL elements in the query we make to fetch the events from the event stream table. We made this mechanism so we can let the database do a lot of the filtering process. After all, it's its job and it's supposed to perform well. To be precise, Clement has even created an Abstract Syntax Tree (AST) so it's easier to inject some content in the query and it creates an abstraction over the SQL language so we can even consider to change the storage of the event stream someday. The bad thing is that some complex filtering are difficult to write with the SQL language (event with the AST) or even impossible. 2/ Post-filtering: after the events have been fetched from the database, each filter can still decide to keep or filter them. This is useful for complex filtering that cannot be expressed with the SQL language. It is also needed by the real-time notification email sender, because it takes the events immediately when they occurs without fetching them in the database (so SQL filters are bypassed). The bad thing is that some events are loaded in the memory to finally be rejected, and these filters can perform costly operations such as loading documents. Until now, this double mechanism was working quite well, with each mechanism filling the lacks of the other. However, we still have technical limitations in our design: 1/ Users who have a lot of filter preferences can end up with a giant SQL query that is almost impossible to perform by the database. Actually we had a user complaining about an OutOfMemory problem in the HQL to SQL translator ! 2/ I cannot implement the tag filter ! The tag filter is supposed to show events that concern pages that hold a given tag, EVEN IF THE PAGE WAS EXCLUDED BY THE USER. Example of use-case: "I don't want to receive notifications about wiki A except for pages marked with the tag T". And it is not working. First because it is difficult to write a SQL query for that. It requires to make a join clause with the document and the object tables, which our SQL injection mechanism does not support. Even if it were possible, creating a SQL join with the document table will de-facto filter events that do not concern any pages or pages that do not have any objects: so many other filters will be broken. I also don't consider creating a SQL subquery, I think the whole query would became too big. So I decided to just not inject any SQL code for this filter and only implement the post-filtering mechanism. But the other filter "EXCLUDE WIKI A" generates a SQL injection such as "WIKI <> 'WIKI A'" so the events concerning the wiki A are not fetched from the database. Consequence: the tag filter never see the events that it is supposed to keep. It would be actually possible to by-pass the first SQL injections by injecting something like "OR 1=1". But doing something like this is like dropping the all SQL injections mechanism. I see some solutions for this problem: A/ For each tag, create a permanent list of pages that hold it. So I can inject "OR document IN (that_list)". I think this is heavy. B/ Drop the SQL injection mechanism and only rely on the post-filtering mechanism. It would require to load from the database A LOT of events, but maybe we could cache this. C/ Don't drop the SQL injection mechanism completely but use it as little as possible (for example, do not use it for LOCATION filtering). Seems hard to determine when a filter should use this feature or not. D/ Don't implement the "tags" filter, since it is the root of the issue. But it is like sweeping dirt under the carpet! Since we have the OutOfMemory problem with the SQL injections becoming too huge, I am more in favor of solution B or C. But I'm not sure for now, since I do not know how much it would impact the performances and the scalability of the whole notifications feature. This is a complex topic, but I hope this message will inspire you some suggestions or things I have not seen with my own eyes. Thanks for your help, Guillaume

7 years, 2 months

3
4
0 0

[xwiki-devs] [Brainstorming] Next gen functional testing for XWiki

by Vincent Massol

Hi devs, I’d like to give you some info about what I’ve started working on and verify you like the direction I’m proposing to take for the future of functional testing on the xwiki project. Needs ===== * Be able to test xwiki on multiple environments Context ====== * Right now we test only in 1 env (Jetty+HSQLDB) * I've started some docker images in xwiki-contrib * I’ve also started some experiment through https://jira.xwiki.org/browse/XWIKI-14929 and https://jira.xwiki.org/browse/XWIKI-14930 (see also email thread "[Brainstorming] Implementing multi-environment tests - Take 2” and https://github.com/xwiki/xwiki-platform/compare/XWIKI-14929-14930). This email supersedes the "[Brainstorming] Implementing multi-environment tests - Take 2” thread. * Initially I imagined doing the multi env testing in Jenkins thanks to the Jenkins Docker plugin/library. However I realized that it would be better to be able to run that on the dev machines and thus decided instead to implement it at the maven level thanks to the Fabric8 Maven plugin. Proposal ======= * The new proposal is to stop trying to do it at the maven level and instead do it at the Java level, i.e. be able to control (start/stop the various docker images for the DB, Servlet Container/XWiki and the Browser from within the java junit/selenium tests). * There are several java libraries existing to control docker from within java. For example: https://github.com/docker-java/docker-java * I got convinced when finding this awesome library that combines JUnit5/Selenium and Docker for multi-browser testing: https://bonigarcia.github.io/selenium-jupiter/ ** Note that this relies on the browser docker images provided by the Selenoid project: https://aerokube.com/selenoid/latest/ * So the idea is to extend that to be able to control the other 2 docker containers for the DB + ServletContainer/XWiki. Pros ==== * Very simple setup to start/stop functional tests (and to debug them). Only requires Docker to be installed locally. * Very simple to test any combination of DB/Servlet Container/Browser. * Always up to date images with the latest version (we can depend on LATEST of Browser images, MySQL, Tomcat, etc). * Using JUnit5 and thus the latest features * Moving to the latest Selenium version too * Also supports manually executing tests in a given running xwiki instance Implementation ============ Something like: --> XWikiSeleniumExtension extends SeleniumExtension @ExtendWith(XWikiSeleniumExtension.class) public class Test @Test public void xxx(XWikiWebDriver driver) { … } And be able to configure the DB to use, the Servlet container to use, and the packaging to use from system properties (and also from the test itself, see https://bonigarcia.github.io/selenium-jupiter/#generic-driver). The idea is to reimplement the XWiki Packaging Maven plugin as a java lib using Aether and to just start our functional tests using pure junit without anymore more. All the hard work will be performed by the JUnit5 extension (create the packaging if not already exist, update some part of it if files have been modifier, start/stop DB+Servlet+Browser+Selenium, download the docker images). The packaging will be configurable. Some ideas of options: * use an already running xwiki instance * docker created from full XS zip from URL * docker created from XS zip from maven artifact * docker created from computed based on pom in current dir Migration ======= Once a first version is working, it’ll be easy to use it only for a single platform functional tests and then slowly move each module to use the new way for its functional tests. WDYT? I’m planning to continue my investigation/development of this. So please let me know if you have feedback. Thanks -Vincent

7 years, 2 months

3
10
0 0

[xwiki-devs] [ANN] XWiki 9.11.7 released

by Thomas Mortagne

The XWiki development team is proud to announce the availability of XWiki <version>. This is a bugfix release that covers important issues that we have discovered since 9.11.6 has been released. 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.11.7 Thanks for your support -The XWiki dev team

7 years, 2 months

1
0
0 0

[xwiki-devs] [UX][Idea] Left Panels

by Ecaterina Moraru (Valica)

Hi devs, Some ideas that could be applied to left panels area: * Mark "More applications" as expandable * Provide a "Customize" panel button on hover * Some styling changes * Demo: show sticky left panels would behave See the prototype in action: http://design.xwiki.org/xwiki/bin/download/Proposal/IdeaExpandableAppBar/Ap… The full proposal at: http://design.xwiki.org/xwiki/bin/view/Proposal/IdeaExpandableAppBar Let me know what you think. Thanks, Caty

7 years, 2 months

4
8
0 0

[xwiki-devs] [Proposal] Add a new method in the icon API

by Adel Atallah

Hi devs, I'm making a rest resource to get a list of pages and, for a query, I want to specify an icon (as a metadata) for each pages in the resulted json. The problem is that the icon APIs (and more specifically the IconManager class) only allow us to render the icon in HTML or velocity and this shouldn't be put inside a json response. Also we can't hardcode the icon class or image URL to be used as it depends on the iconset configured for the wiki. Another possibility would be to render the icon using javascript but it will not be very efficient. As discussed with Marius, our proposal would be to add a new method to the IconManager to get either the icon URL (e.g. http://xwiki.org/xwiki/resources/icons/silk/page.png) or the icon class (e.g. fa fa-page) depending of the specified iconset. We could then have this new property to the icon theme definition: ## Silk xwiki.iconset.render.json=$xwiki.getSkinFile("icons/silk/${icon}.png") ## FontAwesome xwiki.iconset.render.json=fa fa-$icon We could name the new method renderJSON or something more generic (if you have any idea). WDYT? Thanks, Adel

7 years, 2 months

3
4
0 0

[xwiki-devs] [XWiki Day] BFD#182

by Guillaume Delhumeau

Hello devs, This Thursday is BFD#182: http://dev.xwiki.org/xwiki/bin/view/Community/XWikiDays#HBugfixingday Our current status is: * -52 bugs over 120 days (4 months), i.e. we need to close 52 bugs to have created bugs # = closed bugs # * -96 bugs over 365 days (1 year) * -154 bugs over 500 days (between 1 and 2 years) * -326 bugs over 1600 days (4.3 years) See https://jira.xwiki.org/secure/Dashboard.jspa?selectPageId=10352 Here's the BFD#181 dashboard to follow the progress during the day: https://jira.xwiki.org/secure/Dashboard.jspa?selectPageId=14305 Happy Bug Fixing Day, Guillaume

7 years, 2 months

1
1
0 0

[xwiki-devs] [Contrib] New extension request

by Clément Aubin

Hi devs! I would like to propose a new extension called application-extramacrocontent. Currently, macros can only provide one content field, that generally contains the main body of the macro. Parameters are used to pass additional information to the macro but are not the best to put large text in them. With this application, it would be possible to add multiple content fields inside the macro, therefore adding new possibilities to macro creation and leveraging the problem of passing multiple big inputs to the wiki macros. I'm not really sure about the name of the extension itself, so if you have any better idea, please let me know :) Thanks, Clément

7 years, 2 months

2
4
0 0

[xwiki-devs] [Idea] Improving upgrade smoothness in case of error?

by Vincent Massol

Hi devs, One error we see during upgrades is https://www.xwiki.org/xwiki/bin/view/Documentation/UserGuide/Features/Distr… I was wondering if we couldn't fix it for example by storing the database version also in the status.xml file for example (and update it when there are migrations) and at startup if we see a mismatch between the version in the DB and the version in the status.xml file, then would start the DW, asking the user if they are performing an upgrade. I’m mentioning this in the context of trying to make the install/upgrade process as simple as possible for users, and even correcting their mistakes when we can. WDYT? good idea? bad idea? Any other idea? Thanks -Vincent

7 years, 2 months

1
0
0 0

[xwiki-devs] [ANN] XWiki 10.5 released

by Eduard Moraru

The XWiki development team is proud to announce the availability of XWiki 10.5. This release improves the visibility of the save button in edit mode and completes retro-compatibility of the new Notifications with the old Activity Stream by handling messages. Admins get more options on deciding how to protect extension pages from user modifications but also easy customization options for the Navigation panel. 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/10.5 Thanks for your support -The XWiki dev team

7 years, 2 months

1
0
0 0

[xwiki-devs] [ANN] XWiki 9.11.6 released

by Guillaume Delhumeau

The XWiki development team is proud to announce the availability of XWiki 9.11.6. This is a bugfix release that covers important issues that we have discovered since 9.11.5 has been released. 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.11.6 Thanks for your support -The XWiki dev team

7 years, 2 months

1
0
0 0

[xwiki-devs] [Brainstormoing] Removing old "since" from xwiki.org

by Vincent Massol

Hi, I think we need to start removing old mentions on xwiki.org. It makes it harder to read xwiki pages (as a user has just reported, see https://forum.xwiki.org/t/how-to-increase-active-installs-of-xwiki/3132/6?u…). Also we said we don't support documenting old stuff (we only support doc for LTS, stable and latest). For example I just did this: http://www.xwiki.org/xwiki/bin/view/Documentation/AdminGuide/Installation/I… Is that ok with everyone? Thanks -Vincent

7 years, 2 months

5
8
0 0

[xwiki-devs] Velocity 2.0 and DeprecatedCheckUberspector

by Claude Brisson

Hi. I'm currently working on Velocity 2.0 packaging. If that's OK with you, I would like to incorporate DeprecatedCheckUberspector.java into Velocity, but I need a statement from your part to be able to change its licence to Apache 2.0 (LGPL and Apache 2.0 licences aren't compatible). By the way, I take this opportunity to tell you that if there is another specific part of xwiki-commons-velocity that you think should be integrated on our side, or an important missing feature you'd like to insist on, don't hesitate. I already integrated VELOCITY-825, for instance, so String->Enum constant conversions are now handled by Velocity. There may be other important conversion cases you'd like to see handled. Regards, Claude

7 years, 2 months

4
8
0 0

[xwiki-devs] [XWiki Day] BFD#181

by Alex Cotiugă

Hello devs, This Thursday is BFD#181: http://dev.xwiki.org/xwiki/bin/view/Community/XWikiDays#HBugfixingday <http://dev.xwiki.org/xwiki/bin/view/Community/XWikiDays#HBugfixingdays> Our current status is: * -52 bugs over 120 days (4 months), i.e. we need to close 52 bugs to have created bugs # = closed bugs # * -92 bugs over 365 days (1 year) * -144 bugs over 500 days (between 1 and 2 years) * -319 bugs over 1600 days (4.3 years) See https://jira.xwiki.org/secure/Dashboard.jspa?selectPageId=10352 Here's the BFD#181 dashboard to follow the progress during the day: https://jira.xwiki.org/secure/Dashboard.jspa?selectPageId=14303 Happy Bug Fixing Day, Alex

7 years, 3 months

1
0
0 0

[xwiki-devs] [Contrib] New repo and JIRA for the sequence diagram macro

by Vincent Massol

Hi devs, I’d like to move the sequence diagram macro from being a XAR on e.x.o to a proper location in xwiki-contrib. The proposed repo name: macro-sequence-diagram I’ll take care of creating the repo + jira project. Thanks -Vincent

7 years, 3 months

1
1
0 0

[xwiki-devs] Xwiki-contrib/dokuwiki Release v1.1

by Neha Gupta

Greetings everyone, It’s been more than a month now, and it’s been an honour to work with XWiki community. I’ve worked under guidance of Thomas Mortagne and Shubham Jain on Dokuwiki-importer extension as a GSoC project and it’s been a pleasure. The new release supports dokuwiki folder as a source input directly. I’ve fixed some critical and blocker bugs. More testers and bug reports are welcomed. :) The new version of extension is installable with the Extension manager and the details and jar file can be found here (http://extensions.xwiki.org/xwiki/bin/view/Extension/DokuWiki/ <http://extensions.xwiki.org/xwiki/bin/view/Extension/DokuWiki/>). Thank you for your support. Best Regards, Neha Gupta.

7 years, 3 months

1
0
0 0

[xwiki-devs] [Brainstorming] Removing Watchlist & Activity Stream from XS?

by Vincent Massol

Hi devs, Now that Notifications is providing an equivalent feature (and supposedly much faster, we still need some measurements on that!), we need to think about decommissioning the AS and Watchlist features. Decommissioning means moving them to xwiki-attic IMO. So the questions: * Are there any features still missing to replace the AS? For example the AS had the ability to display a RSS feed and other parameters, see http://extensions.xwiki.org/xwiki/bin/view/Extension/Activity%20Macro#HPara…. Are all of these having equivalents or other ways of doing them? * Personal note and especially for Caty: I don’t like too much the big icons that we have ATM. For example http://extensions.xwiki.org/xwiki/bin/view/Extension/User%20Profile%20Appli…. I don’t think the replacement of the main AS with the notifications macro will look very nice with these icons. I already stated that I thought the user-focused view was much nicer visually but I was one of the few to think so from what I remember ;) Still even if we keep the icons, I think there’s some work to make the UI more appealling visually. WDYT? * When can we replace AS with notifications macro? I’d suggest to do that for 10.6-RC1. WDYT? AFAIK there are 2 places: user profiles + Dashboard home page. * Once the previous item is done, can we remove AS + watchlist from XS easily now? What does it entail, just moving xwiki-platform-watchlist and xwiki-platform-activitystream. Actually I think we need to first move the message stream sending UI to another place. I’d propose inside the alert menu as a UIX when message stream is enabled (that would be fast and simple to do and we could tune the location later, it doesn’t matter much since it’s off by default anyway). Could we do this in XWiki 10.6RC1? * Anything else I’ve forgotten? So the plan seems to be, in this order: 1) Replace AS with notifications macro. 2) Move Message Stream sending UI outside of AS 3) Move xwiki-platform-watchlist and xwiki-platform-activitystream to xwiki-attic and update their docs on e.x.o to explain how to put them back if needed Thanks -Vincent

7 years, 3 months

2
4
0 0

[xwiki-devs] [ANN] XWiki 10.5RC1 released

by Clément Aubin

The XWiki development team is proud to announce the availability of XWiki 10.5RC1. This release allows to make the action buttons on an edit page always visible, enable the possibility to send user messages in the notification center and provide improvements to the administration UI of the navigation panel. 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/10.5RC1 Thanks for your support -The XWiki dev team

7 years, 3 months

1
0
0 0

[xwiki-devs] Android Authenticator 0.4.2

by Алексей Овсянников

What’s new? - Fixed bug with private XWiki instances - Fixed bug with impossibility to edit contact (was error) All information about common 0.4 version you can read on previous release note: https://forum.xwiki.org/t/android-authenticator-0-4-release-here/3104 --------- Best regards, Ovsyannikov Aleksey, ovsyannikov.alexey95(a)gmail.com

7 years, 3 months

1
0
0 0

[xwiki-devs] GitLab Commit Application

by Ludovic Dubost

Hi, I've created a GitLab commit application in order to be able to commit XWiki pages to a GitLab instance using the gitlab v4 api. http://extensions.xwiki.org/xwiki/bin/view/Extension/gitlab%20Application/ I've commited it on the XWiki SAS GitLab instance as a way to test the tool https://git.xwikisas.com/ludovic/application-gitlab/ Ludovic -- *Ludovic Dubost* *Founder and CEO* ludovic(a)xwiki.com skype: ldubost Blog: http://blog.ludovic.orgTry XWiki on the cloud <http://www.xwiki.com/en/products/try-xwiki-cloud> - Try Cryptpad: Secure realtime Wysiwyg Editing <https://cryptpad.fr>

7 years, 3 months

1
0
0 0

[xwiki-devs] Android Authenticator 0.4 Release here!

by Алексей Овсянников

Whats news: 1. Fully rewritten network part 2. Rewritten graphical part 3. Fixed a bugs 4. Changed package id (incompatible with old version) More information you can find on XWiki forum page: https://forum.xwiki.org/t/android-authenticator-0-4-release-here/3104 --------- Best regards, Ovsyannikov Aleksey, ovsyannikov.alexey95(a)gmail.com

7 years, 3 months

1
0
0 0

[xwiki-devs] [VOTE] Change Android Authenticator package

by Алексей Овсянников

Hello everybody! We are stuck for the release of "Android Authenticator" application. You need 2 things to publish on play store: - A unique application ID (the current one is "org.xwiki.android.authenticator") - An associated publication key Problem is that we lost the key (we lost contact with Fitz during first GSOC before he get a change to give us the private key he used for the first release) and you can't change the key for an application on play store. We contacted the support to know if we could modify the key but we did not get any answer and since it' not too critical to ditch the old (beta released only) application and create a new one (new from play store point of view) we decided to change the id. Also note that the Java package we use in the module is "org.xwiki.android.authenticator" which is why we have the current application id. Here are a few proposals: 1) "org.xwiki.android.authenticator.v2" as in the second version of the key and if we loose the key again it can be v3 :) 2) "org.xwiki.android.authenticator.i2" to not look to much like a version of the application (id 2) 3) "org.xwiki.android.sync" since the application is about synchronization of xwiki data 4) "org.xwiki.android.sync.contacts" since the application is about synchronization of contacts too 5) "org.xwiki.android.authenticator.reborn" as in it's been a long time since we did a release of this application and half of it has been rewritten since that time WDYT ? I think that "*.(v2|reborn)" are not better ways to rename (but "reborn" better than "v2" becase "v2" mean version number 2, but what for do we have android app version?:) ) and in my humble opinion we must choose "org.xwiki.android.sync.contacts" or better to choose "org.xwiki.android.sync" because it will not prohibit us to add extension applications with packages as "org.xwiki.android.sync.contacts" and will show first value and purpose of application. Issue: https://jira.xwiki.org/browse/ANDAUTH-35 --------- Best regards, Ovsyannikov Aleksey, ovsyannikov.alexey95(a)gmail.com

7 years, 3 months

3
5
0 0

[xwiki-devs] GSoC Blockly Editor

by Vivek Iyer

Hello everyone! So Vincent asked me to send a mail to the dev list regarding the current status of the Blockly editor project, and what needs to be done in the coming few months, so we're all on the same page, so here goes. Firstly, regarding the current status of the project, here's what the user çan do: - Create and delete Blockly blocks - Generate code in Javascript (Show Javascript) - Execute it - Save the code to the page (without executing it) However after discussion with Vincent, he raised the following concerns: 1. Show Javascript just appends content to right and does not do anything to the existing content. Now I'm a bit confused as to what the problem is here, because the code just gets appended to the right of the cursor position, and that's how I wanted it to be, because that way the user can just navigate normally to the line where he/she wants code inserted, and click on "Show Javascript" to generate said code. So I believe this is fine. 2. Code does get saved but not interpreted and this is a problem. 3. There is no option to execute the code in view mode, this exists only in the editor 4. There is no option to convert the generated code back to Blockly blocks. Blockly actually does not provide this feature. In order for this to be implemented, the AST generated using Velocity needs to be converted to XML so it can be displayed using blocks, but I feel this would be outside the scope of this project. IMO what we can do is push this to the end and add this feature later if time permits. However if we provide this support for Velocity, we won't be able to provide it for other languages, since it would be much more complicated then and providing the back conversion feature for just one language (ie. Velocity) doesn't make sense to me. That's something else we need to consider. Maybe it can be implemented as part of a separate project. 5. There is a design flaw when the page gets redirected to Blockly/Editor for editing the content of the page. I had implemented it this way since Clement suggested me this editor (https://github.com/xwiki- contrib/application-xwebide) as reference, and so I used this. Nevertheless, it does cause some complications as the content of the page gets edited in case the $docRef is empty which can be handled but it doesn't make sense logically. The solution which we agreed upon is: For points 2 and 3, the generated code should be saved in an XObject that's retranslated back to code when the edit page is rendered. A sheet is attached to this XObject for view and edit modes, and the content gets rendered appropriately. A Javascript macro is used to render the code, and it gets executed when an execute button is pressed in the view mode. For point 5, we decided to drop Blockly as an editor and remove the edit menu entry and implement it as a template instead using a template page and a template provider page, similar to how its been done in https://github.com/xwiki-contrib/application-diagram/. That is all! This is what I've understood so far, and if any of you has feedback/suggestions, please get back to me ASAP! :) Regards, Vivek Iyer

7 years, 3 months

1
0
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