xwiki-devs October 2007

xwiki-devs@xwiki.org

31 participants
94 discussions

by haiko van der Schaaf

Hi there, I set up a xwiki for my company and wanted t o change the tomcat favicon so I made my own xwiki favicon. I just want to share it. Maybe I nice thought for the next release. The icon is attached. Gr. Haiko van der Schaaf

16 years, 10 months

[xwiki-devs] [XEM][VOTE] Postpone XEM 1.0M2 and following

by Thomas Mortagne

Hi, XEM 1.0M1 version was suppose to be released on the 8th of October but cumulate one week late waiting for new right management API supposed to appear in XE 1.1.2 (and 1.2M2). Some works has been done in that delay that was supposed to be released after 1.0M2 (M3 and M4) so I propose to change XEM schedule to : - M2 : Monday the 22nd - M3 : Monday the 29th - RC1 : Monday the 5th of October - RC2 : Monday the 12th of October Here my +1 Regards, -- Thomas Mortagne

16 years, 10 months

[xwiki-devs] Fwd: An Experiment with GIT

by Vincent Massol

Interesting... After reading about distributed SCMs for some time now I think I'm ready to take the plugin and try some experiments as Jason as done. My only worry so far about using a tool like Git was about the tooling (in IDE, etc). Now that Jason as taken the plunge, I'll do some research on it too in the background. -Vincent Begin forwarded message: > From: Jason van Zyl <jason(a)maven.org> > Date: September 29, 2007 7:40:42 PM CEDT > To: Maven Developers List <dev(a)maven.apache.org> > Subject: An Experiment with GIT > Reply-To: "Maven Developers List" <dev(a)maven.apache.org> > > Hi, > > For anyone who wants to make changes to Maven but doesn't have > access I am going to setup a GIT repository to try and enable some > distributed development. After using GIT for about a week I'm > having a hard time using SVN but obviously we're not going to be > switching anytime soon. > > But for anyone who has patches or wants to try and work with me to > get changes in I am going to try this method of publishing Maven as > a GIT repository which will allow anyone to clone the repository > and work on any changes you like in a controlled way. Once you > clone you can commit changes to your own copy of Maven and do > whatever you like. Then in order for me to see your changes I can > simply pull from your originally cloned repository to a branch on > my side and merge. Merging is sooooooo easy with GIT. So easy in > fact that it makes you wonder how SVN got it so wrong and makes it > so painful compared to GIT. > > This is the model that the Linux kernel uses where anyone has a > real copy of the repository, they work as they like, creating > branches for features of what have you. > > I am trying this with Oleg Gusakov who has many ideas and is > helping me do some experiments with the artifact resolution system. > But anyone else who is interested in trying just let me know. This > document is the most helpful: > > http://utsl.gen.nz/talks/git-svn/intro.html > > And a little collection of things I have read about GIT: > > http://del.icio.us/jvanzyl/git > > It is so damn fast it is unbelievable. With the visual tool that > comes with it you can see the entire history of the project in a > few minutes. It is very, very cool. I simply cannot believe how > easy it is to merge bits from all over the place. My hope is that > this method being truly distributed means that people can work on > their branches in a way that's natural and we remove the immense > tedium working with patches. If you have something good, it's now > very easy for me to pull a branch from you and try it. If that > branch works it then takes me a second to merge it. I test and them > push back to subversion using the git-svn bridge. > > In the short term I really only want to try with a few people but > if you're keen, want to learn about GIT (which I highly, highly > recommend) then I will take your patches. I think any developer > here and anyone who has ever tried to contribute changes sees that > the JIRA+patch model is highly unworkable and bordering on > completely useless. JIRA might be fine to raise the issue but with > a reference to a GIT repository to pull from it will make life > infinitely easier. People who are not committers can work with > people that are in a way that resembles everyon being part of the > team. Dealing with patches just sucks ass and as a result we don't > look at them nearly as often as we should so I hope this can become > a model that enables people to contribute in a more effective way. > I'm going to try this with Oleg but I am highly hopeful. I will > help anyone who wants to try this as I see this as a way to truly > collaborate with the community. Down with JIRA+patches! All hail > JIRA+GIT! :-) > > Thanks, > > Jason

