xwiki-devs

xwiki-devs@xwiki.org

9400 discussions

Xwiki is no longer running after my Api.getContext() change...

by Vincent Massol

Hi, Just sending an early warning that on trunk and 1.0 branch xwiki is failing to run. I'm investigating. The error I get is: 17:53:13,215 ERROR P1-18 http://localhost:8080/xwiki/bin/view/Main/ SimpleLog4JLogSystem:logVelocityMessage:143 - Method getMode threw exception for reference $context in template at [1,5] org.apache.velocity.exception.MethodInvocationException: Invocation of method 'getMode' in class com.xpn.xwiki.api.Context threw exception class java.lang.StackOverflowError : null Thanks and sorry... -Vincent ___________________________________________________________________________ Yahoo! Mail r�invente le mail ! D�couvrez le nouveau Yahoo! Mail et son interface r�volutionnaire. http://fr.mail.yahoo.com

17 years, 9 months

by Vincent Massol

On Feb 2, 2007, at 5:09 PM, Vincent Massol wrote: > Author: vmassol > Date: 2007-02-02 17:09:42 +0100 (Fri, 02 Feb 2007) > New Revision: 2031 > > Modified: > xwiki/trunk/core/pom.xml > xwiki/trunk/core/src/main/java/com/xpn/xwiki/api/Api.java > xwiki/trunk/core/src/main/java/com/xpn/xwiki/api/Attachment.java > xwiki/trunk/core/src/main/java/com/xpn/xwiki/api/Class.java > xwiki/trunk/core/src/main/java/com/xpn/xwiki/api/Collection.java > xwiki/trunk/core/src/main/java/com/xpn/xwiki/api/Context.java > xwiki/trunk/core/src/main/java/com/xpn/xwiki/api/Document.java > xwiki/trunk/core/src/main/java/com/xpn/xwiki/api/Object.java > xwiki/trunk/core/src/main/java/com/xpn/xwiki/api/Property.java > xwiki/trunk/core/src/main/java/com/xpn/xwiki/api/User.java > xwiki/trunk/core/src/main/java/com/xpn/xwiki/api/XWiki.java > xwiki/trunk/core/src/main/java/com/xpn/xwiki/plugin/calendar/ > CalendarPluginApi.java > xwiki/trunk/core/src/main/java/com/xpn/xwiki/plugin/captcha/ > CaptchaPluginApi.java > xwiki/trunk/core/src/main/java/com/xpn/xwiki/plugin/feed/ > FeedPluginApi.java > xwiki/trunk/core/src/main/java/com/xpn/xwiki/plugin/fileupload/ > FileUploadPluginApi.java > xwiki/trunk/core/src/main/java/com/xpn/xwiki/plugin/graphviz/ > GraphVizPluginApi.java > xwiki/trunk/core/src/main/java/com/xpn/xwiki/plugin/image/ > ImagePluginAPI.java > xwiki/trunk/core/src/main/java/com/xpn/xwiki/plugin/ldap/ > LDAPPluginApi.java > xwiki/trunk/core/src/main/java/com/xpn/xwiki/plugin/packaging/ > PackageAPI.java > xwiki/trunk/core/src/main/java/com/xpn/xwiki/plugin/svg/ > SVGPluginApi.java > xwiki/trunk/core/src/main/java/com/xpn/xwiki/plugin/usertools/ > XWikiUserManagementToolsAPI.java > xwiki/trunk/core/src/main/java/com/xpn/xwiki/plugin/zipexplorer/ > ZipExplorerPluginAPI.java > Log: > Fixed POM error: the version for the build verification module must > be fixed as otherwise the build looks for the wrong version (1.1- > SNAPSHOT). > hmmm... This is the wrong log message. The correct one should have been: XWIKI-808: Add Api.getContext() method Note: I haven't moved context variable from protected to private just yet as we need to take a call on that. -Vincent ___________________________________________________________________________ Yahoo! Mail r�invente le mail ! D�couvrez le nouveau Yahoo! Mail et son interface r�volutionnaire. http://fr.mail.yahoo.com

17 years, 9 months

[VOTE] Branching policy for 1.0

by Vincent Massol

