xwiki-devs June 2011

xwiki-devs@xwiki.org

36 participants
61 discussions

[xwiki-devs] Status: Xwiki Android Client

by Chamika Weerasinghe

Hi, For now I added Wiki and Space and the Search access in xwiki-android-rest via handling JSON objects. I commited new files to repo. When I implementing access to Page resources I found that Xwiki REST sends different contents in XML and JSON For example XML content http://localhost:8080/xwiki/rest/wikis/xwiki/spaces/Blog/pages/BlogIntroduc… is different from JSON content http://localhost:8080/xwiki/rest/wikis/xwiki/spaces/Blog/pages/BlogIntroduc… Because of this difference I decided to deserialize XML instead of JSON. (I must modify all the class files for this). XWiki RESTful API doc ( http://platform.xwiki.org/xwiki/bin/view/Features/XWikiRESTfulAPI) describes XML -> Java conversion by using "org.apache.commons.httpclient". But this library seems to be larger in size. As Thomas said size does matter in Android. Therefore I decided to use "org.apache.http" which built in Android. But I got following error 06-12 20:02:55.070: WARN/dalvikvm(650): VFY: unable to resolve static method 1169: Ljavax/xml/bind/JAXBContext;.newInstance (Ljava/lang/String;)Ljavax/xml/bind/JAXBContext; Can anybody suggest me what causes this error? Best Regards, Chamika Weerasinghe

13 years, 4 months

[xwiki-devs] [VOTE] Build Manager duty

by Vincent Massol

Hi committers, We're having a hard time stabilizing our build (especially the functional test part, see my previous mail entitled "[VOTE] Important: Strategy to fix failing tests and stability"). Now I believe that it's going to be hard to enforce it and thus I'd like to propose a variation: * The Build Manager has the *responsibility* to get the build fixed ASAP whenever it's failing. His priority #1 during the week becomes monitoring the Build * By "Build" we mean the CI Build on ci.xwiki.org and by "failing" we mean anything that makes the build fail: tests, compilation, clirr, etc. * Every week we have a different Build Manager chosen amongst the Committers * In order to fix build issues the Build Manager has several possibilities: - find out who caused the build to break and ask that person to fix it. That person cannot refuse that and must consider it his/her priority to fix it (or rollback the change that caused the build to fail) - rollback the issue that caused the build to fail - fix it himself/herself - find someone knowledgable in the failing domain and get him/her to fix the build. * At the end of the Week the Build Manager hands over his duty to the next Build Manager by contacting him/her. * We create a Build Manager Roster page on dev.xwiki.org to log past Build Managers (and possibly future ones if some have expressed the wish to be the Build Manager for a specific week). * All committers must perform this duty and take turns Since I've started doing this this week, I propose to take this role for the current week. I'm also proposing to log Caleb has having been the Build Manager for the past week since he's done a lot to stabilize the build. If the vote is passed I'll log this on the Committership page as a Committer duty (I'll also cross reference it from the Build page). Here's my +1 Thanks -Vincent

13 years, 4 months

Re: [xwiki-devs] Status

by 许凌志(Jamesxu)

I am working on this project all the days following your instructions we discussed before. And the mainly work I have done are following : (1). Set up the framework for auto-suggestion, including three parts: a).The main object XWiki.editors.AutoSuggestion which is the entry for trigger auto-suggestion functions b).XWiki.editors.AutoSuggestion.Suggestor, which is only for wiki editors, and the main function is give the right suggestions according to user input in different context of triggers. The suggestor includes: XWiki.editors.AutoSuggestion.LinkSuggestor, XWiki.editors.AutoSuggestion.ImageSuggestor and XWiki.editors.AutoSuggestion.MacroSuggestor. c).XWiki.editors.autoSuggestion.SuggestionList, whic is the used for initializing the suggestion box, there are three kinds of SuggestionList: XWiki.editors.autoSuggestion.LinkSuggestionList, XWiki.editors.autoSuggestion.ImageSuggestionList, XWiki.editors.autoSuggestion.MacroSuggestionList. (2). I finished the XWiki.editors.autoSuggestion.SuggestionList and XWiki.editors.autoSuggestion.LinkSuggestionList. include the related css, it is more like a widget, can be instantiated alone, so that it can be used in Wysiwyg editors (3). Finish part of the main object : XWiki.editors.AutoSuggestion(only for testing Link SuggestionList) (4). Working on the XWiki.editors.AutoSuggestion.Suggestor and XWiki.editors.AutoSuggestion.LinkSuggestor for wiki editors. I don't commit the code because it is only part of them, and some of them can not run properly right now, In my plan, I will commit tonight maybe the in the afternoon in your time zoon. Sorry for commit late, because start is hard, I will increase the commit times, after the first commit, it will be helpful for mentors to review the code On Mon, Jun 13, 2011 at 6:03 PM, Marius Dumitru Florea < mariusdumitru.florea(a)xwiki.com> wrote: > Hi James, > > Any progress on the GSoC project? Time is passing and I haven't seen any > commit from you. Asking for feedback is very important as it gives you the > guarantee that you're going in the right direction. For instance, I don't > know what you're working on currently. > > Thanks, > Marius > -- Best wishes, 许凌志(Jame Xu) MOE KLINNS Lab and SKLMS Lab, Xi'an Jiaotong University Department of Computer Science and Technology, Xi’an Jiaotong University

