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

[xwiki-devs] [Proposal] Do not write pure-developer release notes

by Vincent Massol

Hi devs, Context ======= It’s been since we’ve deviated from the original purpose of the Release Notes by also adding developer-oriented release notes. The goal of the Release Notes was to **highlight** important novelties for our **users**, because looking at the JIRA list is too technical (otherwise we could simply use the Release feature of JIRA! :)). So you may ask why we do have a “Developer” Category in the RN app. These were not for pure developers but for XWiki users who are more advanced and can write scripts in wiki pages. And when it’s the case we **must** add examples, otherwise, it’s completely useless. For example this morning I saw this RN added: https://www.xwiki.org/xwiki/bin/view/ReleaseNotes/Data/XWiki/11.0/Change004/ This is typically something that has very little value to me: * It’s for pure developers (java devs) * It’s not understandable by anyone except the person who coded it or participated to the dev mailing list discussion about it * It doesn’t say more than what’s in the JIRA issue so what’s the point? * There are no examples at all in it! * Real developers can simply look at the reference documentation or can read the JIRAs. We always link the JIRA issues in the RN anyway (it was for this reason that we’re listing them). * It takes time to write RN items and thus it needs to have high value Proposal ======== * Go back to the original idea and only list developer RN items when they are for scripting users and not APIs. For example, document some new script service or some additions to existing script services. Of course Groovy would allow you to call any API so being able to use it from Groovy is not a good criteria. I’d say that the criteria should be whether the Release Note Change is useful for Velocity users. * Rename “Developers” into “Scripters” or or “Advanced Users” (any better name?) * Always put an example when writing a “developer” change and take the time to explain properly what it’s about. WDYT? Thanks -Vincent

6 years, 3 months

6
14
0 0

[xwiki-devs] [Proposal] Merge on save

by Simon Urli

Hi everyone, I'm working on the merge on save for the roadmap of 11.5 and I need some decision to be taken. The main idea of the merge on save, is to try to merge users work in case of save conflict. Knowing that the merge might led to merge conflict in case of edits on the same places. Those merge conflict can be tackled automatically, but a priority will be then given to one version over another. I first propose to add an option in user profile, so users would have the possibility to choose between: 1. Always merge automatically the work, even in case of merge conflict 2. Always merge automatically, but ask what to do in case of merge conflict 3. Always ask what to do in case of save conflict Now the question is: what should be the default option? Option 1 looks like a good fit for decreasing the number of clicks to do, but I'm a bit afraid that in case of conflict they would have the same feeling as before the warning conflict window: i.e. to loose some part of their work. WDYT? Simon -- Simon Urli Software Engineer at XWiki SAS simon.urli(a)xwiki.com More about us at http://www.xwiki.com

6 years, 3 months

6
30
0 0

[xwiki-devs] [Brainstorming] Controlling transformations

by Vincent Massol

Hi devs, I’d like to discuss about how to control transformations and when they are executed. Right now we have an all-or-nothing strategy (either the transformation is defined in the config property or it’s not). We have some needs to be able to turn on/turn off some transformations on a page level basis. Here’s the idea that I put on https://jira.xwiki.org/browse/XWIKI-15100: * Add a new xproperty to Rendering.RenderingConfigClass * Modify java code: XWikiRenderingConfiguration, ExtendedRenderingConfiguration, DefaultExtendedRenderingConfiguration, RenderingConfigClassDocumentConfigurationSource * For the wiki level, get the config in Rendering.RenderingConfig * For the page level, get the config from an xobject of type Rendering.RenderingConfigClass * Make RenderingConfiguration.getTransformationNames() search in the current page, parent pages (spaces), current wiki, and fallback to xwiki.properties Note that, as Thomas pointed out in comment of https://jira.xwiki.org/browse/XWIKI-15100 the last point is the hard one. We could imagine having a transformation cache that would be loaded at startup and updated whenever a XWiki.RenderingConfigClass xobject is modified in the wiki. Very similar to wiki components. Note: We could also implement https://jira.xwiki.org/browse/XWIKI-13167 at the same time, with the query string in the URL overriding the transformations. WDYT? Any idea of the cost of adding such a feature in term of days? Does 7 days sounds good to you? (inluding testing and doc). Thanks -Vincent

6 years, 3 months

2
3
0 0

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

by Oana-Lavinia Florean

Hello devs, This Thursday is BFD#211: http://dev.xwiki.org/xwiki/bin/view/Community/XWikiDays#HBugfixingday Our current status is: * -18 bugs over 120 days (4 months), i.e. we need to close 18 bugs to have created bugs == closed bugs * -97 bugs over 365 days (1 year) * -156 bugs over 500 days (between 1 and 2 years) * -357 bugs over 1600 days (4.3 years) See https://jira.xwiki.org/secure/Dashboard.jspa?selectPageId=10352 Here's the BFD#211 dashboard to follow the progress during the day: https://jira.xwiki.org/secure/Dashboard.jspa?selectPageId=14418 Good luck at fixing bugs, Lavinia

6 years, 3 months

1
0
0 0

[xwiki-devs] [Contrib] New Repository creation request

by Shubham Jain

Hello Devs, This is a request to create a repo for the XWiki Helm chart project. Something like `xwiki-helm-chart` or `helm-chart` (maybe because it’s implicit that it’s going to be XWiki’s Helm chart?) sounds good to start with. This repo will also be used by Ashish Sharma for his GSOC project. The helm chart should help deploy XWiki in minutes in both local or production level setting, on a Kubernetes setup. My Github handle - slayerjain, Ashish’s - ASHISH932 Thanks, Shubham.

6 years, 3 months

4
6
0 0

[xwiki-devs] [ANN] XWiki 11.4 released

by Ecaterina Moraru (Valica)

