Hi,
One user spammed our jira yesterday (user name: "marie"). I've
removed the spam comments she left and removed the user from JIRA.
-Vincent
___________________________________________________________________________
Yahoo! Mail r�invente le mail ! D�couvrez le nouveau Yahoo! Mail et son interface r�volutionnaire.
http://fr.mail.yahoo.com
Hi Sergiu,
Ludovic has noticed several important issues with beta 3. Apparently
this is cause by a modification you made, see http://
svn.forge.objectweb.org/cgi-bin/viewcvs.cgi/xwiki/xwiki/trunk/core/
src/main/java/com/xpn/xwiki/XWiki.java?r2=1946&r1=1944&rev=1946
Apparently there are some data loss happening, some strange stuff
with history, some panels do not work anymore (the Add Object panel
doesn't work for example).
Ludovic is suggesting we rollback this change.
WDYT?
Thanks
-Vincent
PS: I'm holding of the release till this is resolved.
___________________________________________________________________________
Yahoo! Mail r�invente le mail ! D�couvrez le nouveau Yahoo! Mail et son interface r�volutionnaire.
http://fr.mail.yahoo.com
On Nov 15, 2006, at 1:05 PM, Ludovic Dubost wrote:
>
> Great.. this is what we need.. Can we have this on xwiki.org ?
Done: http://www.xwiki.org/xwiki/bin/view/Community/DevelopmentProcess
-Vincent
>
> Ludovic
>
> Vincent Massol a écrit :
> > Hi XWiki committers,
> >
> > I'd like to suggest one good practice when developing with JIRA:
> whenever
> > someone commits something to SVN he/she has to put the reference
> to the JIRA
> > issue # in the commit message. Of course this shouldn't be done
> for any
> > trivial things like adding a small javadoc, renaming a single
> variable,
> > cosmetic changes, svn ignore, etc.
> >
> > The strategy goes like this:
> >
> > * When you plan to work on something, create a jira issue and
> assign it to
> > yourself
> > * Implement it
> > * Commit it with the jira issue #
> > * Close the jira issue
> >
> > Another acceptable variation is:
> >
> > * Implement something
> > * When you want to commit it you realize you don't have any jira
> issue to
> > put in the commit message so don't commit
> > * Create the jira issue
> > * Commit
> >
> > The rationale behind this:
> >
> > * One consistent way to manage our work (this is different from
> now where
> > sometimes it's in jira and sometimes it's not). It also means
> there's no
> > unaccounted work, meaning I can go to jira and query it and I'll
> see what
> > everyone has been working on.
> > * Automated release notes/change logs. When we release a version
> we can
> > simply do a jira extract and it'll give the full change log of what
> > happened. This is really important for our users to see what has
> been done
> > when in XWiki.
> > * Tracability. When you use the jira issue # in your commit, the
> jira
> > subversion plugin can show the modified files directly from jira.
> This is
> > quite useful later on, when someone is looking at a jira issue
> and wants to
> > see what was modified. In addition fisheye is also integrated
> with jira and
> > when you browse the source repository you can see the jira issue
> associated
> > with files.
> >
> > I'm proposing that we adopt this practice in XWiki.
> >
> > WDYT?
> >
> > Thanks
> > -Vincent
> >
> > PS: Some time back I blogged about 6 jira issue smells. This was
> one of
> > them. Here's the link: http://tinyurl.com/yzv4bf
>
Hi,
The com.xpn.xwiki.store.XWikiRCSFileStore file doesn't seem to exist
anymore. I can see it's referenced in comment in xwiki.cfg files and
in a StoreObjectRCSFileTest class. Can I remove them?
I'm also curious to know why we have removed it?
Thanks
-Vincent
PS: I wish we had fisheye working, I could have done a quick search
to get the full knowledge about this... Unfortunately OW's SVN
implementation is very old and they're not allowing us to query it
from fisheye as it seems it's making the svn server fail!!
___________________________________________________________________________
D�couvrez une nouvelle fa�on d'obtenir des r�ponses � toutes vos questions !
Profitez des connaissances, des opinions et des exp�riences des internautes sur Yahoo! Questions/R�ponses
http://fr.answers.yahoo.com
On Nov 15, 2006, at 12:48 PM, Ludovic Dubost wrote:
>
> It's not sure that we will find exactly in which version they have
> been
> fixed.
> If we are working on the head, is the policy to mark it fix for the
> upcoming release ?
The policy is to fill the "fix for" either:
* When you're planning to fix an issue for a given release. If it
happens that it's not fixed for that release then the fix for must be
updated at the time of the release
* When you're closing an issue
In any case there should never be any issue closed without a "fix
for" filled.
> in this case what happens if the upcoming release
> never comes out or does not have the version number that we thought
I'm not sure what you mean. Imagine that we define a version named
1.1 planned for a given date. Now imagine that we decide not to
release this version and instead to name it 1.0.9. Then in JIRA we'll
rename 1.1 in 1.0.9 and all issues will then have a fix for for 1.0.9.
I'm probably not understanding something here :-)
Thanks
-Vincent
> Maybe we need to define our versioning policy
>
> Ludovic
>
> Vincent Massol a écrit :
> > Hi developers,
> >
> > I've noticed that there are 43 issues which are resolved or
> closed and which
> > do not have a "fix for" value. This means that these issues are
> not going to
> > be associated with a XWiki version which also means that they are
> > unaccounted for and that users cannot know in which version they
> have been
> > fixed.
> >
> > I think it would be good if everyone had a look and added a "fix
> for" value
> > for the issues they have fixed.
> >
> > WDYT?
> >
> > Note: With the default jira workflow it's not possible to edit an
> issue that
> > has been closed so you'll have to reopen it and close it again.
> If you want
> > I can also modify the workflow to allow editing an issue that's
> been closed.
> > Let me know.
> >
> > Thanks
> > -Vincent
>
Hi,
I'd like to know if I can remove the wysiwyg directory in xwiki-sandbox?
It seems to me this is now part of the core.
Let me know
Thanks
-Vincent
___________________________________________________________________________
D�couvrez une nouvelle fa�on d'obtenir des r�ponses � toutes vos questions !
Profitez des connaissances, des opinions et des exp�riences des internautes sur Yahoo! Questions/R�ponses
http://fr.answers.yahoo.com
This proposal is fully accepted. Here are the results:
- jeremi: +1
- jean-vincent: +1
- ludovic: +1
- sergiu: +1
- vincent: +1
Some have not voted :-(
- nam
- marta
- amelentev
- jkraemer
- tepich
- slauriere
- moghrabi
- wr0ngway
- torcq
- rewbs
- sgaide
I wonder if these persons shouldn't have been contributors rather
than committers... :-)
I am now modifying the permissions accordingly in ObjectWeb.
Thanks
-Vincent
On Jan 4, 2007, at 1:47 PM, Vincent Massol wrote:
> Hi,
>
> Following our recently accepted definition of Committers/Emeritus
> Committers (see http://www.xwiki.org/xwiki/bin/view/Community/
> Committership) and the email entitled "[Important] Definition of
> Committers and their roles and responsibilities" I sent on the
> 28/12/2006, I have now reviewed the SVN logs to see who have been
> active committers for the past year.
>
> I've put some statistics on http://www.xwiki.org/xwiki/bin/download/
> Community/HallOfFame/xwiki-mpy-svn-stats-20070102.zip/xwiki-mpy-svn-
> stats/index.html. I've also used another tool to generate more
> information and to find out who's not been active for more than 1
> year. Note that other stats can be seen here too: http://ohloh.net/
> projects/68
>
> As a reminder the goals for this are:
> * Get more active committers and more participations
> * Establish rules for defining what a Committer is
> * Get more transparent to the community by establishing rules and
> thus have clear rules for accepting new committers
> * Be fair to everyone
>
> I have noticed that there are 3 areas of Committers in XWiki:
> - Core Committers: Committers working on XWiki Core (i.e. the main
> XWiki distribution)
> - Committers working on applications built on top of XWiki (for
> example Curriki). Of course Core committers can also be Application
> Committers
> - Research Project Committers: We've had a few of them for the
> Google Summer of Code for example and we have some new ones joining
> us to continue the work on the P2P project.
>
> Note that non Core Committers cannot commit to the Core. They need
> to send patches as other contributors.
>
> Core Committers
> ---------------
>
> Thus I'd like to propose to confirm the following persons as Core
> Committers (who have been active during the past 1 year):
>
> - ludovic - Ludovic Dubost
> - vmassol - Vincent Massol
> - sdumitriu - Sergiu Dumitriu
> - jeremi - Jeremi Joslin
> - namphunghai - Phung Hai Nam
> - marta_girdea - Marta Girdea
> - jvdrean - Jean-Vincent Drean
> - amelentev - Artem Melentev
> - jkraemer - Jens Krämer
> - tepich - Jiri Luzny
> - wr0ngway - Matthew Conway
> - slauriere - Stéphane Laurière
> - torcq - Cédric Torcq
> - moghrabi - Xavier MOGHRABI
> - rewbs - Robin Fernandes
> - sgaide (just 1 year) - Sébastien Gaïde - Sebastien has expressed
> the desire to contribute an installer to XWiki. Thus even though
> he's not committed for just a year I'm proposing to keep him as an
> active committer
>
> Of course anyone on this list can decide to be moved to the
> Emeritus Committer status if he/she wants.
>
> Curriki Committers
> ------------------
>
> - jeremi - Jeremi Joslin
> - ludovic - Ludovic Dubost
>
> Research Project Committers
> ---------------------------
>
> - thimel - Arnaud Thimel
> - chrabiehroy - Roy Chrabbieh
>
> Emeritus Committers
> -------------------
>
> And I propose to move the following as Emeritus Committers:
>
> - kevingc - Kevin Chiu
> - hasseeb - Abdul Haseeb
> - kaaloo (just 1 year) - Luis Arias
> - bikash - bikash agarwalla
> - thomas (just 1 year) - thomas doucedame
> - akartmann - Alexis KARTMANN
> - erwan (just 1 year) - Erwan Arzur
> - ptcoder - Pedro Ornelas
> - tim - Timothée Peignier
> - davidbrady - David Brady
> - alberto - Alberto Saavedra
> - mpetrashev - Maxim Petrashev
> - huyennt - Nguyen Thanh Huyen
> - chungnv - Nguyen Viet Chung
> - arjunan - Arjunan
> - mileticn - Nebojsa Miletic
>
> In addition the following ids have never committed and will thus
> not be Committers (they were added as developers on http://
> forge.objectweb.org/project/memberlist.php?group_id=170). If they
> need to commit they'll have to be voted in:
>
> - alis - Ali Sakebi
> - cburleso - Cody Burleson
> - denis - Denis Hovart
> - dgrizzanti - David Grizzanti
> - ebilange - Eric Bilange
> - gflandre - Guillaume Flandre
> - glaforge - Guillaume Laforge
> - jdelaulanie - jean de laulanie
> - ldesmarets - laurent desmarets
> - leonardosouza - Leonardo Souza
> - Mahefasoa - NY HERIARIVONY
> - mjobert - Matthieu Jobert
> - mno - Max Nokhrin
> - nicka - Nick Astete
> - nthomas - Nicolas Thomas
> - poussin - Benjamin POUSSIN
> - raffaello - Raffaello PELAGALLI
> - ramihery - ramihajamalala hery
> - tuan08 - Tuan Nguyen
> - yunz - Yun Zhu
>
> Of course this is just a proposal and anyone listed here who do not
> agree, please contact me directly. It's very much possible I've
> made a mistake.
>
> I'll allow for 1 week to ensure everyone has a chance to see this
> mail.
>
> Thanks
> -Vincent
>
>
On Mar 9, 2007, at 11:36 PM, Kai Londenberg wrote:
> Hi ..
>
> Vincent Massol wrote:
> > I think we need to say explicitely what browsers we're supporting on
> > wiki.org and then make sure we test with all those browsers when
> we make any
> > change.
> >
> > So what's the list of browsers we want to support?
> >
> > I think the minimal list is:
> > * IE6
> > * FF 1.5
> > * FF 2.0
> >
> > Do we want to officially support more? (with the available
> > committers/contributors we have of course - Otherwise we could
> support all
> > the browsers on earth :-)).
> >
> >
> Don't forget IE7 - judging from logfiles I had access to, almost
> 50% of
> the IE6 users have already switched (due to the autoupdate).
>
Right, this is a good point (autoupdate). Right now we're not really
supporting IE7 yet but we definitely need to add it.
> Supporting IE 7 should be easy, though - except that some IE Tweaks
> (don't know if you use any) should check for IE <=6 instead of just
> IE.
Apparently nothing is easy when it comes to browsers and especially
IE... :-) We already have some JIRA issues for stuff that need fixing
in IE7. Please also open new issues if you find anything not working
in IE7.
So do we all agree that our minimal list of browsers we're supporting
is:
* IE6
* IE7
* FF 1.5
* FF 2.0
If so I'll add some note on the web site (I'll add the JDK 1.5
requirements too at the same time - I'll create a prerequisites
section). It also means that when we add some new feature or fix
something we need to test it with all these browsers!
Thanks
-Vincent
Hi,
Objectweb is becoming OW2.
we need to tranfert the informations to this new site.
jeremi
---------- Forwarded message ----------
From: Cedric Thomas <cedric.thomas(a)objectweb.org>
Date: Jan 17, 2007 2:05 PM
Subject: [community] Joining OW2 Consortium
To: community(a)objectweb.org
Dear All,
Welcome to OW2! As you know, your Consortium became OW2 on January 1,
2007, following merger with Orientware.
The OW2 Consortium is a brand new organization: new governance, new
bylaws, new membership categories, new Intellectual Property policy, etc.
Therefore, as former ObjectWeb and Orientware members please note that
membership is not automatically transferred from either ObjectWeb or
Orientware to OW2.
I am writing to you to remind you that, whether you are an organization
or an individual, you must complete a registration process.
First, please go to www.ow2.org, download and read the Consortium Bylaws,
its Intellectual Property Rights Policy and its Membership Agreement.
Then it is imperative you proceed through the OW2 Online Registration
process:
1) Former ObjectWeb members
Former ObjectWeb members may transfer their information to OW2 by login
in at: http://myow2.objectweb.org/viewProfile.php. From there, you can
validate or update the information we already have on yourself or your
organization.
2) New members
New members must complete the Online Registration process at
http://joining.objectweb.org/registration.html
Please note that the Online Registration process will automatically
generate a completed Membership Agreement in .pdf format. All you need to
do is print it and send two copies (of which one will be returned to you)
of the signed original Membership Agreement to:
OW2 Consortium
Avenue du Port, 86C
1000 Bruxelles
Belgium
As membership fees are concerned, Purchasing Power Parity (PPP) rules as
defined by the World Bank will be taken into account for developing
countries. Please do not hesitate to contact me directly should you feel
the PPP is applicable to your membership.
With the Management Office, I look forward to working with you on making
OW2 the leading open source middleware consortium it deserves to be.
Best regards,
Cedric Thomas
OWC Consortium CEO
cedric.thomas AT objectweb.org
--
jeremi
Hi,
what do you think about excluding the XWiki space from the rss feed?
Because users don't care about the modification of the configuration
of the wiki or the new accounts, they only care about the content
modifications.
jeremi
Hi,
I've created a class and added a couple of properties to it via the class
editor (a string and a text area). When I try to add a User list (from the
drop down menu) the following exception occurs:
Error number 0 in 11: Uncaught exception
Wrapped Exception: com.xpn.xwiki.objects.meta.UsersMetaClass
incompatible with com.xpn.xwiki.objects.classes.PropertyClass
com.xpn.xwiki.XWikiException: Error number 0 in 11: Uncaught exception
Wrapped Exception: com.xpn.xwiki.objects.meta.UsersMetaClass
incompatible with com.xpn.xwiki.objects.classes.PropertyClass
at com.xpn.xwiki.web.XWikiAction.execute(XWikiAction.java:159)
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.doPost(ActionServlet.java:432)
at javax.servlet.http.HttpServlet.service(HttpServlet.java:615)
at javax.servlet.http.HttpServlet.service(HttpServlet.java:688)
at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:252)
at org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:173)
at com.xpn.xwiki.web.SetCharacterEncodingFilter.doFilter(SetCharacterEncodingFilter.java:121)
at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:202)
at org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:173)
at org.apache.catalina.core.StandardWrapperValve.invoke(StandardWrapperValve.java:213)
at org.apache.catalina.core.StandardContextValve.invoke(StandardContextValve.java:178)
at org.apache.geronimo.tomcat.valve.DefaultSubjectValve.invoke(DefaultSubjectValve.java:46)
at org.apache.geronimo.tomcat.GeronimoStandardContext$SystemMethodValve.invoke(GeronimoStandardContext.java:342)
at org.apache.geronimo.tomcat.valve.GeronimoBeforeAfterValve.invoke(GeronimoBeforeAfterValve.java:31)
at org.apache.catalina.core.StandardHostValve.invoke(StandardHostValve.java:126)
at org.apache.catalina.valves.ErrorReportValve.invoke(ErrorReportValve.java:105)
at org.apache.catalina.core.StandardEngineValve.invoke(StandardEngineValve.java:107)
at org.apache.catalina.valves.AccessLogValve.invoke(AccessLogValve.java:541)
at org.apache.catalina.authenticator.SingleSignOn.invoke(SingleSignOn.java:392)
at org.apache.catalina.connector.CoyoteAdapter.service(CoyoteAdapter.java:148)
at org.apache.coyote.http11.Http11Processor.process(Http11Processor.java:869)
at org.apache.coyote.http11.Http11BaseProtocol$Http11ConnectionHandler.processConnection(Http11BaseProtocol.java:667)
at org.apache.tomcat.util.net.PoolTcpEndpoint.processSocket(PoolTcpEndpoint.java:527)
at org.apache.tomcat.util.net.LeaderFollowerWorkerThread.runIt(LeaderFollowerWorkerThread.java:80)
at org.apache.tomcat.util.threads.ThreadPool$ControlRunnable.run(ThreadPool.java:869)
at java.lang.Thread.run(Thread.java:799)
Wrapped Exception:
java.lang.ClassCastException:
com.xpn.xwiki.objects.meta.UsersMetaClass incompatible with
com.xpn.xwiki.objects.classes.PropertyClass
at com.xpn.xwiki.web.PropAddAction.action(PropAddAction.java:59)
at com.xpn.xwiki.web.XWikiAction.execute(XWikiAction.java:143)
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.doPost(ActionServlet.java:432)
at javax.servlet.http.HttpServlet.service(HttpServlet.java:615)
at javax.servlet.http.HttpServlet.service(HttpServlet.java:688)
at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:252)
at org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:173)
at com.xpn.xwiki.web.SetCharacterEncodingFilter.doFilter(SetCharacterEncodingFilter.java:121)
at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:202)
at org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:173)
at org.apache.catalina.core.StandardWrapperValve.invoke(StandardWrapperValve.java:213)
at org.apache.catalina.core.StandardContextValve.invoke(StandardContextValve.java:178)
at org.apache.geronimo.tomcat.valve.DefaultSubjectValve.invoke(DefaultSubjectValve.java:46)
at org.apache.geronimo.tomcat.GeronimoStandardContext$SystemMethodValve.invoke(GeronimoStandardContext.java:342)
at org.apache.geronimo.tomcat.valve.GeronimoBeforeAfterValve.invoke(GeronimoBeforeAfterValve.java:31)
at org.apache.catalina.core.StandardHostValve.invoke(StandardHostValve.java:126)
at org.apache.catalina.valves.ErrorReportValve.invoke(ErrorReportValve.java:105)
at org.apache.catalina.core.StandardEngineValve.invoke(StandardEngineValve.java:107)
at org.apache.catalina.valves.AccessLogValve.invoke(AccessLogValve.java:541)
at org.apache.catalina.authenticator.SingleSignOn.invoke(SingleSignOn.java:392)
at org.apache.catalina.connector.CoyoteAdapter.service(CoyoteAdapter.java:148)
at org.apache.coyote.http11.Http11Processor.process(Http11Processor.java:869)
at org.apache.coyote.http11.Http11BaseProtocol$Http11ConnectionHandler.processConnection(Http11BaseProtocol.java:667)
at org.apache.tomcat.util.net.PoolTcpEndpoint.processSocket(PoolTcpEndpoint.java:527)
at org.apache.tomcat.util.net.LeaderFollowerWorkerThread.runIt(LeaderFollowerWorkerThread.java:80)
at org.apache.tomcat.util.threads.ThreadPool$ControlRunnable.run(ThreadPool.java:869)
at java.lang.Thread.run(Thread.java:799)
It looks to me as if UsersMetaClass.newObject(ctx) should return an instance
of UsersClass (this is what StringMetaClass does for example). It also looks
like GroupMetaClass does the same....
Incidently, is there a way to remove an unwanted property from the class ?
During my experiment I added a DBListClass (to test this) but can't see how
to remove it.
Cheers,
Dan
PS. Top job on getting b2 out :)
Hi all,
I think XWiki is picking up the wrong database name for XMLRPC
requests (see http://jira.xwiki.org/jira/browse/XWIKI-738 ). I'd like
to fix this, but can't establish how to get the correct database name
in the code.
Elsewhere, it is either obtained from an XWikiContext or XWiki object
(which are not available in the RpcHandler), or it is hardcoded to
"xwiki". This feels wrong since it could be set by the user in
hibernate.cfg.xml. What's the correct approach? :)
Cheers,
Robin.
On 11/01/07, Robin Fernandes <rewbs.soal(a)gmail.com> wrote:
> Hi all,
>
> Has XMLRPC been disabled on xwiki.com?
>
> I used to access
> http://openmpt.xwiki.com/xwiki/bin/xmlrpc/confluence
> but that has gone away
>
> Looking at the XMLRPC tests in the code, it seems the RPC url has
> moved to http://<server>/xwiki/xmlrpc, but accessing
> http://openmpt.xwiki.com/xwiki/xmlrpc results in:
>
> Exception in thread "main" org.apache.xmlrpc.XmlRpcException: Failed
> to invoke method login in class
> com.xpn.xwiki.xmlrpc.ConfluenceRpcHandler: Error number 2 in 0: The
> wiki openmpt does not exist
> at org.apache.xmlrpc.XmlRpcClient$Worker.execute(Unknown Source)
> at org.apache.xmlrpc.XmlRpcClient.execute(Unknown Source)
> [...]
>
> Any ideas?
>
>
> By the way, I also tried XMLRPC on a local copy from svn trunk and
> couldn't get it to work. I haven't done much debugging yet, so it
> could be an env problem on my side. But here's the error in case
> someone has seen it before:
>
> Exception in thread "main" org.apache.xmlrpc.XmlRpcException: Failed
> to instantiate class com.xpn.xwiki.xmlrpc.ConfluenceRpcHandler
> at org.apache.xmlrpc.XmlRpcClient$Worker.execute(Unknown Source)
> at org.apache.xmlrpc.XmlRpcClient.execute(Unknown Source)
> [...]
>
> Regards,
> Robin
>
Hello,
I have problems integrating xwiki in exo platform.
I'm not sure if this is the right list to ask, but had to pick one,
please tell me if I chose wrong.
So, here is the context : I'm using eXo sources dated 20070108 and xwiki
1.0 Beta 2.
xwiki.war is placed in webapps, xwiki.conf has been modified to set exo
usage.
portlet.xml seems ok, web.xml has been modified to add the
portlet/servlet wrapper.
I modified wxiki context from / to /xwiki.
With all this, xwiki portlet appears in eXo import portlet.
The database has been loaded from the script 1.0-beta1, in a database
named xwiki, accessible with user xwiki/pass xwiki.
When I try to prompt xwiki in eXo, I have a "You are not allowed to ...
message, end hidden by black squares".
I'm connected with exoadmin. Just to be sure, i logged to xwiki
(standalone) and created a exoadmin user.
But I still get this kind of errors : "[INFO] XWikiRightServiceImpl -
Access has been denied for (xwiki:XWiki.exoadmin,Main.WebHome,view):
access manager denied right" along many stack traces about documents
that could'nt be instanciated because no row with id xyz found in database.
Looks like a bad filled database to me.
What did I do wrong ?
Any thing I didn't do ?
What do I have to do ?
Sincerely yours,
Nicolas Pays.
Call for Participation
======================
Research Room @ FOSDEM: Libre software as a matter of research
E pur si muove (And yet it moves)
http://libresoft.urjc.es/Activities/fosdem2007
Joint workshop on "libre software research meets libre software
developers", sponsored by the QUALOSS, SQO-OSS, QUALIPSO, FLOSSMETRICS
FLOSSWorld and EDOS EU-funded projects
The workshop will take place in the Research Room in the next FOSDEM, to
be held on Brussels next February 24th and 25th 2007.
Libre (free, open source) software development has been gaining
attention from the research community during the last years. Currently,
many research groups are focused on understanding, and trying to
improve, the practices, procedures and products of the libre software
development community. This research is starting to produce a new view
on many aspects of the classical software engineering paradigms. In
fact, if the lessons shown in most classical software engineering texts
were applied to almost any libre software development project, it should
be concluded that it was headed to failure. And yet it moves... Libre
software is showing a new way of organizing software development
projects, in forms that make success possible under circumstances
previously thought to be unmanageable.
In this context, the relationship between research groups focused on
understanding libre software, and software development groups actually
producing libre software, can be of great interest for both parties.
FOSDEM, probably the largest meeting point for libre software developers
in Europe, provides an opportunity for this contact and exchange of
ideas. The idea of the Research Room at FOSDEM is to explore the
opportunities of this exchange, and what happens when developers and
researchers are put together in the same (physical) space.
Therefore, we're asking for contributions both from researchers and
developers, on the following topics (the list is not exhaustive):
* What developers feel could be useful from research on libre software
* Feedback from the developer community to researchers
* Experiences of developers and researchers working together
* Results of applying research methodologies and analysis to libre
software projects
* Results (including expected results) of research projects studying
libre software
* What can the research community offer to libre software development
* Methodologies and techniques that could be used to address specific
problems in libre software development
Although academic presentations are welcome, other, more informal (and
maybe provocative) contributions are also encouraged. The main target is
to have a good collection of ideas and experiences to foster discussion
and interaction.
Those interested in contributing are invited to submit a short paper in
PDF format, summarizing the intended contents of the presentation
(probably two or three pages are enough, but no paper will be rejected
for being too long). It should provide enough information to let the
organizing committee decide on its appropriateness for the workshop, and
the potential interest for participants.
* Deadline for submissions: January 22rd 2007
* Notification of acceptance: January 31st 2007
* Workshop dates: February 24th (afternoon) and 25th (morning) 2007
Submissions should be sent to all three addresses below, by the deadline:
* Jesus M. Gonzalez-Barahona - jgb at gsyc.escet.urjc.es
* Israel Herraiz - herraiz at gsyc.escet.urjc.es
* Gregorio Robles - grex at gsyc.escet.urjc.es
Accepted papers will be published on-line, after letting authors provide
more complete versions, if they want.
Organizing committee (alphabetical order, tentative list)]:
* Ioannis Antoniades (Aristotle University of Thessaloniki, Greece)
* Adriaan de Groot (KDE)
* Jean-Christophe Deprez (CETIC, Belgium)
* Roberto Di Cosmo (University of Paris VII, France)
* Rishab Ghosh (MERIT, Nederlands)
* Jesus M. Gonzalez-Barahona (Universidad Rey Juan Carlos, Spain)
* Israel Herraiz (Universidad Rey Juan Carlos, Spain)
* Stefan Koch (Vienna University of Economics and Business
Administration, Austria)
* Sebastian Kugler (KDE)
* Stéphane Laurière (Mandriva, France)
* Martin Michlmayr (University of Cambridge, UK)
* Gregorio Robles (Universidad Rey Juan Carlos, Spain)
* Diomidis Spinellis (Athens University of Economics and Business, Greece)
* Ioannis Stamelos (Aristotle University of Thessaloniki, Greece)
The Research Room at FOSDEM is sponsored by the following projects
(although the meeting is completely open to anyone interested):
* FLOSSMETRICS
* QUALOSS
* SQO-OSS
* QUALIPSO
* FLOSSWORLD
* EDOS
All these projects are funded in part by the European Commission, under
the Information Society Technologies (IST) research programme of the
Sixth Framework Program. A list of the IST projects in the area of
Software Technologies is available from
http://cordis.europa.eu/ist/st/projects.htm
--
Stéphane Laurière
Email: slauriere(a)mandriva.com
Mandriva Research
http://www.mandriva.comhttp://nepomuk.semanticdesktop.orghttp://www.edos-project.org
Hi,
I'm in the process of finishing an XWiki Google Web Toolkit API
(server-side and client-side).
I'd like to commit that one in the core including the Java code that is
compiled to Javascript. There is common code for both.
Curriki will also rely on this API.
It is not necessary that the build system compiles the code to
Javascript for the moment, however it is needed to compile the server code.
Currently I suggest commiting the code in:
web/standard/src/main/java/api
or
web/standard/src/main/java/com.xpn.xwiki.gwt.api
I also have a Google Web Toolkit client for the FeedPlugin. It's a very
cool RSS Aggregator interface.
It's only client side code. I'm not sure if it should be commit in the core.
If it is it would be in
web/standard/src/main/java/rssreader
or
web/standard/src/main/java/com.xpn.xwiki.gwt.reader
Can we vote for these 2 things:
- commit the API
- commit the RSS Reader
Ludovic
--
Ludovic Dubost
Blog: http://www.ludovic.org/blog/
XWiki: http://www.xwiki.com
Skype: ldubost GTalk: ldubost
AIM: nvludo Yahoo: ludovic
Indeed, Java 1.6 introduces some changes in the API. I tried to fix these
errors, but at the first glance the API is incompatible with Java 1.4 (or I
don't know that much Java 1.6). This will have to be fixed soon, as some
systems (such as Gentoo) introduced J1.6 in the default system installation.
On 12/24/06, Ludovic Dubost <ludovic(a)xwiki.com> wrote:
>
>
> It's the right repository.
> Clearly createStruct is a JavaSE 6 function which includes JDBC 3.0. You
> must have some jdbc 3 library somewhere if this also happens with jdk 1.5
>
> Ludovic
>
> Marc Lijour a écrit :
> > According to the ant file that should not matter as it targets the 1.4
> > platform:
> >
> > <target name="xwiki" depends="clover-yes, clover-no, xwiki.nonjava">
> > <javac srcdir="${core.java.main.src.dir}"
> > destdir="${classes.dir}"
> > classpath="${libs}"
> > debug="on" optimize="on" deprecation="on"
> > compiler="${compiler}" source="1.4"
> > sourcepath=""
> > encoding="ISO-8859-1"/>
> > </target>
> >
> > I tried with 1.5 and 32/64 bit versions of the jdk (>=1.5) and I get
> exactly
> > the same error.
> >
> > Is this the right repository? It looks like it because you committed to
> it
> > yesterday. But just in case:
> >
> > $ svn info
> > Path: .
> > URL: svn://svn.forge.objectweb.org/svnroot/xwiki/xwiki/trunk
> > Repository Root: svn://svn.forge.objectweb.org/svnroot/xwiki
> > Repository UUID: f329d543-caf0-0310-9063-dda96c69346f
> > Revision: 1800
> > Node Kind: directory
> > Schedule: normal
> > Last Changed Author: ludovic
> > Last Changed Rev: 1800
> > Last Changed Date: 2006-12-22 18:52:06 -0500 (Fri, 22 Dec 2006)
> > Properties Last Updated: 2006-12-22 17:39:52 -0500 (Fri, 22 Dec 2006)
> >
> >
> > On Sunday 24 December 2006 07:56, Ludovic Dubost wrote:
> >
> >> I don't think anybody has tried 1.6 on xwiki
> >> Probably some news api's in 1.6 JDBC.
> >>
> >> Ludovic
> >>
> >> Marc Lijour a écrit :
> >>
> >>> I should have mentioned it.
> >>> It is actually the latest.
> >>>
> >>> $ java -version
> >>> java version "1.6.0"
> >>> Java(TM) SE Runtime Environment (build 1.6.0-b105)
> >>> Java HotSpot(TM) 64-Bit Server VM (build 1.6.0-b105, mixed mode)
> >>>
> >>> On Saturday 23 December 2006 10:02, Ludovic Dubost wrote:
> >>>
> >>>> Hi,
> >>>>
> >>>> I think you are having a JDBC version problem. Maybe you are
> compiling
> >>>> with an older java
> >>>>
> >>>> Ludovic
> >>>>
> >>>> Marc Lijour a écrit :
> >>>>
> >>>>> Hi
> >>>>>
> >>>>> I try to compile from the latest svn image. It does not compile at
> >>>>> target xwiki. Have you some idea why?
> >>>>>
> >>>>> Buildfile: build.xml
> >>>>>
> >>>>> prepare:
> >>>>> [propertyfile] Updating property
> >>>>> file:
> >>>>>
> /home/samba/devel/xwiki/web/standard/src/main/webapp/WEB-INF/version.pr
> >>>>> op erties
> >>>>>
> >>>>> clover-yes:
> >>>>>
> >>>>> clover-no:
> >>>>>
> >>>>> xwiki.nonjava:
> >>>>> [copy] Copying 1 file to /home/samba/devel/xwiki/build/web
> >>>>>
> >>>>> xwiki:
> >>>>> (...)
> >>>>>
> >>>>> [javac]
> >>>>>
> /home/samba/devel/xwiki/core/src/main/java/com/xpn/xwiki/store/XWikiJDB
> >>>>> CC onnection.java:34: com.xpn.xwiki.store.XWikiJDBCConnection is not
> >>>>> abstract and does not override abstract method
> >>>>> createStruct(java.lang.String,java.lang.Object[]) in
> >>>>> java.sql.Connection [javac] public class XWikiJDBCConnection
> implements
> >>>>> Connection { [javac] ^
> >>>>> (...)
> >>>>> [javac] 1 error
> >>>>> [javac] 37 warnings
> >>>>>
> >>>>>
> >>>>>
> >>>>>
> -----------------------------------------------------------------------
> >>>>> -
> >>>>>
> >>>>>
> >>>>> --
> >>>>> You receive this message as a subscriber of the
> xwiki-dev(a)objectweb.org
> >>>>> mailing list. To unsubscribe:
> >>>>> mailto:xwiki-dev-unsubscribe@objectweb.org For general help:
> >>>>> mailto:sympa@objectweb.org?subject=help
> >>>>> ObjectWeb mailing lists service home page:
> http://www.objectweb.org/wws
> >>>>>
> >>>
> ------------------------------------------------------------------------
> >>>
> >>>
> >>> --
> >>> You receive this message as a subscriber of the
> xwiki-dev(a)objectweb.org
> >>> mailing list. To unsubscribe: mailto:
> xwiki-dev-unsubscribe(a)objectweb.org
> >>> For general help: mailto:sympa@objectweb.org?subject=help
> >>> ObjectWeb mailing lists service home page:
> http://www.objectweb.org/wws
> >>>
> >
> >
> > ------------------------------------------------------------------------
> >
> >
> > --
> > You receive this message as a subscriber of the xwiki-dev(a)objectweb.orgmailing list.
> > To unsubscribe: mailto:xwiki-dev-unsubscribe@objectweb.org
> > For general help: mailto:sympa@objectweb.org?subject=help
> > ObjectWeb mailing lists service home page: http://www.objectweb.org/wws
> >
>
>
> --
> Ludovic Dubost
> Blog: http://www.ludovic.org/blog/
> XWiki: http://www.xwiki.com
> Skype: ldubost GTalk: ldubost
> AIM: nvludo Yahoo: ludovic
>
>
>
>
>
> --
> You receive this message as a subscriber of the xwiki-dev(a)objectweb.orgmailing list.
> To unsubscribe: mailto:xwiki-dev-unsubscribe@objectweb.org
> For general help: mailto:sympa@objectweb.org?subject=help
> ObjectWeb mailing lists service home page: http://www.objectweb.org/wws
>
>
>
Hi,
I think we need to say explicitely what browsers we're supporting on
wiki.org and then make sure we test with all those browsers when we make any
change.
So what's the list of browsers we want to support?
I think the minimal list is:
* IE6
* FF 1.5
* FF 2.0
Do we want to officially support more? (with the available
committers/contributors we have of course - Otherwise we could support all
the browsers on earth :-)).
Note: this doesn't mean it won't work with other browsers. It means it's not
guaranteed it'll work and shouldn't be considered a bug when it doesn't.
Thanks
-Vincent
___________________________________________________________________________
D�couvrez une nouvelle fa�on d'obtenir des r�ponses � toutes vos questions !
Profitez des connaissances, des opinions et des exp�riences des internautes sur Yahoo! Questions/R�ponses
http://fr.answers.yahoo.com
Hi everyone,
We're happy to announce the 1.0 Beta 2 release. It's mostly a bug fix
release but it also contains some new improvements such as new macros.
* Lots of bugs fixed. Most of them are bugs related to the WYSIWYG editor
and the new 1.0 skin.
* Simplified Edit menu with only a single menu entry. This is to make it
simpler for new users. It's possible to switch between Simple and Advanced
from the user profile page.
* New #info("This is some useful information"), #warning("Careful not to
break something") and #error("You did something terrible") macros.
* New #floatingbox() macro to display a floating box (aligned right by
default).
* __text__ is now the notation for underline
* Lots of other minor improvements
Full list: http://tinyurl.com/yz9ccw
Thanks and enjoy
-The XWiki Team
___________________________________________________________________________
D�couvrez une nouvelle fa�on d'obtenir des r�ponses � toutes vos questions !
Profitez des connaissances, des opinions et des exp�riences des internautes sur Yahoo! Questions/R�ponses
http://fr.answers.yahoo.com
Hi everyone,
I patched the Navigation panel in the new skin to display page titles
instead of the page name if a page title exists. If this is useful
please included it in the standard skin.
Cheers,
--
Luis Arias
http://www.xwiki.com
+33 6 14 20 87 93
skype : kaaloo
Hi,
I'm calling a code freeze on 1.0 Beta 2. This means:
* I've created a XWIKI_1_0_BETA_2 branch. All code for Beta 2 must now go
there
* No new code should be submitted for beta 2 unless:
- this code fixes a regression from b1
- this code fixes a bug introduced in b2
* Any code checked in on the beta 2 branch MUST also be merged immediately
on trunk (The beta 2 branch will be removed once we tag the Beta 2)
* People working on beta 3 must commit on trunk
The next step is for me to build beta 2 from the branch and try it out to
see if there's no glaring error. I'd like help from as many developers or
users as possible. Let me know if you're interested in helping out for
testing the beta2 release.
Thanks
-Vincent
___________________________________________________________________________
Yahoo! Mail r�invente le mail ! D�couvrez le nouveau Yahoo! Mail et son interface r�volutionnaire.
http://fr.mail.yahoo.com
I try to get into maven to build xwiki but I don't find any doc on xwiki.org.
When I checked out xwiki/trunk as a project in eclipse and I enable the maven2
plugin, it starts downloading a bunch of stuff and it complains about 2 items
(see log below). Is that normal? Did I checked out everything I need?
Is everybody using maven2 or ant or something else?
A few pointers would be nice. Thanks.
(I still wonder why it has to download stuff since everything is available in
the svn repository. Actually it would be a good idea to keep the libraries
aside, in another folder, if they have to be re-used in different places but
then why keeping them in the repository as well?)
**********************************
(...)
1/2/07 4:59:04 PM EST: [WARN] Unable to get resource from repository xwiki
(http://maven.xwiki.org)
1/2/07 4:59:05 PM EST: [WARN] Unable to get resource from repository xwiki
(http://maven.xwiki.org)
1/2/07 4:59:05 PM EST: Failed to run generate source goals /xwiki -
trunk/wikis/default/pom.xml Missing:
----------
1) com.xpn.xwiki:xwiki-build-xar-handlers:jar:1.0-SNAPSHOT
Try downloading the file manually from the project website.
Then, install it using the command:
mvn
install:install-file -DgroupId=com.xpn.xwiki -DartifactId=xwiki-build-xar-handlers
\
-Dversion=1.0-SNAPSHOT -Dpackaging=jar -Dfile=/path/to/file
Path to dependency:
1) com.xpn.xwiki:xwiki-wiki-default:xar:1.0-SNAPSHOT
2) com.xpn.xwiki:xwiki-build-xar-handlers:jar:1.0-SNAPSHOT
----------
1 required artifact is missing.
for artifact:
com.xpn.xwiki:xwiki-wiki-default:xar:1.0-SNAPSHOT
from the specified remote repositories:
central (http://repo1.maven.org/maven2),
xwiki (http://maven.xwiki.org)
*************************************
Hi,
I think we need to improve the way we update the documentation. Right now I
see several issues are marked as closed even though we haven't documented
them. Typical examples include new macros. They should be documented on
xwiki.org before we close the issue IMO. At the very least if for some good
reason we cannot do it immediately at least a new issue for documenting them
should be created at the same time so that it's not forgotten and so that
it's implemented in the future.
Nobody likes documenting stuff so my belief is that someone who does
something must do it completely, i.e. design, implement, *document* and
support.
WDYT?
Thanks
-Vincent
___________________________________________________________________________
D�couvrez une nouvelle fa�on d'obtenir des r�ponses � toutes vos questions !
Profitez des connaissances, des opinions et des exp�riences des internautes sur Yahoo! Questions/R�ponses
http://fr.answers.yahoo.com