xwiki-devs

xwiki-devs@xwiki.org

9399 discussions

[xwiki-devs] Maven Repository problem (org.restlet.ext.jaxrs)

by Fernando Ferreira

Hi all! I was trying to build XWiki from sources (xwiki-commons) with a fresh new Maven installation (empty local repository) and found a problem with the * org.restlet.ext.jaxrs* artifact (2.0.14). This was the build error: [ERROR] Failed to execute goal org.apache.maven.plugins:maven-compiler-plugin:2.5.1:compile (default-compile) on project xwiki-commons-extension-repository-xwiki: Compilation failure: Compilation failure: [ERROR] /data/Repository/XWiki/xwiki-commons/xwiki-commons-core/xwiki-commons-extension/xwiki-commons-extension-repositories/xwiki-commons-extension-repository-xwiki/src/main/java/org/xwiki/extension/repository/xwiki/internal/XWikiExtensionRepository.java:[38,23] package org.restlet.data does not exist [ERROR] /data/Repository/XWiki/xwiki-commons/xwiki-commons-core/xwiki-commons-extension/xwiki-commons-extension-repositories/xwiki-commons-extension-repository-xwiki/src/main/java/org/xwiki/extension/repository/xwiki/internal/XWikiExtensionRepository.java:[116,47] package MediaType does not exist A little above it i saw this: Downloading: http://nexus.xwiki.org/nexus/content/groups/public/org/restlet/jse/org.rest… [WARNING] Checksum validation failed, expected <!DOCTYPE but is 97d021087f5852baf8cc9deca20825b1bf42bbaf for http://nexus.xwiki.org/nexus/content/groups/public/org/restlet/jse/org.rest… [WARNING] Checksum validation failed, expected <!DOCTYPE but is 97d021087f5852baf8cc9deca20825b1bf42bbaf for http://nexus.xwiki.org/nexus/content/groups/public/org/restlet/jse/org.rest… Downloaded: http://nexus.xwiki.org/nexus/content/groups/public/org/restlet/jse/org.rest… KB at 1.6 KB/sec) [WARNING] The POM for org.restlet.jse:org.restlet.ext.jaxrs:jar:2.0.14 is invalid, transitive dependencies (if any) will not be available, enable debug logging for more details Downloading: http://nexus.xwiki.org/nexus/content/groups/public/org/restlet/jse/org.rest… Downloaded: http://nexus.xwiki.org/nexus/content/groups/public/org/restlet/jse/org.rest… KB at 47.0 KB/sec) It seems the org.restlet's repository was down for maintenance at the time Nexus fetched the files. The POM ( http://nexus.xwiki.org/nexus/content/groups/public/org/restlet/jse/org.rest…) has this inside: You caught us doing a little maintenance. We're sorry that you can't access your community right now. ... With a problem like this, would something like adding the org.restlet's repository to my settings.xml do the work? I'm in no hurry anyway, i can wait for the repository... ;) If there's anything else i can do, just drop me a message! Thanks, Fernando

13 years

[xwiki-devs] [Proposal] Failing a module's build if under a given TPC threshold

by Vincent Massol

Hi devs, Each java module has a current TPC level (Test Percentage Coverage), be it 5% of 90%. As part of improving XWiki's quality, the idea is that future commits in this module shouldn't lower the module's quality. One easy way to ensure this is to measure the current TPC level and make the build fail whenever the build is under this TPC threshold. This means that if you commit code that has less tests average than what currently exists then the build will fail. Here's one way to implement it:  <profiles> <profile> <id>integration-tests</id> <build> <plugins> <plugin> <groupId>com.atlassian.maven.plugins</groupId> <artifactId>maven-clover2-plugin</artifactId> <configuration> <targetPercentage>86.9%</targetPercentage> </configuration> <executions> <execution> <id>clover-check</id> <phase>verify</phase> <goals> <goal>instrument-test</goal> <goal>check</goal> </goals> </execution> </executions> </plugin> </plugins> </build> </profile> </profiles> So this proposal is about the following strategy: * Allow committers to modify module's pom.xml to fail the build when then TPC is under the current threshold * Since oldcore is really difficult to test, maybe we should not set build failing for oldcore. OTOH oldcore is an important module. WDYT? * If for some reason a committer wants to lower the TPC threshold for a module he needs to get the agreement from the other committers (vote). There might be valid reasons like fixing an important bug quickly for a release and writing a test is just too complex so the writing of the test is to be delayed for after the release, etc. * I'd like to consider this as an experiment and see how it goes Note: This is about unit test TPC which is different from the TPC that includes functional tests. WDYT? Here's my +1 to try this out and see how it goes. Thanks -Vincent