The XWiki development team is proud to announce the availability of XWiki 11.4. This release brings improvements to the management of the conflicts encountered when editing a page. We've also provided better explained error messages for several cases, in order for the users to understand more easily the occurring issues. For developers we've added the ability to write a wiki macro in velocity and make its content inline-editable. You can download it here: https://www.xwiki.org/xwiki/bin/view/Main/Download Make sure to review the release notes: https://www.xwiki.org/xwiki/bin/view/ReleaseNotes/Data/XWiki/11.4/ Thanks for your support -The XWiki dev team

6 years, 3 months

1
0
0 0

[xwiki-devs] Improve Android XWiki authenticator GSOC-19

by Divyansh Jain

Hello, devs My name is Divyansh Jain. I’m pursuing me under graduation in BCA. Bachelor of Computer Application in Mahatma Jyoti Rao Phoole University Campus. Currently, I’m in my sixth semester. I’m an avid and enthusiastic programmer with strong experience in Java and Android. I'll be working on the XWiki Android Authenticator App in this GSOC19. I've already submitted my proposal on http://design.xwiki.org/xwiki/bin/view/Main/ Here's the link to my proposal: - https://design.xwiki.org/xwiki/bin/view/Proposal/Codemigrationandfixexistin… - https://design.xwiki.org/xwiki/bin/view/Proposal/ImproveXWikiAndroidApplica… Though there are still some areas where I still need to study/practice*:* - Kotlin (working on sample projects of my own) - OCID (Need to watch some more google developer videos like https://www.youtube.com/watch?v=DdQTXrk6YTk&feature=youtu.be )e - Unit Test (Practicing on sample projects.) - AccountManager for adding several accounts in the XWiki Authenticator page. I'm very excited to work with all of you devs. I've already started working on migrating code in MVVM architecture and fixing existing bugs some of which are merged: - https://jira.xwiki.org/projects/ANDAUTH/issues/ANDAUTH-48?filter=doneissues - https://jira.xwiki.org/projects/ANDAUTH/issues/ANDAUTH-49?filter=doneissues - https://jira.xwiki.org/projects/ANDAUTH/issues/ANDAUTH-47?filter=doneissues - https://jira.xwiki.org/projects/ANDAUTH/issues/ANDAUTH-27?filter=doneissues Regards, Divyansh Jain

6 years, 3 months

2
1
0 0

[xwiki-devs] OpenCollective for XWiki Community

by Ecaterina Moraru (Valica)

Hi devs, This is a proposal for the content we would have if we were to create an OpenCollective account for XWiki. Take a look at https://design.xwiki.org/xwiki/bin/view/Proposal/XWikiOpenCollective The issues we need to solve / validate are: A. Decide on the URL name (xwiki is already taken by XWiki SAS) B. See if XWiki SAS can act like our Fiscal host C. Validate the tiers and content https://design.xwiki.org/xwiki/bin/view/Proposal/XWikiOpenCollective#HTiers (we might need more details on how the "Bug Fixer" works in case we agree to it) Let me know what you think, Caty

6 years, 3 months

2
14
0 0

[xwiki-devs] Location for extensions ideas

by Thomas Mortagne

Hi xwikiers, I'm never sure where to put ideas of extensions I have so I often forget them or details I had tough about or gathered back then. I don't think http://design.xwiki.org is the right place until you really start designing the extension. Also it's too generic for this need and not a very good entry point for searching something IMO, more something to link to from somewhere else. I would prefer something really dedicated to this "that would be a nice thingy but not sure about the details yet" state. Would be a good source for hackathons and GSOC or for contributors who are searching for something interesting to work on. I was thinking about the following alternatives: * a new dedicated project on https://jira.xwiki.org * reuse https://jira.xwiki.org/projects/XCONTRIB after some cleanup (close everything left in it basically) but not super clean (it's just that it's a good name) * some new application on http://www.xwiki.org WDYT ? Right now my preference goes to a clean new jira project (just need to think about a good project id) where you put description and close it when the extension work really start on a dedicated location. Less work and should do the job well. -- Thomas Mortagne

6 years, 3 months

4
7
0 0

[xwiki-devs] Fwd: [Proposal] WikiMacro inline editing: 2 new dedicated macros

by Marius Dumitru Florea