16 years, 10 months

[xwiki-devs] Announcing the XWiki Concerto research project

by Stéphane Laurière

Hi everyone, I don't think this news was shared with the community yet: XPertNet's team (http://www.xwiki.com) has been selected by the French Research Agency together with a set of partners for conducting a research project for adding P2P and mobility capabilities to XWiki. This project is called "XWiki Concerto". The objectives are the following: - design a fault tolerant P2P architecture for XWiki supporting large scale collaborative editing on a set of peers that synchronize their changes regularly using reconciliation algorithms, - support mobility work: off-line capabilities and UI dedicated to mobile handsets. This project will allow to design a P2P XWiki farm that will scale at much lower costs than classical solutions and will let XWiki users work offline and from handsets with limited capabilities. The set of partners are INRIA, ENST, Mandriva and EISTI. The project's web site is http://concerto.xwiki.com. INRIA teams include ECOO (Environments for COOperation) [1] and ATLAS [2]. ECOO team has expertise in reconciliation techniques, ATLAS has expertise in P2P databases. ENST team focuses on the mobility aspects. EISTI is bringing security expertise. XPertNet, Mandriva and INRIA will experiment with the solutions respectively in the context of the XWiki.com farm, the Mandriva Club wiki and the OW2 wiki. [1] http://www.loria.fr/equipes/ecoo/english/index.html [2] http://www.sciences.univ-nantes.fr/lina/ATLAS/ We already delivered a first version of specifications and use cases but it's in French: http://concerto.xwiki.com/xwiki/bin/download/Main/L2/xwikiconcerto-l2.pdf We're currently designing a set of complementary XWiki APIs. I'll send some proposals to the devs list in the next days. Your feedback will be most welcome. There will be many interesting synergies with XEclipse off-line work of course. That'd be good also to investigate about the eRCP capabilities http://www.eclipse.org/ercp/ Cheers Stéphane -- Stéphane Laurière slauriere(a)xwiki.com XWiki http://www.xwiki.com http://concerto.xwiki.com http://nepomuk.semanticdesktop.org

16 years, 10 months

[xwiki-devs] [Watch][Proposal] Insert a web module or/and inject conf in web.xml

by Jerome Velociter

Dear All, Currently XWiki Watch product has a "web" module that holds java sources for the GWT client application. The maven build then generate a war with : * gwt-compiled JS files (+ other resources) * the standard xwiki webapp war. I would like to propose to split that module into two "gwt" and "web" modules. The gwt module build would only take care of gwt compiling, and the web module would build the actual war. The advantage of this would be we can add stuff to our webapp (for example a future skin if we want one), and define our own web.xml. Overriding the web.xml would allow us to have gwt server code for Watch (for now Watch works only with client code + the xwiki gwt api. while it makes it easier for deploying, IMHO it has some limitations on the developer side). However, for this purpose (having specific gwt server code), I see another possibility : we inject some configuration in web.xml as we are doing with xwiki.cfg, thus letting us choose the XWikiService servlet implementation class. If I'm not wrong, this requires modifications in the xwiki configuration resources. Vincent can you tell us if it's stupid/possible/desirable ? Also, again if I'm not wrong, having a web module would allow us to define a jetty run profile, that could be usefull for developers. So my point would be then to : 1- Split the web module into gwt and web (on the same scheme as the curriki product) 2- Inject the XWikiService impl class in web.xml, so that we don't fully override the standard web existing one, and can benefit from its evolutions. Does it make sense ? WDYT ? Jérôme.

16 years, 11 months

[xwiki-devs] XEclipse Off-Line

by Asiri Rathnayake

Hi All, I've undertaken the task of implementing XEclipse off-line and thought I would start a thread with status updates (as told by Vincent). As of today I have implemented caching of documents into local repository. When the user navigates through the document hierarchy, each visited node is stored into the local repository. Also, all edits to documents are saved into local repository as well. To complete XEclipse off-line, following tasks need to be done, * Add an "off-line" flag to XWikiConnection and divert user actions into local repository when user is working off-line. * Add necessary routines to re-construct the document hierarchy using local repository. * Add a sync function to sync the above created hierarchy with remote server. * Make necessary changes to UI components. As you can see there is lot to be done. Due to my exams I won't be able to work on XEclipse for about 2-3 weeks (till 28th), but I will definitely get on with it after that. A big sorry about the missed dead-line (XEclipse Off-line was promised to deliver on 10th). Thanks. - Asiri

16 years, 11 months

Re: [xwiki-devs] [Proposal][UI] Top menu refactoring

by goldring, richard

Bookmarks/favourites - what a good idea! Perhaps with a favorites left hand flyout menu tree? Although you always have your browser bookmarks/favourites but this means you'd have access to your favourites independent of the PC or browser you were using. -----Original Message----- From: devs-bounces(a)xwiki.org [mailto:devs-bounces@xwiki.org]On Behalf Of Jean-Vincent Drean Sent: 11 October 2007 01:18 To: XWiki Developers Subject: Re: [xwiki-devs] [Proposal][UI] Top menu refactoring 2007/10/11, Vincent Massol <vincent(a)massol.net>: > Hi, > > I've just reviewed this last proposal and here are my comments: > > * I'm -1 on naming the menu entry "File" unless someone convinces > me... Right now I don't understand the rationale. Why not call it > "Orange Juice"? ;) I'm -1 for "File" too, "Page seems more appropriate" > * I hate those Microsoft menu entries! ;) Ok so let's talk about mozilla menu entries then ;) > * Don't put CTRL+P in the menu (since the keys are different > depending on the OS) Ok > * Edit menu should be on the left since it's the most used menu I was waiting for someone to raise this one, I'm testing the proposal 3 on my local xwiki and I confirm that it's annoying for people accustomed to the edit at the left. > * Not sure why we're changing "Show" to "View". Show looks fine to me > and since it's been around for some time why change it? This proposal was an attempt of a more desktopish layout. (Page/Edit/View). BTW i never liked "Show" ;) > * I don't like the Watchlist menu entry. This is a very specific > application and I'm not sure why it gets its own menu entry compared > to other applications. Page/Edit/View wait for it.. Bookmarks -> File/Edit/View/Watchlist (since bookmark doesn't fit here). > * I'd be fine with keeping the current Edit and Show menus and > collapse the Delete, Rename and other actions into an "Actions" menu > (or "Other actions") -1 for the hodge-podge until we had discussed all the other options ;) JV. _______________________________________________ devs mailing list devs(a)xwiki.org http://lists.xwiki.org/mailman/listinfo/devs Thales UK Ltd (Wells) DISCLAIMER: The information contained in this e-mail is confidential. It may also be legally privileged. It is intended only for the stated addressee(s) and access to it by any other person is unauthorised. If you are not an addressee, you must not disclose, copy, circulate or in any other way use or rely on the information contained in this e-mail. Such unauthorised use may be unlawful. We may monitor all e-mail communications through our networks. If you have received this e-mail in error, please inform us immediately on +44 (0) 1749 672081 and delete it and all copies from your system. We accept no responsibility for changes to any e-mail which occur after it has been sent. Attachments to this e-mail may contain software viruses which could damage your system. We therefore recommend you virus-check all attachments before opening. A business of Thales UK Ltd. Registered Office: 2 Dashwood Lang Road, The Bourne Business Park, Addlestone, Weybridge, Surrey KT15 2NX Registered in England No. 868273