13 years, 4 months

[xwiki-devs] [Follow-up] New administration section for the WYSIWYG editor

by Marius Dumitru Florea

Hi devs, Following http://lists.xwiki.org/pipermail/devs/2010-November/021012.html I made some improvements and now I have this http://incubator.myxwiki.org/xwiki/bin/view/Improvements/WysiwygEditorConfig . I'd like to include it in XE 3.0. WDYT? Thanks, Marius

13 years, 4 months

[xwiki-devs] Scalable XWiki on NoSQL (Cassandra )

by supun wickramasinghe

Hi Devs, I'm Pulasthi and currently working on the Scalable XWiki on NoSQL (Cassandra ) project with Caleb James DeLisle. i got involved with the project as a GSOC applicant but the project was not selected for GSOC. i thought of informing the devs about my progress. As the project needed to use the Todd Nines Datanucleus Cassandra plugin which was not capable of querying non indexed queries. As the first part of the project i was able to successfully add a patch[1] to this and made some changes after getting feedback from Caleb James. [1] .Datanucleus Cassandra plugin with patch - https://github.com/pulasthi/Datanucleus-Cassandra-Plugin -- Pulasthi Supun Undergraduate Dpt of Computer Science & Engineering University of Moratuwa

13 years, 4 months

[xwiki-devs] [proposal] Release on the coming Tuesday -- Also any known blockers for release?

by Caleb James DeLisle

Since there has not been much change since The last release I think we can get largely back on track. I understand Monday is a holiday for a number of people so I would like to propose releasing on Tuesday. That means we will need to start testing ASAP and I would like to know now if anybody knows of an issue which is a blocker for the 3.1 release. Thanks Caleb

13 years, 4 months

[xwiki-devs] Global solution for flickering tests (was Fwd: Re : Re: How to know if a page has been reloaded after some ajax refresh)

by Vincent Massol

Hi guys, I asked the following on the webdriver forum: https://groups.google.com/d/topic/webdriver/5WdDJsiyAzc/discussion Kristian mailed me the following below which I find interesting. WDYT? Since I'm not know a prototype expert could someone knowledgable tell me if this can be done? (I've found http://www.prototypejs.org/api/ajax/responders but not sure if it's enough for us). Thanks -Vincent Begin forwarded message: > From: krosenvold <kristian.rosenvold(a)gmail.com> > Date: June 9, 2011 8:56:20 PM GMT+02:00 > To: Vincent Massol <vmassol(a)gmail.com> > Subject: Re: Re : Re: How to know if a page has been reloaded after some ajax refresh > > I have generally solved this problem by instrumenting > the application javascript ever so slightly, by exploiting > the following known facts: > > Any immediate code executed by "onClick" handlers is > guaranteed to be finished before control is returned to > the client code. > > Most popular frameworks allow you to add a global hook > that allows you to increment a counter for every request > that is started. If you add one hook that increments on > start and one that increments on ajax request termination, > your test can basically wait for a given javascript variable > to become 0. > > The nice thing about this is that if you do fancy visuals > (sliding or fading stuff that you actually intend to click in your > tests), > you can intercept "onEffectStart" and "onEffectEnd" and > increment/decrement the same counter. > > And if you chain this properly, you can have a client-side added > "onComplete" ajax handler that starts a sliding visual effect and > the counter will be guaranteed to not reach 0 before the effect is > finished. > > So our page object base class has a waitForAllEffectsToFinish > method that we actually surround to all calls to click. Our tests > went to flaky to 100% rock solid after we did this. > > Btw, you must use a counter - this won't work well enough with > a boolean. > > Kristian > > > > >

13 years, 4 months

Re: [xwiki-devs] CAS Integration + new User creation

by js

hi macro: I also need your code,thanks! -- View this message in context: http://xwiki.475771.n2.nabble.com/CAS-Integration-new-User-creation-tp62069… Sent from the XWiki- Dev mailing list archive at Nabble.com.

13 years, 4 months

[xwiki-devs] Feature to embed XWiki in external sites

by Ludovic Dubost