---------- Forwarded message --------- From: Marius Dumitru Florea <mariusdumitru.florea(a)xwiki.com> Date: Tue, May 21, 2019 at 1:06 PM Subject: Re: [xwiki-devs] [Proposal] WikiMacro inline editing: 2 new dedicated macros To: Simon Urli <simon.urli(a)xwiki.com> On Mon, May 20, 2019 at 11:57 AM Simon Urli <simon.urli(a)xwiki.com> wrote: > Hello Marius, > > On 14/05/2019 13:12, Simon Urli wrote: > > > > > > On 14/05/2019 13:07, Marius Dumitru Florea wrote: > >> On Tue, May 14, 2019 at 2:04 PM Simon Urli <simon.urli(a)xwiki.com > >> <mailto:simon.urli@xwiki.com>> wrote: > >> > >> > >> > >> On 14/05/2019 13:02, Marius Dumitru Florea wrote: > >> > On Tue, May 14, 2019 at 1:55 PM Simon Urli <simon.urli(a)xwiki.com > >> <mailto:simon.urli@xwiki.com> > >> > <mailto:simon.urli@xwiki.com <mailto:simon.urli@xwiki.com>>> > >> wrote: > >> > > >> > > >> > > >> > On 14/05/2019 12:43, Marius Dumitru Florea wrote: > >> > > On Fri, May 10, 2019 at 11:21 AM Simon Urli > >> <simon.urli(a)xwiki.com <mailto:simon.urli@xwiki.com> > >> > <mailto:simon.urli@xwiki.com <mailto:simon.urli@xwiki.com>> > >> > > <mailto:simon.urli@xwiki.com <mailto:simon.urli@xwiki.com > > > >> <mailto:simon.urli@xwiki.com <mailto:simon.urli@xwiki.com>>>> > wrote: > >> > > > >> > > Hi Marius, all, > >> > > > >> > > On 09/05/2019 09:29, Simon Urli wrote: > >> > > > Hi Marius, all, > >> > > > > >> > > > On 08/05/2019 14:09, Marius Dumitru Florea wrote: > >> > > >> Hi Simon, > >> > > >> > >> > > >> As I commented on > >> > > https://github.com/xwiki/xwiki-platform/pull/1109 I > >> > > >> think > >> > > >> that most of the time you will want to use a > >> scripting > >> > macro + > >> > > HTML macro > >> > > >> like this: > >> > > >> > >> > > >> {{velocity}} > >> > > >> {{html clean="false"}} > >> > > >> <div ...> > >> > > >> ... > >> > > >>  > >> > > >> ... > >> > > >> </div> > >> > > >> {{/html}} > >> > > >> {{/velocity}} > >> > > >> > >> > > >> An example of such a macro could be: > >> > > >> > >> > > >> {{figure src="someImage.png"}}some > >> description{{/figure}} > >> > > >> > >> > > >> The macro code would look like this: > >> > > >> > >> > > >> {{velocity}} > >> > > >> {{html clean="false"}} > >> > > >> <div class="figure"> > >> > > >> <div class="figure-image-wrapper"> > >> > > >> <img src="..." class="figure-image" /> > >> > > >> </div> > >> > > >> <div class="figure-caption"> > >> > > >>  > >> > > >> </div> > >> > > >> </div> > >> > > >> {{/html}} > >> > > >> {{/velocity}} > >> > > >> > >> > > >> I know you can output DIVs with wiki syntax but > >> that's > >> > not the > >> > > point. The > >> > > >> point is that we want to use HTML for the UI and > >> leave > >> > the wiki > >> > > syntax > >> > > >> for > >> > > >> the user content. So I don't think > >> ``wikimacrocontent`` > >> > is that > >> > > useful > >> > > >> (if > >> > > >> it's only purpose is to help you output the > >> > > ``non-generated-content`` > >> > > >> DIV). > >> > > > > >> > > > so as Thomas mentioned in order to allow inline > >> editing I also > >> > > perform > >> > > > transformation on the generated list of blocks in > >> > > > DefaultWikiMacroRenderer to remove the macro marker > >> that > >> > can cause > >> > > > troubles for inline editing. So the > >> wikimacrocontent is > >> > used both to > >> > > > insert content, and to detect where to remove the > >> macro > >> > markers > >> > > during > >> > > > the transformation. > >> > > > > >> > > > Now right now even with this solution it's not > >> possible to > >> > inline > >> > > edit > >> > > > html macro because of the way it's designed: the > >> HTML > >> > macro only > >> > > create > >> > > > a raw blocks that contains all the html, so I > >> cannot easily > >> > > transform it > >> > > > for inline editing. IMO it requires a change in the > >> HTML > >> > macro. > >> > > > >> > > so, re the subject of HTML macro and the handle of > >> inline > >> > editing I was > >> > > actually wrong to assume that it was linked to the raw > >> block. > >> > It's > >> > > actually linked to the metadata that are currently not > >> > handled in the > >> > > custom HTML renderer of HTML macro. I created a > >> dedicated > >> > issue for it > >> > > (https://jira.xwiki.org/browse/XRENDERING-563), it's > >> actually > >> > easy to > >> > > fix since the mechanism already exist in > >> AnnotatedHTMLRenderer. > >> > > So I've been able to successfully create a very simple > >> inline > >> > editing > >> > > wiki macro like this: > >> > > > >> > > {{html wiki="true"}} > >> > > <div style="border: 1px solid red"> > >> > > ((({{wikimacrocontent/}}))) > >> > > </div> > >> > > {{/html}} > >> > > > >> > > I had to put the ((( ))) to avoid having the > >> wikimacrocontent > >> > rendered > >> > > inline, maybe there's a way to do it cleaner, but I > >> just > >> > wanted to > >> > > check > >> > > that it's working there. > >> > > IMO it should really be the next priority in terms of > >> > usability of > >> > > inline editing, to find a way to allow inline > >> editing of > >> > inline macro. > >> > > > >> > > > >> > > Would it be hard to have a scripting API equivalent for > the > >> > > wikimacrocontent macro? I don't like mixing HTML with wiki > >> syntax > >> > (you > >> > > can get into trouble easily). As a wiki macro developer I > >> would > >> > prefer > >> > > to be able to write something like this: > >> > > > >> > > {{velocity}} > >> > > {{html clean="false"}} > >> > > <div class="my-macro"> > >> > > $xcontext.macro.renderNonGeneratedContent() > >> > > </div> > >> > > {{/html}} > >> > > {{/velocity}} > >> > > Thanks, > >> > > Marius > >> > > >> > Basically this API would need to: > >> > 1. Create the div around the macro content > >> > 2. Add a marker around that div to specify that > >> everything's inside > >> > should be kept (since we need to remove the other macro > >> markers in the > >> > WikiMacroRenderer) > >> > 3. Render the div + the content in the right target > syntax > >> > > >> > What bothers me here is that I don't think we would have > >> access to the > >> > rendering context, to know the syntax that should be used to > >> render the > >> > metadata. > >> > > >> > > >> > The alternative is: > >> > > >> > {{velocity}} > >> > {{html clean="false"}} > >> > <div class="my-macro"> > >> > ... > >> > {{html}} > >> > > >> > {{wikimacrocontent/}} > >> > > >> > {{html clean="false"}} > >> > ... > >> > </div> > >> > {{/html}} > >> > {{/velocity}} > >> > It feels like a hack, but I can leave with it. > >> > >> Actually you could do: > >> > >> {{html wiki="true"}} > >> <div class="my-macro"> > >> {{wikimacrocontent/}} > >> </div> > >> {{/html}} > >> > >> but yeah it's mixing both syntax. > >> > >> I want to avoid this if possible. > > > > Now I have to check but with > > https://jira.xwiki.org/browse/XRENDERING-563 you might be able to > > directly do: > > > > {{velocity}} > > {{html}} > > <div class="mymacro"> > > <div > > data-xwiki-non-generated-content="java.util.List<org.xwiki.Block>"> > > $xcontext.macro.content > > </div> > > </div> > > {{/html}} > > {{/velocity}} > > > > However I don't know how it would handle content containing other macros. > > So I just tested how we would do that, and I managed to do it using the > following code: > {{velocity}} > {{html}} > <div style="border: 1px solid red"> > <div class="xwiki-metadata-container" > data-xwiki-non-generated-content="java.util.List<org.xwiki.Block>" > data-xwiki-wikimacrocontent="true" data-xwiki-syntax="xhtml/1.0"> > $xcontext.macro.content > </div> > </div> > {{/html}} > {{/velocity}} > > Note that the syntax metadata is mandatory here since the HTML Macro > will consider that it's content is HTML. > > Now there is one remaining issue: we cannot apparently insert macro in > it. Here's the parameter request which is sent: > > <!DOCTYPE+html+PUBLIC+"-//W3C//DTD+XHTML+1.0+Strict//EN"+" > http://www.w3.org/TR/xhtml1/DTD/xhtml1-strict.dtd"><html+xmlns=" > http://www.w3.org/1999/xhtml > "+xml:lang="en"+lang="en"><body><div+data-xwiki-non-generated-content="java.util.List<org.xwiki.Block>"+data-xwiki-syntax="xhtml/1.0"+data-xwiki-wikimacrocontent="true"+class="xwiki-metadata-container"><p>Some+content+inside+the+macro+encore+un+test?</p><div+class="wikimodel-emptyline"></div><p></p><p>un+autre+<strong>test</strong></p></div><div+class="wikimodel-emptyline"></div></body></html> > > you can see the markers for the box macro, with a new paragraph around > it and an empty line before it. > Here's the body answer of the request: > > <body id="body" class="skin-flamingo viewbody main wiki-xwiki > space-TotoMacro"><div > style="border: 1px solid red"> > <div class="xwiki-metadata-container" > data-xwiki-non-generated-content="java.util.List<org.xwiki.Block>" > data-xwiki-syntax="xhtml/1.0" data-xwiki-wikimacrocontent="true"> > <p>Some content inside the macro encore un test?</p><p>un autre > <strong>test</strong></p> > </div> > </div><div class="wikimodel-emptyline"></div></body> > > The fact that the macro marker is missing is expected since I removed it > after transformation in WikiMacroRenderer. However, it should have been > transformed: we should get the HTML for the box. I still need to > investigate to understand why it disappeared. > > > I'm not sure if I need to document this way to allow inline editing of > macro content, or maybe just in HTML macro page? WDYT? > I think it's worth documenting it on the wiki macro documentation page or on the tutorial about writing a wiki macro, as an advanced feature. I don't think the HTML macro page is the right place. Thanks for working on this, Marius > > Simon > > >> > >> Still it's working. > >> > > >> > Thanks, > >> > Marius > >> > > >> > > > >> > > > >> > > Simon > >> > > > > >> > > > Simon > >> > > >> > >> > > >> Thanks, > >> > > >> Marius > >> > > >> > >> > > >> > >> > > >> On Tue, May 7, 2019 at 9:21 AM Simon Urli > >> > <simon.urli(a)xwiki.com <mailto:simon.urli@xwiki.com> > >> <mailto:simon.urli@xwiki.com <mailto:simon.urli@xwiki.com>> > >> > > <mailto:simon.urli@xwiki.com > >> <mailto:simon.urli@xwiki.com> <mailto:simon.urli@xwiki.com > >> <mailto:simon.urli@xwiki.com>>>> > >> > wrote: > >> > > >> > >> > > >>> Hi everyone, > >> > > >>> > >> > > >>> I'm currently working on allowing inline editing > >> on new > >> > wikimacros. > >> > > >>> My first challenge right now is to cope with the > >> problem of > >> > > inserting > >> > > >>> the macro content and allowing to inline edit it. > >> > > >>> > >> > > >>> In order to do so, I propose to create two new > >> dedicated > >> > macro: > >> > > >>> - wikimacrocontent: would allow to insert and > >> inline > >> > edit a > >> > > wiki > >> > > >>> macro content > >> > > >>> - wikimacroparameter: the same for a > >> parameter. > >> > > >>> > >> > > >>> The idea would be to be able to write something > >> such as: > >> > > >>> > >> > > >>> {{velocity}} > >> > > >>> {{wikimacrocontent/}} > >> > > >>> This is a content of > >> $xcontext.macro.content.length() > >> > characters. > >> > > >>> {{/velocity}} > >> > > >>> > >> > > >>> So the purpose of those macros would be twofold: > >> > > >>> 1. to ease the insertion of macro > >> content/parameters (no > >> > > need to > >> > > >>> always use > >> {{velocity}}$xcontext.macro.content{{/velocity}} > >> > > >>> 2. to create the dedicated metadata around > the > >> > content and > >> > > to be > >> > > >>> processed during wikimacro rendering to allow > >> inline editing > >> > > >>> > >> > > >>> Of course those macro would be only to be used > >> inside a > >> > wikimacro. > >> > > >>> I started to develop the wikimacroccontent, so I > >> have a > >> > first > >> > > working > >> > > >>> POC, but I'd like to know WDYT about this. > >> > > >>> > >> > > >>> I would also be really happy if you could give me > >> some > >> > wikimacro > >> > > >>> examples where the inline editing would make > >> sense, so I > >> > could > >> > > use it in > >> > > >>> my tests. > >> > > >>> > >> > > >>> Thanks, > >> > > >>> Simon > >> > > >>> -- > >> > > >>> Simon Urli > >> > > >>> Software Engineer at XWiki SAS > >> > > >>> simon.urli(a)xwiki.com > >> <mailto:simon.urli@xwiki.com> <mailto:simon.urli@xwiki.com > >> <mailto:simon.urli@xwiki.com>> > >> > <mailto:simon.urli@xwiki.com <mailto:simon.urli@xwiki.com> > >> <mailto:simon.urli@xwiki.com <mailto:simon.urli@xwiki.com>>> > >> > > >>> More about us at http://www.xwiki.com > >> > > >>> > >> > > > > >> > > > >> > > -- > >> > > Simon Urli > >> > > Software Engineer at XWiki SAS > >> > > simon.urli(a)xwiki.com <mailto:simon.urli@xwiki.com> > >> <mailto:simon.urli@xwiki.com <mailto:simon.urli@xwiki.com>> > >> > <mailto:simon.urli@xwiki.com <mailto:simon.urli@xwiki.com> > >> <mailto:simon.urli@xwiki.com <mailto:simon.urli@xwiki.com>>> > >> > > More about us at http://www.xwiki.com > >> > > > >> > > >> > -- > >> > Simon Urli > >> > Software Engineer at XWiki SAS > >> > simon.urli(a)xwiki.com <mailto:simon.urli@xwiki.com> > >> <mailto:simon.urli@xwiki.com <mailto:simon.urli@xwiki.com>> > >> > More about us at http://www.xwiki.com > >> > > >> > >> -- Simon Urli > >> Software Engineer at XWiki SAS > >> simon.urli(a)xwiki.com <mailto:simon.urli@xwiki.com> > >> More about us at http://www.xwiki.com > >> > > > > -- > Simon Urli > Software Engineer at XWiki SAS > simon.urli(a)xwiki.com > More about us at http://www.xwiki.com >