16 years, 11 months

[xwiki-devs] [Proposal][UI] Top menu refactoring

by Jean-Vincent Drean

Hi XWikiers! We currently have features planned for 1.2M2 with a common point : the xwiki top menu. Features : - New space admin UI : http://jira.xwiki.org/jira/browse/XWIKI-1780 [incomplete jira issue] - Email notifications (aka watchlist) : http://jira.xwiki.org/jira/browse/XWIKI-268 - RSS for spaces/pages : http://jira.xwiki.org/jira/browse/XWIKI-448 - Improve Admin.WebHome : http://jira.xwiki.org/jira/browse/XE-14 [I'll write later about this one] To address needs from those features we'll have to add entries in the top menu without breaking our "800x600 users" compatibility. We currently run out of place in this menu, I've made a proposal of refactoring here : http://www.xwiki.org/xwiki/bin/view/Design/Topmenurefactoring WDYT ? JV.

16 years, 11 months

Re: [xwiki-devs] [xwiki-notifications] r5354 - xwiki-products/xwiki-watch/trunk

by Vincent Massol

On Oct 10, 2007, at 8:40 AM, jvelociter (SVN) wrote: > Author: jvelociter > Date: 2007-10-10 17:40:51 +0200 (Wed, 10 Oct 2007) > New Revision: 5354 > > Modified: > xwiki-products/xwiki-watch/trunk/pom.xml > Log: > XWATCH-68 Added property for enterprise wiki version (needed by the > wiki module) > > > > Modified: xwiki-products/xwiki-watch/trunk/pom.xml > =================================================================== > --- xwiki-products/xwiki-watch/trunk/pom.xml 2007-10-10 15:34:16 > UTC (rev 5353) > +++ xwiki-products/xwiki-watch/trunk/pom.xml 2007-10-10 15:40:51 > UTC (rev 5354) > @@ -46,6 +46,7 @@ > <platform.tools.version>1.7-SNAPSHOT</platform.tools.version> > <platform.core.version>1.1-SNAPSHOT</platform.core.version> > <platform.web.version>1.1-SNAPSHOT</platform.web.version> > + <products.enterprise.wiki.version>1.1-SNAPSHOT</ > products.enterprise.wiki.version> I see that thomas has used: product.xe.version Would be better to all use the same property name. My preference goes to: product.enterprise.version (product.manager.version, product.watch.version, product.curriki.version, etc). WDYT? Thanks -Vincent

