- xwiki-devs@xwiki.org - lists.xwiki.org

[xwiki-devs] adding a new jsr-223 scripting language to xwiki (clojure)

by Niels Mayer

In http://code.xwiki.org/xwiki/bin/view/Snippets/DisplayFormatedCodeAttachment… > VincentMassol | 2009/05/05 20:03 > >> Niels, no there's no plan but we can now support any language using macros > so feel free to provide a clojure macro if you're interested. Shouldn't be > too hard to do, especially if there's a JSR-223 implementation (in which > case simply dropping the jar in WEB-INF/lib should be enough - you'd then > use it using the script macro). Clojure <http://groups.google.com/group/clojure> has aJSR-223 implementation according to: http://github.com/pmf/clojure-jsr223/tree/master http://groovy.codehaus.org/JSR-223+access+to+other+JVM+languages http://sayspy.blogspot.com/2009/03/interacting-between-jvm-lang-here-and.ht… Are there any examples, documentation, or suggestions of writing a "script macro" to call a new jar in WEB-INF/lib ? Any other special magic I should know? Does anything from the above suggest that Clojure couldn't be used as an Xwiki scripting language, replacing cases where Groovy scripting might normally be employed? Niels http://nielsmayer.com PS: Here's examples of easy "scripted java" programming you can do in Clojure (note the helpful parallelism constructs): http://travis-whitton.blogspot.com/2009/07/network-sweeping-with-clojure.ht… http://travis-whitton.blogspot.com/2009/06/clojures-agents-scientists-monke… It could be very useful to employ massive parallelism via such Clojure scripts, which could achieve a xwiki-based web portal performance akin to Yahoo's, Google's, etc. For example, the following describes how Yahoo works -- and would be quite easy to implement this kind of processing "for free" in Clojure with very little code: http://research.yahoo.com/files/pnuts.pdf The component responsible for multi-record requests is called the > scatter-gather engine, and is a component of the router. > The scatter-gather engine receives a multi-record request, > splits it into multiple individual requests for single records > or single tablet scans, and initiates those requests in parallel. > As the requests return success or failure, the scatter-gather > engine assembles the results and then passes them to the > client. In our implementation, the engine can begin streaming > some results back to the client as soon as they appear. > We chose a server-side approach instead of having the client > initiate multiple parallel requests for several reasons. First, > at the TCP/IP layer, it is preferable to have one connection > per client to the PNUTS service; since there are many clients > (and many concurrent processes per client machine) opening > one connection to PNUTS for each record being requested > in parallel overloads the network stack. Second, placing this > functionality on the server side allows us to optimize, for > example by grouping multiple requests to the same storage > server in the same web service call. > > Range queries and table scans are also handled by the > scatter gather engine. Typically there is only a single client > process retrieving the results for a query. The scatter gather > engine will scan only one tablet at a time and return results > to the client; this is about as fast as a typical client can > process results. In the case of a range scan, this mecha- > nism simplifies the process of returning the top-K results > (a frequently requested feature), since we only need to scan > enough tablets to provide K results. After returning the > first set of results, the scatter-gather engine constructs and > returns a continuation object, which allows the client to re- > trieve the next set of results. The continuation object con- > tains a modified range query, which, when executed, restarts > the range scan at the point the previous results left off. Con- > tinuation objects allow us to have cursor state on the client > side rather than the server. In a shared service such as > PNUTS, it is essential to minimize the amount of server- > side state we have to manage on behalf of clients. >

16 years

3
5
0 0

[xwiki-devs] good reading for the future regarding Software Transactional Memory (STM) and Clojure

by Niels Mayer