6 years, 3 months

1
0
0 0

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

by Alex Cotiugă

The XWiki development team is proud to announce the availability of XWiki 11.4RC1. This release brings important improvements on the management of the conflicts encountered when editing a page as well as better explained messages, displayed to users, to easily understand the occurring issues. Also, a dedicated macro for inserting WikiMacro Content was introduced. You can download it here: https://www.xwiki.org/xwiki/bin/view/Main/Download Make sure to review the release notes: https://www.xwiki.org/xwiki/bin/view/ReleaseNotes/Data/XWiki/11.4RC1 Thanks for your support -The XWiki dev team

6 years, 3 months

1
0
0 0

[xwiki-devs] [Proposal] Roadmaps for 11.5 and 11.6

by Vincent Massol

Hi devs, Here’s a proposal for 11.5 + 11.6, discussed with Thomas, Marius and Simon already. XWiki 11.5 ========== * BFD: All * Hibernate upgrade to finish - Assignee: Thomas * "Finish the autocomplete of references which has been dropped since Adel left and we still don't have it in the WYSIWYG + implement autocomplete on attachments.”. - Assignee: Marius * Merge on Save: https://jira.xwiki.org/browse/XWIKI-175 - Assignee: Simon Dates: * 11.5RC1: 17 June 2019 * 11.5: 24 June 2019 XWiki 11.6 ========= * BFD: All * Velocity upgrade (too dangerous for 11.2/11.3) - Assignee: Thomas * Security: Add permissions for xobjects to prevent giving all permissions to users with edit rights on a page. - Assignee: Marius (+ Thomas)? * Limit number of login attempts until user gets blocked - http://jira.xwiki.org/browse/XWIKI-15488 - Assignee: Simon ? Dates: * 11.6RC1: 22 July 2019 (added one more week due to the XWiki SAS seminar) * 11.6: 29 July 2019 Others ====== The following item couldn’t be planned for 11.5 or 11.6 due to lack of time/manpower but we should consider it for 11.7+: * Better handling of user removal and transfer of rights ( http://jira.xwiki.org/browse/XWIKI-12142 ) WDYT? @devs: please confirm that you’re ok. @Simon, please let me know if it’s ok for the item where there’s a question mark. @Marius: same for you. @evalica: I didn’t put any investigations/designs but we should IMO. Any proposals? Thanks -Vincent