13 years

[xwiki-devs] Unable to add new topics under Xwiki BulletinBoard plugin

by echocoder

I have the BulletinBoard plugin installed into Xwiki to use as a forum. The forum works fine if it is accessed directly. However, I have a page in the Xwiki that includes a menu and a particular section of the forum. I can see content, I am just unable to add new topics via the page that contains a menu. When accessing the forum directly under the same section I am able to add new topics. The problem is that the site navigational menu must be included so this "middle man" page is necessary. The page that includes references to the menu and the forum section is written as: (% style="margin-top: -2em;" %) ((( |(% style="vertical-align: top; position: relative; top: -1.0em; left: -0.4em; border:0;" %)((( {{include document="CTAs.Menu"/}} )))|(% style="width: 100%; border-width: medium; border-style: none; border-color: -moz-use-text-color; vertical-align: top;" %)((( (% style="margin-top: -0.7em; margin-left: -0.25em" %) ((( {{include document="BulletinBoard.CTAENS" context="new"/}} ))) ))) ))) Where CTAs.Menu is the menu I need to include and the BullentinBoard.CTAENS is the section of the forum I need to display. The page displays fine, however the link "Add new topic" is not functional. The error that seems to be generated due to this action is.... 012-08-21 12:32:33,548 [/xwiki/bin/view/CTAs/ens_forum] ERROR rnal.DefaultObservationManager - Fail to send event [org.xwiki.observation.event.ActionExecutionEvent@373aa5] to listener [com.xpn.xwiki.stats.impl.XWikiStatsServiceImpl@110bc5c] java.lang.NullPointerException at com.xpn.xwiki.stats.impl.XWikiStatsServiceImpl.onEvent(XWikiStatsServiceImpl.java:190) at org.xwiki.observation.internal.DefaultObservationManager.notify(DefaultObservationManager.java:278) at org.xwiki.observation.internal.DefaultObservationManager.notify(DefaultObservationManager.java:247) at com.xpn.xwiki.web.XWikiAction.execute(XWikiAction.java:316) at com.xpn.xwiki.web.XWikiAction.execute(XWikiAction.java:117) at org.apache.struts.action.RequestProcessor.processActionPerform(RequestProcessor.java:431) at org.apache.struts.action.RequestProcessor.process(RequestProcessor.java:236) at org.apache.struts.action.ActionServlet.process(ActionServlet.java:1196) at org.apache.struts.action.ActionServlet.doGet(ActionServlet.java:414) at javax.servlet.http.HttpServlet.service(HttpServlet.java:627) at javax.servlet.http.HttpServlet.service(HttpServlet.java:729) at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:269) at org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:188) at com.xpn.xwiki.web.ActionFilter.doFilter(ActionFilter.java:129) at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:215) at org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:188) at com.xpn.xwiki.wysiwyg.server.filter.ConversionFilter.doFilter(ConversionFilter.java:152) at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:215) at org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:188) at com.xpn.xwiki.plugin.webdav.XWikiDavFilter.doFilter(XWikiDavFilter.java:68) at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:215) at org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:188) at org.xwiki.container.servlet.filters.internal.SavedRequestRestorerFilter.doFilter(SavedRequestRestorerFilter.java:218) at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:215) at org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:188) at org.xwiki.container.servlet.filters.internal.SetCharacterEncodingFilter.doFilter(SetCharacterEncodingFilter.java:112) at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:215) at org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:188) at org.apache.catalina.core.StandardWrapperValve.invoke(StandardWrapperValve.java:213) at org.apache.catalina.core.StandardContextValve.invoke(StandardContextValve.java:172) at org.apache.catalina.core.StandardHostValve.invoke(StandardHostValve.java:127) at org.apache.catalina.valves.ErrorReportValve.invoke(ErrorReportValve.java:117) at org.apache.catalina.core.StandardEngineValve.invoke(StandardEngineValve.java:108) at org.apache.catalina.connector.CoyoteAdapter.service(CoyoteAdapter.java:174) at org.apache.jk.server.JkCoyoteHandler.invoke(JkCoyoteHandler.java:200) at org.apache.jk.common.HandlerRequest.invoke(HandlerRequest.java:291) at org.apache.jk.common.ChannelSocket.invoke(ChannelSocket.java:775) at org.apache.jk.common.ChannelSocket.processConnection(ChannelSocket.java:704) at org.apache.jk.common.ChannelSocket$SocketConnection.runIt(ChannelSocket.java:897) at org.apache.tomcat.util.threads.ThreadPool$ControlRunnable.run(ThreadPool.java:689) at java.lang.Thread.run(Thread.java:662) -- View this message in context: http://xwiki.475771.n2.nabble.com/Unable-to-add-new-topics-under-Xwiki-Bull… Sent from the XWiki- Dev mailing list archive at Nabble.com.