Hi, Sergiu said in an email he wanted to modify the branching policy for 1.0. So I'm proposing 2 choices and let you vote about them: Option 1 (current policy): ==================== * Work on trunk till we cut the RC. At that point in time create a branch Pros: * Simple. Minimal merging from branch to trunk to do. * No risk of forgetting something (like something is on trunk but not in branch where it should be, and no risk of forgetting to merge back on trunk something from the branch) Cons: * If someone introduces a big instability, we'll need to revert it * Committers cannot commit something not working on trunk (in any case nobody should ever do that) * If a new feature is committed that impacts other features, it's possible that it won't be stable enough. This is especially true as we don't have lots of automated tests to discover regression. Note: If we had strong automated tests we would never need to create a branch (this is how I do it on the Cargo project and I've never had any issue). Option 2: ======== * Create a 1.0 branch right now. All work leading to 1.0 must go to that branch. Trunk is for work for 1.1. Pros: * People working on 1.1 can do so on trunk * Less stabilization risk issues Cons: * Requires more discipline. People must be careful to commit on the right branch/trunk. * We absolutely need to merge to trunk whenever someone commits to the 1.0 branch as otherwise merging is a big pain later on. Please cast your votes. I'm +1 for Option 2 but provided all committers agree as it's a little bit more work and more importantly requires discipline. Thanks -Vincent ___________________________________________________________________________ Yahoo! Mail r�invente le mail ! D�couvrez le nouveau Yahoo! Mail et son interface r�volutionnaire. http://fr.mail.yahoo.com

17 years, 9 months

[Lucene] Fixing the rebuildIndex API?

by Vincent Massol

Hi everyone, I can see the following API in LucenePluginAPI: public int rebuildIndex(XWiki wiki, Context context) I can see 2 problems with that: 1) I don't see the need for exposing the context, especially as it's known internally by the plugin. 2) Passing both the context and the wiki object seems redundant as it's possible to call context.getXWiki() I'm thus proposing to deprecate this method and instead replace it with: public int rebuildIndex() Ok for everyone? Thanks -Vincent ___________________________________________________________________________ Yahoo! Mail r�invente le mail ! D�couvrez le nouveau Yahoo! Mail et son interface r�volutionnaire. http://fr.mail.yahoo.com

17 years, 9 months

Removing xwiki-plugins/lucene?

by Vincent Massol

Hi, The lucene plugin is currently in 2 locations: - in xwiki-plugins/lucene - in xwiki/core Which one is the latest one? The core one? Let me know and I'll clean up... Thanks -Vincent ___________________________________________________________________________ Yahoo! Mail r�invente le mail ! D�couvrez le nouveau Yahoo! Mail et son interface r�volutionnaire. http://fr.mail.yahoo.com

17 years, 9 months

[JIRA] New issue creation screen scheme

by Vincent Massol

Hi, In order to prevent users from assigning developers, assigning fix for dates or due dates, I've created a custom issue creation screen scheme in JIRA which only lists "non-developers" fields. This means that when you create an issue you'll only see some fields. Of course, it's then possible to edit issues to set the other fields. Note: This is the solution applied on jira.codehaus.org and I've copied it. I hope this is fine for everyone. Thanks -Vincent ___________________________________________________________________________ Yahoo! Mail r�invente le mail ! D�couvrez le nouveau Yahoo! Mail et son interface r�volutionnaire. http://fr.mail.yahoo.com

17 years, 9 months

Cannot register new user.

by stephendturner＠gmail.com

I am a New user. I have some previous experience with 0.9.840. Just installed Xwiki 1.0 beta3 (requiring upgraded to java5) The sql database is xwiki, user xwiki, pasword xwiki as before Everything seems to work OK and I can edit content. I have imported Panels, nothing else. I have "Log-in", "Register", "Administration", "En" in the top right BUT ... I cannot login as Admin - password "admin" I cannot register a new user When I try to register I just get a login screen. Under Administration I can get to the "Users and groups" where it says ... You can currently edit users using the wiki on the users page. (I can't) You can currently edit groups using the wiki on the groups page. (I can't) But if I go to those pages I can see nothing and do not see how to add users. What am I missing?

17 years, 9 months

Re: [xwiki-users] [ANN] XWiki 1.0 Beta 3 Released

by Dan Murphy