6 years, 3 months

4
5
0 0

[xwiki-devs] Building/Installing XWiki Platform

by Mua Rachmann

Hi there everyone, I am trying to begin my adventure with xwiki and begin contributions. I wish to build the xwiki platform but i ran into some errors. - I have downloaded and installed maven 3.6.1 - I have java v8 and on Mac OS Following the link Vincent provided here See https://dev.xwiki.org/xwiki/bin/view/Community/Building/ When i run **mvn clean install** i get the following error MBP-de-MACBOOK:xwiki-platform rachmann$ mvn clean install [INFO] Scanning for projects... [ERROR] [ERROR] Some problems were encountered while processing the POMs: [FATAL] Non-resolvable parent POM for org.xwiki.platform:xwiki-platform:11.2-SNAPSHOT: Could not find artifact org.xwiki.commons:xwiki-commons-pom:pom:11.2-SNAPSHOT and 'parent.relativePath' points at no local POM @ line 23, column 11 @ [ERROR] The build could not read 1 project -> [Help 1] [ERROR] [ERROR] The project org.xwiki.platform:xwiki-platform:11.2-SNAPSHOT (/Users/rachmann/Documents/open_source/xwiki-platform/pom.xml) has 1 error [ERROR] Non-resolvable parent POM for org.xwiki.platform:xwiki-platform:11.2-SNAPSHOT: Could not find artifact org.xwiki.commons:xwiki-commons-pom:pom:11.2-SNAPSHOT and 'parent.relativePath' points at no local POM @ line 23, column 11 -> [Help 2] [ERROR] [ERROR] To see the full stack trace of the errors, re-run Maven with the -e switch. [ERROR] Re-run Maven using the -X switch to enable full debug logging. [ERROR] [ERROR] For more information about the errors and possible solutions, please read the following articles: [ERROR] [Help 1] http://cwiki.apache.org/confluence/display/MAVEN/ProjectBuildingException [ERROR] [Help 2] http://cwiki.apache.org/confluence/display/MAVEN/UnresolvableModelException Any help would be appreciated thanks Regards, Mua

6 years, 3 months

3
14
0 0

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

by Oana-Lavinia Florean

