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

[xwiki-devs] Programmed Macro with Velocity Inside

by Matthias Wegner

Hello All, i use a XWiki.WikiMacroClass with a big Velocity-Script in the "Macro Code"-Section. Now i want to transfer it to a Java-Macro as described in http://rendering.xwiki.org/xwiki/bin/view/Main/ExtendingMacro. I am not sure where i have to place the code inside the Java-Macro. I tried @Inject private MacroContentParser contentParser; and in the method public List<Block> execute(...) { Strong code = "{{velocity}}\n" + "$doc\n"+"{{/velocity}}"; List<Block> result = this.contentParser.parse(code, context, true, context.isInline()).getChildren(); return result; } But this give no code-result back in The Page when i use the macro. Is that the right way? Regards, Matthias -- View this message in context: http://xwiki.475771.n2.nabble.com/Programmed-Macro-with-Velocity-Inside-tp7… Sent from the XWiki- Dev mailing list archive at Nabble.com.

11 years, 10 months

2
2
0 0

[xwiki-devs] [Proposal] Stop tracking sessions in URL (when cookies are off)

by Vincent Massol

Hi devs, Right now we're trying to support clients (browsers namely) that have cookies turned off. I've recently updated code to try to support that but I've found that: 1) It's very hard and we still have lot of places in our code that doesn't work without cookies 2) It adds ;jsessionid in the URL and this is causing havoc in tons of unsuspecting place such as RSS feed generation (RSS readers get different URLs every time thus thinking it's a different article, exports, watchlist, tests, etc). 3) It's a security risk to expse the sessionid in the URL 4) It's bad for SEO since search bots may index several times the same resource with different sessionid (it's a new one every time) 5) There are lots of cases where we don't need to track sessions (like for RSS feed generation or HTML exports) I started fixing all failing places because of the ;jsessionid in the URL but more keep coming and it feels strange to have to remove it a bit everywhere when we're adding it in our URL factory. Thus I'd like to propose that we officially don't support tracking sessions in URLs (i.e. when browsers have cookies turned off). The idea is that I'd still call encodeURL in our XWikiURLFactory implementations (we need this if we want to support URL rewriting for short URLs for example) but XWikiURLFactory would strip any jsessionid from the URL. WDYT? Here's my +1 Thanks -Vincent

11 years, 10 months

7
8
0 0

[xwiki-devs] [Reminder] BFD#44

by Vincent Massol

Hi devs, Today is Bug Fixing Day 44. We're currently at -112 bugs (vs -121 last week) for the 1600 days period: http://jira.xwiki.org/secure/Dashboard.jspa?selectPageId=10352 Let's reduce this gap... Here's the BFD#44 dashboard to follow the progress during the day: *http://jira.xwiki.org/secure/Dashboard.jspa?selectPageId=11795 <http://jira.xwiki.org/secure/Dashboard.jspa?selectPageId=11795>* Thanks -Vincent

11 years, 10 months

1
1
0 0

[xwiki-devs] Links to/from page

by Matthias Wegner

Hello, is there a easy way to get all links which are in a page (Forewardlinks, external and internal) and links which linking to page (Backlinks, internal)? I found nothing usefull in the api and the forum. Need i to parse the page my own to get them? Is there a Parser i could use which do the half way? Regards, Matthias -- View this message in context: http://xwiki.475771.n2.nabble.com/Links-to-from-page-tp7587920.html Sent from the XWiki- Dev mailing list archive at Nabble.com.

11 years, 10 months

2
7
0 0

[xwiki-devs] NPE in $escapetool.url()

by Marius Dumitru Florea

Hi devs, I just reported http://jira.xwiki.org/browse/XCOMMONS-494 . It seems the following generates a NPE: $escapetool.url({ 'foo': $null, 'bar': ['one', $null, 'three'], $null: 'value' }) I see 3 possible results: (1) Skip null parameter key and value bar=one&bar=three (2) Use 'null' for both the key and the value foo=null&bar=one&bar=null&bar=three&null=value (3) Use empty string for null value foo=&bar=one&bar=&bar=three&null=value I'm going to implement (1) if no one is against it. Thanks, Marius

11 years, 10 months

2
2
0 0

[xwiki-devs] rel attribute instead of target??

by Paul Libbrecht

Hello XWiki community, The current syntax 2.1 allows me to use [[ link-label >> http://example.com || target="targ"]] so as to write a link that goes to a named target targ (which could also be "_blank"). However, both XWiki Syntax 2.1 documentation for links: http://platform.xwiki.org/xwiki/bin/view/Main/XWikiSyntax#HXWikiSyntax2.1Li… and the WYSIWYG editor employ the rel attribute instead to denote that a link should be opened in a new window. I am surprised such a choice is made since: - the rel attribute is deemed to be only useful for robots (see, e.g. http://www.w3.org/TR/html401/struct/links.html#adef-rel, http://dev.w3.org/html5/markup/a.html#a.attrs.rel,http://reference.sitepoin… or http://www.htmlhelp.com/reference/html40/values.html#linktypes) - the target attribute which was deprecated in html4 has been resurrected by hmtl5 and is indeed output by: [[ link-label >> http://example.com || rel="__blank"]] I would suggest: - to modify the syntax documentation to speak about the target attribute as well as the rel attribute (e.g. with the nofollow attribute) - to let the wysiwyg editor output target="_blank" instead of including the rel nae Do you agree? It appears that I need particular rights to edit the XWikiSyntax page. How do I get them? thanks in advance. Paul

11 years, 10 months

2
1
0 0

[xwiki-devs] Upload Attachments

by Matthias Wegner

Hello, I have an old self-made wiki with nearly thousand pages which i want to import. At the moment i don't know which attachments makes the problem. On Images and Content everything works fine for all pages. I want to import the content to new xwiki-documents and upload into them my attachments and images with doc.addAttachment(attachmentName, new FileInputStream(data), xcontext) in a groovy-script. In some i get the following exception: java.lang.OutOfMemoryError: Java heap space at java.util.Arrays.copyOf(Unknown Source) at java.lang.AbstractStringBuilder.expandCapacity(Unknown Source) at java.lang.AbstractStringBuilder.ensureCapacityInternal(Unknown Source) at java.lang.AbstractStringBuilder.append(Unknown Source) at java.lang.StringBuffer.append(Unknown Source) at org.suigeneris.jrcs.util.ToString.arrayToString(ToString.java:110) at org.suigeneris.jrcs.rcs.impl.Node.setText(Node.java:349) at org.suigeneris.jrcs.rcs.Archive.<init>(Archive.java:243) at org.suigeneris.jrcs.rcs.Archive.<init>(Archive.java:214) at com.xpn.xwiki.doc.XWikiAttachmentArchive.updateArchive(XWikiAttachmentArchive.java:186) at com.xpn.xwiki.doc.XWikiAttachment.updateContentArchive(XWikiAttachment.java:739) at com.xpn.xwiki.store.XWikiHibernateStore.saveAttachment(XWikiHibernateStore.java:1568) at com.xpn.xwiki.store.XWikiHibernateStore.saveAttachmentList(XWikiHibernateStore.java:1536) at com.xpn.xwiki.store.XWikiHibernateStore.saveXWikiDoc(XWikiHibernateStore.java:524) at com.xpn.xwiki.store.XWikiCacheStore.saveXWikiDoc(XWikiCacheStore.java:177) at com.xpn.xwiki.store.XWikiCacheStore.saveXWikiDoc(XWikiCacheStore.java:170) at com.xpn.xwiki.XWiki.saveDocument(XWiki.java:1448) at com.xpn.xwiki.XWiki.saveDocument(XWiki.java:1404) at com.xpn.xwiki.XWiki.saveDocument(XWiki.java:1399) at com.xpn.xwiki.XWiki$saveDocument.call(Unknown Source) at Script2.upload(Script2.groovy:56) at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) at sun.reflect.NativeMethodAccessorImpl.invoke(Unknown Source) at sun.reflect.DelegatingMethodAccessorImpl.invoke(Unknown Source) at java.lang.reflect.Method.invoke(Unknown Source) at org.codehaus.groovy.reflection.CachedMethod.invoke(CachedMethod.java:90) at groovy.lang.MetaMethod.doMethodInvoke(MetaMethod.java:233) at groovy.lang.MetaClassImpl.invokeMethod(MetaClassImpl.java:1085) at groovy.lang.MetaClassImpl.invokeMethod(MetaClassImpl.java:909) at groovy.lang.DelegatingMetaClass.invokeMethod(DelegatingMetaClass.java:149) at org.codehaus.groovy.jsr223.GroovyScriptEngineImpl$2.invokeMethod(GroovyScriptEngineImpl.java:330) at org.codehaus.groovy.runtime.callsite.PogoMetaClassSite.callCurrent(PogoMetaClassSite.java:66) I didn't get it to catch that exception in groovy. Is that possible? The groovy-script is skipped by the exception, so nothing is done. I really like to catch that, so all possible is done and i get an information what is not working. I tried to surround the try-catch-block to thedocument-save method, but it not helps. Is that a problem of the size of the attachments? Some are bigger than 100MB. I didn't change the attachment storage to file-system yet. What is your experience? Is that a problem of the attachment size or something else? To test this i use the Portable XWiki 5.1 with the Hsqldb. Regards, Matthias -- View this message in context: http://xwiki.475771.n2.nabble.com/Upload-Attachments-tp7587887.html Sent from the XWiki- Dev mailing list archive at Nabble.com.

11 years, 10 months

2
1
0 0

[xwiki-devs] [Proposal] Adding a Contrib top level project in commons

by Vincent Massol

Hi devs, We need to provide a contrib top level POM for extension contributors. ATM we recommend to extend the commons top level pom on http://contrib.xwiki.orgbut it's a bad idea because contributors forget to override some pom.xml elements (such as the <developers> section) and thus the published extensions end up with wrong information (such as wrong author: "XWiki Development Team"). The reason to put it in commons: * We will have dependencyManagement in it and thus it needs to be in sync with the commons version. It'll have the same version as commons top level pom version. * Easy for us since it'll be released at the same time as commons * Easy for extension authors to choose the top level contrib version they need: they'll pick the one corresponding to the xwiki version they want to depend on Note that since some extensions may want to depend on versions of XWiki older than 5.3 we can deploy this contrib pom also for older versions using mvn deploy:deploy-file WDYT? Thanks -Vincent

11 years, 10 months

4
10
0 0

[xwiki-devs] [ANN] XWiki 5.2.1 released

by Vincent Massol

The XWiki development team is proud to announce the availability of XWiki 5.2.1. This is a important bugfix release which fixes several regressions introduced in 5.2 (RSS, Watchlist, PDF export, etc). You can download it here: http://www.xwiki.org/xwiki/bin/view/Main/Download(please allow a few hours for the binaries to propagate to the download servers if the download doesn't work yet) Make sure to review the release notes: http://www.xwiki.org/xwiki/bin/view/ReleaseNotes/ReleaseNotesXWiki521 Thanks -The XWiki dev team

11 years, 10 months

1
0
0 0

[xwiki-devs] Postpone 5.3M2 by 3 days

by Guillaume "Louis-Marie" Delhumeau

Hi. Vincent and Thomas has started reviewing my work for the new Wiki API. Some changes: - do not store the membershipType in the descriptor, but as a configuration object in the subwiki. - having the option Local Users, Global users, Local + Global users instead of enableLocalUsers(), because we need the 3 uses cases: - global users only: the workspaces use-case - local users only: a farm like xwiki cloud, where each wiki should not know anything about the main wiki - global + local users: myxwiki.org use case. + some changes to do in the UI. Because of that, I won't be able to reach the M2 deadline. Moreover, I can't work until the 12th. So I propose to postpone it. 5.3M2: 14th november (was 11) 5.3RC1: 21th november (was 18) 5.3 final: 2st decembre (was 25th november). WDYT? Thanks, Louis-Marie

11 years, 10 months

5
5
0 0

Re: [xwiki-devs] [Reminder] BFD#43 (RESULT)

by Vincent Massol

This was a disappointing BFD: http://www.xwiki.org/xwiki/bin/view/Blog/Bug+Fixing+Day+43 Let's make sure the next one is better! Thanks -Vincent On Thu, Nov 7, 2013 at 8:51 AM, Vincent Massol <vincent(a)massol.net> wrote: > Hi devs, > > Today is Bug Fixing Day 43. > > We're currently at -121 bugs for the 1600 days period: > http://jira.xwiki.org/secure/Dashboard.jspa?selectPageId=10352 > > Let's reduce this gap... > > Here's the BFD#43 dashboard to follow the progress during the day: > *http://jira.xwiki.org/secure/Dashboard.jspa?selectPageId=11793 > <http://jira.xwiki.org/secure/Dashboard.jspa?selectPageId=11793>* > > Thanks > -Vincent >

11 years, 10 months

1
0
0 0

[xwiki-devs] [Proposal] Release XWiki 5.2.1 tomorrow

by Vincent Massol

Hi devs, I'd like to release XWiki 5.2.1 tomorrow since it contains lots of important regressions... Thanks -Vincent

11 years, 10 months

4
3
0 0

[xwiki-devs] Regarding editing the breadcrumb in Xwiki

by Prachi Maheshwari

Hey everyone, I want to edit the default breadcrumb for Xwiki. Can anyone please help me with it? I have created apps using app within minutes, but I don't want the breadcrumb showing it. It should directly go from Xwiki to my created app instead. Is there any way of doing it?? Thanks in advance. Prachi -----Original Message----- From: devs-bounces(a)xwiki.org [mailto:devs-bounces@xwiki.org] On Behalf Of devs-request(a)xwiki.org Sent: Thursday, November 07, 2013 11:16 AM To: devs(a)xwiki.org Subject: devs Digest, Vol 77, Issue 12 Send devs mailing list submissions to devs(a)xwiki.org To subscribe or unsubscribe via the World Wide Web, visit http://lists.xwiki.org/mailman/listinfo/devs or, via email, send a message with subject or body 'help' to devs-request(a)xwiki.org You can reach the person managing the list at devs-owner(a)xwiki.org When replying, please edit your Subject line so it is more specific than "Re: Contents of devs digest..." Today's Topics: 1. Re: Postpone 5.3M2 by 3 days (Marius Dumitru Florea) 2. Re: Postpone 5.3M2 by 3 days (Vincent Massol) 3. [Proposal] Adding a Contrib top level project in commons (Vincent Massol) 4. Re: [Proposal] Adding a Contrib top level project in commons (Thomas Mortagne) 5. Re: [Proposal] Adding a Contrib top level project in commons (Sergiu Dumitriu) 6. Re: [Proposal] Adding a Contrib top level project in commons (Vincent Massol) 7. Re: [Proposal] Adding a Contrib top level project in commons (Sergiu Dumitriu) ---------------------------------------------------------------------- Message: 1 Date: Thu, 7 Nov 2013 16:40:44 +0200 From: Marius Dumitru Florea <mariusdumitru.florea(a)xwiki.com> To: XWiki Developers <devs(a)xwiki.org> Subject: Re: [xwiki-devs] Postpone 5.3M2 by 3 days Message-ID: <CALZcbBbSN0h_YzB2Wm4kb3ruvoQzUivxJN8bpzVdH0Sp9FNcCg(a)mail.gmail.com> Content-Type: text/plain; charset=ISO-8859-1 On Wed, Nov 6, 2013 at 6:53 PM, Guillaume "Louis-Marie" Delhumeau <gdelhumeau(a)xwiki.com> wrote: > Hi. > > Vincent and Thomas has started reviewing my work for the new Wiki API. > > Some changes: > - do not store the membershipType in the descriptor, but as a > configuration object in the subwiki. > - having the option Local Users, Global users, Local + Global users > instead of enableLocalUsers(), because we need the 3 uses cases: > - global users only: the workspaces use-case > - local users only: a farm like xwiki cloud, where each wiki should > not know anything about the main wiki > - global + local users: myxwiki.org use case. > > + some changes to do in the UI. > > Because of that, I won't be able to reach the M2 deadline. Moreover, I > can't work until the 12th. So I propose to postpone it. > > 5.3M2: 14th november (was 11) > 5.3RC1: 21th november (was 18) > 5.3 final: 2st decembre (was 25th november). > > WDYT? Both 14th and 21th are Thursday so BFDs. Also, I think there is too much time between RC1 and final. 5.3 M2: 14th November (was 11th) 5.3 RC1: 20th November (was 18th) 5.3 final: 27th November (was 25th). Thanks, Marius > > Thanks, > Louis-Marie > _______________________________________________ > devs mailing list > devs(a)xwiki.org > http://lists.xwiki.org/mailman/listinfo/devs ------------------------------ Message: 2 Date: Thu, 7 Nov 2013 15:49:28 +0100 From: Vincent Massol <vincent(a)massol.net> To: XWiki Developers <devs(a)xwiki.org> Subject: Re: [xwiki-devs] Postpone 5.3M2 by 3 days Message-ID: <CAK2AU7tt-gi8-WjqHON+ibUtfvS+AerGEdWkX1pUMxXic1=0qg(a)mail.gmail.com> Content-Type: text/plain; charset=ISO-8859-1 Hi Guillaume, On Wed, Nov 6, 2013 at 5:53 PM, Guillaume "Louis-Marie" Delhumeau < gdelhumeau(a)xwiki.com> wrote: > Hi. > > Vincent and Thomas has started reviewing my work for the new Wiki API. > > Some changes: > - do not store the membershipType in the descriptor, but as a > configuration object in the subwiki. > - having the option Local Users, Global users, Local + Global users > instead of enableLocalUsers(), because we need the 3 uses cases: > - global users only: the workspaces use-case > - local users only: a farm like xwiki cloud, where each wiki should > not know anything about the main wiki > - global + local users: myxwiki.org use case. > > + some changes to do in the UI. > > Because of that, I won't be able to reach the M2 deadline. Moreover, I > can't work until the 12th. So I propose to postpone it. > > 5.3M2: 14th november (was 11) > 5.3RC1: 21th november (was 18) > 5.3 final: 2st decembre (was 25th november). > > WDYT? > This proposal is not complete since you're proposing to change the final release date (which is always an important change) and thus you're possibly proposing to impact the end of the 5.x cycle (and hence the beginning of the 6.x one). However I still believe that we need to keep an end date of end of December for 5.4 and end of January for 5.5 so that we begin 6.0 at beginning of February 2014 and release it around end of April 2014. Our goal is still to try to catch up so that at the end of 2014 we'll release the last version of 6.x (i.e. 6.5). And thus start the new year one a new cycle. Another possibility is to skip 5.5 for the 5.x cycle and release 5.4 as the last one (barring bug fix releases such as 5.4.1, 5.4.2, etc). I think it's ok to keep 5.4 and 5.5 and to make them short stabilization releases (ie similar to bug fix releases). WDYT? I agree with the dates proposed by Marius which are better IMO. Thanks -Vincent > Thanks, > Louis-Marie > _______________________________________________ > devs mailing list > devs(a)xwiki.org > http://lists.xwiki.org/mailman/listinfo/devs > ------------------------------ Message: 3 Date: Thu, 7 Nov 2013 16:29:21 +0100 From: Vincent Massol <vincent(a)massol.net> To: XWiki Developers <devs(a)xwiki.org> Subject: [xwiki-devs] [Proposal] Adding a Contrib top level project in commons Message-ID: <CAK2AU7sBdmc67BreJj5UBMVpU4zGWa7SEtdx02Y0FHM2c926rw(a)mail.gmail.com> Content-Type: text/plain; charset=ISO-8859-1 Hi devs, We need to provide a contrib top level POM for extension contributors. ATM we recommend to extend the commons top level pom on http://contrib.xwiki.orgbut it's a bad idea because contributors forget to override some pom.xml elements (such as the <developers> section) and thus the published extensions end up with wrong information (such as wrong author: "XWiki Development Team"). The reason to put it in commons: * We will have dependencyManagement in it and thus it needs to be in sync with the commons version. It'll have the same version as commons top level pom version. * Easy for us since it'll be released at the same time as commons * Easy for extension authors to choose the top level contrib version they need: they'll pick the one corresponding to the xwiki version they want to depend on Note that since some extensions may want to depend on versions of XWiki older than 5.3 we can deploy this contrib pom also for older versions using mvn deploy:deploy-file WDYT? Thanks -Vincent ------------------------------ Message: 4 Date: Thu, 7 Nov 2013 16:39:14 +0100 From: Thomas Mortagne <thomas.mortagne(a)xwiki.com> To: XWiki Developers <devs(a)xwiki.org> Subject: Re: [xwiki-devs] [Proposal] Adding a Contrib top level project in commons Message-ID: <CAPnKnLERptDa_r2fW90PmY0giYZCTzKjQnjA+SnBmZdZOQoGCQ(a)mail.gmail.com> Content-Type: text/plain; charset=ISO-8859-1 +1 On Thu, Nov 7, 2013 at 4:29 PM, Vincent Massol <vincent(a)massol.net> wrote: > Hi devs, > > We need to provide a contrib top level POM for extension contributors. > ATM we recommend to extend the commons top level pom on > http://contrib.xwiki.orgbut it's a bad idea because contributors > forget to override some pom.xml elements (such as the <developers> > section) and thus the published extensions end up with wrong > information (such as wrong author: "XWiki Development Team"). > > The reason to put it in commons: > * We will have dependencyManagement in it and thus it needs to be in > sync with the commons version. It'll have the same version as commons > top level pom version. > * Easy for us since it'll be released at the same time as commons > * Easy for extension authors to choose the top level contrib version > they > need: they'll pick the one corresponding to the xwiki version they > want to depend on > > Note that since some extensions may want to depend on versions of > XWiki older than 5.3 we can deploy this contrib pom also for older > versions using mvn deploy:deploy-file > > WDYT? > > Thanks > -Vincent > _______________________________________________ > devs mailing list > devs(a)xwiki.org > http://lists.xwiki.org/mailman/listinfo/devs -- Thomas Mortagne ------------------------------ Message: 5 Date: Thu, 07 Nov 2013 10:58:05 -0500 From: Sergiu Dumitriu <sergiu(a)xwiki.com> To: XWiki Developers <devs(a)xwiki.org> Subject: Re: [xwiki-devs] [Proposal] Adding a Contrib top level project in commons Message-ID: <527BB88D.6020303(a)xwiki.com> Content-Type: text/plain; charset=UTF-8 On 11/07/2013 10:29 AM, Vincent Massol wrote: > Hi devs, > > We need to provide a contrib top level POM for extension contributors. ATM > we recommend to extend the commons top level pom on > http://contrib.xwiki.orgbut it's a bad idea because contributors > forget to override some pom.xml > elements (such as the <developers> section) and thus the published > extensions end up with wrong information (such as wrong author: "XWiki > Development Team"). > > The reason to put it in commons: > * We will have dependencyManagement in it and thus it needs to be in sync > with the commons version. It'll have the same version as commons top level > pom version. > * Easy for us since it'll be released at the same time as commons > * Easy for extension authors to choose the top level contrib version they > need: they'll pick the one corresponding to the xwiki version they want to > depend on > > Note that since some extensions may want to depend on versions of XWiki > older than 5.3 we can deploy this contrib pom also for older versions using > mvn deploy:deploy-file > > WDYT? +1. Will this be a copy of xwiki-commons-pom, or an extension that overrides a few sections? Should it include the license check plugin, which currently enforces LGPL2.1? Should we make it easier to change the license being enforced? What do we put instead of the <developers>? Do we make it a generic "XWiki community", or leave it empty so that others can fill it in? We can use the enforcer's requireProperty rule to check that mandatory sections have been filled in. I'd like to have a single xwiki.version property instead of the current commons, rendering, platform.version, so that people don't have to think which one should they use for each module. Instead of deploy-file, why not actually release older versions? Since it's a separate repository, we can do that, we don't have to sync releases with the official XWiki releases. -- Sergiu Dumitriu http://purl.org/net/sergiu ------------------------------ Message: 6 Date: Thu, 7 Nov 2013 17:10:39 +0100 From: Vincent Massol <vincent(a)massol.net> To: XWiki Developers <devs(a)xwiki.org> Subject: Re: [xwiki-devs] [Proposal] Adding a Contrib top level project in commons Message-ID: <CAK2AU7uWBL9UQRhQbqqPS7dDpxkasQAx1vHrPgLm0fuOA+ZQ+A(a)mail.gmail.com> Content-Type: text/plain; charset=ISO-8859-1 On Thu, Nov 7, 2013 at 4:58 PM, Sergiu Dumitriu <sergiu(a)xwiki.com> wrote: > On 11/07/2013 10:29 AM, Vincent Massol wrote: > > Hi devs, > > > > We need to provide a contrib top level POM for extension contributors. > ATM > > we recommend to extend the commons top level pom on > > http://contrib.xwiki.orgbut it's a bad idea because contributors > > forget to override some pom.xml > > elements (such as the <developers> section) and thus the published > > extensions end up with wrong information (such as wrong author: "XWiki > > Development Team"). > > > > The reason to put it in commons: > > * We will have dependencyManagement in it and thus it needs to be in sync > > with the commons version. It'll have the same version as commons top > level > > pom version. > > * Easy for us since it'll be released at the same time as commons > > * Easy for extension authors to choose the top level contrib version they > > need: they'll pick the one corresponding to the xwiki version they want > to > > depend on > > > > Note that since some extensions may want to depend on versions of XWiki > > older than 5.3 we can deploy this contrib pom also for older versions > using > > mvn deploy:deploy-file > > > > WDYT? > > +1. > > Will this be a copy of xwiki-commons-pom, or an extension that overrides > a few sections? > > Should it include the license check plugin, which currently enforces > LGPL2.1? Should we make it easier to change the license being enforced? > > What do we put instead of the <developers>? Do we make it a generic > "XWiki community", or leave it empty so that others can fill it in? We > can use the enforcer's requireProperty rule to check that mandatory > sections have been filled in. > See a first version at https://github.com/xwiki-contrib/contrib-pom/blob/master/pom.xml > I'd like to have a single xwiki.version property instead of the current > commons, rendering, platform.version, so that people don't have to think > which one should they use for each module. > I think that's orthogonal to this discussion. > Instead of deploy-file, why not actually release older versions? Since > it's a separate repository, we can do that, we don't have to sync > releases with the official XWiki releases. > It's not a separate repository, that's the point ;) I explained above why I think it's good to have it in xwiki-commons ;) Thanks -Vincent > -- > Sergiu Dumitriu > http://purl.org/net/sergiu > _______________________________________________ > devs mailing list > devs(a)xwiki.org > http://lists.xwiki.org/mailman/listinfo/devs > ------------------------------ Message: 7 Date: Thu, 07 Nov 2013 11:16:25 -0500 From: Sergiu Dumitriu <sergiu(a)xwiki.com> To: XWiki Developers <devs(a)xwiki.org> Subject: Re: [xwiki-devs] [Proposal] Adding a Contrib top level project in commons Message-ID: <527BBCD9.7030808(a)xwiki.com> Content-Type: text/plain; charset=UTF-8 On 11/07/2013 11:10 AM, Vincent Massol wrote: > On Thu, Nov 7, 2013 at 4:58 PM, Sergiu Dumitriu <sergiu(a)xwiki.com> wrote: > >> On 11/07/2013 10:29 AM, Vincent Massol wrote: >>> Hi devs, >>> >>> We need to provide a contrib top level POM for extension contributors. >> ATM >>> we recommend to extend the commons top level pom on >>> http://contrib.xwiki.orgbut it's a bad idea because contributors >>> forget to override some pom.xml >>> elements (such as the <developers> section) and thus the published >>> extensions end up with wrong information (such as wrong author: "XWiki >>> Development Team"). >>> >>> The reason to put it in commons: >>> * We will have dependencyManagement in it and thus it needs to be in sync >>> with the commons version. It'll have the same version as commons top >> level >>> pom version. >>> * Easy for us since it'll be released at the same time as commons >>> * Easy for extension authors to choose the top level contrib version they >>> need: they'll pick the one corresponding to the xwiki version they want >> to >>> depend on >>> >>> Note that since some extensions may want to depend on versions of XWiki >>> older than 5.3 we can deploy this contrib pom also for older versions >> using >>> mvn deploy:deploy-file >>> >>> WDYT? >> >> +1. >> >> Will this be a copy of xwiki-commons-pom, or an extension that overrides >> a few sections? >> >> Should it include the license check plugin, which currently enforces >> LGPL2.1? Should we make it easier to change the license being enforced? >> >> What do we put instead of the <developers>? Do we make it a generic >> "XWiki community", or leave it empty so that others can fill it in? We >> can use the enforcer's requireProperty rule to check that mandatory >> sections have been filled in. >> > > See a first version at > https://github.com/xwiki-contrib/contrib-pom/blob/master/pom.xml > > >> I'd like to have a single xwiki.version property instead of the current >> commons, rendering, platform.version, so that people don't have to think >> which one should they use for each module. >> > > I think that's orthogonal to this discussion. > > >> Instead of deploy-file, why not actually release older versions? Since >> it's a separate repository, we can do that, we don't have to sync >> releases with the official XWiki releases. >> > > It's not a separate repository, that's the point ;) I explained above why I > think it's good to have it in xwiki-commons ;) > Ah, right, somehow I missed that part. -- Sergiu Dumitriu http://purl.org/net/sergiu ------------------------------ _______________________________________________ devs mailing list devs(a)xwiki.org http://lists.xwiki.org/mailman/listinfo/devs End of devs Digest, Vol 77, Issue 12 ************************************

11 years, 10 months

2
1
0 0

[xwiki-devs] [Reminder] BFD#43

by Vincent Massol

Hi devs, Today is Bug Fixing Day 43. We're currently at -121 bugs for the 1600 days period: http://jira.xwiki.org/secure/Dashboard.jspa?selectPageId=10352 Let's reduce this gap... Here's the BFD#43 dashboard to follow the progress during the day: *http://jira.xwiki.org/secure/Dashboard.jspa?selectPageId=11793 <http://jira.xwiki.org/secure/Dashboard.jspa?selectPageId=11793>* Thanks -Vincent

11 years, 10 months

1
0
0 0

[xwiki-devs] [Proposal] Wiki API

by Guillaume "Louis-Marie" Delhumeau

Hi. In this thread, I want to propose you the tiniest API that we need to handle multiwiki. All other features (users, templates, workspaces...) will be on other modules, because I think it is better for the extensibility. The new module will be based on the xwiki-platform-wiki-descriptor-api module, that I will rename to xwiki-platform-wiki-api. The WikiDescriptorManager becomes WikiManager and handle both descriptors and databases. This API will permit: * to create a wiki * to remove a wiki * to list all wikis (returning a list of descriptors) * ... You can see the code of that proposal there: https://github.com/gdelhumeau/xwiki-platform/tree/new-wiki-api/xwiki-platfo… The most important is to decide what the API must look like. The implementation can still be modified afterwards. I hope you like it, Louis-Marie

11 years, 10 months

5
30
0 0

[xwiki-devs] anybody attending Horizon 2020/Digital Agenda for Europe ICT 2013 Conference, Vilnius, 6-8 November 2013?

by Ricardo.Julio.Rodriguez.Fernandez＠sergas.es

It would be great to meet XWiki guys/gals there! Cheers! Ricardo -- Ricardo Rodríguez Research Management and Promotion Technician Technical Secretariat Health Research Institute of Santiago de Compostela (IDIS) http://www.idisantiago.es Nota: A información contida nesta mensaxe e os seus posibles documentos adxuntos é privada e confidencial e está dirixida únicamente ó seu destinatario/a. Se vostede non é o/a destinatario/a orixinal desta mensaxe, por favor elimínea. A distribución ou copia desta mensaxe non está autorizada. Nota: La información contenida en este mensaje y sus posibles documentos adjuntos es privada y confidencial y está dirigida únicamente a su destinatario/a. Si usted no es el/la destinatario/a original de este mensaje, por favor elimínelo. La distribución o copia de este mensaje no está autorizada. See more languages: http://www.sergas.es/aviso_confidencialidad.htm

11 years, 10 months

2
2
0 0

[xwiki-devs] Proposal to push wiki-nodes, the XWiki/Cassandra demonstration over to contrib.

by Caleb James DeLisle

Hi guys, It's been a while since this demo was created but I was looking at my github and it has not been touched so I would like to document it and put it in contrib where it's available. I have a question about technique, this demo builds on the standard version of xwiki-platform but requires a special version of xwiki-enterprise. Is it ok to have a long term branch in the xwiki-enterprise repository or should the entire repository be copied into contrib? WDYT? Caleb

11 years, 10 months

2
4
0 0

[xwiki-devs] Proposal to move REPL Console Application to xwiki-contrib.

by Caleb James DeLisle

Hi guys, I'd like to move the REPL Console Application http://extensions.xwiki.org/xwiki/bin/view/Extension/REPL+Console+Applicati… from my github account here: https://github.com/cjdelisle/xwiki-contrib-repl To the xwiki-contrib account because I'm not actively working on it and if anyone else feels like adding features or changing it, it's better that they take the lead. WDYT? Caleb

11 years, 10 months

2
4
0 0

[xwiki-devs] Invitation to connect on LinkedIn

by Flavius Olaru

LinkedIn ------------ XWiki, I'd like to add you to my professional network on LinkedIn. - Flavius Flavius Olaru Web Developer at XWiki Iasi County, Romania Confirm that you know Flavius Olaru: https://www.linkedin.com/e/3vasf0-hnlpn2rt-1m/isd/17783891139/ziS3Akov/?hs=… -- You are receiving Invitation to Connect emails. Click to unsubscribe: http://www.linkedin.com/e/3vasf0-hnlpn2rt-1m/9s_c-0fN05p6qjQq9meQgfVB/goo/d… (c) 2012 LinkedIn Corporation. 2029 Stierlin Ct, Mountain View, CA 94043, USA.

11 years, 10 months

2
2
0 0

[xwiki-devs] [Proposal] Crypto API - Expose Bouncy Castle, JCA or not ?

by Denis Gervalle

Hi devs, In the process of preparing signed scripts and other security improvements, I am currently refactoring the crypto API that suffer from being available during the early days of the component manager. Our objective has also changed, and some part will be deprecated in favor of a new more evolve API. In that process, I am wondering which kind of object we allow to go through our API, and I see 3 possibilities: 1) Do not use any object from either Bouncy Castle (BC), nor Java Cryptography API (JCA), and build our own, like BC does. This is obviously the most decouple solution, but it will increase the conversion between APIs. User that may also use BC or JCA on their own will also have to convert their native objects to our own, to use our API. 2) Use the JCA objects only in addition to our own. The JCA has not evolved since a while, and is therefore really stable. This seems to me a better alternative. BC provide support to use those objects, so the conversion to BC is easy. However, these objects are not as friendly as those of BC, so we may need to provide some equivalent helpers existing in BC. 3) Link us more closely with BC, and use the best alternative depending on the situation, either BC, JCA, or our own. This is more easy for us, and better for users of BC outside of our API. This will avoid having to duplicate some BC functionality that are already user friendly enough on our side, therefore limiting maintenance work as well. I am more in favor of 2) or 3), not because I am lazy, but since the initial API already use 2) and I prefer not to duplicate existing features in BC which looks to me a de-facto standard for cryptography in the open-source world. WDYT ? -- Denis Gervalle SOFTEC sa - CEO