13 years

[xwiki-devs] [XWiki DEVS][GSOC]Solr Search Features and Set Up Documentation

by savitha sundaramurthy

Dear XWiki community, The Advanced Search features, Administration module is almost complete in Solr Search component. The link to the running instance is given below. http://savitha.hoplahup.net/xwiki/bin/view/Main/AdvancedSearch Link to the Set Up Documentation and the features Page Set Up Doc and Feature Page<http://dev.xwiki.org/xwiki/bin/view/GoogleSummerOfCode/SolrSearchApplication> Progress Page<http://dev.xwiki.org/xwiki/bin/view/GoogleSummerOfCode/SOLRsearchcomponent> Work remaining to be able to commit the component in platform : 1. Fix checkstyle errors 2. Auto Suggest feature 3. Admin UI 4. Minor bugs in Facet search to be fixed 5. Search calibration 6. Unit test cases and Functional test cases. Planning to do the following this week 1. Fix checkstyle errors 2. Auto Suggest feature 3. Fix the minor bugs. 4. Search calibration 5. Complete the documentation. -- Thanks, Savitha

13 years

[xwiki-devs] [Proposal] Problem displaying localized document titles

by Sergiu Dumitriu

Hi devs, Trying to address http://jira.xwiki.org/browse/XWIKI-6228 I noticed today a big problem with the way translations work. $xwiki.getDocument('Main.Welcome').getTranslatedDocument('fr').plainTitle No matter what language I request, the title will always be displayed in English. This is caused by the fact that for all translations, the title is actually $msg.get("xe.dashboard.wiki.welcome"), and $msg uses the context language, not the document language. This means that getting the right title of the document is almost impossible. Given that we've separated the displayers from the oldcore and the main rendering engine, we could change their behavior so that document translations would work better. Whenever displaying some information from a document, we should temporarily change the context language to be the same as the document's language, if any. This would be a backwards-incompatible change, but IMO it's a change for the better. WDYT? -- Sergiu Dumitriu http://purl.org/net/sergiu/

13 years

[xwiki-devs] [VOTE] Modification to groupid for contrib projects

by Vincent Massol

hi devs, I'd like to propose a small improvement for contrib project group ids. ATM our rule is: "A generic maven groupId : org.xwiki.contrib (until the project reaches a certain size and visibility, in which case it can have its own maven group id)" ( see http://contrib.xwiki.org/xwiki/bin/view/Main/WebHome) I'd like to change that to: "A generic maven groupId : org.xwiki.contrib.<module name> (until the project reaches a certain size and visibility, in which case it can have its own maven group id)" So for example if I have a "Mail Archive Application" I'd use the groupid: org.xwiki.contrib.mailarchive Here's my +1 for the change Thanks -Vincent

13 years

Re: [xwiki-devs] [GSoc] XWiki Android

by sasinda rukshan