Hello devs, This Thursday is BFD#210: http://dev.xwiki.org/xwiki/bin/view/Community/XWikiDays#HBugfixingday Our current status is: * -15 bugs over 120 days (4 months), i.e. we need to close 15 bugs to have created bugs == closed bugs * -97 bugs over 365 days (1 year) * -150 bugs over 500 days (between 1 and 2 years) * -349 bugs over 1600 days (4.3 years) See https://jira.xwiki.org/secure/Dashboard.jspa?selectPageId=10352 Here's the BFD#210 dashboard to follow the progress during the day: https://jira.xwiki.org/secure/Dashboard.jspa?selectPageId=14414 Good luck at fixing bugs, Lavinia

6 years, 3 months

1
0
0 0

[xwiki-devs] [Proposal] WikiMacro inline editing: 2 new dedicated macros

by Simon Urli

Hi everyone, I'm currently working on allowing inline editing on new wikimacros. My first challenge right now is to cope with the problem of inserting the macro content and allowing to inline edit it. In order to do so, I propose to create two new dedicated macro: - wikimacrocontent: would allow to insert and inline edit a wiki macro content - wikimacroparameter: the same for a parameter. The idea would be to be able to write something such as: {{velocity}} {{wikimacrocontent/}} This is a content of $xcontext.macro.content.length() characters. {{/velocity}} So the purpose of those macros would be twofold: 1. to ease the insertion of macro content/parameters (no need to always use {{velocity}}$xcontext.macro.content{{/velocity}} 2. to create the dedicated metadata around the content and to be processed during wikimacro rendering to allow inline editing Of course those macro would be only to be used inside a wikimacro. I started to develop the wikimacroccontent, so I have a first working POC, but I'd like to know WDYT about this. I would also be really happy if you could give me some wikimacro examples where the inline editing would make sense, so I could use it in my tests. Thanks, Simon -- Simon Urli Software Engineer at XWiki SAS simon.urli(a)xwiki.com More about us at http://www.xwiki.com

6 years, 4 months

4
9
0 0

[xwiki-devs] [proposal] Process to handle Pull Requests

by Ludovic Dubost

Hi devs, I don't think there is currently a process that is in place to handle pull requests and I have the feeling that the way there are handled today is a bit random. There are usually comments sent out on each pull request but sometimes it seems that some pull requests are going in sleep mode and it's not clear who is in charge. I would like to suggest that a process is put in place where it's clear who is responsible for a pull request and a status is given to the contributors that propose that pull request. Something like: Assigned developer: XXXX Status: New -> new pull request, not yet assigned Assigned -> assigned to a developer, he is in charge of reviewing the pull request and ask for modifications or accept it. The developer can auto assign it to himself. If nobody does, we need to decide how they will be taken into account. ModificationsRequired -> for now rejected with comments. Contributor needs to apply comments and then change back to Assigned for further evaluation VoteRequired -> there are no more comments, but a vote is required as the changes to XWiki core are important WaitingFinalAuthorization -> optional step for complex patches where a additional authorization would be required (need to define who would be the persons that give the authorization) WaitingApplication -> there are no more comments and no changes or vote required. The pull request can be applied and is waiting for a developer to apply it Abandoned -> contributors is abandoning the pull request (cannot do the changes, no more time, etc..) Rejected -> pull request is rejected (quality not enough, etc..) Applied -> pull request is applied What do you think ? Ludovic -- Ludovic Dubost Founder and CEO Blog: http://blog.ludovic.org/ XWiki: http://www.xwiki.com Skype: ldubost GTalk: ldubost

6 years, 4 months

7
12
0 0

[xwiki-devs] [Proposal] Roadmap for XS 11.4

by Vincent Massol

Hi devs, We’re already 10 days into the release so this is coming very late and I apologize. So here’s a proposal for 11.4: * BFD: All * Finish the autocomplete of references which has been dropped since Adel left and we still don't have it in the WYSIWYG + implement autocomplete on attachments. - Assignee: Marius ** Note: this will carry over in 11.5 since Marius won’t have many days available during the 11.4 timeframe * Inline editing of wiki macros - Assiggne: Simon * Hibernate upgrade - Assignee: Thomas * Fix the notifications endless loop: https://jira.xwiki.org/browse/XWIKI-16363 - Assignee: Thomas (note: already done!) Dates: * 11.4RC1: 20 May 2019 * 11.4: 27 May 2019 @committers: if you’re ok please create the relevant jira issues if they don’t exist and assign yourself to them + set the fix version value, and update the roadmap page with the jiras: https://www.xwiki.org/xwiki/bin/view/Roadmaps/ Thanks -Vincent PS: I’ll send proposals for 11.5 and 11.6 real soon.

6 years, 4 months

1
0
0 0

[xwiki-devs] Analysis of BFD releases 11.2 and 11.3

by Vincent Massol

