Hi,
I'm currently working on building an Android library which gives RESTful
features within android device.
As the first step I managed to import jaxb libraries and now I'm trying to
execute them within android so that xwiki-android client will not need
complete new REST library.
For importing jaxb I used following dependencies in maven configuration
xwiki-core-rest
xwiki-core-annotations-rest
wiki-core-rest-model
I planed to push to the repo as soon as I build something useful in purpose
of code review.
Thank you,
Best Regards,
Chamika Weerasinghe
Hi devs,
Here's the situation:
* We've been having a hard time releasing on time and the main issue is test stability. We lag by at least a week and we even release with failing tests, causing regressions.
* It's not the role of the release manager to fix tests before releasing
* It's not normal that some people spend time fixing issues caused by others and that others continue to work on the next thing they are working on. Everyone needs to help.
Here's what I propose as a drastic and temporary measure till we get better:
1) It's forbidden to commit anything till all tests are passing (unit AND functional tests), unless what is committed is about fixing tests. On the exceptional case when a committer absolutely needs to commit even though tests are failing he needs to ask the permission explicitly.
2) When tests are failing, everyone should stop what they're doing and help stabilize again. We synchronize on IRC.
3) Flickering tests can be marked as @Ignore and a jira issue created to stabilize the build.
4) Release Manager creates a release branch 1 week before the release to let everyone stabilize the build
On a long term we need to work on improving our CI so that functional tests are built faster. One idea is: more agents and functional tests spread on several agents.
Here's my +1 to apply this now for master (3.2-SNAPSHOT leading to 3.2M1), which means not committing anything more till we have all functional tests passing.
Thanks
-Vincent
Hi,
I would like to propose a small re-organization of the rest module.
Currently the module is organized as follow :
xwiki-platform-rest/
\_xwiki-platform-rest-model/
\_xwiki-platform-rest-server/
Where xwiki-platform-rest-model contains the JAXB bindings and
generates model classes ; and where xwiki-platform-rest-server
contains "everything else", being the Restlet plumbing to expose a
REST application, and the REST resources and representations that
makes the XWiki REST API.
I'm proposing a first re-organization going towards the following structure :
xwiki-platform-rest/
\_xwiki-platform-rest-model/
\_xwiki-platform-rest-resources/
\_xwiki-platform-rest-server/
Where xwiki-platform-rest-model remains the same, and where everything
that is not needed to expose a functional REST system is extracted out
of xwiki-platform-rest-server and into xwiki-platform-rest-resources.
With this, xwiki-platform-rest-resources would become the actual
implementation of the XWiki Restful API, while
xwiki-platform-rest-server will be the module needed to expose any
REST API from XWiki.
The rationale behind this is simply to ease implementation of
alternate APIs while keeping benefits from the server module which is
agnostic to any API exposed.
My +1 for this. If we agree I can push it early in the 3.2 cycle (in a
couple of days).
WDYT ?
----
Note for the future :
In the future we could want to split the REST module even more. Right
now some parts of the module are tied to Restlet, but resources aren't
(basically everything in org.xwiki.rest.resources), and we could
extract them out in a generic module while introducing a restlet
module for everything Restlet (server plumbing + representations). It
could for example look like this :
xwiki-platform-rest/
\_xwiki-platform-rest-model/
\_xwiki-platform-rest-restlet/
\_xwiki-platform-rest-restlet-server/
\_xwiki-platform-rest-restlet-representations/
\_xwiki-platform-rest-resources/
This would ease alternative implementations based on other JAX-RS
implementations (CFX, Jersey, etc.)
Jerome
Does anyone know why the CreateEmptyWiki selenium test is failing in XEM tests?
http://ci.xwiki.org/job/xwiki-manager-tests/1164/org.xwiki.manager$xwiki-ma…
It seems that it has been failing for quite some time although the failure looks serious enough to warrant attention.
If this is a "normal" failure then I propose we @Ignore it and if nobody wants to get it functioning correctly then remove it entirely since it is not
proving anything now and if there isn't a regression here then it is just creating unnecessary noise.
Caleb
Dear all,
Down below is the working plan for this week and the next one.
Time Period
Tasks
Deliverable
May 24 -- May 28
use xwiki-platform-rest-model library and replace
xwiki-core-xmlrpc-model-1.4; develop RemoteXWikiDataStorage.java which
uses REST instead of XML-RPC
complete all the current methods in IDataStorage.java interface
May 30 -- June 3
extend IDataStorage.java with new functionality and resources provided
in rest-model library
complete all the functionalities in rest-model library, provide test
case plugin (xwiki.eclipse.test)
I have a question about restlet library, is there any plan to upgrade it
to v2.0+?
Or we will stick with v1.1?
Best regards
Jun Han
Hello,
To keep schedule we would need to have a release today and I am ready to release but we have some outstanding issues which need to be addressed.
1. An blocker was discovered today:
http://jira.xwiki.org/jira/browse/XWIKI-6654 Multiple backslash are not properly handled in reference resolvers
tmortagne is assigned so he can report back when this is finished.
2. vmassol wanted to evaluate each test to make sure that all test failures were indeed test errors and not software bugs.
Unfortunately this has been severely delayed because of:
http://jira.xwiki.org/jira/browse/XE-928 broken tests because jmx control port is in use
3. sburjan discovered what seems to be a blocker in the watchlist functionality
http://jira.xwiki.org/jira/browse/XWIKI-6656 Unable to watch a page/space/wiki
We need someone to confirm this and find out what's happening.
For release I would like somebody to help me with publicity management, I will handle Wikipedia where I have an account and the announcement mail where
I will use my signature but I would like somebody to help with Freshmeat, Wikimatrix, XWiki.org blog, and OW2 news. By spreading out the effort we can put
a little bit more time into adding some quality to the writeup. Can I get a volunteer?
Caleb
I would like to propose releasing 3.1-RC1 on the scheduled date. We (I) have lagged very badly with
the milestone release dates but now is the time to get this in order.
I would like to do the following:
1. Freeze on new features effective immediately. Everybody start working on stability.
2. Any test which is observed to pass and then fail must be @Ignored and a bug reported for it.
3. Release happens on Monday regardless of the state of the tests.
Since the release date is upon us, I need a quick response on this.
WDYT?
Caleb
How can this be done under a "jenkins" user? Who is this Jenkins? (It's a bad idea not to use a committer's name IMO since we don't know who's done the action).
Thanks
-Vincent
On May 29, 2011, at 7:13 PM, noreply(a)github.com wrote:
> Branch: refs/heads/master
> Home: https://github.com/xwiki/xwiki-commons
>
> Commit: 1e6f6891de0d727b48cdb30aba4488d5b222a117
> https://github.com/xwiki/xwiki-commons/commit/1e6f6891de0d727b48cdb30aba448…
> Author: Jenkins <build-noreply(a)xwiki.org>
> Date: 2011-05-29 (Sun, 29 May 2011)
>
> Changed paths:
> M pom.xml
> M xwiki-commons-core/pom.xml
> M xwiki-commons-core/xwiki-commons-component/pom.xml
> M xwiki-commons-core/xwiki-commons-component/xwiki-commons-component-api/pom.xml
> M xwiki-commons-core/xwiki-commons-component/xwiki-commons-component-default/pom.xml
> M xwiki-commons-core/xwiki-commons-component/xwiki-commons-component-observation/pom.xml
> M xwiki-commons-core/xwiki-commons-configuration/pom.xml
> M xwiki-commons-core/xwiki-commons-configuration/xwiki-commons-configuration-api/pom.xml
> M xwiki-commons-core/xwiki-commons-context/pom.xml
> M xwiki-commons-core/xwiki-commons-management/pom.xml
> M xwiki-commons-core/xwiki-commons-observation/pom.xml
> M xwiki-commons-core/xwiki-commons-observation/xwiki-commons-observation-api/pom.xml
> M xwiki-commons-core/xwiki-commons-properties/pom.xml
> M xwiki-commons-core/xwiki-commons-script/pom.xml
> M xwiki-commons-core/xwiki-commons-test/pom.xml
> M xwiki-commons-core/xwiki-commons-velocity/pom.xml
> M xwiki-commons-core/xwiki-commons-xml/pom.xml
> M xwiki-commons-pom/pom.xml
> M xwiki-commons-tools/pom.xml
> M xwiki-commons-tools/xwiki-commons-tool-license-resources/pom.xml
> M xwiki-commons-tools/xwiki-commons-tool-validation-resources/pom.xml
> M xwiki-commons-tools/xwiki-commons-tool-xar-handlers/pom.xml
> M xwiki-commons-tools/xwiki-commons-tool-xar-plugin/pom.xml
>
> Log Message:
> -----------
> [release] Moving trunk to 3.2-SNAPSHOT
>
>
> _______________________________________________
> notifications mailing list
> notifications(a)xwiki.org
> http://lists.xwiki.org/mailman/listinfo/notifications