The concepts, as well as the Clojure implementation, presented in this article, may be useful for those designing and implementing some of the "distributed wiki" and "load-balancing" capabilities of 2.X; also for "realtime group editing" features I've seen mentioned in the survey. Also, the concepts here could help in designing finer-grained, yet "federalized/distributed" locking for concurrent access e.g. which might be needed for "collaborative" or simultaneous editing of xwiki documents, as well as load-balanced wikis. This also isn't just "starry eyed theory" -- via JSR223, these features could be integrated into the Xwiki Java API, giving a "concurrent scripting face" to the Xwiki API running on multiple wiki hosts. (see http://groups.google.com/group/clojure/msg/ad811b69d448e3db re JSR-223 status of Clojure). Software Transactional Memory <http://java.ociweb.com/mark/stm/article.html> - Overview <http://java.ociweb.com/mark/stm/article.html#Overview> - Lock-based Concurrency<http://java.ociweb.com/mark/stm/article.html#Locks> - Actor-based Concurrency<http://java.ociweb.com/mark/stm/article.html#Actors> - Transactional Memory <http://java.ociweb.com/mark/stm/article.html#TM> - Software Transactional Memory<http://java.ociweb.com/mark/stm/article.html#STM> (STM) - Persistent Data Structures<http://java.ociweb.com/mark/stm/article.html#PersistentDataStructures> - STM Implementations<http://java.ociweb.com/mark/stm/article.html#STMImplementations> - Clojure Overview<http://java.ociweb.com/mark/stm/article.html#ClojureOverview> - Clojure Reference Types<http://java.ociweb.com/mark/stm/article.html#ClojureReferenceTypes> - Clojure Validators and Watchers<http://java.ociweb.com/mark/stm/article.html#ClojureValidatorsAndWatchers> - Clojure STM - High Level<http://java.ociweb.com/mark/stm/article.html#ClojureSTMHigh> - Clojure STM - Low Level<http://java.ociweb.com/mark/stm/article.html#ClojureSTMLow> - Conclusion <http://java.ociweb.com/mark/stm/article.html#Conclusion> - References <http://java.ociweb.com/mark/stm/article.html#References> Clojure has built-in support for Concurrency: ( http://java.ociweb.com/mark/clojure/article.html#Concurrency ) > Managing concurrency with locks is hard. It requires determining which > objects need to be locked and when they need to be locked. These decisions > need to be reevaluated when the code is modified or new code is added. If a > developer forgets to lock objects that need to be locked or locks them at > the wrong times, bad things can happen. These include deadlocks<http://en.wikipedia.org/wiki/Deadlock> > and race conditions <http://en.wikipedia.org/wiki/Race_condition>. If > objects are locked unnecessarily, there is a performance penalty. Support for concurrency is one of the main reasons why many developers > choose to use Clojure. All data is immutable unless explicitly marked as > mutable by using the reference types Var<http://java.ociweb.com/mark/clojure/article.html#Vars> > , Ref <http://java.ociweb.com/mark/clojure/article.html#Refs>, Atom<http://java.ociweb.com/mark/clojure/article.html#Atoms> > and Agent <http://java.ociweb.com/mark/clojure/article.html#Agents>. > These provide safe ways to manage shared state and are described in the next > section titled "Reference Types<http://java.ociweb.com/mark/clojure/article.html#ReferenceTypes> > ". Niels http://nielsmayer.com

16 years

1
0
0 0

[xwiki-devs] Blog Plugin Proposal

by Andreas Schaefer

Now that the Blog Upgrade to 2.0 wiki syntax comes soon to a close I want to focus on the improving its performance and ease of use. As suggested beforehand I think creating a Blog Plugin would probably the best way to accomplish that. For that I would suggest that all methods in "Code" documents in the blog (BlogCode2, CategoryCode and if needed RssCode) become part of that plugin. Beside that I am also wondering if that plugin should become part of the Core (xwiki-core) like the Feed Plugin or a regular plugin like the Scheduler Plugin which I think would be the best. Cheers Andreas Schaefer

16 years

4
5
0 0

Re: [xwiki-devs] [Issue] Commented: (XABLOG-63) Create a Blog Plugin and Adjust the Blog Application to use it

by Andreas Schaefer

As you might have seen I uploaded the Blog Application XAR file as well as the Blog Plugin (including the source). Let me know what you think. Hopefully this could start a good discussion about it. Anyway I am going to upgrade my own Blog using the Plugin this weekend to see how it works out. Cheers - Andy On Aug 29, 2009, at 10:50 AM, Vincent Massol (JIRA) wrote: > > [ http://jira.xwiki.org/jira/browse/XABLOG-63?page=com.atlassian.jira.plugin.… > ] > > Vincent Massol commented on XABLOG-63: > -------------------------------------- > > Note that the start of a discussion on this was started on the list > and so far we're not sure we want to do it. Sergiu is against it and > I'm not sure either. There are some problems. I think we need to all > agree first before we implement this. > >> Create a Blog Plugin and Adjust the Blog Application to use it >> -------------------------------------------------------------- >> >> Key: XABLOG-63 >> URL: http://jira.xwiki.org/jira/browse/XABLOG-63 >> Project: XWiki Blog Application >> Issue Type: Improvement >> Affects Versions: 1.10 >> Reporter: Andreas Schaefer >> Fix For: Future >> >> >> Currently the entire Blog Application is powered by Velocity code. >> We should extract the non-UI code into a blog plugin to present a >> more stable API to the blog applications. > > -- > This message is automatically generated by JIRA. > - > If you think it was sent incorrectly contact one of the > administrators: http://jira.xwiki.org/jira/secure/Administrators.jspa > - > For more information on JIRA, see: http://www.atlassian.com/software/jira > > >

16 years

1
0
0 0

[xwiki-devs] Not allowing the code macro in inline mode when there are NL inside

by Vincent Massol

Hi, Right now we support code macro in both inline and standalone modes. However the style isn't nice if the macro is inline and on several lines. For ex: This is {{code language="java"}} public class LoggingEventListener implements EventListener { } {{/code}} inline I'm proposing to test in the code macro if there are NL in the macro content and if so and if the macro is inline then generate an error explaining that the macro but not be inline to use multi line content. WDYT? Thanks -Vincent

16 years

4
7
0 0

[xwiki-devs] toc in some dev.xwiki.org pages -> enforcing structure

by [Ricardo Rodriguez] Your EPEC Network ICT Team

Hi, Some pages in dev.xwiki.org have a table of content. For instance, http://dev.xwiki.org/xwiki/bin/view/Community/Building I guess if to add this simple table of content to pages like Building XWiki in Eclipse will ease the understanding of the whole process to newcomers like me myself. It will result something similar to the Building page. Something like http://tinyurl.com/mc6e8d. Generalizing the question, must all and every documents on dev.xwiki.org have a TOC? Is it possible, in this virtual wiki or any other hosted locally, or in a given space, enforce a structure? Something like: any document is created in DummySpace must have a heading1 followed some paragraphs, then a TOC, then any number of heading2, paragraph, heading3, paragraph and so on, so forth. Thanks! Ricardo -- Ricardo Rodríguez Your EPEC Network ICT Team

16 years

2
4
0 0

[xwiki-devs] [Proposal] Staging Period?

by Vincent Massol

Hi everyone, I was thinking about the regression found on the 2.0M4 release yesterday. I think we should have an official testing period between the code freeze and the release (called the staging period) when everyone who want to help could test the release before we make it official. Something like a 2 days period for a 2 or 3 weeks release. This could be done easily with Nexus (which we have installed already - it needs to be configured). We could set it up and try it for the next release (2.1 onwards). Since it needs 2-3 days per release this would mean accounting for it in the roadmaps/timelines. That said, since a release should always be done on a branch, the devs can continue to work on the next release while the staged release is being tested. It would affect the amount of things we put in a release if we keep the same period of 2 weeks for RCs and 3 weeks for milestones but I don't think this is a problem. It just means we need to be careful not to overcommit in general. Obviously the ideal is still to have as many automated functional tests as possible and to reduce this period to the minimum. WDYT? Thanks -Vincent

16 years

1
0
0 0

Re: [xwiki-devs] [xwiki-users] XWiki 2 ML 4 .xar import error

by Andreas Schaefer

On a side note I checked what is in SVN and built the entire application from scratch. The generic installer is failing there the same way. In addition the built from 2 days ago (8/25/09) does work fine meaning the error was introduced in the last two days. - Andreas Schaefer On Thursday, August 27, 2009, at 04:00PM, "Andreas Schaefer" <schaefera(a)me.com> wrote: >I downloaded the Generic Installer, installed it and when showing the XWiki Dashboard I get an exception from the menuview.vm caused by the DB upgrade. This is what I see first in the console: > >009-08-27 15:47:21,258 [http://localhost:8080/xwiki/bin/view/Main/] [http://localhost:8080/xwiki/bin/view/Main/?null] INFO .AbstractXWikiMigrationManager - New storage version is now [15429] >org.hibernate.MappingException: Unknown entity: com.xpn.xwiki.plugin.activitystream.impl.ActivityEventImpl > at org.hibernate.impl.SessionFactoryImpl.getEntityPersister(SessionFactoryImpl.java:550) > at org.hibernate.impl.SessionImpl.getEntityPersister(SessionImpl.java:1338) > at org.hibernate.event.def.AbstractSaveEventListener.saveWithGeneratedId(AbstractSaveEventListener.java:98) > at org.hibernate.event.def.DefaultSaveOrUpdateEventListener.saveWithGeneratedOrRequestedId(DefaultSaveOrUpdateEventListener.java:187) > at org.hibernate.event.def.DefaultSaveEventListener.saveWithGeneratedOrRequestedId(DefaultSaveEventListener.java:33) > at org.hibernate.event.def.DefaultSaveOrUpdateEventListener.entityIsTransient(DefaultSaveOrUpdateEventListener.java:172) > at org.hibernate.event.def.DefaultSaveEventListener.performSaveOrUpdate(DefaultSaveEventListener.java:27) > at org.hibernate.event.def.DefaultSaveOrUpdateEventListener.onSaveOrUpdate(DefaultSaveOrUpdateEventListener.java:70) > >Cheers > >Andreas Schaefer >CEO of Madplanet.com Inc. >EMail: andreas.schaefer(a)madplanet.com > schaefera(a)me.com >Twitter: andy_mpc >AIM: schaefera(a)me.com > > >On Wednesday, August 26, 2009, at 06:29PM, "Dilipkumar Jadhav" <jadhav.dilipkumar(a)gmail.com> wrote: >>Hello everyone, >> >>Tried setting up XWiki 2 ML4 as a fresh installation on a test machine. >> >>The installation went fine. However, importing the .xar file for XWiki 2 ML >>4 throws the following error: >> >> >> >>Wrapped Exception: >> >> >> >>org.apache.velocity.exception.MethodInvocationException: Invocation of >>method 'save' in class com.xpn.xwiki.api.Document threw exception >>com.xpn.xwiki.XWikiException: Error number 9001 in 9: Access denied in edit >>mode on document XWiki.XWikiPreferences at /templates/admin.vm[line 58, >>column 26] >> >> at >>org.apache.velocity.runtime.parser.node.ASTMethod.handleInvocationException( >>ASTMethod.java:337) >> >>. >> >> >> >>When I tried again, it takes me to the XWiki preferences page but the page >>says it is locked in edit mode by XWiki.Guest. Clicking force edit throws >>the above mentioned error again. >> >>Is anyone else too facing the same issue. Did I miss out on anything >>critical during setup. >> >>The machine is the same where a test version of XWiki 2 ML 3 works just >>fine. >> >>_______________________________________________ >>users mailing list >>users(a)xwiki.org >>http://lists.xwiki.org/mailman/listinfo/users >> >> >_______________________________________________ >users mailing list >users(a)xwiki.org >http://lists.xwiki.org/mailman/listinfo/users > >

16 years

2
1
0 0

[xwiki-devs] m2eclipse 0.9.9 setup

by Vincent Massol

Hi everyone, Just setup m2eclipse 0.9.9. I have modified the top level pom.xml to configure it properly ie support incremental build + use a different target dir (I've chosen target-eclipse/). I'll add svn ignores to all modules for target-eclipse Let me know if you see a problem. Thanks -Vincent

16 years

1
0
0 0

Re: [xwiki-devs] [xwiki-notifications] r22829 - in platform: core/trunk/xwiki-core/src/main/resources xwiki-applications/trunk/scheduler/src/main/resources/Scheduler xwiki-plugins/trunk/scheduler/src/main/java/com/xpn/xwiki/plugin/scheduler

by Sergiu Dumitriu

jvdrean (SVN) wrote: > Author: jvdrean > Date: 2009-08-21 22:46:51 +0200 (Fri, 21 Aug 2009) > New Revision: 22829 > > Modified: > platform/core/trunk/xwiki-core/src/main/resources/ApplicationResources.properties > platform/xwiki-applications/trunk/scheduler/src/main/resources/Scheduler/WebHome.xml > platform/xwiki-plugins/trunk/scheduler/src/main/java/com/xpn/xwiki/plugin/scheduler/SchedulerPlugin.java > platform/xwiki-plugins/trunk/scheduler/src/main/java/com/xpn/xwiki/plugin/scheduler/SchedulerPluginApi.java > platform/xwiki-plugins/trunk/scheduler/src/main/java/com/xpn/xwiki/plugin/scheduler/SchedulerPluginException.java > Log: > XASCH-35 : Allow to manually trigger a job (execute it once) > XASCH-36 : Provide a getPreviousFireTime method in the API > > Modified: platform/xwiki-applications/trunk/scheduler/src/main/resources/Scheduler/WebHome.xml > =================================================================== > --- platform/xwiki-applications/trunk/scheduler/src/main/resources/Scheduler/WebHome.xml 2009-08-21 20:34:10 UTC (rev 22828) > +++ platform/xwiki-applications/trunk/scheduler/src/main/resources/Scheduler/WebHome.xml 2009-08-21 20:46:51 UTC (rev 22829) > @@ -205,6 +205,16 @@ > #set($deleteRedirect = $xwiki.getURL($jobObj.getName(),"delete")) > $response.sendRedirect($deleteRedirect)) > #end > + #elseif($request.do=="trigger") > + ## > + ## Trigger a job (execute it now) > + ## > + #set($ok=$scheduler.triggerJob($jobObj)) > + #if($ok==false) > + #error("$context.get('error')") > + #else > + #info("Job ~~$jobObj.get('jobName')~~ *$msg.get('xe.scheduler.triggered')*") > + #end > #end > #end > 1 $msg.get('xe.scheduler') > @@ -235,6 +245,7 @@ > #set( $ok = $!actions.put("unschedule",$doc.getURL("view","do=unschedule&amp;which=${jobHolder.fullName}")) ) > #end > #set($ok = $!actions.put("delete",$doc.getURL("view","do=delete&amp;which=${jobHolder.fullName}")) ) > + #set($ok = $!actions.put("trigger",$doc.getURL("view","do=trigger&amp;which=${jobHolder.fullName}")) ) > $job.get("jobName")|$status|$firetime| *$msg.get('xe.scheduler.jobs.infos')* : [view>$jobHolder.fullName] #if($jobHolder.hasAccessLevel("programming")) <a href="${jobHolder.getURL('inline')}">$msg.get("edit")</a> #end *$msg.get("job")* : #foreach($action in $actions.keySet()) <a href="${actions.get($action)}">$action</a> #end > > #end Some quick velocity performance tests: #set($y = "abc") #foreach($i in [0..4000000]) #set($x = "$y") #end ~~2.7s #set($y = "abc") #foreach($i in [0..4000000]) #set($x = $y) #end ~~1.8s Here, the quotes around "$y" are completely unneeded. Similarly, "abc" is more costly than 'abc'. Please think of the penguins before using so many double quotes... -- Sergiu Dumitriu http://purl.org/net/sergiu/

16 years

1
0
0 0

[xwiki-devs] Documentation for Formula macro

by Vincent Massol

Hi guys, We're missing the doc for the new formula macro on code.xwiki.org Who could do it? Thanks -Vincent

16 years

2
1
0 0

[xwiki-devs] Wiki Macros in multi wiki

by Ludovic Dubost

I've tried to create a macro page on myxwiki.org but it does not seem to be recognized. Is it ok to put it in the local wiki and what exactly is needed ? Is XWiki.WikiMacroClass enough ? Ludovic -- Ludovic Dubost Blog: http://blog.ludovic.org/ XWiki: http://www.xwiki.com Skype: ldubost GTalk: ldubost

16 years

4
5
0 0

[xwiki-devs] How to Automatically Build and Run Xwiki Within Eclipse?

by Leon Wang

Hi guys, I really love Xwiki. I think it is pretty and cool. I hope I could build a tool base on Xwiki Platform for my master thesis. And I want to contribute to Xwiki Community too. Should I create a new module or component. I could not distinguish those two. I tried follow this tutorial ( http://dev.xwiki.org/xwiki/bin/view/Community/Debugging) more than 10 times for automatically build and run Xwiki in Eclipse. For Import and link maven jar projects to debug secttion, I find how to Link Jar project to the web project is vague( http://dev.xwiki.org/xwiki/bin/view/Community/DebugXEWithEclipse_ImportJarP…), for "Since M2Eclipse 0.9.4, you need to install Maven Integration for WTP then you just have to add the imported maven jar project in the pom.xml file of the project xe-debug." Could any guru explain a little about how write pom.xml file for the imported maven jar project? Does Eclipse 3.5 JEE Galileo work well with Maven and everything？ Thank you everyone, have a nice day! Leon

16 years

5
6
0 0

[xwiki-devs] [Colibri Skin] Color Themes

by Ecaterina Valica

Hi, The new XWiki 2.0 Skin (Colibri) will let you easily change the colors using a ColorTheme Class done by Marta. Here are some examples of theme customization: http://incubator.myxwiki.org/xwiki/bin/download/ColorThemes/DefaultColorThe… Default) http://incubator.myxwiki.org/xwiki/bin/download/ColorThemes/AColorTheme/Sch… http://incubator.myxwiki.org/xwiki/bin/download/ColorThemes/BColorTheme/Sch… http://incubator.myxwiki.org/xwiki/bin/download/ColorThemes/CColorTheme/Sch… http://incubator.myxwiki.org/xwiki/bin/download/ColorThemes/DColorTheme/Sch… http://incubator.myxwiki.org/xwiki/bin/download/ColorThemes/EColorTheme/Sch… After XWiki's Colibri release would be nice to have a gallery with themes submitted by the community. Thanks, Caty

16 years

8
15
0 0

[xwiki-devs] [VOTE] Move Attachment code from Rendering to the Model Bridge

by Vincent Massol

Hi, Right now we have an AttachmentParser in the Rendering module: @ComponentRole public interface AttachmentParser { /** * Extract informations from attachment location string an return an {@link Attachment}. * * @param attachmentLocation the location of the attachment in string. * @return the {@link Attachment} object. */ Attachment parse(String attachmentLocation); } and /** * Represents an attachment in a document. * * @version $Id: Attachment.java 18089 2009-03-27 15:51:39Z tmortagne $ * @since 1.7.1 */ public interface Attachment extends Cloneable { /** * @return the name of the document containing the attachment. */ String getDocumentName(); /** * @return the name of the attachment. */ String getAttachmentName(); } and public class DefaultAttachement implements Attachment ... This allows parsing attachment representations such as: Space.Page(a)some.attachment Since this is a generic notion I'd like to move this code to the xwiki- bridge module. Note 1: This is also especially relevant since we already have an AttachmentName class in the bridge module. Note 2: This will mean some changes in the Rendering API module too so that it doesn't depend on the bridge module but that's normal and technical Thanks -Vincent

16 years

5
6
0 0

Re: [xwiki-devs] [xwiki-notifications] r22926 - in enterprise/trunk/wiki/src/main/resources: . ColorThemes

by Vincent Massol

Hi everyone, hmm we need to decide where to put this. I think it's the first time we have pages for a skin. Is that something we want? Till now we've used vms instead of pages for skins. Or do you consider color themes independent of a given skin? In which case, we could decide to create an application for it in applications/ WDYT? Thanks -Vincent On Aug 26, 2009, at 9:21 AM, sdumitriu (SVN) wrote: > Author: sdumitriu > Date: 2009-08-26 09:21:10 +0200 (Wed, 26 Aug 2009) > New Revision: 22926 > > Added: > enterprise/trunk/wiki/src/main/resources/ColorThemes/ > enterprise/trunk/wiki/src/main/resources/ColorThemes/BlueSky.xml > enterprise/trunk/wiki/src/main/resources/ColorThemes/Bordo.xml > enterprise/trunk/wiki/src/main/resources/ColorThemes/ > ColorThemeClass.xml > enterprise/trunk/wiki/src/main/resources/ColorThemes/ > ColorThemeSheet.xml > enterprise/trunk/wiki/src/main/resources/ColorThemes/ > ColorThemeTemplate.xml > enterprise/trunk/wiki/src/main/resources/ColorThemes/ > DefaultColorTheme.xml > enterprise/trunk/wiki/src/main/resources/ColorThemes/InnerDark.xml > enterprise/trunk/wiki/src/main/resources/ColorThemes/Nature.xml > enterprise/trunk/wiki/src/main/resources/ColorThemes/Nightfall.xml > enterprise/trunk/wiki/src/main/resources/ColorThemes/Peach.xml > enterprise/trunk/wiki/src/main/resources/ColorThemes/WebHome.xml > Log: > XE-?: New ColorTheme application > Done >

16 years

3
5
0 0

Re: [xwiki-devs] [xwiki-notifications] r22926 - in enterprise/trunk/wiki/src/main/resources: . ColorThemes

by Jerome Velociter

> Author: sdumitriu > Date: 2009-08-26 09:21:10 +0200 (Wed, 26 Aug 2009) > New Revision: 22926 > > Added: > enterprise/trunk/wiki/src/main/resources/ColorThemes/ > enterprise/trunk/wiki/src/main/resources/ColorThemes/BlueSky.xml > enterprise/trunk/wiki/src/main/resources/ColorThemes/Bordo.xml > enterprise/trunk/wiki/src/main/resources/ColorThemes/ColorThemeClass.xml > enterprise/trunk/wiki/src/main/resources/ColorThemes/ColorThemeSheet.xml > enterprise/trunk/wiki/src/main/resources/ColorThemes/ColorThemeTemplate.xml > enterprise/trunk/wiki/src/main/resources/ColorThemes/DefaultColorTheme.xml > enterprise/trunk/wiki/src/main/resources/ColorThemes/InnerDark.xml > enterprise/trunk/wiki/src/main/resources/ColorThemes/Nature.xml > enterprise/trunk/wiki/src/main/resources/ColorThemes/Nightfall.xml > enterprise/trunk/wiki/src/main/resources/ColorThemes/Peach.xml > enterprise/trunk/wiki/src/main/resources/ColorThemes/WebHome.xml > Log: > XE-?: New ColorTheme application > Done Hi Sergiu, I find the ColorThemes application pretty confusing : we can edit existing themes, but not create new ones? I would have seen it the other way around : existing themes are freezed, and users create new custom ones. Also I find it hard to understand what the application really do, and how it relate to the Colibri skin. It looks a little like dropped in the middle of nowhere. Finally, I think this kind of application raises the question of how we want them to be accessed. Personally I find a bit odd to have 'ColorThemes' in the space index. I would be in favor of blacklisting the space, and linking the application from the presentation section of the administration. Jerome.

16 years

2
1
0 0

[xwiki-devs] Student asking for your help in open source survey

by Rod Hilton

Hello, I'll make this short and sweet. 1) I'm a graduate student. 2) I'm doing research on development practices in the open source community. 3) I would like to use xwiki as part of my research. I'd be eternally grateful if everyone who has ever contributed code to this project could fill out my survey. It's three questions long, and you can do the whole thing with just the mouse. Please take a few seconds and help me complete my research, I'd really appreciate it. The survey is here: http://spreadsheets.google.com/viewform?formkey=cHU2aHo5bS14cE04c2gzWGlhaUp… .. Thank you, Rod Hilton P.S. If you are involved with multiple open source projects and seeing this message on other mailing lists, first let me apologize for being so annoying, but second let me ask you to please fill out the survey again, once for each project. Thanks!

16 years

1
0
0 0

[xwiki-devs] [ANN] XWiki Enterprise 2.0 Milestone 4 released

by Thomas Mortagne

The XWiki development team is pleased to announce the release of XWiki Enterprise 2.0 Milestone 4. Go grab it at http://www.xwiki.org/xwiki/bin/view/Main/Download This is the fourth and last milestone for the XWiki enterprise 2.0 version. Changes from 2.0 Milestone 3: * Introduce new Colibri skin * Improvements and bugfixes in the new network event distribution system * Improvements in the scheduler * Improvements in the watchlist * Introduce activity stream plugin * Add macros categories support * Add attachment support to mail created from template As usual we need the community to heavily test this release before the final release to catch all the remaining issues. You can look at http://dev.xwiki.org/xwiki/bin/view/Drafts/EventClustering to test the new event based clustering support. For more information see the Release notes at: http://www.xwiki.org/xwiki/bin/view/Main/ReleaseNotesXWikiEnterprise20M4 Thanks -The XWiki dev team

16 years

1
0
0 0

[xwiki-devs] [VOTE] Branch trunk for 2.0 release so that we can start work for 2.1

by Vincent Massol

Hi, I'd like to branch platform/core, web and enterprise/ so that we can start working on 2.1. I'd like to be able make commits for 2.1 that shouldn't go in 2.0 (they're too dangerous). Here's my +1 Thanks -Vincent

16 years

3
2
0 0

[xwiki-devs] [VOTE] Release XWiki Enterprise 2.0M4

by Thomas Mortagne

Hi, I would like to release what was planned as a RC1 as a Milestone 4 now to release something and since there is some remaining issues in it. Among other things, this release contains: - first final and automatically tested version of remote observation manager and support of new observation manager instead of old notification system - new colibri skin - first introduction of activity stream plugin - refactor of the watchlist based on activity stream to greatly improve speed - new macros categories Here is my +1 Thanks, -- Thomas Mortagne

16 years

7
7
0 0

Re: [xwiki-devs] [xwiki-notifications] r22950 - platform/core/trunk/xwiki-core/src/main/java/com/xpn/xwiki/notify

by Vincent Massol

Some questions: 1) I thought this notify package was going to be removed since all the code was updated to use the new observation module? 2) Why do you do the protection inside the rule instead of inside the Notification Manager. Funnily I had put a TODO comment 2 days ago there exactly for this... ;) Thanks -Vincent On Aug 26, 2009, at 5:04 PM, tmortagne (SVN) wrote: > Author: tmortagne > Date: 2009-08-26 17:04:31 +0200 (Wed, 26 Aug 2009) > New Revision: 22950 > > Modified: > platform/core/trunk/xwiki-core/src/main/java/com/xpn/xwiki/notify/ > DocChangeRule.java > platform/core/trunk/xwiki-core/src/main/java/com/xpn/xwiki/notify/ > XWikiActionRule.java > Log: > XWIKI-4238: Nofification system should protectd itself from bad > listeners > > Modified: platform/core/trunk/xwiki-core/src/main/java/com/xpn/xwiki/ > notify/DocChangeRule.java > =================================================================== > --- platform/core/trunk/xwiki-core/src/main/java/com/xpn/xwiki/ > notify/DocChangeRule.java 2009-08-26 15:04:15 UTC (rev 22949) > +++ platform/core/trunk/xwiki-core/src/main/java/com/xpn/xwiki/ > notify/DocChangeRule.java 2009-08-26 15:04:31 UTC (rev 22950) > @@ -21,12 +21,17 @@ > > package com.xpn.xwiki.notify; > > +import org.apache.commons.logging.Log; > +import org.apache.commons.logging.LogFactory; > + > import com.xpn.xwiki.XWikiContext; > import com.xpn.xwiki.doc.XWikiDocument; > > @Deprecated > public class DocChangeRule implements XWikiNotificationRule > { > + protected static final Log LOG = > LogFactory.getLog(DocChangeRule.class); > + > private XWikiDocChangeNotificationInterface target; > > private boolean preverify = false; > @@ -71,7 +76,13 @@ > return; > } > > - getTarget().notify(this, newdoc, olddoc, > XWikiDocChangeNotificationInterface.EVENT_CHANGE, context); > + try { > + getTarget().notify(this, newdoc, olddoc, > XWikiDocChangeNotificationInterface.EVENT_CHANGE, context); > + } catch (Exception e) { > + // protect from bad listeners > + LOG.error("Fail to notify target [" + getTarget() + "] > for event [" + this + ", newdoc=" + newdoc > + + ", olddoc=" + olddoc + "]", e); > + } > } > > /** > @@ -86,7 +97,13 @@ > return; > } > > - getTarget().notify(this, newdoc, olddoc, > XWikiDocChangeNotificationInterface.EVENT_CHANGE, context); > + try { > + getTarget().notify(this, newdoc, olddoc, > XWikiDocChangeNotificationInterface.EVENT_CHANGE, context); > + } catch (Exception e) { > + // protect from bad listeners > + LOG.error("Fail to notify target [" + getTarget() + "] > for pre event [" + this + ", newdoc=" + newdoc > + + ", olddoc=" + olddoc + "]", e); > + } > } > > /** > > Modified: platform/core/trunk/xwiki-core/src/main/java/com/xpn/xwiki/ > notify/XWikiActionRule.java > =================================================================== > --- platform/core/trunk/xwiki-core/src/main/java/com/xpn/xwiki/ > notify/XWikiActionRule.java 2009-08-26 15:04:15 UTC (rev 22949) > +++ platform/core/trunk/xwiki-core/src/main/java/com/xpn/xwiki/ > notify/XWikiActionRule.java 2009-08-26 15:04:31 UTC (rev 22950) > @@ -21,12 +21,17 @@ > > package com.xpn.xwiki.notify; > > +import org.apache.commons.logging.Log; > +import org.apache.commons.logging.LogFactory; > + > import com.xpn.xwiki.XWikiContext; > import com.xpn.xwiki.doc.XWikiDocument; > > @Deprecated > public class XWikiActionRule implements XWikiNotificationRule > { > + protected static final Log LOG = > LogFactory.getLog(XWikiActionRule.class); > + > private XWikiActionNotificationInterface target; > > private boolean preverify = false; > @@ -74,9 +79,9 @@ > try { > getTarget().notify(this, doc, action, context); > } catch (Throwable e) { > - // Notification should never fail > - // Just report an error > - e.printStackTrace(); > + // protect from bad listeners > + LOG.error("Fail to notify target [" + getTarget() + "] > for event [" + this + ", doc=" + doc + ", action=" > + + action + "]", e); > } > } > > @@ -87,9 +92,9 @@ > try { > getTarget().notify(this, doc, action, context); > } catch (Throwable e) { > - // Notification should never fail > - // Just report an error > - e.printStackTrace(); > + // protect from bad listeners > + LOG.error("Fail to notify target [" + getTarget() + "] > for pre event [" + this + ", doc=" + doc > + + ", action=" + action + "]", e); > } > }

16 years

2
1
0 0

[xwiki-devs] Feeds page in default XE + no UI for getting the global RSS feed

by Vincent Massol

Hi, Problem 1 ======== We need to decide what we do with http://localhost:8080/xwiki/bin/view/Main/RssFeeds I thought it was useful but it's not linked anymore from anywhere. Problem 2 ======== On the Blog home there's no way to easily get the Blog RSS feed. The category panel only allows to get feeds for a given category. Any ideas? Thanks -Vincent

16 years

3
5
0 0

[xwiki-devs] Interesting idea of i18N: CAI18N

by Vincent Massol

http://cai18n.qos.ch/manual.html Advantage: typed keys. Thanks -Vincent

16 years

1
0
0 0

Re: [xwiki-devs] [xwiki-notifications] r22920 - in platform/skins/trunk: . colibri colibri/src colibri/src/assemble colibri/src/main colibri/src/main/resources colibri/src/main/resources/colibri

by Vincent Massol

Hi Sergiu, You've been busy :) Wow lots of vms. Won't we have problems maintaining (ie keep in sync) all the vms from templates + toucan + colibri? Also isn't the idea to have only vm files in templates as much as possible? (maybe this is just a temporary step?) Thanks -Vincent On Aug 26, 2009, at 8:59 AM, sdumitriu (SVN) wrote: > Author: sdumitriu > Date: 2009-08-26 08:59:24 +0200 (Wed, 26 Aug 2009) > New Revision: 22920 > > Added: > platform/skins/trunk/colibri/ > platform/skins/trunk/colibri/pom.xml > platform/skins/trunk/colibri/src/ > platform/skins/trunk/colibri/src/assemble/ > platform/skins/trunk/colibri/src/assemble/skin.xml > platform/skins/trunk/colibri/src/main/ > platform/skins/trunk/colibri/src/main/resources/ > platform/skins/trunk/colibri/src/main/resources/colibri/ > platform/skins/trunk/colibri/src/main/resources/colibri/ > accessdenied.vm > platform/skins/trunk/colibri/src/main/resources/colibri/admin.vm > platform/skins/trunk/colibri/src/main/resources/colibri/ > attachments.vm > platform/skins/trunk/colibri/src/main/resources/colibri/captcha.vm > platform/skins/trunk/colibri/src/main/resources/colibri/ > changemyavatar.vm > platform/skins/trunk/colibri/src/main/resources/colibri/ > changesall.vm > platform/skins/trunk/colibri/src/main/resources/colibri/colibri.css > platform/skins/trunk/colibri/src/main/resources/colibri/comments.vm > platform/skins/trunk/colibri/src/main/resources/colibri/ > contentview.vm > platform/skins/trunk/colibri/src/main/resources/colibri/copy.vm > platform/skins/trunk/colibri/src/main/resources/colibri/delete.vm > platform/skins/trunk/colibri/src/main/resources/colibri/deleted.vm > platform/skins/trunk/colibri/src/main/resources/colibri/ > deleteversionsconfirm.vm > platform/skins/trunk/colibri/src/main/resources/colibri/ > docalreadyexists.vm > platform/skins/trunk/colibri/src/main/resources/colibri/ > docdoesnotexist.vm > platform/skins/trunk/colibri/src/main/resources/colibri/docextra.vm > platform/skins/trunk/colibri/src/main/resources/colibri/edit.vm > platform/skins/trunk/colibri/src/main/resources/colibri/ > edithistory.vm > platform/skins/trunk/colibri/src/main/resources/colibri/ > editinline.vm > platform/skins/trunk/colibri/src/main/resources/colibri/editmodes.vm > platform/skins/trunk/colibri/src/main/resources/colibri/ > editpanelsvars.vm > platform/skins/trunk/colibri/src/main/resources/colibri/exception.vm > platform/skins/trunk/colibri/src/main/resources/colibri/global.vm > platform/skins/trunk/colibri/src/main/resources/colibri/header.vm > platform/skins/trunk/colibri/src/main/resources/colibri/hierarchy.vm > platform/skins/trunk/colibri/src/main/resources/colibri/history.vm > platform/skins/trunk/colibri/src/main/resources/colibri/ > historyinline.vm > platform/skins/trunk/colibri/src/main/resources/colibri/ie.css > platform/skins/trunk/colibri/src/main/resources/colibri/ > information.vm > platform/skins/trunk/colibri/src/main/resources/colibri/ > informationinline.vm > platform/skins/trunk/colibri/src/main/resources/colibri/login.vm > platform/skins/trunk/colibri/src/main/resources/colibri/logo.png > platform/skins/trunk/colibri/src/main/resources/colibri/menuview.vm > platform/skins/trunk/colibri/src/main/resources/colibri/message.vm > platform/skins/trunk/colibri/src/main/resources/colibri/passwd.vm > platform/skins/trunk/colibri/src/main/resources/colibri/preview.vm > platform/skins/trunk/colibri/src/main/resources/colibri/register.vm > platform/skins/trunk/colibri/src/main/resources/colibri/rename.vm > platform/skins/trunk/colibri/src/main/resources/colibri/ > resetversions.vm > platform/skins/trunk/colibri/src/main/resources/colibri/ > resetversionsdone.vm > platform/skins/trunk/colibri/src/main/resources/colibri/shortcuts.vm > platform/skins/trunk/colibri/src/main/resources/colibri/style.css > platform/skins/trunk/colibri/src/main/resources/colibri/ > templatedoesnotexist.vm > platform/skins/trunk/colibri/src/main/resources/colibri/ > userinactive.vm > platform/skins/trunk/colibri/src/main/resources/colibri/view.vm > platform/skins/trunk/colibri/src/main/resources/colibri/ > viewattachrev.vm > Modified: > platform/skins/trunk/pom.xml > Log: > XSCOLIBRI-1: Initial version > Done. >

16 years

2
1
0 0

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

2005

xwiki-devs