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
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:
<!-- Fail the build if the test coverage is below a given value.
Note: Since this takes a bit of time to execute we only run this when the integration-tests profile is active -->
<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
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.
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
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/
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
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.
>>
>
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
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.
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