Hi, There doesn't seem to be a tag in xwiki corrisponding to the beta 3 release... should there be (I like to have the source so I can poke around when things go wrong & the trunk will obviously, soon if not already, be out of sync). On 30/01/07, Vincent Massol <vincent(a)massol.net> wrote: > Hi Mark, > > On Jan 30, 2007, at 5:17 AM, Marc Lijour wrote: > > > On Monday 29 January 2007 11:06, Vincent Massol wrote: > >> Hi everyone, > >> > >> We're happy to announce the 1.0 Beta 3 release. It's a bug fix > >> release. > >> > >> Release note on: http://www.xwiki.org/xwiki/bin/view/Main/ > >> ReleaseNotesXWiki10Beta3 > >> > >> Thanks and enjoy > >> -The XWiki Team > > > > Thank you. > > > > Curious, there is no WEB-INF directory under webapps/xwiki/ in the > > tarball. > > You got me worried for a few minutes... Fortunately I've checked and > it's there... :-) > > -Vincent > > > > > > > ___________________________________________________________________________ > Yahoo! Mail réinvente le mail ! Découvrez le nouveau Yahoo! Mail et son interface révolutionnaire. > http://fr.mail.yahoo.com > > > > > -- > You receive this message as a subscriber of the xwiki-users(a)objectweb.org mailing list. > To unsubscribe: mailto:xwiki-users-unsubscribe@objectweb.org > For general help: mailto:sympa@objectweb.org?subject=help > ObjectWeb mailing lists service home page: http://www.objectweb.org/wws > > >

17 years, 9 months

Re: [xwiki-dev] HTML Import Plugin and possible XML/HTML checker?

by Vincent Massol

Hi Ed/Mac, You wet our appetite with your plugin... Any progress? Thanks -Vincent On Jan 6, 2007, at 1:54 AM, Ludovic Dubost wrote: > > Hi, > > This looks nice.. We are already using JTidy for the HTML -> XHTML > conversion before we export to PDF. > A good way to do this is indeed as an XWiki plugin. > I would suggest 2 plugins: > > 1/ Importer > It would be great if the importer have a generic part and a format > specific part. We could use the base code as the code to import from > other wiki formats. > There is one case which is complex in importing is when you want to > handle links. You might need to read multiple files to convert links > from one format to another. For example if you have a set of HTML > files > with relative links you might want to convert them to wiki links. > An importer framework which allows to handle this would be great. > > 2/ Validator/Cleaner > It would be great to be able to use each part separately and have > some > options when calling it. > Besides cross side scripting being able to allow/refuse tag lists > would > be great and also allow/refuse velocity and groovy > > I guess Vincent would like to see the plugin outside of the core, but > I'll leave this to him. > > Ludovic > > Mac a écrit : > > Hey there, > > I was thinking about building a XWiki plugin that will import > > (dynamically) another website, either whole or partial (A little XML > > parsing of it), besides reading the one page Plugin Doc Is there any > > thing else that I could use to help me speed up this development? > Like > > XML parser/HtmlTidy or something that XWiki may already uses? > > > > > > Also, > > While I am on this topic of html, since the Wiki will take > > Html/xml in the normal editing of the page. I would be willing to > > write a Validator that would strip out dangerious html (Cross site > > scripting,...) I have already done this in a filter for a "Sudo > wiki" > > I was building from scratch, but would be willing to re-write it > in a > > way that would be helpful to the project, if someone could point > me in > > the right direction where this type of Class would fit in to the > project. > > > > Thanks, > > > > Cant wait to see beta 2 > > > > > > >

17 years, 9 months

.xar Extension NOT Used Properly

by Catalin Hritcu

The new way to import/export wiki pages is very useful. However, I think that using the .xar extension for the zip(!) archive is highly confusing. This because there is already a XAR(eXtensible ARchiver) archiving utility which uses the .xar extension for quite a while. And while now XAR is standalone, it will be quite probable used by the MacOSX package system in the future. Then download your archive will yield an error like this (safari automatically expands archives): "Error opening xar archive: xwiki-1.0-beta-1.xar" Links: http://www.opendarwin.org/projects/xar/ http://www.nabble.com/xar-in-Mac-OS-X-t2081148.html

17 years, 9 months

Jump to page:

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

2005

xwiki-devs