Hi Thomas, >>I restarted it and it seems ok now. Thanks a lot. Instrumentation tests that check the activities are running ok. (XWiki Android Instrumentation Tests<http://ci.xwiki.org/job/xwiki-android-client/216/org.xwiki.android$xwiki-an…> ) I disabled the base rest api tests (xwiki-android-test-rest). I'll enable them in the next commit. There should be a local xwiki test instance in jenkins server as well. Can you tell me how to access it. Tried http://ci.xwiki.org:8080. Since the test properties are directing to a local server instance 10.0.2.2:8080 it should be there. We will be running tests bottom up. i.e. low lvl rest API --> Rest API in RAL --> application layer UI components. And RAL tests will use low lvl rest API to achieve its pre-conditions and do cleanup after tests. If low level fails testing highlvl ones are not meaningful if they depend on the components that failed. ;-). Best Regards. Sasinda. > > > On Mon, Aug 6, 2012 at 1:00 PM, Thomas Mortagne <thomas.mortagne(a)xwiki.com > > wrote: > >> On Mon, Aug 6, 2012 at 9:12 AM, Thomas Mortagne >> <thomas.mortagne(a)xwiki.com> wrote: >> > On Mon, Aug 6, 2012 at 9:10 AM, Thomas Mortagne >> > <thomas.mortagne(a)xwiki.com> wrote: >> >> On Mon, Aug 6, 2012 at 8:57 AM, Thomas Mortagne >> >> <thomas.mortagne(a)xwiki.com> wrote: >> >>> On Sun, Aug 5, 2012 at 5:42 PM, sasinda rukshan >> >>> <sasindarukshan(a)gmail.com> wrote: >> >>>> Hi Thomas, >> >>>> :-) >> >>>> Also still we cannot ignore failed tests in maven android plugin. If >> a test >> >>>> fails we get Build Failure as result. >> >>> >> >>> Well that's the whole point, not sure why you want to ignore failing >> tests. >> >>> >> >>>> http://code.google.com/p/robotium/issues/detail?id=130 >> >>>> >> >>>>> Need an AVD / Device connected to Jenkins to >> >>>> run the tests. >> >>>> I think you just have to download android sdk to the jenkins server >> and use >> >>>> avd-manager to start up an avd in it. >> >>>> Not urgent ;-). >> >> >> >> Well thing is there is an AVD running and always have (since it was >> >> required by previous tests) so I don't understand exactly what's >> >> wrong. >> > >> > Here is what I have in ps aux: >> > >> > emulator -avd test-2.1 -noaudio -no-window -wipe-data >> >> Looks like it was not in a very good state actually, I restarted it >> and it seems ok now. >> >> > >> >> >> >>>> >> >>>> Still writing tests for core module. >> >>>> >> >>>> Regards. >> >>>> Sasinda Rukshan. >> >>>> >> >>>> On Sun, Aug 5, 2012 at 8:49 PM, Thomas Mortagne < >> thomas.mortagne(a)xwiki.com> >> >>>> wrote: >> >>>>> >> >>>>> On Sun, Aug 5, 2012 at 4:46 PM, sasinda rukshan >> >>>>> <sasindarukshan(a)gmail.com> wrote: >> >>>>> > Hi Thomas, >> >>>>> > Thnx. >> >>>>> > >> >>>>> >>No, you need to start one (which is not very hard with >> jetty/hsqldb >> >>>>> >>distribution) >> >>>>> > Well what about the earlier project's test server. It should have >> had >> >>>>> > its >> >>>>> > test environment setup properly. Shouldn't it?. >> >>>>> >> >>>>> Yes it should have but Chamika did not had time to finish. >> >>>>> >> >>>>> > >> >>>>> > >> >>>>> >>(but then you have the risk that you don't >> >>>>> >>have the exact same behavior) when you start the tests. You can >> look >> >>>>> >>at how >> >>>>> >> >> >>>>> >> >> https://github.com/xwiki/xwiki-enterprise/tree/master/xwiki-enterprise-test… >> >>>>> >>does it for example. >> >>>>> > Thanks. I'll make the setup, tear down methods to achieve >> preconditions >> >>>>> > and >> >>>>> > cleanup. >> >>>>> > >> >>>>> > Best Regards. >> >>>>> > >> >>>>> > On Sun, Aug 5, 2012 at 7:14 PM, Thomas Mortagne >> >>>>> > <thomas.mortagne(a)xwiki.com> >> >>>>> > wrote: >> >>>>> >> >> >>>>> >> On Sun, Aug 5, 2012 at 11:42 AM, sasinda rukshan >> >>>>> >> <sasindarukshan(a)gmail.com> wrote: >> >>>>> >> > Hi Thomas, >> >>>>> >> > >> >>>>> >> > >> >>>>> >> > This is the latest result for >> xwiki-android-tests-instrumentation >> >>>>> >> > (The >> >>>>> >> > UI stress testing test module) >> >>>>> >> > >> >>>>> >> > >> >>>>> >> > >> >>>>> >> > [INFO] *Found 0 devices connected with the Android Debug >> Bridge* >> >>>>> >> > mojoFailed >> >>>>> >> > >> >>>>> >> > >> com.jayway.maven.plugins.android.generation2:android-maven-plugin:3.3.0(default-internal-pre-integration-test) >> >>>>> >> > projectFailed >> >>>>> >> > >> org.xwiki.android:xwiki-android-tests-instrumentation:1.0-SNAPSHOT >> >>>>> >> > sessionEnded >> >>>>> >> > >> >>>>> >> > >> >>>>> >> > Need an AVD / Device connected to Jenkins to run the tests. >> >>>>> >> >> >>>>> >> Will look at it. >> >>>>> >> >> >>>>> >> > >> >>>>> >> > Also the ....test-rest will have failures if some >> preconditions are >> >>>>> >> > not >> >>>>> >> > met. (like having a page named Blog/test2 ) >> >>>>> >> > >> >>>>> >> > Is there a testing server instance running on the Jenkins >> server?. >> >>>>> >> >> >>>>> >> No, you need to start one (which is not very hard with >> jetty/hsqldb >> >>>>> >> distribution) or mock one (but then you have the risk that you >> don't >> >>>>> >> have the exact same behavior) when you start the tests. You can >> look >> >>>>> >> at how >> >>>>> >> >> >>>>> >> >> https://github.com/xwiki/xwiki-enterprise/tree/master/xwiki-enterprise-test… >> >>>>> >> does it for example. >> >

13 years

[xwiki-devs] [vote] improvements for the REST api

by Ludovic Dubost

While working on a prototype on a HTML5 mobile and desktop application I've hit a few limitations of the REST APIs. This is why I propose some enhancements to the current REST APIs to give more flexibility, particularly: Support for start and order parameter in queries returning large list of pages Support order parameter in page list Adding page version, author information and data information when missing Hidden documents filter activation or deactivation in REST APIs Adding pretty display of title and author names Support queries using XWQL, HQL and Lucene The rendered content should be accessible from REST apis The details of the proposal is here: http://dev.xwiki.org/xwiki/bin/view/Design/RESTApiImprovements A pull request for a prototype implementation of these requirements is available here: https://github.com/xwiki/xwiki-platform/pull/56/files#r1040052 Not everything has an implementation (hidden docs and rendered content is not implemented yet). Other are not implementing according to this specification as some comments have already been made. Particularly the following votes are required: VOTE to accept supporting "start" and "order" parameters only on queries having only one unique scope VOTE in search queries for just adding the descendent date order or add more order possibilities using order and orderdir param VOTE in page list queries for just adding the descendent date order or add more order possibilities using order and orderdir param VOTE to add page version and author fields to page and other resources VOTE for adding the additional fields with or without a parameter "pagedetails=1" VOTE for adding a parameter to show/hide hidden documents independent of user setting VOTE to add the displayTitle field with or without the pagedetails=1 parameter or with it's own parameter displayTitle=1 VOTE to add the author display names with or without the displayPrettyNames parameter VOTE for supporting the searchQuery API at the wiki level with multi wiki support at the lucene level VOTE for adding rendered content using the withrenderedcontent=1 param VOTE for having absolute URLs in the rendered content using withabsoluteurls=1 param Thanks Ludovic -- Ludovic Dubost Founder and CEO Blog: http://blog.ludovic.org/ XWiki: http://www.xwiki.com Skype: ldubost GTalk: ldubost

13 years, 1 month

[xwiki-devs] Lucene - external indexing

by Jones, Dan

Would it be possible to add an external directory for lucene to crawl and index? I want to be able to search wiki content, including the attachments, and also incorporate external search results as well. I was taking a look at Solr, and might try to go that route, despite being intimidated a bit. It looks extremely cool and well suited. Gracias! ________________________________ This communication (including all attachments) is intended solely for the use of the person(s) to whom it is addressed and should be treated as a confidential AAA communication. If you are not the intended recipient, any use, distribution, printing, or copying of this email is strictly prohibited. If you received this email in error, please immediately delete it from your system and notify the originator. Your cooperation is appreciated.

13 years, 1 month

[xwiki-devs] [GSOC] SOLR status evaluation

by Vincent Massol

Hi Guys, I haven't been that closely the SOLR GSOC work and it would be great to see where we stand. I'd love to know the following: * What's the status of the code; is it following our best practices (code style/passing checkstyle, unit tests, functional tests)? * What's the level of the UI in term of readiness, compared to our current one? * Do we have all the features of the current Lucene plugin (including improvements already listed in JIRA, we should verify that they can be implemented with the current code if not already there) * Could we do drop-in replacement of the current search? In general, how much work remains to be able to commit this in platform and start bundling it and using it in XE? Thanks a lot -Vincent

13 years, 1 month

Jump to page:

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

2005

xwiki-devs