I did a quick analysis of 11.2 & 11.3 to see how many bugs we fixed since they were supposed to be BFD releases. The results are not that impressive: * XWiki 11.0 (non BFD): 32 bugs closed * XWiki 11.1 (non BFD) 44 bugs closed * XWiki 11.2 (BFD): 37 bugs closed * XWiki 11.3 (BFD): 54 bugs closed Here’s the graph: https://www.evernote.com/l/AHcQ57uKyNRK-YmB09gvM70OXXVTIhFWcs0 The graph shows that during the period (March and April) we had: * Created issues (128) * Resolved issues (123) So we were not even able to catch up with created bugs during the period. So the question is: why are we not able to catch up? Let’s look at who closed bugs during the period: https://www.evernote.com/l/AHfj3Z0DW8RAuZ0AHw9BX6cnoDZc89KPvog Top resolvers: * Simon Urli - 32 * Thomas Mortagne - 30 * Vincent Massol - 15 * Guillaume Delhumeau - 5 * Marius Dumitru Florea - 2 So one reason is that we roughly have only 2 main issue resolvers (Simon and Thomas) and the other committers are not closing enough. So not enough manpower. Would be interesting to see if we have more bugs being created every month these days when compared to, say, 2 years ago. For ex: * category = 10000 AND type = Bug and created >= 2019-03-01 and created <= 2019-03-31 ** 70 bugs created * category = 10000 AND type = Bug and created >= 2018-03-01 and created <= 2018-03-31 ** 41 bugs created * category = 10000 AND type = Bug and created >= 2017-03-01 and created <= 2017-03-31 ** 46 bugs created * category = 10000 AND type = Bug and created >= 2016-03-01 and created <= 2016-03-31 ** 81 bugs created More generally: * category = 10000 AND type = Bug and created >= 2015-01-01 and created <= 2015-12-31 ** 780 bugs created * category = 10000 AND type = Bug and created >= 2016-01-01 and created <= 2016-12-31 ** 732 bugs created * category = 10000 AND type = Bug and created >= 2017-01-01 and created <= 2017-12-31 ** 609 bugs created * category = 10000 AND type = Bug and created >= 2019-01-01 and created <= 2019-12-31 * 257 bugs created so far. Extrapolates to 257*3 = 771 So it seems we don’t have specifically more bugs being reported in general. So it seems it’s mostly a manpower/focus issue. WDYT? Thanks -Vincent

6 years, 4 months

4
12
0 0

[xwiki-devs] [ANN] XWiki 10.11.8 released

by Guillaume Delhumeau

The XWiki development team is proud to announce the availability of XWiki 10.11.8. This is a bugfix release that covers important issues that we have discovered since 10.11.7 has been released. You can download it here: https://www.xwiki.org/xwiki/bin/view/Main/Download Make sure to review the release notes: https://www.xwiki.org/xwiki/bin/view/ReleaseNotes/Data/XWiki/10.11.8 Thanks for your support -The XWiki dev team

6 years, 4 months

1
0
0 0

[xwiki-devs] [GSOC] Welcoming our GSoC students

by Eduard Moraru