11 years, 10 months

5
4
0 0

[xwiki-devs] [Reminder] BFD#42

by Vincent Massol

Hi devs, Today is Bug Fixing Day 42. We're currently at 3364 bugs created over 1500 days vs 3362 closed, ie only 2 bugs behind! (I think we got lucky ;)) http://jira.xwiki.org/secure/Dashboard.jspa?selectPageId=10352 Let’s crush the 1500 days threshold today! Here's the BFD#42 dashboard to follow the progress during the day: http://jira.xwiki.org/secure/Dashboard.jspa?selectPageId=11792 Thanks -Vincent

11 years, 10 months

4
4
0 0

[xwiki-devs] Bundle flag icons in XE

by Marius Dumitru Florea

Hi devs, In order to implement http://jira.xwiki.org/browse/XWIKI-9512 (display the flag icon and the language pretty name instead of the language code) I need to bundle a flag icon set in XE. The best option seems to be http://www.famfamfam.com/lab/icons/flags/ . They say: "These flag icons are available for free use for any purpose with no requirement for attribution." So if no one objects I'm going to add the PNG set to xwiki-platform-web, in webapp/resources/icons/flags . It weights about 130KB. The alternative is to display only the language pretty name, but it's less nicer. Or maybe you know a better flag icon set. Thanks, Marius