Hi, I've wrote a simple embed.vm template allowing to insert and XWiki page with JSX and SSX in an external site. http://jira.xwiki.org/jira/browse/XWIKI-6696 It might require some improvements but it would be great to have it as an experimental feature in 3.1. Would they be a volunteer to commit it (i'm not yet setup in git) Ludovic -- Ludovic Dubost Founder and CEO Blog: http://blog.ludovic.org/ XWiki: http://www.xwiki.com Skype: ldubost GTalk: ldubost

13 years, 4 months

[xwiki-devs] Fwd: [VOTE] Build Manager duty

by Denis Gervalle

Hi committers, Even if I completely understand and agree with the goal pursued, I really dislike this way of solving it. It is the responsability of all of us to keep the build stable at all time. It should be the concerns of all recent committers to check if their recent commit breaks the CI, and to fix it ASAP when needed. If someone is not ready to do so in the upcomming hours following its commit, he should simply refrain to do that commit until he can follow it into the CI. I always follow these rules (even if most of the time, I commit only stuff that I have in production on my side), and I should admit that I would have commit more without them. But this is the necessary trade-off between evolutivity and stability. Having someone to enforce such rules is admitting that some of us needs another one to remind them the best practices. This is not for me the philosophy behind Open-Source project, where everyone should do their best for the wellness of the project. So I could not admit there is a real need for this, and I really hope that everyone of us will understand the needs to move their cursor towards the stability of the build. So please guys, takes your responsibility without a need for a build policeman. Sorry, but I am -1 to do the policeman (but if I need to, I will do my duty), and I vote -0, just because I do not consider myself active enough to veto. Denis On Thursday, June 9, 2011, Thomas Mortagne <thomas.mortagne(a)xwiki.com> wrote: > On Thu, Jun 9, 2011 at 09:20, Vincent Massol <vincent(a)massol.net> wrote: >> >> On Jun 9, 2011, at 9:08 AM, Thomas Mortagne wrote: >> >>> On Wed, Jun 8, 2011 at 19:40, Vincent Massol <vincent(a)massol.net> wrote: >>>> Hi committers, >>>> >>>> We're having a hard time stabilizing our build (especially the functional test part, see my previous mail entitled "[VOTE] Important: Strategy to fix failing tests and stability"). Now I believe that it's going to be hard to enforce it and thus I'd like to propose a variation: >>>> >>>> * The Build Manager has the *responsibility* to get the build fixed ASAP whenever it's failing. His priority #1 during the week becomes monitoring the Build >>>> * By "Build" we mean the CI Build on ci.xwiki.org and by "failing" we mean anything that makes the build fail: tests, compilation, clirr, etc. >>>> * Every week we have a different Build Manager chosen amongst the Committers >>> >>> A week seems a bit short but in the other hand it will seems pretty >>> long for the Build Manager itself I'm sure ;) >>> >>>> * In order to fix build issues the Build Manager has several possibilities: >>>> - find out who caused the build to break and ask that person to fix it. That person cannot refuse that and must consider it his/her priority to fix it (or rollback the change that caused the build to fail) >>>> - rollback the issue that caused the build to fail >>>> - fix it himself/herself >>>> - find someone knowledgable in the failing domain and get him/her to fix the build. >>>> * At the end of the Week the Build Manager hands over his duty to the next Build Manager by contacting him/her. >>>> * We create a Build Manager Roster page on dev.xwiki.org to log past Build Managers (and possibly future ones if some have expressed the wish to be the Build Manager for a specific week). >>>> * All committers must perform this duty and take turns >>>> >>>> Since I've started doing this this week, I propose to take this role for the current week. I'm also proposing to log Caleb has having been the Build Manager for the past week since he's done a lot to stabilize the build. >>>> >>>> If the vote is passed I'll log this on the Committership page as a Committer duty (I'll also cross reference it from the Build page). >>>> >>>> Here's my +1 >>> >>> +1 >>> >>> What don't you think about designed people who broke the build the >>> most for the following week ? >> >> An interesting idea... >> >> However: >> 1) it's hard for flickering tests to find out the culprit >> 2) it's not so much a problem of breaking the build often, it's more a problem of not fixing it immediately when broken > > Sure, my really proposal was actually "design the most painful people > for Build Manager as build manager" but I wanted to find a better > metric :) > >> >> However I agree that in the Roster we could log information for the past week about who broke the build, how many flicker fixed, etc >> >> Thanks >> -Vincent >> >> _______________________________________________ >> devs mailing list >> devs(a)xwiki.org >> http://lists.xwiki.org/mailman/listinfo/devs >> > > > > -- > Thomas Mortagne > _______________________________________________ > devs mailing list > devs(a)xwiki.org > http://lists.xwiki.org/mailman/listinfo/devs > -- Denis Gervalle SOFTEC sa - CEO eGuilde sarl - CTO

13 years, 4 months

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

2005

xwiki-devs June 2011