Hello community, Hello Google Summer of Code students, First of all, congratulations on your applications and your activity during the selection period, and welcome in the XWiki development team. Before guiding the accepted students to their next steps, we'd like to thank again all those who showed interest in XWiki for this Summer of Code. We had a lot of good applications this year, with professional approaches and interesting ideas, and it was very difficult to choose. Unfortunately, some very good students, with great potential, were not accepted. So, to those interested in getting involved anyway, without Google's implication, I renew the invitation to put your ideas in practice under the guidance of the community. Even though the money will be missing, you can still take advantage of the other GSoC benefits: learning new things, gaining experience, earning recognition, etc [1]. If you would like to do that, please let us know by replying to this mail. For the accepted students, here are some getting started hints: = Community bonding period = According to the program timeline [2], the next month (until - May 27th) is to be used for community bonding. The first thing to do, sometime this week, is to present yourself and your project on the dev list, so that everyone knows who you are and what to expect from you. A precondition to being able to send mails to the devs list is to first be subscribed [2.1] to it, which you __need to do ASAP__ if you haven't already. Also, you should continue getting acquainted with the code, the practices and the developers. Please make sure you all read and understand the following - very useful - documents: - [3] http://dev.xwiki.org/xwiki/bin/view/Community/ - [4] http://platform.xwiki.org/xwiki/bin/view/DevGuide/ - [5] http://platform.xwiki.org/xwiki/bin/view/Features/ = Mentorship = We prefer open mentorship. While your assigned mentor is the one officially in charge with your guidance, almost all interaction should be done 'in the open' as much as possible, on the IRC channel or on the mailing list. You should choose the communication medium according to the importance of the matters to be discussed: naturally, the less important issues are to be discussed on IRC/Matrix, while the design decisions, important progress announcements and testing/feedback requests go on the devs list. This way, the community is informed on the evolution of your project, and other developers can come up any time with useful ideas and suggestions. Moreover, if your mentor is "hit by a bus" (the bus factor [6]), another developer can take his place with little effort. = Communication = Sitting alone in your room, working secretly on your project is definitely a __bad__ approach. However, please keep in mind that too much communication can also be harmful, as it distracts the others from their own work. You need to be able to communicate just right: - provide meaningful information about your progress, - ask the community's opinion on non-trivial design or implementation decisions - avoid wasting a lot of time on a problem, when a more experienced developer (or a student that fought the same problem) could quickly provide you an answer; however, do try to find the answer yourself at first. Wrong: "Where do I start? What do I do now? And how do I do that? Is this good? It doesn't work, help me!" Right: "Since a couple of hours ago I get a strange exception when building my project, and googling for a solution doesn't seem to help. Looking at the error, I think that there's a wrong setting for the assembly plugin, but nothing I tried works. Can someone please take a look?" Subscribe to the devs list (if you didn't do this already), and start monitoring the discussions. It is also recommended to register on the users forum, but not mandatory. The notifications list is a little too high volume and technical for the moment, but it is a great knowledge source. Also, try to make sure that you're generally available on chat (IRC/Matrix) in order to have a better view on the daily discussions, get involved and generally be easily reachable, should your mentors or any of the students want to easily get a hold of you. Generally speaking, if you are online (working on your project), you should also be available on the chat, just in case. = Development process = The project's lifecycle is NOT design -> implementation -> testing -> documentation. [7] We invite you to adopt a test driven development [8][9][10] approach and to experience agile development [11]. After the first coding week, you must have some code that works. It won't do much, of course, but it will be the seed of your project. Every functionality will be validated by tests. The code must be properly tested and commented at the time of the writing (don't think you'll do that afterwards, because in most cases you won't). Since our code is hosted on GitHub [12], you should register an account there and fork some xwiki repositories, so that you can try to build XWiki from sources, and be able to contribute bugfixes. We'll add you to the xwiki-contrib organization [13], and we'll create dedicated repositories for each project. We encourage you to do __at least__ weekly commits (ideally, if you are well organized, you should be able to commit code that works daily, so try to aim at daily commits). This way, the code can be properly reviewed, and any problems can be detected before they grow into something too difficult to fix. One big code blob committed at the end, no matter how good it may seem, is a failure at several levels. A simple way of having something functional in the first week is to prepare the maven build for your modules, which will give you the first unit test for the first class. = Next steps, in a nutshell = - Get more familiar with the code and development process and try to master Maven, JUnit, Selenium, component driven development, ... - Continue fixing a few small issues, chosen so that they are __related to your project__. You can ask on IRC for help selecting good issues, or you can pick from the (non-comprehensive) list of easy issues [14] -- This will help you get more familiar with the code your project needs to interact with. - Refine and organize the ideas concerning your project (you can use the Drafts space [15]), and write several use case scenarios. - Start writing the first piece of code for your project. At the end of the community bonding period, you should have a clear vision of the project, well documented on the xwiki.org wiki, you should have the build infrastructure ready, and you should be pretty familiar with the existing code you will need to interact with. And, of course, you should be familiar with the community and the way we communicate. Good luck, and may we all have a great Summer of Code! -The XWiki Development Team ---------- [1] http://www.catb.org/~esr/writings/cathedral-bazaar/homesteading/ [2] https://developers.google.com/open-source/gsoc/timeline [2.1] https://dev.xwiki.org/xwiki/bin/view/Community/Discuss#HMailingLists [3] http://dev.xwiki.org/xwiki/bin/view/Community/ [4] http://platform.xwiki.org/xwiki/bin/view/DevGuide/ [5] http://platform.xwiki.org/xwiki/bin/view/Features/ [6] http://en.wikipedia.org/wiki/Bus_factor [7] http://www.catb.org/~esr/writings/cathedral-bazaar/cathedral-bazaar/ [8] http://en.wikipedia.org/wiki/Test-driven_development [9] http://www.amazon.com/dp/0321146530/ [10] http://www.amazon.com/dp/0201485672/ [11] http://www.amazon.com/dp/0596527675/ [12] https://github.com/xwiki/ [13] https://github.com/xwiki-contrib/ [14] https://jira.xwiki.org/secure/IssueNavigator.jspa?mode=hide&requestId=10510 [15] http://dev.xwiki.org/xwiki/bin/view/Drafts/

6 years, 4 months

1
0
0 0

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

by Oana-Lavinia Florean

Hello devs, This Thursday we are back at having BFD after 2 bug fix releases: http://dev.xwiki.org/xwiki/bin/view/Community/XWikiDays#HBugfixingday Our current status is: * -24 bugs over 120 days (4 months), i.e. we need to close 24 bugs to have created bugs == closed bugs * -108 bugs over 365 days (1 year) * -159 bugs over 500 days (between 1 and 2 years) * -364 bugs over 1600 days (4.3 years) See https://jira.xwiki.org/secure/Dashboard.jspa?selectPageId=10352 Here's the BFD#209 dashboard to follow the progress during the day: https://jira.xwiki.org/secure/Dashboard.jspa?selectPageId=14412 Good luck at fixing bugs, Lavinia

6 years, 4 months

1
1
0 0

Re: [xwiki-devs] XAR source projects should allow source files

by paul＠hoplahup.net

>> On 26 Aug 2016, at 13:50, Vincent Massol wrote: [...] >> * What I understand is that you’re not proposing to change the XAR >> format but to introduce some tooling to generate a XAR from a set of >> source files, at build time. Correct? [...] I am rewaking this rather older subject (see http://xwiki.475771.n2.nabble.com/XAR-source-projects-should-allow-source-f… and older things mentioned there) with yet another attempt which might satisfy everyone: an attempt to use XAR-Transformations to include files into XARs. It defines two extra transformations: - INSERT_TEXT (using an XPath expression): inserts the content of the text file - INSERT_ATTACHMENT_CONTENT (using a file name): inserts the content of a file in base64 The attempt is detailed in https://jira.xwiki.org/browse/XCOMMONS-1614 and has a pull-request and an example realisation. I claim that this attempt allows project developers to nicely edit files and let them be combined into a xar when it is the time. See the issue for an example realisation. I would love your comments. Paul

6 years, 4 months

3
2
0 0

[xwiki-devs] Introduction & Newbie

by Mua Rachmann

Hi there xwiki devs, I am Mua from Cameroon. I study computer engineering where i offer as major software engineering. I am a lover of open source and would love to contribute to xwiki. Here is my github link https://github.com/muarachmann I have been around open source for a year now and familiar to the way it works. I am kind of lost with xwiki to my suprise (lol). I would really love to contribute to this organization and help increase my skills. My skill set is python, C, html, css , php, javascript and a little of java. I have a few questions with regards to xwiki. 1. Does it works like wiki. 2. How can i setup a dev environment for xwiki. I am on MacOS 3. I forked this repo https://github.com/muarachmann/xwiki-platform to begin contributions but i am lost Regards, Mua

6 years, 4 months

2
2
0 0

[xwiki-devs] [Proposal] Define Xmx value in jvm.config for xwiki-* repositories

by Vincent Massol

Hi, Since Maven 3.3.1 it’s possible to declare default command line options and JVM options, see https://maven.apache.org/docs/3.3.1/release-notes.html It could be interesting to do so in our repos so that all users run with the right values. Or we could decide that the values depend too much on the profiles being executed and it’s not worht it. WDYT? Thanks -Vincent

6 years, 4 months

2
1
0 0

[xwiki-devs] [ANN] XWiki 11.3 released

by Simon Urli

The XWiki development team is proud to announce the availability of XWiki 11.3. This release was focused on bug fixes and also comes with a couple of small improvements for things like the live table date filter, the Database List field from AppWithinMinutes or the Delete User modal. There's also a new Tomcat 9 based Debian package that you might want to try. You can download it here: https://www.xwiki.org/xwiki/bin/view/Main/Download Make sure to review the release notes: https://www.xwiki.org/xwiki/bin/view/ReleaseNotes/Data/XWiki/11.3 Thanks for your support -The XWiki dev team

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