16 years, 11 months

[xwiki-devs] [VOTE] Commit rights to Fabio on XEclipse

by Stéphane Laurière

Hi all, I'd like to propose that Fabio becomes a committer on XEclipse. Fabio has created a first patch for XEclipse (connection persistence feature): http://jira.xwiki.org/jira/browse/XECLIPSE-28 and he has gained an expertise in Eclipse by creating the Eclipse PSEW prototype in the frame of the Nepomuk project [1]. He has also developed an XWiki library for indexing XWiki resources in RDF at [2], that we'll announce and discuss on the list in a separate message. PSEW is a generic metadata workbench for Eclipse. It integrates optionaly XEclipse, which makes it then possible to annotate XWiki documents from Eclipse using one or several ontologies. This lets you for example add private tags and personal comments to remote XWiki documents, or draw links between XWiki pages and some local files. The idea would be then to also let you publish some of these annotations to the public server if you feel like it, or to share them with others over a P2P protocol. In this context we'd like to help adding several features to XEclipse like storing various XWiki addresses in the user's preferences, displaying several XWiki trees, adding custom editors, classifying the resources by their types (all classes in a common folder, all Groovy scripts in another one etc.). Tharindu, Asiri, everyone, what do you think? Of course we would discuss with you the features we have in mind before committing them, and we'll use extension points in XEclipse whenever appropriate for not turning XEclipse into a bloated thing! Here's my +1 [1] http://nepomuk-eclipse.semanticdesktop.org/xwiki/bin/view/Main/PSEW [2] http://dev.nepomuk.semanticdesktop.org/repos/trunk/java/org.xwiki.aperture/ Cheers Stéphane -- Stéphane Laurière slauriere(a)xwiki.com XWiki http://www.xwiki.com http://concerto.xwiki.com http://nepomuk.semanticdesktop.org

16 years, 11 months

← Newer
1
2
3
4
5
6
7
8
9
10
Older →

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

2005

xwiki-devs October 2007