11 years, 10 months

7
11
0 0

[xwiki-devs] HTMLCleaner to remove some iframes?

by Paul Libbrecht

Hello fellow xwiki developers, trying to understand why an iframe element disappears after we re-edit source after we insert the iframe in source html, I seem to understand that the service called "HTMLCleaner" is the guilty one (the service is called as a POST to URL /xwiki/resources/js/xwiki/wysiwyg/xwe/HTMLConverter.gwtrpc Is there any way to configure the policy of the html-cleaner? I did not see this among the configs. thanks in advance. paul

11 years, 10 months

3
7
0 0

[xwiki-devs] Postpone 5.3M2 by 1 week

by Marius Dumitru Florea

Hi devs, We didn't manage to release 5.3M1 on time (1 week delay..) and this leaves only 1 week for M2 which is not enough for me to finish my work on Solr (see http://www.xwiki.org/xwiki/bin/view/Roadmaps/WebHome ) so I propose to take 1 week from RC1: 5.3M2: 11th of November (was 4th) 5.3RC1: 18th of November 5.3Final: 25th of November WDYT? Thanks, Marius

11 years, 10 months

4
3
0 0

[xwiki-devs] [ANN] XWiki 5.3 Milestone 1 Released

by Marius Dumitru Florea

The XWiki development team is proud to announce the availability of XWiki 5.3 Milestone 1. This is more a developer oriented release with new Extension Manager APIs, an XWiki Enterprise Maven Archetype, XAR plugin improvements and fold observation events but it also has a number of bug fixes (36) and improvements (22) that the users will appreciate. 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/ReleaseNotesXWiki53M1 Thanks -The XWiki dev team

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