September 2009 - xwiki-devs@xwiki.org

[xwiki-devs] Questions about fixing getRenderedContent() bug
by Vincent Massol 18 Feb '15

18 Feb '15

Hi, Im trying to fix http://jira.xwiki.org/jira/browse/XWIKI-4274 Basically if you do $xwiki.getDocument("someDoc").getRenderedContent() it'll get executed in the context of the current doc which I believe is wrong especially since other signatures of getRenderedContent() execute in the target document's context. I have fixed this locally but found that admin.vm for example is assuming that getRenderedContent() will get executed in the context of the calling doc (i.e. XWiki.Import when doing an import for example). FYI the chain flow is admin.vm -- getRenderedContent() --> XWiki.AdminSheet --> XWiki.AdminImportSheet --> importinline.vm, which requires the current doc to be XWiki.Import (to get/put attachments from/to it). I can fix this easily using a new getRenderedContent signature I've introduced. However I'm wondering if we have other places that incorrectly use getRenderedContent() and assume it won't be rendered in the context of the target document. Is this change too dangerous to make? If not know, we'll need to it quickly (2.1M1?) since it's an important bug IMO. WDYT? Thanks -Vincent

4 7

[xwiki-devs] Redirect to a space
by Bruno Amaro Almeida 04 Jun '13

04 Jun '13

Hi How can i redirect the users after login to a space ? I`m looking at login.vm but i have no clue to do this Thanks

4 6

[xwiki-devs] Pretty Time library
by Vincent Massol 11 Jul '12

11 Jul '12

Could be useful: http://ocpsoft.com/prettytime/ Idea of usage: For ex we could use that to show the last modified document dates for dates in the past week (for ex): "Document created 2 days ago" It's in the maven central repo and it's under LGPL -Vincent

5 7

[xwiki-devs] [Proposal] XWiki.org horizontal navigation + home page
by Vincent Massol 26 Mar '10

26 Mar '10

Hi there, I'd like to start a overhaul of the xwiki.org home page + a first level navigation overhaul. Today: * Home page = list the different products * First level nav = the ecosystem panel Problems: * We now have a single product: XE and all the others are actually modules that plugin into the main products. Hence we shouldn't focus on other products so much IMO. * I'd like to view xwiki.org as a forge of projects. Today our top level projects are the ones listed here: http://svn.xwiki.org/svnroot/xwiki/ * The main page should be more dynamic and show some news and activity instead of being static * People are confused by the top level navigation vs the second level one because they both use panels and it's not easy to differentiate them Proposal: * Use a horizontal top level navigation with the following items (from left to right): - Overview or Home (the main page) - Platform - Projects (when clicked will list all top level projects) - We could have the list of subproject available as submenu items too (as it's done on http://jboss.org/) - Support (when clicked will explain the various ways to get support including mailing list/forum, irc/jabber, FAQ & listing companies offering commercial support) - Contribute or Community (when clicked we'll get dev.xwiki.org) - Playground This means that the panels on the right will become the second level navigation and the content will depend completely on where you are on the site. * Have some facilities links in the header on the right: - News - Downloads (as a visible button maybe) * On the home page: - Have a nice diagram of the xwiki platform that shows how XE, XE modules are positioned on the platform so that people understand right away that xwiki is a collaborative web dev platform - Have a Highlight box with XE so that users looking for a full- fledged wiki can quickly see it and click on it + maybe one featured screenshot of an entry from the References page that would be different every time the page is refreshed (this could encourage people to add references + provide a link to the references directly) - Have a Featured project box and list 3-4 featured projects (XE, XEM, XEclipse, XOffice for ex to start with) - Have some news: -- latest 5 blog post titles -- latest 5 code zone additions (all snippet, plugins, macro, apps, etc included) -- latest 5 mailing list threads subjects (with links to our nabble forum) We could not have any second level navigation for the home page in order to have more space for displaying the elements above. WDYT? If/when we're ok in term of content maybe Cati (or anyone interested) could provide some mockups of what it could look like. Thanks -Vincent PS: Let's not get bogged down with details at this point. I think what's important is to make progress and refine later on. What's important is that we agree on the broad lines at this stage.

10 49

[xwiki-devs] [Proposal] Script Bridge
by Vincent Massol 04 Feb '10

04 Feb '10

Hi, This is following the proposal done here some time ago: http://markmail.org/message/nnybto3mluvp2rov Since we now have a generic Script notion we need to revisit it in that light. Also we really need to implement it now since more and more components are put in the velocity context (office importer, syntax factory, etc) and we need to bring some order. Here's a new generic proposal: Short term ======== * The variable "services" is bound in the script context. For ex in Velocity: $services * The Services object (ScriptServiceManager) has a ScriptService get(String serviceName) method which returns the service * We use the namespace: services.<module name>.<method>. Each module provides only one service entry point. * ScriptService interface (empty interface) represents a service to be bound in the context * ScriptServiceManager.get() looks for all components of role ScriptService and returns the component matching the the name as the component hint. Ex: @Component("mymodule") public class MyModuleScriptService implements ScriptService, MyModuleBusinessInterface { public void myMethod() {} } In script: {{velocity}} $services.mymodule.myMethod {{/velocity}} Medium term ========== * We handle @authorization(Authorization.PROGRAMMING) annotations to check for access rights. To do this in ScriptServiceManager.get() we use a Dynamic Proxy to implement MyModuleBusinessInterface (we probably need a ScriptService.getInterface() method to make it unambiguous). The Dynamic Proxy checks the annotation before proxying to the real object. WDYT? Thanks -Vincent PS: This is to answer Sergiu's question about where is getAvailableParserSyntaxes() from my other mail... ;) Answer: It would be in RenderingScriptService.

5 17

[xwiki-devs] [VOTE] Strategy for handling translations
by Vincent Massol 02 Jan '10

02 Jan '10

Hi devs, We need to define a strategy for better handling translations. I've had a call with Guillaume and Jean-Vincent and here's the process we'd like to propose: * One person is in charge of http://l10n.xwiki.org/. This means monitoring the work there, coordinating validation of key values and ensuring validated translations are incorporated in the source tree. Guillaume is willing to take that role for now. * The XE release manager has the responsibility of taking the validated keys on l10n.xwiki.org and committing them during the Milestone 2 dev (before the RC1). * The l10n manager should ping the release manager whenever there are translated and validated keys ready to be incorporated or if there have been important changes to be included in the release after M2 has been released. * The l10n manager should test XE and the applications after the keys have been applied to ensure quality. Basically the l10n manager is responsible for the quality of translations in general. Here's my +1 Thanks -Vincent

10 20

[xwiki-devs] [Proposal] Wiki macros improvement ideas
by Vincent Massol 09 Dec '09

09 Dec '09

Hi, Wiki macros currently require programming rights and thus are limited and in addition cannot be created in subwikis by the majority of users. Since I've now almost finished implementing component isolation I'd like to agree on what we want for wiki macros. Proposal: * Modify the wiki macro class to add a "Visibility" field with 2 values: - visible only in the current wiki - visible to everyone * Visible to everyone will require admin rights * Make the macro available to a user only if that user has view rights to the wiki macro page. This is to allow making a wiki macro private (when testing for example). It also allows making a macro visible only to a given group of users. Note: I considered having a "visible only to the current user" value for the Visibility field but I don't think it means much since if someone else edit the page and saves it, then suddenly the macro becomes visible only to that person... WDYT? Thanks -Vincent

2 5

[xwiki-devs] [Proposal] Component isolation implementations
by Vincent Massol 27 Nov '09

27 Nov '09

Hi, We have the need to isolate groups of components. For ex a wiki macro created in a subwiki should only be visible in that subwiki by default. Here's an implementation proposal that I'm planning to implement: * There's a Root Component Manager (the current CM) * There are 3 components which implement the ComponentManager role and with 3 hints: "wiki", "user" and "all". There's a CompositeComponentManager class that allows chaining CM and the "all" CM chains the "default" (root CM), "wiki" CM and "user" CM. This works the same as with the configuration module. * Other components can have CMs injected as they want (if not specified then it's the default, etc). For ex: @Requirement("all") private ComponentManager cm * Creation process. As for now the user creates the root CM and then the annotation loader will create the descriptors for the other CMs and register them against the root CM. They'll get instantiated once (singleton) the first time they're looked up. * In order to register a component for, say, a given "enterprise" wiki, we need to add a new property to the ComponentDescriptor: get/ setAdditionalData(Object data). For example: wikiCM.registerComponent(CD mycd) where cd.setAdditionalData("enterprise"). * Last, Guice uses Modules to isolate component definitions so it should be possible and relatively easy to port the implementation to Guice (even though Guice uses static Modules we can make them dynamic). WDYT? Thanks -Vincent

5 17

[xwiki-devs] Reduce heap exhaustion during export operation (and partly import for now)
by Denis Gervalle 26 Nov '09

26 Nov '09

Hi, As you knows, Import/Export operation on large XAR file cause problem. We felt on an even worse situation, where a single XWiki document is not properly exported due to heap exhaustion during the built of its XML DOM or due to large attachments. Having a look at the source, I have notice that many optimizations on the way the export is produce could be quite easily introduced. Currently, XWiki stored the exported document several times in memory during the operation, which impact performance negativly and is uselessly heavy on memory usage, even for reasonable documents. Therefore, I have started a large patch to avoid these caveats, here is the strategies I have followed: 1) The current implementation mostly build a DOM in memory for immediately serialized it into a stream. So I have remove the intermediate DOM and provide direct streaming of Element content by: 1.1) extending org.dom4j.XMLWriter to allow direct streaming of Element content into the output stream, as is, or Base64 encoded. Accessorily, my extension also ensure proper pairing of open/close tag. 1.2) writing a minimal DOMXMLWriter which extends my XMLWriter and could be used with the same toXML() code to build a DOMDocument to provide the toXMLDocument() methods to support the older implementation unchanged if ever needed. 1.3) using the above, minimal change to the current XML code was required 1.3.1) replacing element.add(Element) by either writer.writeElement) or writer.writeOpen(Element) 1.3.2) for large content, use my extensions, either writer.write(Element, InputStream) or writer.writeBase64(Element, InputStream) which use the InputStream for the element content 2) The current implementation for binary data such as attachments and export zip file is mostly based on in memory byte[] passing from function to function while these data initially came from a request.getInputStream() or are written to a response.getOutputStream (). So I have change these to passover the stream instead of the data: 2.1) using IOUtils.copy when required 2.2) using org.apache.commons.codec.binary.Base64OutputStream for base64 encoding when required 2.3) using an extension of ZipInputStream to cope with unexpected close() 2.4) avoid buffer duplication in favor of stream filters 3) Since most oftently used large data came from the database through an attachment content, it would be nice to have these attachment streamed from the database when they are too large. However, I feel that it is still too early to convert our binary into a blob, mainly because HSQLDB and MySQL still does not really support blob, just an emulation. These are also used to be cached in the document cache, and this will require improvement to support blob. However I propose to take the occasion to go in the direction of the blob by: 3.1) deprecating setContent(byte[]) and Byte[] getContent() in favor of newly created setContent(InputStream, int), InputStream getContentInputStream() and getSize() 3.2) Begin to use these new function as much as possible as 2) implied 3.3) this also open the ability to store attachment in another repository that support better the streaming aspect (ie: a filesystem) I am currently testing the above changes onto our client project, and I expect to provide a patch really soon. It will require an upgrade of org.apache.commons.codec to version 1.4, to have access to Base64OutputStream. I feel it will be a first step into the right direction, further improvement should be to: - import XML using a SAXParser without building a DOM in memory - manage JRCS Archive better, the way they are built and store raise the same issue then attachment - manage the recycle bin better for the same reason - improve caching to avoid caching very large stuffs WDYT ? Denis Gervalle -- SOFTEC sa http://www.softec.st

4 5

[xwiki-devs] [VOTE] What to do with RawBlock in plain text renderer ?
by Thomas Mortagne 24 Nov '09

24 Nov '09

Hi devs, We need to decide what to do with html macro content (or any other RawBlock content) in plain text renderer. For me the rule of plain text renderer should be to print anything we are able to print which mean printing any pure text content and skip styles for which obviously we don't have syntax. RawBlock content is pure text so we should print it. Note that first version of plain text renderer was printing html content and it was lost when introducing RawBlock. Here is my +1 for printing RawBlock content in plain text renderer. WDYT ? -- Thomas Mortagne

3 4

Template for Blog Entries
by handey＠gmail.com 09 Nov '09

09 Nov '09

Hello, I am working on creating blog entries using xwiki. I was wondering if it would be possible to create a template for the blog entries so that they will be more structured? Thank you for your time and help! Hande Aksac

5 4

[xwiki-devs] [VOTE] Change group id for top level pom from com.xpn to xwiki.org
by Vincent Massol 02 Nov '09

02 Nov '09

Hi From com.xpn.xwiki.platform to org.xwiki.platform. +1 Thanks -Vincent

7 7

[xwiki-devs] [Proposal] XWiki "2.0" Syntax
by Vincent Massol 27 Oct '09

27 Oct '09

Hi, Since I'm rewriting the new Rendering component (see http://dev.xwiki.org/xwiki/bin/view/Design/NewRenderingArchitecture) , we need to finalize the new syntax we want to have. Right now I'v planned to use the same wiki syntax as now (http://platform.xwiki.org/xwiki/bin/view/Main/ XWikiSyntax#HTextStyles) with only one change: all macros now need to be closed. For example: {macro}...{/macro} and {macro:text|param=value|.../} Is that ok with everyone or do we want to make changes? Thanks -Vincent

4 4

Re: [xwiki-devs] [xwiki-notifications] r12079 - in platform/core/trunk/xwiki-rendering/src/main/java/org/xwiki/rendering: macro transformation
by Vincent Massol 22 Oct '09

22 Oct '09

Hi Sergiu, Are you sure about this below? What's your use case? I find it strange to order by class name for an execution order. Thanks -Vincent On Aug 27, 2008, at 1:59 AM, sdumitriu (SVN) wrote: > Author: sdumitriu > Date: 2008-08-27 01:59:21 +0200 (Wed, 27 Aug 2008) > New Revision: 12079 > > Modified: > platform/core/trunk/xwiki-rendering/src/main/java/org/xwiki/ > rendering/macro/AbstractMacro.java > platform/core/trunk/xwiki-rendering/src/main/java/org/xwiki/ > rendering/transformation/AbstractTransformation.java > Log: > XWIKI-2568: Continue implementing the new Rendering Architecture > Improve the macro and transformation comparer so that component > implementations with the same priority are ordered by the classname. > > > Modified: platform/core/trunk/xwiki-rendering/src/main/java/org/ > xwiki/rendering/macro/AbstractMacro.java > =================================================================== > --- platform/core/trunk/xwiki-rendering/src/main/java/org/xwiki/ > rendering/macro/AbstractMacro.java 2008-08-26 23:57:19 UTC (rev 12078) > +++ platform/core/trunk/xwiki-rendering/src/main/java/org/xwiki/ > rendering/macro/AbstractMacro.java 2008-08-26 23:59:21 UTC (rev 12079) > @@ -78,6 +78,9 @@ > */ > public int compareTo(Macro< ? > macro) > { > - return getPriority() - macro.getPriority(); > + if (getPriority() != macro.getPriority()) { > + return getPriority() - macro.getPriority(); > + } > + return > this > .getClass > ().getSimpleName().compareTo(macro.getClass().getSimpleName()); > } > } > > Modified: platform/core/trunk/xwiki-rendering/src/main/java/org/ > xwiki/rendering/transformation/AbstractTransformation.java > =================================================================== > --- platform/core/trunk/xwiki-rendering/src/main/java/org/xwiki/ > rendering/transformation/AbstractTransformation.java 2008-08-26 > 23:57:19 UTC (rev 12078) > +++ platform/core/trunk/xwiki-rendering/src/main/java/org/xwiki/ > rendering/transformation/AbstractTransformation.java 2008-08-26 > 23:59:21 UTC (rev 12079) > @@ -52,6 +52,9 @@ > */ > public int compareTo(Transformation transformation) > { > - return getPriority() - transformation.getPriority(); > + if (getPriority() != transformation.getPriority()) { > + return getPriority() - transformation.getPriority(); > + } > + return > this > .getClass > ().getSimpleName > ().compareTo(transformation.getClass().getSimpleName()); > } > }

2 4

[xwiki-devs] [PROPOSAL] OfficeImporter API changes for 2.1
by Asiri Rathnayake 14 Oct '09

14 Oct '09

Hi Devs, I've been refactoring OfficeImporter code base to make it more modular and maintainable. With these refactorings I believe we can improve the main OfficeImporter API. Currently OfficeImporter component interface exposes following two methods: <code> void importStream(InputStream documentStream, String documentFormat, String targetWikiDocument, Map<String, String> params) throws OfficeImporterException; String importAttachment(String documentName, String attachmentName, Map<String, String> params) throws OfficeImporterException; </code> Problems with these two methods are; * Loosely typed (params) * Both of them perform almost the same task. There is also a problem with how customizations to the normal import process is implemented. So, I propose we deprecate these two methods and introduce following methods: <code> XHTMLOfficeDocument officeToXHTML(byte[] officeFileData, String referenceDocument, boolean filterStyles) throws OfficeImporterException; XDOMOfficeDocument xhtmlToXDOM(XHTMLOfficeDocument xhtmlOfficeDocument) throws OfficeImporterException; XDOMOfficeDocument officeToXDOM(byte[] officeFileData, String referenceDocument, boolean filterStyles) throws OfficeImporterException; XDOMOfficeDocument buildPresentation(byte[] officeFileData) throws OfficeImporterException; Map<TargetPageDescriptor, XDOMOfficeDocument> splitXDOM(XDOMOfficeDocument xdomOfficeDocument, int[] headingLevelsToSplit, String namingCriterionHint, String baseDocumentName) throws OfficeImporterException; </code> As you can see, these methods are more granular and the responsibilities are well defined. Customizing the import process can be done from the client code. For an example: 1. Make the initial import from office to XHTMLOfficeDocument. 2. Perform customizations on the XHTMLOfficeDocument (w3c DOM). 3. Import the XHTMLOfficeDocument into XDOMOfficeDocument. 4. Perform customizations on the XDOMOfficeDocument (XDOM). 5. Split the XDOMOfficeDocument into multiple XDOMOfficeDocument instances. 6. Perform customizations on these child XDOMOfficeDocument instances. 7. Render the XDOMOfficeDocument instances & save them into wiki pages. (saving can be done in client code) I think this interface will make it easy to extend & maintain officeimporter functionality in the future. For an example, a preview function can be implemented with above methods (which is not possible with the previous interface). WDYT? Here's my +1. Thanks. - Asiri

1 2

[xwiki-devs] [Help] About Sanity Check
by Junjun He 08 Oct '09

08 Oct '09

Hi, there, I'm running the sanity check script on mysql 5.0.54 and there are some queries return results. To correct these problems, should I simply just delete these results or I need to do something else before the deletion? Take an example, for the following query: select * from xwikiproperties,xwikilargestrings where xwp_classtype='com.xpn.xwiki.objects.StringListProperty' and xwp_name=xwl_name and xwp_id=xwl_id +---------+-----------------+--------------------------------------+---------+-----------------+--------------------------------------------- | XWP_ID | XWP_NAME | XWP_CLASSTYPE | XWL_ID | XWL_NAME | XWL_VALUE +---------+-----------------+--------------------------------------+---------+-----------------+--------------------------------------------- | -1877168607 | subscribedDocuments | com.xpn.xwiki.objects.StringListProperty | -1877168607 | subscribedDocuments | Main.WebSearch|Main.Categories | 261169163 | subscribedDocuments | com.xpn.xwiki.objects.StringListProperty | 261169163 | subscribedDocuments | Service Measurements.WebHome|IMProcess.WebHome | 683557787 | subscribedWebs | com.xpn.xwiki.objects.StringListProperty | 683557787 | subscribedWebs | Replication | 683557787 | subscribedDocuments | com.xpn.xwiki.objects.StringListProperty | 683557787 | subscribedDocuments | IIS.WebHome I've got couple hundred lines of records like this. If I delete all these records, what kind of impact will be to my content? Thank you very much for your help -- View this message in context: http://n2.nabble.com/Help-About-Sanity-Check-tp3670302p3670302.html Sent from the XWiki- Dev mailing list archive at Nabble.com.

2 2

[xwiki-devs] [VOTE] Release XE 1.9.4 and XEM 1.7.4
by Jean-Vincent Drean 06 Oct '09

06 Oct '09

Hi devs, Since XE 2.0 will be released soon I'd like to release XE 1.9.4 and XEM 1.7.4 tomorrow. After this XEM release I suggest to create the 1.7 branch and make XEM trunk 2.0. Changelog since 1.9.3: XWIKI-4249 . key acts like the delete key at the end of the list items XWIKI-4263 Include macro should expose the default value of "context" property XWIKI-4175 Livetable sorting failed when the text of the header column is clicked XWIKI-4093 Refactor the code to use the new EventHandler system XWIKI-4158 Update the Feed Plugin to work properly with latest XWiki and Rome Code XWIKI-4170 Wrong encoding in ApplicationResources_pt.properties XWIKI-4139 New {{formula}} macro for displaying mathematical expressions Here's my +1. JV.

8 13

[xwiki-devs] attachment's mime-types
by Paul Libbrecht 04 Oct '09

04 Oct '09

Hello XWiki developers, can someone explain me what is the strategy to define the mime-type of an attachment? I see not configurable map nor any setter on the attachment types. Is there any way I can enrich this or is it simply taking over the mime-type provided the browser (which, too often, ends up being application/octet-stream) ? thanks in advance paul

4 9

[xwiki-devs] [Discussion] XWiki Enterprise 2.1 Roadmap
by Guillaume Lerouge 03 Oct '09

03 Oct '09

Hi XWiki Devs & Users, It's roadmap time again! Based on the previous roadmap, feedback on the lists and the results of the survey we conducted (see http://www.xwiki.org/xwiki/bin/view/Blog/Features+Survey+Results ), here's a list of stuff we might want to work on in the XE 2.1 timeframe which will last approximately until December 2009: IMPROVEMENTS On top of the usual bugfix work, here's a list of improvements we might want to bring in the course of the release in order to stabilize the 2. branch as much as we can: - Colibri skin - Clean the skin so that it's no longer a pile of code added on top of Toucan - Improve the ColorTheme page (theme catalog, theme creation) - WYSIWYG editor - Test and improve IE8 compatibility - Test and improve Chrome / Safari compatibility - Add more translations - Rendering - Internationalize - Add translations - Conversion to 2.0 syntax - XAR 2.0 (notably Blog & Panels) - Office importer - The application shouldn't be displayed when the office server is not running - Wiki macros - Textarea should be larger - Importer - Make the import create new versions of existing pages instead of overwriting them - *Search (one of the most asked for features in the survey)* - Fix the bugs with our Lucene Search implementation to make it the default one - Finish implementing the new search UI - Performance (one of the most asked for features in the survey) - Clean and apply Denis Gervalle's patch related to attachment upload memory handling - Clean and apply Caleb James DeLisle's patch related to document loading - Keep working on making the skin lighter - Other? - User Profile UI - Improve the watchlist UI - Make the user profile look clearer NEW FEATURES We won't have the time to work on all of them, but here's a list of new features we might want to consider working on: - Skin -> revamp / move the action bar - CAPTCHA Integration -> make CAPTCHAS available on login / comments - Application Manager -> create applications descriptors, ability to version applications - Document Type Manager -> make XClass & application creation easy through a nicer UI - Invitation Manager -> make it easier to add users to the wiki (send an email allowing account creation) - Multipage Management tools -> create and export lists of pages Feedback is welcome and appreciated. Thanks, Guillaume -- Guillaume Lerouge Product Manager - XWiki Skype: wikibc Twitter: glerouge http://guillaumelerouge.com/

4 4

[xwiki-devs] [Proposal] daily watchlist notifications for XWiki.org sites on the notification list
by Jerome Velociter 01 Oct '09

01 Oct '09

Hi all, I propose we create a user on XWiki.org that will subscribe to daily watchlist notifications on the xwiki.org wikis, with notifications(a)xwiki.org as email address. We can try to watch entire wikis, though we might get some noise on certain wikis (for example with all users that are created on the main wiki). WDYT ? +1 to try out this. Jerome.

7 11

[xwiki-devs] [VOTE] Put a new line at the beginning and the end of group content in xwiki/2.0 renderer
by Thomas Mortagne 01 Oct '09

01 Oct '09

Hi devs, I would like to modify the xwiki/2.0 renderer to print the group with a trailing and ending new line: 1.A ((( * list1 * list 2 ))) instead of 1.B (((* list1 * list 2))) for example but it also mean: 2.A | ((( * list ))) | second cell instead of 2.B | (((* list with one item))) Here are my arguments: * i tough of that idea at first because it's not very easy/clean to support well the escaping of an ending ) before a ending group in an events based renderer, the problem is that you need to bufferize at least 4 events (if not more) to know when you print the ) character that it will be followed by end group syntax when printed. For example it can be the last character of paragraph in the last cell or last row of a table before the end of the group * i prefer to "break" 2.A done on purpose than 1.A done on purpose since it's not possible to support both currently * even with 2.A it's more readable to have it in its own line IMO Here is my +1 -- Thomas Mortagne

6 8

[xwiki-devs] XWiki Workspaces built on top of Enterprise 2.0?
by glenn_engel＠agilent.com 30 Sep '09

30 Sep '09

With the release of Enterprise 2.0 (congratulations!) are there any plans to update XWiki Workspaces to utilize the 2.0 framework? -- Glenn

2 1

[xwiki-devs] Xwiki 2.0 migration problems
by Valdis Vītoliņš 30 Sep '09

30 Sep '09

Hello friends! I have migrated xwiki testing instance from 1.8 to the 2.0 http://test.odo.lv:8180/xwiki/bin/view/Main/ I could import XAR 2.0 only using hack with stopping 2.0 instance, and ran updated DB with 1.8 web instance, imported XAR, and svitched back to web 2.0. It worked previous times. Though currently there are many regressions: 1. Can't choose different view/edit modes from the menu, only default ones ar accessible, as drop-down menus aren't shown, 2. Can log in only with superuser. Using other users Xwiki says: "You are not allowed to view this document or perform this action." 3. Cannot edit neither groups, nor users. When form is opened, it stills with progress bar and "Loading..." message. 4. Site index doesn't work. In summary it seems, there ar bunch of pages where either Javascipt doesn't work properly, or there is global problems with page access. Site is multi lingual, there are lot of custom objects in some spaces. I couldn't find anything interesting in tomcat logs. Can you point some directions, what to check and investigate? Thanks in advance, Valdis

4 4

[xwiki-devs] Who can design nice and unique color themes for xwiki.org
by Vincent Massol 30 Sep '09

30 Sep '09

Hi, Since we're upgrading xwiki.org to 2.0 it would be nice to use the new colibri skin. So who can design nice and unique color themes for xwiki.org? Thanks -Vincent

8 28

[xwiki-devs] FAQ Tutorial
by Guillaume Lerouge 30 Sep '09

30 Sep '09

Hi Devs, Silvia and I have been working on updating & improving the FAQ tutorial located at: http://platform.xwiki.org/xwiki/bin/view/DevGuide/FAQTutorial Apart from the conversion to 2.0, the most notable change I brought is to provide some code to be used on the homepage of the FAQ space. This code removes the need for the user to go to the FAQ.FAQClass page to create new FAQs documents. It's more in line with our current best practices for application (very little applications create new items directly from the class page). However in doing so I'm not sure I used the most streamlined code. I'd be glad if some users could try following the tutorial to see whether it meets their need and if a dev could give it a look in order to improve it further. Thanks, Guillaume -- Guillaume Lerouge Product Manager - XWiki Skype: wikibc Twitter: glerouge http://guillaumelerouge.com/

2 2

Re: [xwiki-devs] [xwiki-notifications] r24144 - enterprise/trunk/distribution-test/wysiwyg-tests/src/test/it/com/xpn/xwiki/it/selenium
by Vincent Massol 30 Sep '09

30 Sep '09

On Sep 30, 2009, at 12:00 PM, Anca Paula Luca wrote: > On 09/30/2009 12:58 PM, mflorea (SVN) wrote: >> Author: mflorea >> Date: 2009-09-30 11:58:20 +0200 (Wed, 30 Sep 2009) >> New Revision: 24144 >> >> Modified: >> enterprise/trunk/distribution-test/wysiwyg-tests/src/test/it/com/ >> xpn/xwiki/it/selenium/LineTest.java >> enterprise/trunk/distribution-test/wysiwyg-tests/src/test/it/com/ >> xpn/xwiki/it/selenium/StandardFeaturesTest.java >> Log: >> Fixed some WYSIWYG standard features tests. >> > > [snip] > >> >> - // More the caret between x and y. >> + // More the caret between x and Y. Using some other letters might be easier.... like "abc" (or "def" if "abc" is already used)... ;) -Vincent > > typo > > Happy coding, > Anca > >> moveCaret("XWE.body.firstChild.firstChild", 1); >> >> // Insert HR in the middle of the paragraph.

1 0

[xwiki-devs] Anyone using XWiki with an open source Java runtime?
by Vincent Massol 30 Sep '09

30 Sep '09

Hi, I'm interested to know if XWiki works with an open source JDK. Anyone using one for XWiki? Thanks -Vincent

3 2

[xwiki-devs] newLoadXWikiDoc works great, but ListProperty.equals must be changed.
by Caleb James DeLisle 30 Sep '09

30 Sep '09

I have been testing and analyzing my new loader for a few days now, It seems to be working perfectly. I have written a comprehensive testing script available here: http://jira.xwiki.org/jira/browse/XWIKI-2874 There is a change which must be made: ListProperty.equals must be change to convert null values to empty ArrayList objects in the event that it is asked to compare to a BaseProperty. The change looks like this: Index: core/xwiki-core/src/main/java/com/xpn/xwiki/objects/ListProperty.java =================================================================== --- core/xwiki-core/src/main/java/com/xpn/xwiki/objects/ListProperty.java (revision 23877) +++ core/xwiki-core/src/main/java/com/xpn/xwiki/objects/ListProperty.java (working copy) @@ -145,6 +145,14 @@ return true; } + //The save opperation triggers hibernate to compare the new property to the original + //If the property was gotten by a query like "SELECT prop FROM BaseProperty AS prop WHERE..." + //and the value stored in the db is null, hibernate thinks the original is a BaseProperty, + //thus we may end up comparing a ListProperty to a BaseProperty with value = null. + if (list2 == null && obj.getClass().getName().indexOf(".BaseProperty")!=-1){ + list2 = new ArrayList<String>(); + } + if (list1.size() != list2.size()) { return false; } Why is this necessary? Because the new loader loads all types of properties at once with a query like "select prop from BaseProperty prop where prop.id in (:ids)" (ids being the list of object ids from the objects attached to the document.) This is okay until the property is saved, then hibernate has to check that the id of the property is the same. The id of the property is an empty property with the same name and object id number. Because the property is loaded by a query for BaseProperty, if the value in the database is null, Hibernate thinks the property IS a BaseProperty and passes a BaseProperty to the equals method. If these changes are not made, we get this exception. java.lang.NullPointerException at com.xpn.xwiki.objects.ListProperty.equals(ListProperty.java:148) at org.hibernate.event.def.ProxyVisitor.isOwnerUnchanged(ProxyVisitor.java:44) at org.hibernate.event.def.OnUpdateVisitor.processCollection(OnUpdateVisitor.java:45) at org.hibernate.event.def.AbstractVisitor.processValue(AbstractVisitor.java:101) at org.hibernate.event.def.AbstractVisitor.processValue(AbstractVisitor.java:61) at org.hibernate.event.def.AbstractVisitor.processEntityPropertyValues(AbstractVisitor.java:55) at org.hibernate.event.def.AbstractVisitor.process(AbstractVisitor.java:123) at org.hibernate.event.def.DefaultSaveOrUpdateEventListener.performUpdate(DefaultSaveOrUpdateEventListener.java:293) at org.hibernate.event.def.DefaultSaveOrUpdateEventListener.entityIsDetached(DefaultSaveOrUpdateEventListener.java:223) at org.hibernate.event.def.DefaultUpdateEventListener.performSaveOrUpdate(DefaultUpdateEventListener.java:33) at org.hibernate.event.def.DefaultSaveOrUpdateEventListener.onSaveOrUpdate(DefaultSaveOrUpdateEventListener.java:70) at org.hibernate.impl.SessionImpl.fireUpdate(SessionImpl.java:564) at org.hibernate.impl.SessionImpl.update(SessionImpl.java:552) at org.hibernate.impl.SessionImpl.update(SessionImpl.java:544) at com.xpn.xwiki.store.XWikiHibernateStore.saveXWikiProperty(XWikiHibernateStore.java:1726) at com.xpn.xwiki.store.XWikiHibernateStore.saveXWikiCollection(XWikiHibernateStore.java:1072) at com.xpn.xwiki.store.XWikiHibernateStore.saveXWikiDoc(XWikiHibernateStore.java:582) at com.xpn.xwiki.store.XWikiCacheStore.saveXWikiDoc(XWikiCacheStore.java:181) at com.xpn.xwiki.store.XWikiCacheStore.saveXWikiDoc(XWikiCacheStore.java:174) at com.xpn.xwiki.XWiki.saveDocument(XWiki.java:1309) I suggest we apply the patch to 2.1, but leave the functionality deactivated in xwiki.cfg until 2.2 so there is time to see if there are any latent issues. I don't expect any but I don't know what it might do with corrupt data in storage. Better safe than sorry. Caleb James DeLisle

1 0

[xwiki-devs] [VOTE] DAB API changes (for 2.0.1)
by Vincent Massol 30 Sep '09

30 Sep '09

Hi, I'd like to add: * List<AttachmentName> getAttachments(DocumentName documentName) throws Exception; * byte[] getAttachmentContent(AttachmentName attachmentName) throws Exception; And deprecate: * List<String> getAttachmentURLs(DocumentName documentName, boolean isFullURL) throws Exception; * byte[] getAttachmentContent(String documentName, String attachmentName) throws Exception; I need this fix a bug in the Script Macro when using jarurls parameter (for 2.0.1). Here's my +1 Thanks -Vincent

7 7

[xwiki-devs] Xwiki bundled with Ubuntu
by Valdis Vītoliņš 29 Sep '09

29 Sep '09

Hello friends! I'd like suggest to check how to bundle Xwiki with/in Ubuntu repositories. As examples I can mention Alfresco (http://wiki.alfresco.com/wiki/Installing_Alfresco_on_Ubuntu_8.04) and Openbravo (http://wiki.openbravo.com/wiki/ERP/2.50/Ubuntu_Installation#Ubuntu_Installa…) which are the same J2EE application stack. It will lower entry barrier for Xwiki usage and I hope will greatly increase Xwiki user base. Sincerely, Valdis Vitolins

2 1

[xwiki-devs] Testing exceptions in JUnit 4.7
by Vincent Massol 29 Sep '09

29 Sep '09

Hi, I've been wondering how to test exceptions in JUnit 4.x when you want to assert the exception message. Just found an answer: http://www.wakaleo.com/blog/225-testing-exceptions-in-junit-47 It looks to me slightly better than using the try/fail/catch strategy. WDYT? Thanks -Vincent

2 1

[xwiki-devs] [Proposal] Change Panel usage of ID attribute in favor of CLASS attribute + naming strategy
by Vincent Massol 29 Sep '09

29 Sep '09

Hi, We have a pb if we display several times the same panel on a page (for ex for the search panel) since if the panel defines an ID this ID will not be unique in the page and thus will produce invalid XHTML. This happens for ex when you're on the panel page itself and that panel is displayed in the right or left columns. I'm proposing that we change the use of ID in favor of CLASSNAME for panels. For example for the search panel right now we have: #panelhiddenheader($msg.get("panels.search.title")) <form action="$xwiki.getURL('Main.WebSearch')"> <div id="globalsearch"> <input id="globalsearchinput" type="text" name="text" ... It'll become: #panelhiddenheader($msg.get("panels.search.title")) <form action="$xwiki.getURL('Main.WebSearch')"> <div class="globalsearch"> <input id="globalsearchinput" type="text" name="text" I think it would also be best to define a naming strategy. What about "panel-<short name of the panel page in lowercase and without any panel suffix>" So for Panels.Search it would be "panel-search" and for Panels.QuickLinks it would be "panel-quicklinks" Note: Changing id="globalsearch" to class="globalsearch" (or class="panel-search") means changing lots of places in the skins (albatross, finch, toucan, colibri). But I don't see any better way anyway. Thanks -Vincent

3 5

[xwiki-devs] [ANN] XWiki Enterprise and XWiki Enterprise Manager 2.0 released
by Thomas Mortagne 28 Sep '09

28 Sep '09

The XWiki development team is pleased to announce the release of XWiki Enterprise and XWiki Enterprise Manager 2.0. Go grab it at http://www.xwiki.org/xwiki/bin/view/Main/Download More than 400 issues were fixed from XWiki Enterprise 1.9.3 to XWiki Enterprise 2.0. Many thanks to the very active community for all the reports and the contributions ! Main changes from 1.9.3: * new Colibri skin and easy color modifications * many new 2.0 macro and improvements on existing macros * new wiki based 2.0 macros * new event distribution and clustering support * many WYSIWYG improvements * many rendering improvements * many general UI improvements * new Swedish and Korean translation and updated translations for lots of other languages For more informations see the releases notes at: http://www.xwiki.org/xwiki/bin/view/Main/ReleaseNotesXWikiEnterprise20 and http://www.xwiki.org/xwiki/bin/view/Main/ReleaseNotesXEM20 Thanks -The XWiki dev team

9 8

[xwiki-devs] [VOTE] Hide Office Importer Features when the OOo server isn't running
by Guillaume Lerouge 28 Sep '09

28 Sep '09

Hi Devs, right now an user can go to the Office Importer page and try uploading a file even when the backend OOo server isn't running. This leads to usability issues. Thus I'd like to send a vote on the following 2 items: - On the Office Importer page, add the following message: - "You cannot import an Office document since the conversion server has not been started. Please ask an administrator to get it started for you." - If the current user is an admin, the message should read: "You cannot import an Office document since the OpenOffice server has not been started yet. You can start the OpenOffice server and manage it from this page (link to the OOo server administration page)." - In the action bar: add a check to see whether the OOo server is running and don't display the link if the OOo server is not. Here's my +1 to both. Guillaume -- Guillaume Lerouge Product Manager - XWiki Skype: wikibc Twitter: glerouge http://guillaumelerouge.com/

5 16

[xwiki-devs] Remove the notification message in OpenOffice Server Administration UI
by Asiri Rathnayake 28 Sep '09

28 Sep '09

Hi All, This is very trivial, I have put the message: "You can change these configuration options via *WEB-INF/xwiki.properties*file." In OpenOffice server administration UI which is actually not required (since this UI is meant to be used by admins who knows about xwiki.properties). I'm not sure this is worth a vote but just in case, here is my +1. Thanks. - Asiri

2 1

[xwiki-devs] [Discussion] Programming rights grant policy
by Asiri Rathnayake 28 Sep '09

28 Sep '09

Hi all, Currently XWikiRightService has two methods for evaluating programming rights: XWikiRightService#hasProgrammingRights(XWikiContext context); & XWikiRightService#hasProgrammingRights(XWikiDocument doc, XWikiContext context); Since newer components are using DAB (Document Access Bridge) than directly accessing XWikiRightService, only one form of programming rights evaluation is available: <code> public boolean hasProgrammingRights() { XWikiContext xcontext = getContext(); return xcontext.getWiki().getRightService().hasProgrammingRights(xcontext.getDoc(), xcontext); } </code> So the procedure carried out in evaluating programming rights is: - If the context document is null, check whether the current user has programming rights or if he is the superadmin - If the context document is not null, check if the author of the context document has programming rights on the context document itself. Recently we came across a requirement where we need to grant programming rights to some scripts programmatically. See http://jira.xwiki.org/jira/browse/XWIKI-4262 With the current policy for programming rights evaluation, this is not possible (not without side effects). So we need to decide a new method for granting programming rights. One approach proposed by Thomas Mortagne is to change the programming rights evaluation as below: - Check if a particular flag is set in context (like "hasProgrammingRights"), if so current execution is considered to have programming rights - Else do the earlier evaluation process. This way we can grant programming rights in a programmatical fashion and since XWikiContext is mostly read-only for normal users, they won't be allowed to hijack programming rights by tampering with XWikiContext. Please let us know your opinions regarding this issue. Thanks. - Asiri

1 1

[xwiki-devs] [Proposal] Operation Stabilisation till 1st of November + 2.0.x releases
by Vincent Massol 28 Sep '09

28 Sep '09

Hi devs, I'd like to propose a stabilisation operation starting now and for 1 month (ie from now to the 1st of November) The idea would be that **no new feature** is allowed to be committed in SVN. We have several domains to stabilize quickly after the 2.0 release: - Colibri skin - WYSIWYG editor - Rendering - XAR 2.0 - conversion to 2.0 syntax. - internationalization texts - Various (office importer page shouldn't be displayed when the office server is not running, wiki macro textarea should be larger, etc) These should go in both the trunk (2.1) and for 2.0.x I also propose to release a 2.0.1 in 2 weeks time (i.e. for the 12th of October) and to continue 2.0.x release every 2 weeks till we reach that month's end. WDYT? Thanks -Vincent

9 10

[xwiki-devs] Features Survey Results
by Guillaume Lerouge 28 Sep '09

28 Sep '09

Hi XWikiers, as promised I posted a blog article listing the results of the XWiki Features Survey. You can read it here: http://www.xwiki.org/xwiki/bin/view/Blog/Features+Survey+Results We'll use the results during the discussion about the XE 2.1 roadmap. I've also included the original result files for the data crunchers among you to play with ;-) Thanks a lot to all of you who took part to the survey! Guillaume -- Guillaume Lerouge Product Manager - XWiki Skype: wikibc Twitter: glerouge http://guillaumelerouge.com/

1 0

[xwiki-devs] [PROPOSAL] {{doclist}} macro syntax - [Take 1]
by Asiri Rathnayake 28 Sep '09

28 Sep '09

Hi Devs, I've been thinking about the new {{doclist}} macro syntax which is going to be the successor of old livetable macro. Following is the syntax I have in mind: {{doclist <macro_parameters>}} |=(% <column_spec> %) column_name |=(% <column_spec> %) column_name |=(% <column_spec> %) column_name ... {{/doclist}} [macro_parameters] class="" ## bounds the table to a class. source="" ## can be a document name or a url. (will be ignored if class parameter is set) rowCount="" ## number of rows per page. tagCloud="" ## whether to display the tag cloud or not. (On/Off) callback="" ## name of a js function to be used for handling server (JSON) response manually. [column_spec] mapping="" ## name of the json attribute to which this column should be bound to. [1] (see below) selected="" ## if this column should be selected by default. order="" ## Default sort order for this column (applies only if this is the default selected column). isHtml="" ## if the result JSON string should be treated as html and directly injected into cell content. filterable="" ## whether this column should present a filter or not. sortable="" ## whether this columnd should be sortable or not. filterType="" ## what type of a filter to be used (only for filterable columns). linkType="" ## type of link to be used if a cell value should link to the original document. [2] (see below) [1] - mapping: This is a mandatory parameter. I'm not sure if this is the correct name for the parameter. For the default implementation (XWiki.DocListMacroResults) we have to decide the names of the JSON properties that will be returned, we could use: "doc.<fieldName>" ## for document metadata. "obj.<propertyName>" ## for object properties when the table is bound to a class. "actions" ## special column for listing all the actions available for the current user. * We could have an special "function_name(field1, field2, ....)" mapping parameter which will deligate the mapping function to a local js function. This can be useful if someone wants to calculate a column value based on the returned results. * Question: Do we need to have attachment / image columns? [2] - linkType: We can have "none", "view", "edit" & "inline" type of links. Any other type of link? You can compare this doclist macro specification with the old livetable macro spec here: http://code.xwiki.org/xwiki/bin/view/Macros/LiveTableMacro. WDYT? Thanks. - Asiri

4 12

[xwiki-devs] Groovy Blog Application: 1st Draft
by Andreas Schaefer 28 Sep '09

28 Sep '09

Hi Geeks I just uploaded the first draft of the Blog Application in Grooyv: http://jira.xwiki.org/jira/browse/XABLOG-81 You need to install the Blog Plugin (also attached there) and then import the XAR file. It uses its own space called "GBlog" and so you don't need to worry that Blog is gone because of it. The current state is that most of the staff works (sort of) including the panels but: 1. The application is not up to date with the latest code 2. Some stuff might look ugly or does not work properly. If so please let me know. 3. I need to redesign the Groovy structure to take better care of the code. I postponed that so far because I wanted to make sure I had a good picture of all the problems with the rewrite. Let me know what you think. Cheers - Andy

1 0

Re: [xwiki-devs] [xwiki-notifications] r24079 - platform/core/trunk/xwiki-core/src/main/java/com/xpn/xwiki/doc
by Vincent Massol 27 Sep '09

27 Sep '09

On Sep 27, 2009, at 5:18 AM, sdumitriu (SVN) wrote: > Author: sdumitriu > Date: 2009-09-27 05:18:20 +0200 (Sun, 27 Sep 2009) > New Revision: 24079 > > Modified: > platform/core/trunk/xwiki-core/src/main/java/com/xpn/xwiki/doc/ > XWikiDocument.java > Log: > XWIKI-4416: Add getPrefixedFullName in XWikiDocument > Done. > > Modified: platform/core/trunk/xwiki-core/src/main/java/com/xpn/xwiki/ > doc/XWikiDocument.java > =================================================================== > --- platform/core/trunk/xwiki-core/src/main/java/com/xpn/xwiki/doc/ > XWikiDocument.java 2009-09-27 02:37:41 UTC (rev 24078) > +++ platform/core/trunk/xwiki-core/src/main/java/com/xpn/xwiki/doc/ > XWikiDocument.java 2009-09-27 03:18:20 UTC (rev 24079) > @@ -651,12 +651,20 @@ > public String getFullName() > { > StringBuffer buf = new StringBuffer(); > - buf.append(getSpace()); > - buf.append("."); > + buf.append(getSpace()).append("."); > buf.append(getName()); > return buf.toString(); > } > > + public String getPrefixedFullName() > + { > + StringBuffer buf = new StringBuffer(); > + buf.append(getDatabase()).append(":"); > + buf.append(getSpace()).append("."); > + buf.append(getName()); > + return buf.toString(); > + } Shouldn't users of this method instead use DocumentName? Couldn't we instead introduce a getDocumentName() in XWikiDocument. Of course if the calling code needs a string (which it shouldn't except in very rare cases but right now it's possible it needs one because not all our api are using DocumentName) then it can use the DocumentNameSerializer. Thanks -Vincent

1 1

[xwiki-devs] Fwd: The Release of Lucene 2.9
by Vincent Massol 25 Sep '09

25 Sep '09

fyi -Vincent Begin forwarded message: > From: Mark Miller <markrmiller(a)apache.org> > Date: September 25, 2009 6:15:57 PM CEDT > To: announce(a)apache.org > Subject: The Release of Lucene 2.9 > Reply-To: markrmiller(a)apache.org > > -----BEGIN PGP SIGNED MESSAGE----- > Hash: SHA512 > > Hello Lucene users, > > On behalf of the Lucene dev community (a growing community far larger > than just the committers) I would like to announce the release of > Lucene 2.9. > > While we generally try and maintain full backwards compatibility > between major versions, Lucene 2.9 has a variety of breaks that are > spelled out in the 'Changes in backwards compatibility policy' section > of CHANGES.txt. > > We recommend that you recompile your application with Lucene 2.9 > rather than attempting to “drop” it in. This will alert you to any > issues you may have to fix if you are affected by one of the backward > compatibility breaks. As always, its a really good idea to thoroughly > read CHANGES.txt before upgrading. > > Lucene 2.9 comes with a bevy of new features, including: > > * Per segment searching and caching (can lead to much faster reopen > among other things) > > * Near real-time search capabilities added to IndexWriter > > * New Query types > > * Smarter, more scalable multi-term queries (wildcard, range, etc) > > * A freshly optimized Collector/Scorer API > > * Improved Unicode support and the addition of Collation contrib > > * A new Attribute based TokenStream API > > * A new QueryParser framework in contrib with a core QueryParser > replacement impl included. > > * Scoring is now optional when sorting by Field, or using a custom > Collector, gaining sizable performance when scores are not > required. > > * New analyzers (PersianAnalyzer, ArabicAnalyzer, > SmartChineseAnalyzer) > > * New fast-vector-highlighter for large documents > > * Lucene now includes high-performance handling of numeric fields. > Such fields are indexed with a trie structure, enabling simple to > use and much faster numeric range searching without having to > externally pre-process numeric values into textual values. > > --- > > And many, many more features, bug fixes, optimizations, and various > improvements. You can find the full list of changes here: > > http://lucene.apache.org/java/2_9_0/changes/Changes.html > > > Many changes have also occurred in Lucene's Contrib area: > > http://lucene.apache.org/java/2_9_0/changes/Contrib-Changes.html > > > Binary and source distributions are available at > http://www.apache.org/dyn/closer.cgi/lucene/java/ > > Lucene artifacts are also available in the Maven2 repository at > http://repo1.maven.org/maven2/org/apache/lucene/ > > The Next Release: > > The next release will be Lucene 3.0. This should come along shortly, > and will > remove all of the deprecated code in Lucene 2.9. Lucene 3.0 will also > be the > first release to move from Java 1.4 to Java 1.5 as a requirement. > > > Thanks, > > Mark Miller > -----BEGIN PGP SIGNATURE----- > Version: GnuPG v1.4.9 (GNU/Linux) > Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ > > iQIcBAEBCgAGBQJKvOy9AAoJEBMFmEzrAZn4rmYP/AsmtlRAOZzCUyGo83pkYyPx > kR2XdaZPUN8Le5RdaW2BuYtm+i3OLhsLFrWeJwCm/DrFM7tTlwLtFGFnYyga3BM6 > L+TCVmgMOke1Mo36E/Sjn6+aPcXLZK/HMb5EHuoYpZZAk7Vx+jsWmTpHPvP5HR4t > ZXNa6CT9wjaK1iV7nvaJnifC5QjPeDncM2qOQWF5wLY26eS/G7a4dXJOsl6IHP7z > uJ2j7fxMSucvSGOzWNjW9SouymVuYqL5m4KyEeiqwUlGvHPfLn1AySmCYClEhSL1 > 5kI0Fmr6z6duPY/LKvTNVTe2S1tQS8DKErtOP2vbclglvuw//dqp/cbjvjP8oTZg > 5B610ehDBNwmKN5DAq8v1PAj0vGj1ygk9hotXFcjGlnEEoTCPegh1P3lg0t0LKlk > vBt5GJC61+8dJMs0BXRznSESV8dl7IjjBzfnGiEqQS1sSGBGxAzgUHaOrVnHW/vh > BfaNwzqFguYvOXMzV8DkwQPpXMOxDMDEHKjAKj3SSYsIAIPLbRP0XwkU2Y6csfoP > rrom1+fZEkNFd/qbQw2i7xhvX1LmShlT6GYezkR9St+fSoWzg2Js44dSpDAYYh33 > 3Ngz6koNyZVCfcwz1oOMI5yz+oD98OICxyG0j/m6w8RtEAhsUE07tX/LEvHp0HPZ > uF1TIGPZcQbC4g3yf8Kz > =WImG > -----END PGP SIGNATURE----- >

2 1

Re: [xwiki-devs] [xwiki-notifications] Build failed in Hudson: xwiki-platform-core-2.0 #42
by Vincent Massol 25 Sep '09

25 Sep '09

On Sep 25, 2009, at 4:07 PM, Hudson wrote: > See <http://hudson.xwiki.org/job/xwiki-platform-core-2.0/42/changes> > > Changes: > > [Thomas Mortagne] [maven-release-plugin] prepare for next > development iteration > > [Thomas Mortagne] [maven-release-plugin] prepare release xwiki- > core-2.0 > > ------------------------------------------ > [...truncated 3713 lines...] > Tests run: 4, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: > 0.201 sec > Running > org.xwiki.officeimporter.internal.OfficeImporterFileStorageTest > Tests run: 1, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: > 0.031 sec > Running > org.xwiki.officeimporter.internal.cleaner.MiscWysiwygCleaningTest > Tests run: 2, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: > 0.057 sec > Running > org > .xwiki > .officeimporter.internal.cleaner.InvalidTagOpenOfficeCleaningTest > Tests run: 2, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: > 0.062 sec > Running > org.xwiki.officeimporter.internal.cleaner.LinkOpenOfficeCleaningTest > Tests run: 4, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: > 0.103 sec > Running > org > .xwiki > .officeimporter > .internal.cleaner.EmptyLineParagraphOpenOfficeCleaningTest > Tests run: 2, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: > 0.047 sec > [snip] > ------------------------------------------------------- > T E S T S > ------------------------------------------------------- > Running com.xpn.xwiki.criteria.impl.PeriodFactoryTest > Tests run: 2, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: > 0.399 sec > Running com.xpn.xwiki.render.DefaultXWikiRenderingEngineTest > 2009-09-25 15:01:00,806 [] [main] ERROR > internal.DefaultVelocityEngine - WebappLoader : unable to retrieve > ServletContext > 2009-09-25 15:01:01,205 [] [main] ERROR > internal.DefaultVelocityEngine - WebappLoader : unable to retrieve > ServletContext > Tests run: 2, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: > 6.097 sec > Running com.xpn.xwiki.user.impl.xwiki.XWikiAuthServiceImplTest > Tests run: 6, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: > 1.366 sec > Running com.xpn.xwiki.doc.DefaultDocumentNameFactoryTest > Tests run: 2, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: > 0.453 sec > Running com.xpn.xwiki.doc.XWikiDocumentArchiveTest > 2009-09-25 15:01:04,256 [] [main] WARN > rcs.XWikiRCSArchive - isDiff: Archive is inconsistent. > Text and diff field are contradicting. version=1.1 > 2009-09-25 15:01:04,347 [] [main] WARN > rcs.XWikiRCSArchive - isDiff: Archive is inconsistent. > Text and diff field are contradicting. version=1.1 > Tests run: 5, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: > 2.505 sec > Running com.xpn.xwiki.doc.XWikiDocumentTest > ERROR: Processing failed due to a bug in the code. Please report > this to users(a)hudson.dev.java.net > java.lang.NullPointerException > at hudson.model.Run$Runner.access$000(Run.java:1007) > at hudson.model.Run.reportCheckpoint(Run.java:984) > at hudson.model.CheckPoint.report(CheckPoint.java:113) > at hudson.tasks.MailSender.execute(MailSender.java:107) > at hudson.maven.reporters.MavenMailer.end(MavenMailer.java:54) > at hudson.maven.MavenModuleSetBuild > $Builder.end(MavenModuleSetBuild.java:677) > at hudson.maven.MavenModuleSetBuild > $RunnerImpl.doRun(MavenModuleSetBuild.java:480) > at hudson.model.AbstractBuild$AbstractRunner.run(AbstractBuild.java: > 354) > at hudson.model.Run.run(Run.java:1123) > at hudson.maven.MavenModuleSetBuild.run(MavenModuleSetBuild.java:302) > at hudson.model.ResourceController.execute(ResourceController.java: > 88) > at hudson.model.Executor.run(Executor.java:123) this looks like a false positive, isn't it? [snip] Thanks -Vincent

2 1

[xwiki-devs] [VOTE] Release XWiki Enterprise 2.0 final
by Thomas Mortagne 24 Sep '09

24 Sep '09

Hi, I would like to start the release of XWiki Enterprise 2.0 final. It's a very important release so make sure there is no blocker remaining on your side before voting. You can look at http://www.xwiki.org/xwiki/bin/view/Main/ReleaseNotesXWikiEnterprise20 for more details. Here is my +1 Thanks, -- Thomas Mortagne

6 6

Re: [xwiki-devs] [xwiki-notifications] r23883 - in enterprise/branches/xwiki-enterprise-2.0/distribution-test: ldap-tests/src/test/it/com/xpn/xwiki/it selenium-tests/src/test/it/com/xpn/xwiki/it/selenium selenium-tests/src/test/it/com/xpn/xwiki/it/selenium/framework wysiwyg-tests/src/test/it/com/xpn/xwiki/it/selenium
by Anca Luca 24 Sep '09

24 Sep '09

Hi Vincent, vmassol (SVN) wrote: > Author: vmassol > Date: 2009-09-24 08:58:35 +0200 (Thu, 24 Sep 2009) > New Revision: 23883 > > Modified: > enterprise/branches/xwiki-enterprise-2.0/distribution-test/ldap-tests/src/test/it/com/xpn/xwiki/it/LDAPAuthTest.java > enterprise/branches/xwiki-enterprise-2.0/distribution-test/selenium-tests/src/test/it/com/xpn/xwiki/it/selenium/AllDocsTest.java > enterprise/branches/xwiki-enterprise-2.0/distribution-test/selenium-tests/src/test/it/com/xpn/xwiki/it/selenium/DocExtraTest.java > enterprise/branches/xwiki-enterprise-2.0/distribution-test/selenium-tests/src/test/it/com/xpn/xwiki/it/selenium/SectionTest.java > enterprise/branches/xwiki-enterprise-2.0/distribution-test/selenium-tests/src/test/it/com/xpn/xwiki/it/selenium/framework/AbstractXWikiTestCase.java > enterprise/branches/xwiki-enterprise-2.0/distribution-test/wysiwyg-tests/src/test/it/com/xpn/xwiki/it/selenium/LinkTest.java > Log: > Improve API names thanks to Marius Shouldn't this also be on trunk? Thanks, Anca > > Modified: enterprise/branches/xwiki-enterprise-2.0/distribution-test/ldap-tests/src/test/it/com/xpn/xwiki/it/LDAPAuthTest.java > =================================================================== > --- enterprise/branches/xwiki-enterprise-2.0/distribution-test/ldap-tests/src/test/it/com/xpn/xwiki/it/LDAPAuthTest.java 2009-09-23 21:45:22 UTC (rev 23882) > +++ enterprise/branches/xwiki-enterprise-2.0/distribution-test/ldap-tests/src/test/it/com/xpn/xwiki/it/LDAPAuthTest.java 2009-09-24 06:58:35 UTC (rev 23883) > @@ -110,7 +110,7 @@ > // /////////////////// > // Validate XWIKI-2201: LDAP group mapping defined in XWikiPreferences is not working > open("XWiki", "XWikiAdminGroup"); > - assertAndWaitBodyContains("XWiki." + LDAPTestSetup.WILLIAMBUSH_UID); > + waitForBodyContains("XWiki." + LDAPTestSetup.WILLIAMBUSH_UID); > > // /////////////////// > // Validate > > Modified: enterprise/branches/xwiki-enterprise-2.0/distribution-test/selenium-tests/src/test/it/com/xpn/xwiki/it/selenium/AllDocsTest.java > =================================================================== > --- enterprise/branches/xwiki-enterprise-2.0/distribution-test/selenium-tests/src/test/it/com/xpn/xwiki/it/selenium/AllDocsTest.java 2009-09-23 21:45:22 UTC (rev 23882) > +++ enterprise/branches/xwiki-enterprise-2.0/distribution-test/selenium-tests/src/test/it/com/xpn/xwiki/it/selenium/AllDocsTest.java 2009-09-24 06:58:35 UTC (rev 23883) > @@ -60,7 +60,7 @@ > // elements in the table > open("Main", "AllDocs"); > // We verify we have a least 3 pages displayed > - assertAndWaitTextContains("//span[@class='xwiki-livetable-pagination-content']", "1 2 3"); > + waitForTextContains("//span[@class='xwiki-livetable-pagination-content']", "1 2 3"); > if (isAuthenticated()) { > logout(); > } > @@ -69,7 +69,7 @@ > // Validate presence of "Actions" column in table view for administrator. > loginAsAdmin(); > open("Main", "AllDocs"); > - assertAndWaitTextContains("//span[@class='xwiki-livetable-pagination-content']", "1 2 3"); > + waitForTextContains("//span[@class='xwiki-livetable-pagination-content']", "1 2 3"); > assertElementPresent("//th[normalize-space(text())='Actions']"); > > // Validate input suggest for Page field. > @@ -77,29 +77,29 @@ > // Note: We wait on the pagination result since it's the last element updated and it's done after the > // table rows have been updated so this allows us to wait on it. In the code below "1" represents the > // displayed pages. > - assertAndWaitTextPresent("//span[@class='xwiki-livetable-pagination-content']", "1"); > + waitForTextPresent("//span[@class='xwiki-livetable-pagination-content']", "1"); > assertElementPresent("//td[contains(@class, 'doc_name')]/a[text()='Treeview']"); > > // Validate input suggest for Space field. > open("Main", "AllDocs"); > - assertAndWaitTextContains("//span[@class='xwiki-livetable-pagination-content']", "1 2 3"); > + waitForTextContains("//span[@class='xwiki-livetable-pagination-content']", "1 2 3"); > getSelenium().typeKeys("xpath=//input[@name='doc.space']", "XWiki"); > getSelenium().typeKeys("xpath=//input[@name='doc.name']", "treeview"); > - assertAndWaitTextPresent("//span[@class='xwiki-livetable-pagination-content']", "1"); > + waitForTextPresent("//span[@class='xwiki-livetable-pagination-content']", "1"); > assertElementPresent("//td[contains(@class, 'doc_name')]/a[text()='Treeview']"); > > // Validate input suggest for Last Author field. > open("Main", "AllDocs"); > - assertAndWaitTextContains("//span[@class='xwiki-livetable-pagination-content']", "1 2 3"); > + waitForTextContains("//span[@class='xwiki-livetable-pagination-content']", "1 2 3"); > getSelenium().typeKeys("xpath=//input[@name='doc.author']", "SomeUnknownAuthor"); > - assertAndWaitTextPresent("//span[@class='xwiki-livetable-pagination-content']", ""); > + waitForTextPresent("//span[@class='xwiki-livetable-pagination-content']", ""); > assertElementNotPresent("//td[contains(@class, 'doc_name')]/a[text()='Treeview']"); > > // Validate Copy link action. > open("Main", "AllDocs"); > - assertAndWaitTextContains("//span[@class='xwiki-livetable-pagination-content']", "1 2 3"); > + waitForTextContains("//span[@class='xwiki-livetable-pagination-content']", "1 2 3"); > getSelenium().typeKeys("xpath=//input[@name='doc.name']", "treeview"); > - assertAndWaitTextPresent("//span[@class='xwiki-livetable-pagination-content']", "1"); > + waitForTextPresent("//span[@class='xwiki-livetable-pagination-content']", "1"); > assertElementPresent("//td[contains(@class, 'doc_name')]/a[text()='Treeview']"); > clickLinkWithText("copy"); > setFieldValue("targetdoc", "New.TreeviewCopy"); > @@ -107,40 +107,40 @@ > open("Main", "AllDocs"); > getSelenium().typeKeys("xpath=//input[@name='doc.space']", "New"); > getSelenium().typeKeys("xpath=//input[@name='doc.name']", "treeviewcopy"); > - assertAndWaitTextPresent("//span[@class='xwiki-livetable-pagination-content']", "1"); > + waitForTextPresent("//span[@class='xwiki-livetable-pagination-content']", "1"); > assertElementPresent("//td[contains(@class, 'doc_name')]/a[text()='TreeviewCopy']"); > > // Validate Rename link action. > open("Main", "AllDocs"); > - assertAndWaitTextContains("//span[@class='xwiki-livetable-pagination-content']", "1 2 3"); > + waitForTextContains("//span[@class='xwiki-livetable-pagination-content']", "1 2 3"); > getSelenium().typeKeys("xpath=//input[@name='doc.name']", "TreeviewCopy"); > - assertAndWaitTextPresent("//span[@class='xwiki-livetable-pagination-content']", "1"); > + waitForTextPresent("//span[@class='xwiki-livetable-pagination-content']", "1"); > clickLinkWithLocator("//tbody/tr/td/a[text()='rename']"); > setFieldValue("newPageName", "TreeviewCopyRenamed"); > clickLinkWithLocator("//input[@value='Rename']"); > open("Main", "AllDocs"); > getSelenium().typeKeys("xpath=//input[@name='doc.name']", "TreeviewCopyRenamed"); > - assertAndWaitTextPresent("//span[@class='xwiki-livetable-pagination-content']", "1"); > + waitForTextPresent("//span[@class='xwiki-livetable-pagination-content']", "1"); > assertElementPresent("//td[contains(@class, 'doc_name')]/a[text()='TreeviewCopyRenamed']"); > > // Validate Delete link action. > open("Main", "AllDocs"); > - assertAndWaitTextContains("//span[@class='xwiki-livetable-pagination-content']", "1 2 3"); > + waitForTextContains("//span[@class='xwiki-livetable-pagination-content']", "1 2 3"); > getSelenium().typeKeys("xpath=//input[@name='doc.name']", "Treeviewcopyrenamed"); > - assertAndWaitTextPresent("//span[@class='xwiki-livetable-pagination-content']", "1"); > + waitForTextPresent("//span[@class='xwiki-livetable-pagination-content']", "1"); > clickLinkWithLocator("//tbody/tr/td/a[text()='delete']"); > clickLinkWithLocator("//input[@value='yes']"); > assertTextPresent("The document has been deleted."); > open("Main", "AllDocs"); > getSelenium().typeKeys("xpath=//input[@name='doc.name']", "treeview"); > - assertAndWaitTextPresent("//span[@class='xwiki-livetable-pagination-content']", "1"); > + waitForTextPresent("//span[@class='xwiki-livetable-pagination-content']", "1"); > assertElementNotPresent("//td[contains(@class, 'doc_name')]/a[text()='TreeviewCopyRenamed']"); > > // Validate Rights link action. > open("Main", "AllDocs"); > - assertAndWaitTextContains("//span[@class='xwiki-livetable-pagination-content']", "1 2 3"); > + waitForTextContains("//span[@class='xwiki-livetable-pagination-content']", "1 2 3"); > getSelenium().typeKeys("xpath=//input[@name='doc.name']", "Treeview"); > - assertAndWaitTextPresent("//span[@class='xwiki-livetable-pagination-content']", "1"); > + waitForTextPresent("//span[@class='xwiki-livetable-pagination-content']", "1"); > clickLinkWithLocator("//tbody/tr/td/a[text()='rights']"); > Assert.assertEquals("Editing Rights for Tree", getTitle()); > } > > Modified: enterprise/branches/xwiki-enterprise-2.0/distribution-test/selenium-tests/src/test/it/com/xpn/xwiki/it/selenium/DocExtraTest.java > =================================================================== > --- enterprise/branches/xwiki-enterprise-2.0/distribution-test/selenium-tests/src/test/it/com/xpn/xwiki/it/selenium/DocExtraTest.java 2009-09-23 21:45:22 UTC (rev 23882) > +++ enterprise/branches/xwiki-enterprise-2.0/distribution-test/selenium-tests/src/test/it/com/xpn/xwiki/it/selenium/DocExtraTest.java 2009-09-24 06:58:35 UTC (rev 23883) > @@ -55,28 +55,28 @@ > open("Main", "WebHome"); > int initialScrollY = Integer.parseInt(getSelenium().getEval("window.scrollY")); > > - assertAndWaitForElement("//a[@id='Attachmentslink']"); > + waitForElement("//a[@id='Attachmentslink']"); > clickLinkWithXPath("//a[@id='Attachmentslink']", false); > waitForCondition("selenium.browserbot.findElement(\"Attachmentspane\").className.indexOf(\"empty\") == -1"); > assertElementPresent("attachform"); > int scrollY = Integer.parseInt(getSelenium().getEval("window.scrollY")); > assertEquals(initialScrollY, scrollY); > > - assertAndWaitForElement("//a[@id='Historylink']"); > + waitForElement("//a[@id='Historylink']"); > clickLinkWithXPath("//a[@id='Historylink']", false); > waitForCondition("selenium.browserbot.findElement(\"Historypane\").className.indexOf(\"empty\") == -1"); > assertElementPresent("historyform"); > scrollY = Integer.parseInt(getSelenium().getEval("window.scrollY")); > assertEquals(initialScrollY, scrollY); > > - assertAndWaitForElement("//a[@id='Informationlink']"); > + waitForElement("//a[@id='Informationlink']"); > clickLinkWithXPath("//a[@id='Informationlink']", false); > waitForCondition("selenium.browserbot.findElement(\"Informationpane\").className.indexOf(\"empty\") == -1"); > assertTextPresent("Created"); > scrollY = Integer.parseInt(getSelenium().getEval("window.scrollY")); > assertEquals(initialScrollY, scrollY); > > - assertAndWaitForElement("//a[@id='Commentslink']"); > + waitForElement("//a[@id='Commentslink']"); > clickLinkWithXPath("//a[@id='Commentslink']", false); > waitForCondition("selenium.browserbot.findElement(\"Commentspane\").className.indexOf(\"empty\") == -1"); > assertElementPresent("commentform"); > > Modified: enterprise/branches/xwiki-enterprise-2.0/distribution-test/selenium-tests/src/test/it/com/xpn/xwiki/it/selenium/SectionTest.java > =================================================================== > --- enterprise/branches/xwiki-enterprise-2.0/distribution-test/selenium-tests/src/test/it/com/xpn/xwiki/it/selenium/SectionTest.java 2009-09-23 21:45:22 UTC (rev 23882) > +++ enterprise/branches/xwiki-enterprise-2.0/distribution-test/selenium-tests/src/test/it/com/xpn/xwiki/it/selenium/SectionTest.java 2009-09-24 06:58:35 UTC (rev 23883) > @@ -96,7 +96,7 @@ > { > initXWiki20Env(); > // Since the section edit links are inserted with JS we need to ensure they've been generated > - assertAndWaitForElement("//div[@id='xwikicontent']/span[2]/a"); > + waitForElement("//div[@id='xwikicontent']/span[2]/a"); > // TODO: I don't understand why the following xpath expression doesn't work: > // clickLinkWithLocator("//div[@id='xwikicontent']/span/a[contains(@href, 'section=2']"); > clickLinkWithLocator("//div[@id='xwikicontent']/span[2]/a"); // Edit the second editable section > @@ -114,7 +114,7 @@ > { > initXWiki20Env(); > // Since the section edit links are inserted with JS we need to ensure they've been generated > - assertAndWaitForElement("//div[@id='xwikicontent']/span[4]/a"); > + waitForElement("//div[@id='xwikicontent']/span[4]/a"); > // TODO: I don't understand why the following xpath expression doesn't work: > // clickLinkWithLocator("//div[@id='xwikicontent']/span/a[contains(@href, 'section=4']"); > clickLinkWithLocator("//div[@id='xwikicontent']/span[4]/a"); // Edit the last editable section > @@ -132,7 +132,7 @@ > { > initXWiki20Env(); > // Since the section edit links are inserted with JS we need to ensure they've been generated > - assertAndWaitForElement("//div[@id='xwikicontent']/span[4]/a"); > + waitForElement("//div[@id='xwikicontent']/span[4]/a"); > // TODO: I don't understand why the following xpath expression doesn't work: > // clickLinkWithLocator("//div[@id='xwikicontent']/span/a[contains(@href, 'section=4']"); > clickLinkWithLocator("//div[@id='xwikicontent']/span[4]/a"); // Edit the last editable section > > Modified: enterprise/branches/xwiki-enterprise-2.0/distribution-test/selenium-tests/src/test/it/com/xpn/xwiki/it/selenium/framework/AbstractXWikiTestCase.java > =================================================================== > --- enterprise/branches/xwiki-enterprise-2.0/distribution-test/selenium-tests/src/test/it/com/xpn/xwiki/it/selenium/framework/AbstractXWikiTestCase.java 2009-09-23 21:45:22 UTC (rev 23882) > +++ enterprise/branches/xwiki-enterprise-2.0/distribution-test/selenium-tests/src/test/it/com/xpn/xwiki/it/selenium/framework/AbstractXWikiTestCase.java 2009-09-24 06:58:35 UTC (rev 23883) > @@ -148,33 +148,6 @@ > assertTrue("[" + text + "] isn't present.", getSelenium().isTextPresent(text)); > } > > - public void assertAndWaitTextPresent(final String elementLocator, final String expectedValue) > - { > - new Wait() { > - public boolean until() { > - return getSelenium().getText(elementLocator).equals(expectedValue); > - } > - }.wait("element [" + elementLocator + "] not found or doesn't have the value [" + expectedValue + "]"); > - } > - > - public void assertAndWaitTextContains(final String elementLocator, final String containsValue) > - { > - new Wait() { > - public boolean until() { > - return getSelenium().getText(elementLocator).indexOf(containsValue) > -1; > - } > - }.wait("element [" + elementLocator + "] not found or doesn't contain the value [" + containsValue + "]"); > - } > - > - public void assertAndWaitBodyContains(final String containsValue) > - { > - new Wait() { > - public boolean until() { > - return getSelenium().getBodyText().indexOf(containsValue) > -1; > - } > - }.wait("Body text doesn't contain the value [" + containsValue + "]"); > - } > - > public void assertTextNotPresent(String text) > { > assertFalse("[" + text + "] is present.", getSelenium().isTextPresent(text)); > @@ -185,15 +158,6 @@ > assertTrue("[" + elementLocator + "] isn't present.", isElementPresent(elementLocator)); > } > > - public void assertAndWaitForElement(final String elementLocator) > - { > - new Wait() { > - public boolean until() { > - return getSelenium().isElementPresent(elementLocator); > - } > - }.wait("element [" + elementLocator + "] not found"); > - } > - > public void assertElementNotPresent(String elementLocator) > { > assertFalse("[" + elementLocator + "] is present.", isElementPresent(elementLocator)); > @@ -316,6 +280,42 @@ > getSelenium().waitForCondition(condition, "" + WAIT_TIME); > } > > + public void waitForTextPresent(final String elementLocator, final String expectedValue) > + { > + new Wait() { > + public boolean until() { > + return getSelenium().getText(elementLocator).equals(expectedValue); > + } > + }.wait("element [" + elementLocator + "] not found or doesn't have the value [" + expectedValue + "]"); > + } > + > + public void waitForTextContains(final String elementLocator, final String containsValue) > + { > + new Wait() { > + public boolean until() { > + return getSelenium().getText(elementLocator).indexOf(containsValue) > -1; > + } > + }.wait("element [" + elementLocator + "] not found or doesn't contain the value [" + containsValue + "]"); > + } > + > + public void waitForBodyContains(final String containsValue) > + { > + new Wait() { > + public boolean until() { > + return getSelenium().getBodyText().indexOf(containsValue) > -1; > + } > + }.wait("Body text doesn't contain the value [" + containsValue + "]"); > + } > + > + public void waitForElement(final String elementLocator) > + { > + new Wait() { > + public boolean until() { > + return getSelenium().isElementPresent(elementLocator); > + } > + }.wait("element [" + elementLocator + "] not found"); > + } > + > /** > * {@inheritDoc} > * > > Modified: enterprise/branches/xwiki-enterprise-2.0/distribution-test/wysiwyg-tests/src/test/it/com/xpn/xwiki/it/selenium/LinkTest.java > =================================================================== > --- enterprise/branches/xwiki-enterprise-2.0/distribution-test/wysiwyg-tests/src/test/it/com/xpn/xwiki/it/selenium/LinkTest.java 2009-09-23 21:45:22 UTC (rev 23882) > +++ enterprise/branches/xwiki-enterprise-2.0/distribution-test/wysiwyg-tests/src/test/it/com/xpn/xwiki/it/selenium/LinkTest.java 2009-09-24 06:58:35 UTC (rev 23883) > @@ -1851,7 +1851,7 @@ > > protected void waitForStepToLoad(String name) > { > - assertAndWaitForElement("//*[contains(@class, '" + name + "')]"); > + waitForElement("//*[contains(@class, '" + name + "')]"); > } > > protected void typeInExplorerInput(String text) > > _______________________________________________ > notifications mailing list > notifications(a)xwiki.org > http://lists.xwiki.org/mailman/listinfo/notifications

2 1

Re: [xwiki-devs] [xwiki-notifications] r23882 - enterprise/branches/xwiki-enterprise-2.0/distribution-test/wysiwyg-tests/src/test/it/com/xpn/xwiki/it/selenium
by Anca Luca 24 Sep '09

24 Sep '09

Hi Vincent, vmassol (SVN) wrote: > Author: vmassol > Date: 2009-09-23 23:45:22 +0200 (Wed, 23 Sep 2009) > New Revision: 23882 > > Modified: > enterprise/branches/xwiki-enterprise-2.0/distribution-test/wysiwyg-tests/src/test/it/com/xpn/xwiki/it/selenium/LinkTest.java > Log: > Try to fix flickering test > > Modified: enterprise/branches/xwiki-enterprise-2.0/distribution-test/wysiwyg-tests/src/test/it/com/xpn/xwiki/it/selenium/LinkTest.java > =================================================================== > --- enterprise/branches/xwiki-enterprise-2.0/distribution-test/wysiwyg-tests/src/test/it/com/xpn/xwiki/it/selenium/LinkTest.java 2009-09-23 21:22:39 UTC (rev 23881) > +++ enterprise/branches/xwiki-enterprise-2.0/distribution-test/wysiwyg-tests/src/test/it/com/xpn/xwiki/it/selenium/LinkTest.java 2009-09-23 21:45:22 UTC (rev 23882) > @@ -167,7 +167,7 @@ > /** > * Test the basic feature for adding a link to a new page in a new space. > * > - * @see http://jira.xwiki.org/jira/browse/XWIKI-3511 > + * @see <a href="http://jira.xwiki.org/jira/browse/XWIKI-3511">XWIKI-3511</a> > */ > public void testCreateLinkToNewPageInNewSpace() > { > @@ -931,7 +931,7 @@ > /** > * Test that editing a link with custom parameters set from wiki syntax preserves the parameters of the link. > * > - * @see http://jira.xwiki.org/jira/browse/XWIKI-3568 > + * @see <a href="http://jira.xwiki.org/jira/browse/XWIKI-3568">XWIKI-3568</a> > */ > public void testEditLinkPreservesCustomParameters() > { > @@ -988,8 +988,8 @@ > /** > * Test that quotes in link tooltips are correctly escaped. > * > - * @see http://jira.xwiki.org/jira/browse/XWIKI-3569 > - * @see http://jira.xwiki.org/jira/browse/XWIKI-3575 > + * @see <a href="http://jira.xwiki.org/jira/browse/XWIKI-3569">XWIKI-3569</a> > + * @see <a href="http://jira.xwiki.org/jira/browse/XWIKI-3569">XWIKI-3575</a> > */ > public void testQuoteInLinkTooltip() > { > @@ -1267,7 +1267,7 @@ > /** > * Test that a relative link is correctly edited. > * > - * @see http://jira.xwiki.org/jira/browse/XWIKI-3676 > + * @see <a href="http://jira.xwiki.org/jira/browse/XWIKI-3676">XWIKI-3676</a> > */ > public void testEditRelativeLink() > { > @@ -1851,7 +1851,7 @@ > > protected void waitForStepToLoad(String name) > { > - waitForCondition("selenium.isElementPresent('//*[contains(@class, \"" + name + "\")]');"); > + assertAndWaitForElement("//*[contains(@class, '" + name + "')]"); Is there any other reason for this change of waiting method besides "let's try something else"? Thanks, Anca > } > > protected void typeInExplorerInput(String text) > > _______________________________________________ > notifications mailing list > notifications(a)xwiki.org > http://lists.xwiki.org/mailman/listinfo/notifications

2 1

Re: [xwiki-devs] [xwiki-notifications] r23882 - enterprise/branches/xwiki-enterprise-2.0/distribution-test/wysiwyg-tests/src/test/it/com/xpn/xwiki/it/selenium
by Vincent Massol 24 Sep '09

24 Sep '09

On Sep 24, 2009, at 8:54 AM, Marius Dumitru Florea wrote: > Hi Vincent, > > vmassol (SVN) wrote: >> Author: vmassol >> Date: 2009-09-23 23:45:22 +0200 (Wed, 23 Sep 2009) >> New Revision: 23882 >> >> Modified: >> enterprise/branches/xwiki-enterprise-2.0/distribution-test/ >> wysiwyg-tests/src/test/it/com/xpn/xwiki/it/selenium/LinkTest.java >> Log: >> Try to fix flickering test >> >> Modified: enterprise/branches/xwiki-enterprise-2.0/distribution- >> test/wysiwyg-tests/src/test/it/com/xpn/xwiki/it/selenium/ >> LinkTest.java >> =================================================================== >> --- enterprise/branches/xwiki-enterprise-2.0/distribution-test/ >> wysiwyg-tests/src/test/it/com/xpn/xwiki/it/selenium/LinkTest.java >> 2009-09-23 21:22:39 UTC (rev 23881) >> +++ enterprise/branches/xwiki-enterprise-2.0/distribution-test/ >> wysiwyg-tests/src/test/it/com/xpn/xwiki/it/selenium/LinkTest.java >> 2009-09-23 21:45:22 UTC (rev 23882) >> @@ -167,7 +167,7 @@ >> /** >> * Test the basic feature for adding a link to a new page in a >> new space. >> * >> - * @see http://jira.xwiki.org/jira/browse/XWIKI-3511 >> + * @see <a href="http://jira.xwiki.org/jira/browse/ >> XWIKI-3511">XWIKI-3511</a> >> */ >> public void testCreateLinkToNewPageInNewSpace() >> { >> @@ -931,7 +931,7 @@ >> /** >> * Test that editing a link with custom parameters set from >> wiki syntax preserves the parameters of the link. >> * >> - * @see http://jira.xwiki.org/jira/browse/XWIKI-3568 >> + * @see <a href="http://jira.xwiki.org/jira/browse/ >> XWIKI-3568">XWIKI-3568</a> >> */ >> public void testEditLinkPreservesCustomParameters() >> { >> @@ -988,8 +988,8 @@ >> /** >> * Test that quotes in link tooltips are correctly escaped. >> * >> - * @see http://jira.xwiki.org/jira/browse/XWIKI-3569 >> - * @see http://jira.xwiki.org/jira/browse/XWIKI-3575 >> + * @see <a href="http://jira.xwiki.org/jira/browse/ >> XWIKI-3569">XWIKI-3569</a> >> + * @see <a href="http://jira.xwiki.org/jira/browse/ >> XWIKI-3569">XWIKI-3575</a> >> */ >> public void testQuoteInLinkTooltip() >> { >> @@ -1267,7 +1267,7 @@ >> /** >> * Test that a relative link is correctly edited. >> * >> - * @see http://jira.xwiki.org/jira/browse/XWIKI-3676 >> + * @see <a href="http://jira.xwiki.org/jira/browse/ >> XWIKI-3676">XWIKI-3676</a> >> */ >> public void testEditRelativeLink() >> { >> @@ -1851,7 +1851,7 @@ >> >> protected void waitForStepToLoad(String name) >> { >> - waitForCondition("selenium.isElementPresent('// >> *[contains(@class, \"" + name + "\")]');"); > >> + assertAndWaitForElement("//*[contains(@class, '" + name + >> "')]"); > > I find "assertAndWait.." a bit confusing since I'm thinking that it > asserts something and then waits for the element to be present. From > the > code it looks like the method just waits for the element to be > present. > Why not simply "waitForElement"? Agreed. Thanks -Vincent

1 0

Re: [xwiki-devs] [xwiki-notifications] r23844 - enterprise/branches/xwiki-enterprise-2.0
by Vincent Massol 23 Sep '09

23 Sep '09

Hi JV, I had kept them with the last released version since I wanted to control what we release (I think it's a good thing on a release branch). If you've made a change to a dep then please update the Release plan on the release page. Thanks -Vincent On Sep 23, 2009, at 12:51 PM, jvdrean (SVN) wrote: > Author: jvdrean > Date: 2009-09-23 12:51:08 +0200 (Wed, 23 Sep 2009) > New Revision: 23844 > > Modified: > enterprise/branches/xwiki-enterprise-2.0/pom.xml > Log: > [build] Updated dependencies > > > Modified: enterprise/branches/xwiki-enterprise-2.0/pom.xml > =================================================================== > --- enterprise/branches/xwiki-enterprise-2.0/pom.xml 2009-09-23 > 10:42:56 UTC (rev 23843) > +++ enterprise/branches/xwiki-enterprise-2.0/pom.xml 2009-09-23 > 10:51:08 UTC (rev 23844) > @@ -48,29 +48,29 @@ > </modules> > <properties> >  > - <platform.tool.xar-handler.version>1.9</platform.tool.xar- > handler.version> > - <platform.tool.xar-plugin.version>1.13</platform.tool.xar- > plugin.version> > - <platform.tool.configuration.version>1.32</ > platform.tool.configuration.version> > - <platform.tool.jetty.version>1.16</platform.tool.jetty.version> > - <platform.tool.rootwebapp.version>1.2</ > platform.tool.rootwebapp.version> > - <platform.tool.packager.version>1.13</ > platform.tool.packager.version> > + <platform.tool.xar-handler.version>1.10-SNAPSHOT</ > platform.tool.xar-handler.version> > + <platform.tool.xar-plugin.version>1.14-SNAPSHOT</ > platform.tool.xar-plugin.version> > + <platform.tool.configuration.version>1.33-SNAPSHOT</ > platform.tool.configuration.version> > + <platform.tool.jetty.version>1.17-SNAPSHOT</ > platform.tool.jetty.version> > + <platform.tool.rootwebapp.version>1.3-SNAPSHOT</ > platform.tool.rootwebapp.version> > + <platform.tool.packager.version>1.14-SNAPSHOT</ > platform.tool.packager.version> > <platform.core.version>2.0-SNAPSHOT</platform.core.version> > <platform.web.version>2.0-SNAPSHOT</platform.web.version> > - <platform.panels.version>1.24</platform.panels.version> > - <platform.administration.version>1.16</ > platform.administration.version> > - <platform.scheduler.version>1.11</platform.scheduler.version> > - <platform.activitystream.version>1.4</ > platform.activitystream.version> > - <platform.watchlist.version>1.19</platform.watchlist.version> > - <platform.blog.version>1.12</platform.blog.version> > - <platform.jodatime.version>1.3</platform.jodatime.version> > - <platform.statistics.version>1.5</platform.statistics.version> > - <platform.plugin.mailsender.version>1.12</ > platform.plugin.mailsender.version> > - <platform.plugin.lucene.version>1.10</ > platform.plugin.lucene.version> > - <platform.plugin.skinx.version>1.10</ > platform.plugin.skinx.version> > - <platform.officeimporter.version>1.11</ > platform.officeimporter.version> > - <platform.webdav.version>1.2</platform.webdav.version> > - <platform.tag.version>1.7</platform.tag.version> > - <platform.wikimacrobridge.version>1.2</ > platform.wikimacrobridge.version> > + <platform.panels.version>1.25-SNAPSHOT</platform.panels.version> > + <platform.administration.version>1.17-SNAPSHOT</ > platform.administration.version> > + <platform.scheduler.version>1.12-SNAPSHOT</ > platform.scheduler.version> > + <platform.activitystream.version>1.5-SNAPSHOT</ > platform.activitystream.version> > + <platform.watchlist.version>1.20-SNAPSHOT</ > platform.watchlist.version> > + <platform.blog.version>1.13-SNAPSHOT</platform.blog.version> > + <platform.jodatime.version>1.4-SNAPSHOT</ > platform.jodatime.version> > + <platform.statistics.version>1.6-SNAPSHOT</ > platform.statistics.version> > + <platform.plugin.mailsender.version>1.13-SNAPSHOT</ > platform.plugin.mailsender.version> > + <platform.plugin.lucene.version>1.11-SNAPSHOT</ > platform.plugin.lucene.version> > + <platform.plugin.skinx.version>1.11-SNAPSHOT</ > platform.plugin.skinx.version> > + <platform.officeimporter.version>1.12-SNAPSHOT</ > platform.officeimporter.version> > + <platform.webdav.version>1.3-SNAPSHOT</platform.webdav.version> > + <platform.tag.version>1.8-SNAPSHOT</platform.tag.version> > + <platform.wikimacrobridge.version>1.3-SNAPSHOT</ > platform.wikimacrobridge.version> > </properties> > <profiles> > <profile>

1 0

Re: [xwiki-devs] [xwiki-notifications] r23823 - platform/xwiki-plugins/trunk/scheduler/src/main/java/com/xpn/xwiki/plugin/scheduler
by Sergiu Dumitriu 22 Sep '09

22 Sep '09

jvelociter (SVN) wrote: > Author: jvelociter > Date: 2009-09-22 16:05:56 +0200 (Tue, 22 Sep 2009) > New Revision: 23823 > > Added: > platform/xwiki-plugins/trunk/scheduler/src/main/java/com/xpn/xwiki/plugin/scheduler/XWikiServletResponseStub.java > Modified: > platform/xwiki-plugins/trunk/scheduler/src/main/java/com/xpn/xwiki/plugin/scheduler/SchedulerPlugin.java > Log: > XASCH-39 Stub the servlet response in the scheduler's thread context A response stub and a request stub are needed for all background threads. Thus, it would be better to move them in xwiki-core. -- Sergiu Dumitriu http://purl.org/net/sergiu/

3 2

22 Sep '09

tmortagne (SVN) wrote: > Author: tmortagne > Date: 2009-09-22 15:57:53 +0200 (Tue, 22 Sep 2009) > New Revision: 23822 > > Modified: > platform/xwiki-applications/trunk/application-manager/pom.xml > platform/xwiki-applications/trunk/calendar/pom.xml > platform/xwiki-applications/trunk/ircbot/pom.xml > platform/xwiki-applications/trunk/photoalbum/pom.xml > platform/xwiki-applications/trunk/scheduler/pom.xml > platform/xwiki-applications/trunk/selenium/pom.xml > platform/xwiki-applications/trunk/statistics/pom.xml > platform/xwiki-applications/trunk/tag/pom.xml > platform/xwiki-applications/trunk/watchlist/pom.xml > platform/xwiki-applications/trunk/webdav/pom.xml > platform/xwiki-applications/trunk/wiki-macro-bridge/pom.xml > platform/xwiki-applications/trunk/wiki-manager/pom.xml > platform/xwiki-applications/trunk/workstream/pom.xml > platform/xwiki-plugins/trunk/activitystream/pom.xml > platform/xwiki-plugins/trunk/adwords/pom.xml > platform/xwiki-plugins/trunk/alexa/pom.xml > platform/xwiki-plugins/trunk/application-manager/pom.xml > platform/xwiki-plugins/trunk/calendar/pom.xml > platform/xwiki-plugins/trunk/exoplatform/pom.xml > platform/xwiki-plugins/trunk/invitationmanager/pom.xml > platform/xwiki-plugins/trunk/jodatime/pom.xml > platform/xwiki-plugins/trunk/lucene/pom.xml > platform/xwiki-plugins/trunk/mailsender/pom.xml > platform/xwiki-plugins/trunk/scheduler/pom.xml > platform/xwiki-plugins/trunk/skinx/pom.xml > platform/xwiki-plugins/trunk/spacemanager/pom.xml > platform/xwiki-plugins/trunk/swizzle/pom.xml > platform/xwiki-plugins/trunk/tag/pom.xml > platform/xwiki-plugins/trunk/watchlist/pom.xml > platform/xwiki-plugins/trunk/wiki-manager/pom.xml > platform/xwiki-plugins/trunk/xml/pom.xml > Log: > Add jira url > > Modified: platform/xwiki-applications/trunk/application-manager/pom.xml > =================================================================== > --- platform/xwiki-applications/trunk/application-manager/pom.xml 2009-09-22 13:55:08 UTC (rev 23821) > +++ platform/xwiki-applications/trunk/application-manager/pom.xml 2009-09-22 13:57:53 UTC (rev 23822) > @@ -52,6 +52,10 @@ > <developerConnection>scm:svn:https://svn.xwiki.org/svnroot/xwiki/platform/xwiki-applications/tru…</developerConnection> > <url>http://svn.xwiki.org/svnroot/xwiki/platform/xwiki-applications/trunk/applic…</url> > </scm> > + <issueManagement> > + <system>jira</system> > + <url>http://jira.xwiki.org/jira/browse/XAAM</url> > + </issueManagement> You used tabs instead of spaces. -- Sergiu Dumitriu http://purl.org/net/sergiu/

1 0

[xwiki-devs] [VOTE] Remove the Search & Create Page panels from the right column in the default XAR
by Guillaume Lerouge 22 Sep '09

22 Sep '09

Hi Devs, Right now the Colibri skin introduces 2 new components (among others): - a search box in the header - a "create" menu entry in the top action bar that allows user to create new pages / spaces Those 2 new features duplicate the Create Page & the Search panel and thus make those panels irrelevant in the default distrib. I'd like to send a vote on removing those 2 panels from the right column in the default XAR & updating the release notes accordingly (so that toucan & albatross users know how to get them back easily). Here's my +1 to remove both panels from the right column in the default XAR. Guillaume -- Guillaume Lerouge Product Manager - XWiki Skype: wikibc Twitter: glerouge http://guillaumelerouge.com/

7 8

22 Sep '09

On Sep 22, 2009, at 3:57 PM, tmortagne (SVN) wrote: > Author: tmortagne > Date: 2009-09-22 15:57:53 +0200 (Tue, 22 Sep 2009) > New Revision: 23822 > > Modified: > platform/xwiki-applications/trunk/application-manager/pom.xml > platform/xwiki-applications/trunk/calendar/pom.xml > platform/xwiki-applications/trunk/ircbot/pom.xml > platform/xwiki-applications/trunk/photoalbum/pom.xml > platform/xwiki-applications/trunk/scheduler/pom.xml > platform/xwiki-applications/trunk/selenium/pom.xml > platform/xwiki-applications/trunk/statistics/pom.xml > platform/xwiki-applications/trunk/tag/pom.xml > platform/xwiki-applications/trunk/watchlist/pom.xml > platform/xwiki-applications/trunk/webdav/pom.xml > platform/xwiki-applications/trunk/wiki-macro-bridge/pom.xml > platform/xwiki-applications/trunk/wiki-manager/pom.xml > platform/xwiki-applications/trunk/workstream/pom.xml > platform/xwiki-plugins/trunk/activitystream/pom.xml > platform/xwiki-plugins/trunk/adwords/pom.xml > platform/xwiki-plugins/trunk/alexa/pom.xml > platform/xwiki-plugins/trunk/application-manager/pom.xml > platform/xwiki-plugins/trunk/calendar/pom.xml > platform/xwiki-plugins/trunk/exoplatform/pom.xml > platform/xwiki-plugins/trunk/invitationmanager/pom.xml > platform/xwiki-plugins/trunk/jodatime/pom.xml > platform/xwiki-plugins/trunk/lucene/pom.xml > platform/xwiki-plugins/trunk/mailsender/pom.xml > platform/xwiki-plugins/trunk/scheduler/pom.xml > platform/xwiki-plugins/trunk/skinx/pom.xml > platform/xwiki-plugins/trunk/spacemanager/pom.xml > platform/xwiki-plugins/trunk/swizzle/pom.xml > platform/xwiki-plugins/trunk/tag/pom.xml > platform/xwiki-plugins/trunk/watchlist/pom.xml > platform/xwiki-plugins/trunk/wiki-manager/pom.xml > platform/xwiki-plugins/trunk/xml/pom.xml > Log: > Add jira url thanks, I was too lazy to finish... ;) -Vincent

1 0

Re: [xwiki-devs] [xwiki-notifications] r23810 - enterprise/trunk/distribution-test/wysiwyg-tests/src/test/it/com/xpn/xwiki/it/selenium
by Vincent Massol 22 Sep '09

22 Sep '09

On Sep 22, 2009, at 2:39 PM, mflorea (SVN) wrote: > Author: mflorea > Date: 2009-09-22 14:39:37 +0200 (Tue, 22 Sep 2009) > New Revision: 23810 > > Modified: > enterprise/trunk/distribution-test/wysiwyg-tests/src/test/it/com/ > xpn/xwiki/it/selenium/LineTest.java > enterprise/trunk/distribution-test/wysiwyg-tests/src/test/it/com/ > xpn/xwiki/it/selenium/NativeJavaScriptApiTest.java > enterprise/trunk/distribution-test/wysiwyg-tests/src/test/it/com/ > xpn/xwiki/it/selenium/StandardFeaturesTest.java > Log: > Fixed some of the WYSIWYG failing tests > * Replaced 'y' with 'Y' to overcome a Selenium bug that > misinterprets 'y' as 'alt' key when typing. This must be well documented in the code below. Thanks -Vincent > * The bogus BR tag is not deleted anymore in FF3.5 when pressing the > Delete key so we must add it when asserting HTML. > > > Modified: enterprise/trunk/distribution-test/wysiwyg-tests/src/test/ > it/com/xpn/xwiki/it/selenium/LineTest.java > =================================================================== > --- enterprise/trunk/distribution-test/wysiwyg-tests/src/test/it/com/ > xpn/xwiki/it/selenium/LineTest.java 2009-09-22 12:09:21 UTC (rev > 23809) > +++ enterprise/trunk/distribution-test/wysiwyg-tests/src/test/it/com/ > xpn/xwiki/it/selenium/LineTest.java 2009-09-22 12:39:37 UTC (rev > 23810) > @@ -252,11 +252,10 @@ > // thus we are forced to collapse the selection to the end. > runScript("XWE.selection.collapseToEnd()"); > typeEnter(); > - typeText("xyz"); > - typeDelete(); > + typeText("xYz"); > assertXHTML("<p>xyz</p>"); > + + "<p>xYz<br class=\"spacer\"></p>"); > } > > /** > > Modified: enterprise/trunk/distribution-test/wysiwyg-tests/src/test/ > it/com/xpn/xwiki/it/selenium/NativeJavaScriptApiTest.java > =================================================================== > --- enterprise/trunk/distribution-test/wysiwyg-tests/src/test/it/com/ > xpn/xwiki/it/selenium/NativeJavaScriptApiTest.java 2009-09-22 > 12:09:21 UTC (rev 23809) > +++ enterprise/trunk/distribution-test/wysiwyg-tests/src/test/it/com/ > xpn/xwiki/it/selenium/NativeJavaScriptApiTest.java 2009-09-22 > 12:39:37 UTC (rev 23810) > @@ -123,7 +123,7 @@ > typeText("x"); > assertEquals("x", getSourceText("editor")); > > - typeText("y"); > + typeText("Y"); > clickButtonWithText("Load Editor"); > waitForCondition("typeof window.editor == 'object'"); > focusRichTextArea(); > > Modified: enterprise/trunk/distribution-test/wysiwyg-tests/src/test/ > it/com/xpn/xwiki/it/selenium/StandardFeaturesTest.java > =================================================================== > --- enterprise/trunk/distribution-test/wysiwyg-tests/src/test/it/com/ > xpn/xwiki/it/selenium/StandardFeaturesTest.java 2009-09-22 12:09:21 > UTC (rev 23809) > +++ enterprise/trunk/distribution-test/wysiwyg-tests/src/test/it/com/ > xpn/xwiki/it/selenium/StandardFeaturesTest.java 2009-09-22 12:39:37 > UTC (rev 23810) > @@ -257,15 +257,15 @@ > { > typeText("x"); > typeShiftEnter(); > - typeText("y"); > + typeText("Y"); > selectAllContent(); > clickUnorderedListButton(); > // Since the left arrow key doesn't move the caret we have > to use the Range API instead. > moveCaret("XWE.body.firstChild.childNodes[1].firstChild", 0); > typeTab(); > - assertXHTML("<ul><li>x<ul><li>y</li></ul></li></ul>"); > + assertXHTML("<ul><li>x<ul><li>Y</li></ul></li></ul>"); > typeShiftTab(); > - assertXHTML("<ul><li>x</li><li>y</li></ul>"); > + assertXHTML("<ul><li>x</li><li>Y</li></ul>"); > } > > /** > @@ -414,7 +414,7 @@ > */ > public void testInsertHRInsideParagraph() > { > - typeText("xy"); > + typeText("xY"); > applyStyleTitle1(); > applyStylePlainText(); > > @@ -435,7 +435,7 @@ > > // We have to assert the XHTML because the arrow keys don't > move the caret so we can't test if the user can edit > // the generated empty paragraphs. The fact that they > contain a BR proves this. > - assertXHTML("<p><br class=\"spacer\"></p><hr><p>x</ > p><hr><p>y</p><hr><p><br class=\"spacer\"></p>"); > + assertXHTML("<p><br class=\"spacer\"></p><hr><p>x</ > p><hr><p>Y</p><hr><p><br class=\"spacer\"></p>"); > } > > /**

2 3

[xwiki-devs] [VOTE] Change group id for skins from com.xpn to xwiki.org
by Vincent Massol 21 Sep '09

21 Sep '09

Hi, Vote: change com.xpn.xwiki.platform.skins to org.xwiki.platform.skins To be done on trunk (2.1) Here's my +1 Thanks -Vincent

7 8

[xwiki-devs] [VOTE] Change group id for applications from com.xpn to xwiki.org
by Vincent Massol 21 Sep '09

21 Sep '09

Hi, Vote: change com.xpn.xwiki.platform.applications to org.xwiki.platform.applications To be done on trunk (2.1) Here's my +1 Thanks -Vincent

6 5

[xwiki-devs] Faster loadXWikiDoc method, preliminary data, 850 - 1000% speed increase.
by Caleb James DeLisle 21 Sep '09

21 Sep '09

My loader is able to load every page in my copy of XE and they all pass the .equals( test against the same page loaded by the default loader so I feel that I'm ready to publish some tests. These are time results (in milliseconds) for loading a page containing 1000 comments. see: http://jira.xwiki.org/jira/browse/XWIKI-2874 My test script runs the tests 30 times interchanging old loader and new. These tests were all the first call to a newly started server, you can see it speed up as the code is jit compiled. Conclusion: 850% improvment can be expected for loading a page with 1000 comments. StringListProperty and LargeStringProperty being mapped to the same column costs about 100ms for the workaround, disabling this workaround brings it to an even 1000% speed increase. Disabling custom mapping saves a whopping 8ms. This surprised me. My loader is only marginally faster at loading all of the pages in XE, it is best at scaling with lots of objects. This didn't surprise me. The actual test results are below. Caleb James DeLisle test1: no special optimizations. Old loader ===================== New Loader 11835ms. ===================== 2875ms. 7776ms. ===================== 771ms. 6827ms. ===================== 684ms. 6652ms. ===================== 405ms. 4406ms. ===================== 348ms. 3790ms. ===================== 363ms. 3482ms. ===================== 288ms. 3431ms. ===================== 965ms. 3173ms. ===================== 295ms. 3029ms. ===================== 271ms. 3714ms. ===================== 278ms. 3017ms. ===================== 285ms. 3828ms. ===================== 271ms. 2907ms. ===================== 285ms. 2845ms. ===================== 258ms. 2884ms. ===================== 275ms. 2829ms. ===================== 276ms. 2871ms. ===================== 256ms. 3638ms. ===================== 285ms. 2797ms. ===================== 295ms. old loader's average: 4284.6ms. new loader's average: 501.4ms. test2: this is with the LargeString/StringList workaround disabled. Old loader ===================== New Loader 11494ms. ===================== 1541ms. 8916ms. ===================== 902ms. 7209ms. ===================== 639ms. 5584ms. ===================== 365ms. 4649ms. ===================== 324ms. 3700ms. ===================== 275ms. 3454ms. ===================== 282ms. 3391ms. ===================== 258ms. 3875ms. ===================== 260ms. 3087ms. ===================== 260ms. 3714ms. ===================== 342ms. 3012ms. ===================== 279ms. 3045ms. ===================== 1109ms. 3012ms. ===================== 242ms. 2873ms. ===================== 244ms. 2863ms. ===================== 247ms. 2880ms. ===================== 257ms. 2842ms. ===================== 276ms. 3667ms. ===================== 255ms. 2881ms. ===================== 259ms. old loader's average: 4305.3ms. new loader's average: 430.8ms. test3: LargeString/StringList workaround & custom mapping disabled. Old loader ===================== New Loader 11813ms. ===================== 1465ms. 7984ms. ===================== 853ms. 6819ms. ===================== 602ms. 6182ms. ===================== 373ms. 4609ms. ===================== 320ms. 3749ms. ===================== 280ms. 3484ms. ===================== 309ms. 3348ms. ===================== 269ms. 3797ms. ===================== 263ms. 3119ms. ===================== 257ms. 3733ms. ===================== 327ms. 3044ms. ===================== 274ms. 2985ms. ===================== 1086ms. 2864ms. ===================== 239ms. 2888ms. ===================== 265ms. 2854ms. ===================== 262ms. 2836ms. ===================== 264ms. 2835ms. ===================== 269ms. 3653ms. ===================== 241ms. 2843ms. ===================== 247ms. old loader's average: 4269.8ms. new loader's average: 423.2ms.

2 3

[xwiki-devs] Rendering Groovy Script in Objects
by Andreas Schaefer 21 Sep '09

21 Sep '09

I am investigation the possibility to write Panels in Groovy. Unfortunately I am not able to figure out: - if I XWiki would render Groovy script code by itself and if how ? - If not can I render a Groovy script form another Groovy script ? BTW I was stuck for a while when trying to create my own BlogPostTemplate because XWiki would not allow me to run it as Groovy script even if I gave myself programming rights. But when I wrote the BlogPostSheet as Groovy class and loaded it inside the Velocity script of the BlogPostTemplate it worked perfectly. Now I am wondering why I could not execute the Groovy script if I can circumvent this restriction so easily. Cheers - Andy

2 4

[xwiki-devs] Something to be aware of when using velocity macro and wiki syntax mixed
by Vincent Massol 20 Sep '09

20 Sep '09

Hi everyone, Example: ----- %> cut here -------- ... something #end ## some comment {{warning..../}} ----- %> cut here -------- Quizz: Will the macro be inline or standalone? Answer: inline Reason is that velocity will start by removing the comment, which will leave a whitespace after the #end Thus you'll get: something + NL + (space) + NL + warning macro Thus since there are no 2 NLs before the macro it's going to be inline! Thanks -Vincent

4 5

[xwiki-devs] [VOTE] Move web/exo module in sandbox
by Vincent Massol 20 Sep '09

20 Sep '09

Since we're not maintaining it and can't guarantee it's quality and since nobody is working on it today. We can put it back when it's updated and working fine. Note: even if we put it back it should be done differently and not as part of platform IMO. Probably an end product. Here's my +1 Thanks -Vincent

5 5

[xwiki-devs] [Proposal] Reorganize XWiki Core JIRA components reflecting core/web modules (Take 2)
by Vincent Massol 19 Sep '09

19 Sep '09

Hi, Following our previous discussion (see http://markmail.org/thread/5lsaq274tvczr5wd) , I'd like to move this forward. Here's what I propose now: 1) We create a new "XWiki Core" (key: XCORE) jira project which is where we put the new components and where we invite everyone to create new core issues. * In this new jira project we use the rule of one jira component per module, whatever the size of the module. ** For example for the rendering module (which is our largest module right now) this means one jira component only. In order to make it easy for users we should name it with something like "Rendering (wiki syntaxes, macros, ...)" ** Users will simply need to explain what it's about in the issue title. For example instead of having a "Rendering - Macro - RSS" component the issue will be named "Add blahblah feature to the RSS macro" ** Having lots of modules might look better but I think 1) having too many components make it hard for end users to find the right one and 2) I don't see real needs for them. Do you see any? 2) We keep the existing "XWiki Core" (key: XWIKI) jira project but: ** we change its permissions so that no new issues can be created in it ** we change its name to "XWiki Core - Old" ** we change its description to tell people to use the other one with a link to it ** we add a welcome message in the default dashboard to explain the change and point people to the new jira project. ** we slowly move whatever issues we can from it to the new project. For example we can easily move all Rendering 2.0 issues or all GWT WYSIWYG issues. For the rest we can move other time whenever we encounter an issue that should go in the new jira project 3) We change our existing jira filters so that they include both XCORE and XWIKI jira projects. WDYT? If we agree, I can start doing this. Thanks -Vincent

3 6

[xwiki-devs] [ANN] XWiki Enterprise 2.0 Release Candidate 2 released
by Thomas Mortagne 18 Sep '09

18 Sep '09

The XWiki development team is pleased to announce the release of XWiki Enterprise 2.0 Release Candidate 2. Go grab it at http://www.xwiki.org/xwiki/bin/view/Main/Download This is the last release candidate before the XWiki enterprise 2.0 final version 69 Jira issues has been closed for this release. Changes from 2.0 Release Candidate 1: * New Colibri skin improvements * General UI improvements * WYSIWYG improvements * Rendering 2.0 improvements * New regexp velocity tool * Update translations: de, fr, gl, ru, sk, lv, pl, sv, zh, ro, ua, ko, hi, cs As usual we need the community to heavily test this release before the final release to catch all the remaining issues. For more information see the Release notes at: http://www.xwiki.org/xwiki/bin/view/Main/ReleaseNotesXWikiEnterprise20RC2 Thanks -The XWiki dev team

1 0

[xwiki-devs] [VOTE] Release XWiki Enterprise 2.0RC2
by Thomas Mortagne 18 Sep '09

18 Sep '09

Hi devs, Here is a vote for the release of the last (hopefully) release candidate of XWiki Enterprise 2.0. The main goal of this release is to introduce the new Colibri skin and new title handling policy by default. It's also supposed to be a real release candidate (meaning that it's supposed to be the final release if nothing critical is found). See http://www.xwiki.org/xwiki/bin/view/Main/ReleaseNotesXWikiEnterprise20RC2 for more details. Here is my +1 -- Thomas Mortagne

7 11

[xwiki-devs] [HELP] LiveTable 2.0 Macro
by Asiri Rathnayake 18 Sep '09

18 Sep '09

Hi All, I'm working on designing LiveTable 2.0 macro, an xwiki/2.0 macro that is supposed to work similar to current LiveTable (say 1.0) Macro. By looking at LiveTable 1.0 macro code I encountered few problems that confuses me a lot. * First, LiveTable macro is different from other macros (those I have seen / written so far) in which the generated content is "live"... Normally macros replaces the macro block with some other generated content but here LiveTable macro makes use of AJAX to fetch content dynamically. So the question, is LiveTable a macro or is it something else? Stuffing JavaScript/AJAX code inside a rendering 2.0 feels unfamiliar to me. * Second, existing LiveTable macro can be viewed in several ways: 1. Way of presenting a list of documents containing an object of a specific class. 2. Way of presenting a list of documents matching a criterion. 3. Generic way of presenting information mactching a criterion. I'm having a hard time figuring out what should be the exact purpose of LiveTable 2.0 macro, should it be same as LiveTable 1.0 macro? * Third, LiveTable macro uses several resources. 1. XWiki.LiveTableResults 2. XWiki.LiveTableResultsMacros 3. LiveTable JavaScript widget & CSS If we decide that LiveTable 2.0 macro should serve the same purpose as LiveTable 1.0 macro, should these resources be reused? (within the 2.0 rendering macro) Please help me to clarify these issues, I'm a bit lost here. Many thanks. - Asiri

5 14

[xwiki-devs] Should we hide changes from superadmin from simple users in Recent Changes?
by Vincent Massol 18 Sep '09

18 Sep '09

WDYT? Thanks -Vincent

6 7

[xwiki-devs] [Proposal] Stop using $msg.get()
by Vincent Massol 18 Sep '09

18 Sep '09

Hi, We now used $msg.get() eveywhere in the default XAR. IMO this is bad for the following reasons: * Our search no longer returns hits since it searches on the page content in the database (web search). BTW this is why some REST tests were failing since the content no longer existed for it (it does a hibernate search). * Users get to see $msg.get() everywhere in document titles when they edit XE pages, which is ugly and not understandable for simple users (for ex check Main.WebHome). * It's not a good way to translate apps since we bundle app translations keys in the core jar! Apps should be self-standing What should we do instead? Proposal: * Use the xwiki page translation feature... * Provide a XAR with all languages (and possibly a XAR per language). If the user configures his wiki for one language he'll see only that language (make sure all translations are imported even when in mono language) * Refactor existing pages to separate content from code. Move code to separate pages included from content pages. Never put content in code pages, have it passed to velocity macros for example. On the technical side we need to verify it can work but this is way better and would address the shortcomings listed above. Thanks -Vincent

4 6

[xwiki-devs] [VOTE] Title compat flag on for now for 2.0 final
by Vincent Massol 18 Sep '09

18 Sep '09

Hi, I'd like to set the compat flag on for now since we haven't converted all page titles yet and this is going to take some time. We should move it back to off when it's all converted. +1 Thanks -Vincent

4 4

[xwiki-devs] interesting comparison of scriping languages for Java from JavaOne
by Niels Mayer 17 Sep '09

17 Sep '09

Too bad Groovy isn't in here: "Alternative Languages on a JVM" http://www.azulsystems.com/events/javaone_2009/session/2009_J1_JVMLang.pdf ... > Deeper Dive > Clojure - “almost close” ● Good: no obvious subroutine calls in inner loop ● Bad: Massive “ephemeral” object allocation - requires good GC ● But needs Escape Analysis to go really fast ● Ugly: fix-num overflow checks everywhere ● Turn off fix-nums: same speed as Java ● Weird “holes” - ● Not-optimized reflection calls here & there ● Can get reports on generated reflection calls 10 Deeper Dive > Jython - “almost close” ● Also has fix-num issue; massive allocation ● Some extra locks thrown in > JavaScript/Rhino - “almost close” ● All things are Doubles – not 'double' ● Same fix-num allocation issues as Clojure, Jython ● Otherwise looks pretty good (no fix-num checks) > JRuby – Missed The Metal ● Assuming CachingCallSite::call inlines ● Using -XX:+PrintInlining to determine ● But flag is lying: claims method inlined, but it's not 11 Common Issue – Fix-Nums > Huge allocation rate of “fix-nums” ● Allocation is not free ● Setting final fields cost a memory fence ● GC does NOT cost here ● i.e., object pooling would be a big loser > Could do much better with JIT ● Need “ultra-stupid” Escape Analysis ● Need some (easy) JIT tweaking ● e.g. Getting around Integer.valueOf(i) caching 12 JRuby – Missed The Metal > Each minor action dispatches via “call” > Assuming CachingCallSite::call inlines ● (and allows further inlining) > Using -XX:+PrintInlining to determine > But flag is lying: claims inlined, but it's not ● BimorphicInlining is 'guessing' wrong target > Confirmed w/GDB on X86 Java6 > Confirmed w/Azul profiler ● My 1st impression: can't be inlined ever Niels http://nielsmayer.com

2 1

[xwiki-devs] Skin TODOs for the 2.0 RC1 release
by Vincent Massol 17 Sep '09

17 Sep '09

Hi, Here are skin problems I can see that need to be fixed before the RC1 release: 1) ColorTheme space is not excluded for simple users 2) On admin page the large header is not correctly positioned 3) Colibri is not set to be the skin by default 4) Colibri is not using the voted default colors 5) The colorTheme property is not set in XWikiPreferences 6) There's no theme editor/chooser available from the admin presentation page 7) Ugly (too large) create button on the blog home page 8) Blog title is no longer using the Blog object title value 9) When going to a blog post page there are 2 dup titles that really don't look nice 10) Use profile page has dup titles. XWiki.User does not start directly with the title, but wraps it inside a vcard microformat. 11) Main.WebSearch is not a plain title, but also contains an icon link to the RSS results. The document should be updated. 12) Main.Tags does not have a heading, but a div styled to look like a heading. Also, it is not a simple title, it also incorporates tools for the selected tag. Anything else that is a blocker for the RC1 and 2.0 final release? Can we spread the work amongst ourselves? Please volunteer to take some items. Note1: This means that we're late yet again since today is supposed to be the release day for RC1... This means we need to finish all the items above today at latest. Note2: I haven't looked at existing colibri skin issues already in jira. Please someone have a look and add to the list above if they are blocker for RC1. Let's crack this all together today! Thanks -Vincent

4 12

[xwiki-devs] [Proposal] Title compatibility flag
by Vincent Massol 17 Sep '09

17 Sep '09

Hi, Following our discussion on the new title behavior we need to define the title compat flag value. I'm proposing: #-# Defines whether title handling should be using the compatyiblity mode or not. When the compatibility #-# mode is active, if the document's content first header (level 1 or level 2) matches the document's title #-# the first header is stripped. xwiki.title.compatibility=0 + we need a way to access this property from contentview.vm so I'm proposing to also add a method to api.XWiki: isTitleInCompatibilityMode() WDYT? Thanks -Vincent

6 7

[xwiki-devs] enterprise pom.xml : hibernate.cfg.xml empty ?
by Hervé Agnoux 16 Sep '09

16 Sep '09

Hi, For some reasons, I build XWiki Enterprise with netbeans and maven. I checkout http://svn.xwiki.org/svnroot/xwiki/enterprise/trunk, I choose project "XWiki Products - Enterprise - Web (war)", I run, and I see in my navigator : Etat HTTP 500 - javax.servlet.ServletException: com.xpn.xwiki.XWikiException: Error number 3 in 0: Could not initialize main XWiki context Wrapped Exception: Error number 3001 in 3: Cannot load class com.xpn.xwiki.store.migration.hibernate.XWikiHibernateMigrationManager from param xwiki.store.migration.manager.class Wrapped Exception: Error number 0 in 3: Exception while hibernate execute Wrapped Exception: Hibernate Dialect must be explicitly set I read in googled world there is a hibernate.cfg.xml. In my checkouted directory, there is a checkout/trunk/web/src/main/webapp/WEB- INF/hibernate.cfg.xml, but this file is empty ? Is it this file ? I read some parts on http://platform.xwiki.org/xwiki/bin/view/AdminGuide/InstallationHSQL but I can't see a complete model hibernate.cfg.xml Thanks for your help.

3 9

[xwiki-devs] [VOTE] Change the default author of documents created programmatically or provided in XARs
by Jean-Vincent Drean 16 Sep '09

16 Sep '09

Hi devs, I'm currently working on documents we create from core/plugins or those we bundle in XARs (xwiki/2.0 conversion, filling title field, etc). I'd like to take advantage of this to discuss about the author we use in those documents. We currently have 2 different behaviors: - classes created from the core usually have their author set to "" - classes created from plugins (skinx, scheduler, etc) or bundled in our XARs usually have their author set to "XWiki.Admin" It lacks consistency and it can lead to security issues. If for some reason the administrator of a wiki decide to delete the XWiki.Admin account some can re-create it and gain the authorship -- thus the right to delete -- plenty of XE documents. We can decide to: 1) Only tackle the consistency problem and use "XWiki.Admin" everywhere 2) Solve the 2 problems by extending core policy to all our documents, ie. use "" everywhere 3) Solve the 2 problems by using a special username everywhere, like "System". Here's my +1 for 3), rationale: - 1) is only a quick fix and core shouldn't be aware of a user that comes with XE, - 2) is fine except that not having an author seems unnatural from a user POV. - In the future we could decide to have special handler for the "System" user, like pointing to a page explaining that it is a pseudo-user when we use $xwiki.getLocalUserName("System"). JV.

5 7

[xwiki-devs] Good News for the XWiki Open Source Project: French State Research funding
by Ludovic Dubost 16 Sep '09

16 Sep '09

Hi XWiki Community, I'm happy to share some good news for the XWiki Platform and Community that we got today. We (XWiki SAS) had responded to a French Government Call for Web 2.0 Projects in early July and we got the good news today that our project was selected with 43 other projects (among 340 proposals) to receive state funding. In this project, where the research entity INRIA/ECOO and Open Source company Mandriva are also participating, we have proposed to enhance XWiki's social features and integrate Real-Time capabilities in XWiki (both for editing information and viewing information in real-time). We already worked with INRIA/ECOO on XWiki Concerto (offline and mobile XWiki) which is the specialist in France and probably Europe of Operational Transformation Technology (which is used in Google Wave for real-time capabilities). We'll talk more about the features this will bring to XWiki when we formally launch the project. We don't know yet how fast it will go to formalize the public funding and start the project (it usually takes at least a few month). It's great to be able to continue to work on innovative technologies in the Wiki space, which is not that easy as we have already so much work to package and polish all the great ideas and features that are already in the XWiki platform. It's also great to see the progress the XWiki software has made in the last year, from XWiki 1.8 to XWiki 2.0 coming out soon. The new rendering, new Wysiwyg editor, the Office Importer and now the new skin are making XWiki do a lightyear of progress in just one year ! Ludovic -- Ludovic Dubost Blog: http://blog.ludovic.org/ XWiki: http://www.xwiki.com Skype: ldubost GTalk: ldubost

3 2

[xwiki-devs] Orphaned WikiMacroClass & WikiMacroParameterClass
by Vincent Massol 15 Sep '09

15 Sep '09

Hi Asiri, They are still orphaned in the 2.0 branch (just rebuilt a few minutes ago) Thanks -Vincent

4 4

[xwiki-devs] [VOTE] New RegexTool velocity tool
by Vincent Massol 15 Sep '09

15 Sep '09

Hi, I'm working on http://jira.xwiki.org/jira/browse/XWIKI-4345 and in order to implement the logic in contenview.vm I need to perform some regex find() from velocity. I'd like to propose introducing a new velocity tool for this: #-# velocity.tools = regextool = org.xwiki.velocity.tools.RegexTool Right now RegexTool has one method: /** * @param content the content to parse * @param regex the regex to look for in the passed content * @return empty list if the passed regex doesn't match the content or several {@link RegexResult} objects * containing the matched position and matched content for all capturing groups, the first group * representing the whole . The first object is represents the entier pattern */ public List<RegexResult> find(String content, String regex) { List<RegexResult> result = new ArrayList<RegexResult>(); Matcher matcher = Pattern.compile(regex, Pattern.MULTILINE).matcher(content); if (matcher.find()) { for (int i = 0; i < matcher.groupCount() + 1; i++) { result.add(new RegexResult(matcher.start(i), matcher.end(i), matcher.group(i))); } } return result; } WDYT? FYI here's what I currently have in contenview.vm: ## ---------------------------------------------------------------------------- ## Remove the first rendered H1 or H2 if the following conditions are met: ## - the document's title is set ## - the title compatibility flag is on ## - the title extracted from the rendered content is the same as the set title ## We need to do this since we've changed how titles are used and we need to ## ensure we don't break existing documents that have not yet migrated to the ## new way. ## ----------------------------------------------------------------------------- #set ($titleToDisplay = $tdoc.displayTitle) #if ($cdoc.title && $cdoc.title.length() > 0) ## Look for first H1 or H2 either in lowercase or uppercase #set ($regexResult = $regextool.find($renderedContent, "<[hH][12].*? ><span>(.*)</span></[hH][12]>")) #if (!$regexResult.isEmpty() && $regexResult.get(1).group.equals($titleToDisplay)) #if ($regexResult.get(0).end < $mathtool.sub($renderedContent.length(), 1)) #set ($renderedContent = "${renderedContent.substring(0, $regexResult.get(0).start)}$ {renderedContent.substring($regexResult.get(0).end)}") #else #set ($renderedContent = $renderedContent.substring(0, $regexResult.get(0).start)) #end #end #end Note that the other option is to introduce yet another API in Document for this but it doesn't look right to me. Here's my +1 Thanks -Vincent

3 2

[xwiki-devs] Proposal to manage columns using simple tables in the Wysiwyg editor
by Ludovic Dubost 15 Sep '09

15 Sep '09

Hi, In multiple cases, we have heard the requirements to manage simple 2 or 3 column layouts in the Wysiwyg. This has come up with some users and is a need in the Socracy project (http://www.socracy.org) I've thought a bit more about this need and realized we could handle it quite simply using our already available Table feature in the Wysiwyg. For this the only thing we actually need would be to be able to edit the "class" being assigned to a table. I've made some CSS to show the results that we could have using such a class: http://incubator.myxwiki.org/xwiki/bin/view/Test/TestColumns The only special thing that these tables have in the wiki syntax is a class assigned: (% class="columns2" %) or (% class="columns3" %) The rest is CSS magic put in the skin. The way I see it would be to have the possibility to choose between different classes when creating or editing table properties. The list of available classes could be a preference set in the Wiki, this way we could extend the styles available for tables. Not only we could handle columns this way but we could also have additional styles for table (home page tables or table to show numbers, etc..). This is not too much work in the Wysiwyg and can provide quite some benefits to make nice presentations in XWiki. WDYT ? Ludovic -- Ludovic Dubost Blog: http://blog.ludovic.org/ XWiki: http://www.xwiki.com Skype: ldubost GTalk: ldubost

4 3

[xwiki-devs] Pb with new Dashboard content & wysiwyg
by Vincent Massol 15 Sep '09

15 Sep '09

Hi, Try editing http://localhost:8080/xwiki/bin/edit/Main/Dashboard You'll get "Document in space null" and "Recent Changes for space null" And you won't see any changes, etc. There seems to be a context problem somewhere. Thanks -Vincent

1 0

Re: [xwiki-devs] [xwiki-notifications] r23516 - platform/core/trunk/xwiki-core/src/main/java/com/xpn/xwiki/plugin/feed
by Vincent Massol 15 Sep '09

15 Sep '09

Hi, On Sep 14, 2009, at 6:13 PM, jvdrean (SVN) wrote: > Author: jvdrean > Date: 2009-09-14 18:13:16 +0200 (Mon, 14 Sep 2009) > New Revision: 23516 > > Modified: > platform/core/trunk/xwiki-core/src/main/java/com/xpn/xwiki/plugin/ > feed/FeedPlugin.java > platform/core/trunk/xwiki-core/src/main/java/com/xpn/xwiki/plugin/ > feed/FeedPluginApi.java > platform/core/trunk/xwiki-core/src/main/java/com/xpn/xwiki/plugin/ > feed/SyndEntryDocumentSource.java > platform/core/trunk/xwiki-core/src/main/java/com/xpn/xwiki/plugin/ > feed/SyndEntrySource.java > platform/core/trunk/xwiki-core/src/main/java/com/xpn/xwiki/plugin/ > feed/SyndEntrySourceApi.java > Log: > [misc] Introduce generics [snip] > /** > @@ -470,7 +481,8 @@ > */ > public SyndFeed getWebFeed(String query, int count, int start) > { > - return getWebFeed(query, count, start, > Collections.EMPTY_MAP); > + Map<String, Object> metadata = new HashMap<String, Object>(); > + return getWebFeed(query, count, start, metadata); > } Shouldn't this use Collections.emptyMap()? Thanks -Vincent

2 2

Re: [xwiki-devs] [xwiki-notifications] r23517 - in platform/core/branches/xwiki-core-2.0/xwiki-rendering: xwiki-rendering-api/src/main/java/org/xwiki/rendering/internal/renderer/xwiki xwiki-rendering-tests/src/test/java/org/xwiki/rendering xwiki-rend
by Thomas Mortagne 15 Sep '09

15 Sep '09

On Mon, Sep 14, 2009 at 21:11, Vincent Massol <vincent(a)massol.net> wrote: > > On Sep 14, 2009, at 6:22 PM, tmortagne (SVN) wrote: > >> Author: tmortagne >> Date: 2009-09-14 18:22:10 +0200 (Mon, 14 Sep 2009) >> New Revision: 23517 >> >> Added: >> platform/core/branches/xwiki-core-2.0/xwiki-rendering/xwiki- >> rendering-tests/src/test/resources/escape/escape20.test >> Modified: >> platform/core/branches/xwiki-core-2.0/xwiki-rendering/xwiki- >> rendering-api/src/main/java/org/xwiki/rendering/internal/renderer/ >> xwiki/XWikiSyntaxEscapeHandler.java >> platform/core/branches/xwiki-core-2.0/xwiki-rendering/xwiki- >> rendering-tests/src/test/java/org/xwiki/rendering/ >> SimpleRenderingTests.java >> Log: >> XWIKI-4341: Quote syntax is not escaped when HTML is parsed >> >> Modified: platform/core/branches/xwiki-core-2.0/xwiki-rendering/ >> xwiki-rendering-api/src/main/java/org/xwiki/rendering/internal/ >> renderer/xwiki/XWikiSyntaxEscapeHandler.java >> =================================================================== >> --- platform/core/branches/xwiki-core-2.0/xwiki-rendering/xwiki- >> rendering-api/src/main/java/org/xwiki/rendering/internal/renderer/ >> xwiki/XWikiSyntaxEscapeHandler.java 2009-09-14 16:13:16 UTC (rev >> 23516) >> +++ platform/core/branches/xwiki-core-2.0/xwiki-rendering/xwiki- >> rendering-api/src/main/java/org/xwiki/rendering/internal/renderer/ >> xwiki/XWikiSyntaxEscapeHandler.java 2009-09-14 16:22:10 UTC (rev >> 23517) >> @@ -43,6 +43,8 @@ >> private static final Pattern LIST_PATTERN = >> Pattern.compile("\\p{Blank}*((\\*+[:;]*)|([1*]+\\.[:;]*)| >> ([:;]+))\\p{Blank}+"); >> >> + private static final Pattern QUOTE_PATTERN = Pattern.compile("(\ >> \>+)"); >> + >> private static final Pattern HEADER_PATTERN = Pattern.compile("\ >> \p{Blank}*(=+)"); >> >> private static final Pattern TABLE_PATTERN = Pattern.compile("\ >> \p{Blank}*(\\||!!)"); >> @@ -77,6 +79,9 @@ >> >> // Look for table character patterns at beginning of >> line and escape the first character only (it's enough) >> escapeFirstMatchedCharacter(TABLE_PATTERN, >> accumulatedBuffer); >> + >> + // Look for quote pattern at beginning of line and >> escape the first character only (it's enough) >> + escapeFirstMatchedCharacter(QUOTE_PATTERN, >> accumulatedBuffer); >> } >> >> // Escape table characters >> @@ -136,7 +141,7 @@ >> >> // Escape begin link >> replaceAll(accumulatedBuffer, "[[", ESCAPE_CHAR + "[" + >> ESCAPE_CHAR + "["); >> - >> + >> // Escape link label >> int linkLevel = getLinkLevel(listenerChain); >> >> >> Modified: platform/core/branches/xwiki-core-2.0/xwiki-rendering/ >> xwiki-rendering-tests/src/test/java/org/xwiki/rendering/ >> SimpleRenderingTests.java >> =================================================================== >> --- platform/core/branches/xwiki-core-2.0/xwiki-rendering/xwiki- >> rendering-tests/src/test/java/org/xwiki/rendering/ >> SimpleRenderingTests.java 2009-09-14 16:13:16 UTC (rev 23516) >> +++ platform/core/branches/xwiki-core-2.0/xwiki-rendering/xwiki- >> rendering-tests/src/test/java/org/xwiki/rendering/ >> SimpleRenderingTests.java 2009-09-14 16:22:10 UTC (rev 23517) >> @@ -184,6 +184,7 @@ >> suite.addTestsFromResource("escape/escape17", false); >> suite.addTestsFromResource("escape/escape18", false); >> suite.addTestsFromResource("escape/escape19", false); >> + suite.addTestsFromResource("escape/escape20", false); >> >> // Other >> suite.addTestsFromResource("horizontalline/horizontalline1", >> false); >> >> Added: platform/core/branches/xwiki-core-2.0/xwiki-rendering/xwiki- >> rendering-tests/src/test/resources/escape/escape20.test >> =================================================================== >> --- platform/core/branches/xwiki-core-2.0/xwiki-rendering/xwiki- >> rendering-tests/src/test/resources/escape/ >> escape20.test (rev 0) >> +++ platform/core/branches/xwiki-core-2.0/xwiki-rendering/xwiki- >> rendering-tests/src/test/resources/escape/escape20.test 2009-09-14 >> 16:22:10 UTC (rev 23517) >> @@ -0,0 +1,19 @@ >> + >> .#--------------------------------------------------------------------------------------------------------- >> +.input|xwiki/2.0 >> +.# Verify that ) is escaped if last character of a group > > The comment talks about ")" but the test below is about ">". > > copy paste? Yes as usual, always do the same mistake, fixing it. Thanks for the report. > > Thanks > -Vincent > >> + >> .#--------------------------------------------------------------------------------------------------------- >> +~> text >> +.#----------------------------------------------------- >> +.expect|event/1.0 >> +.#----------------------------------------------------- >> +beginDocument >> +beginParagraph >> +onSpecialSymbol [>] >> +onSpace >> +onWord [text] >> +endParagraph >> +endDocument >> +.#----------------------------------------------------- >> +.expect|xwiki/2.0 >> +.#----------------------------------------------------- >> +~> text >> \ No newline at end of file > _______________________________________________ > devs mailing list > devs(a)xwiki.org > http://lists.xwiki.org/mailman/listinfo/devs > -- Thomas Mortagne

1 0

[xwiki-devs] [VOTE] Upgrade the 2.0 branch to GWT 1.7
by Marius Dumitru Florea 15 Sep '09

15 Sep '09

Hi devs, I upgraded the 2.1 branch to GWT 1.7 and I'm waiting for Hudson to run the selenium tests. If everything goes well I'd like to upgrade the 2.0 branch too. The main reason for doing this is to improve the support for IE8 (XWIKI3446 and XWIKI3448 for instance). Note that I ran the unit tests in IE8 and I got the same results as in IE6/7. Here's my +1 Thanks, Marius

7 7

Re: [xwiki-devs] [xwiki-notifications] r23517 - in platform/core/branches/xwiki-core-2.0/xwiki-rendering: xwiki-rendering-api/src/main/java/org/xwiki/rendering/internal/renderer/xwiki xwiki-rendering-tests/src/test/java/org/xwiki/rendering xwiki-rendering-tests/src/test/resources/escape
by Vincent Massol 14 Sep '09

14 Sep '09

On Sep 14, 2009, at 6:22 PM, tmortagne (SVN) wrote: > Author: tmortagne > Date: 2009-09-14 18:22:10 +0200 (Mon, 14 Sep 2009) > New Revision: 23517 > > Added: > platform/core/branches/xwiki-core-2.0/xwiki-rendering/xwiki- > rendering-tests/src/test/resources/escape/escape20.test > Modified: > platform/core/branches/xwiki-core-2.0/xwiki-rendering/xwiki- > rendering-api/src/main/java/org/xwiki/rendering/internal/renderer/ > xwiki/XWikiSyntaxEscapeHandler.java > platform/core/branches/xwiki-core-2.0/xwiki-rendering/xwiki- > rendering-tests/src/test/java/org/xwiki/rendering/ > SimpleRenderingTests.java > Log: > XWIKI-4341: Quote syntax is not escaped when HTML is parsed > > Modified: platform/core/branches/xwiki-core-2.0/xwiki-rendering/ > xwiki-rendering-api/src/main/java/org/xwiki/rendering/internal/ > renderer/xwiki/XWikiSyntaxEscapeHandler.java > =================================================================== > --- platform/core/branches/xwiki-core-2.0/xwiki-rendering/xwiki- > rendering-api/src/main/java/org/xwiki/rendering/internal/renderer/ > xwiki/XWikiSyntaxEscapeHandler.java 2009-09-14 16:13:16 UTC (rev > 23516) > +++ platform/core/branches/xwiki-core-2.0/xwiki-rendering/xwiki- > rendering-api/src/main/java/org/xwiki/rendering/internal/renderer/ > xwiki/XWikiSyntaxEscapeHandler.java 2009-09-14 16:22:10 UTC (rev > 23517) > @@ -43,6 +43,8 @@ > private static final Pattern LIST_PATTERN = > Pattern.compile("\\p{Blank}*((\\*+[:;]*)|([1*]+\\.[:;]*)| > ([:;]+))\\p{Blank}+"); > > + private static final Pattern QUOTE_PATTERN = Pattern.compile("(\ > \>+)"); > + > private static final Pattern HEADER_PATTERN = Pattern.compile("\ > \p{Blank}*(=+)"); > > private static final Pattern TABLE_PATTERN = Pattern.compile("\ > \p{Blank}*(\\||!!)"); > @@ -77,6 +79,9 @@ > > // Look for table character patterns at beginning of > line and escape the first character only (it's enough) > escapeFirstMatchedCharacter(TABLE_PATTERN, > accumulatedBuffer); > + > + // Look for quote pattern at beginning of line and > escape the first character only (it's enough) > + escapeFirstMatchedCharacter(QUOTE_PATTERN, > accumulatedBuffer); > } > > // Escape table characters > @@ -136,7 +141,7 @@ > > // Escape begin link > replaceAll(accumulatedBuffer, "[[", ESCAPE_CHAR + "[" + > ESCAPE_CHAR + "["); > - > + > // Escape link label > int linkLevel = getLinkLevel(listenerChain); > > > Modified: platform/core/branches/xwiki-core-2.0/xwiki-rendering/ > xwiki-rendering-tests/src/test/java/org/xwiki/rendering/ > SimpleRenderingTests.java > =================================================================== > --- platform/core/branches/xwiki-core-2.0/xwiki-rendering/xwiki- > rendering-tests/src/test/java/org/xwiki/rendering/ > SimpleRenderingTests.java 2009-09-14 16:13:16 UTC (rev 23516) > +++ platform/core/branches/xwiki-core-2.0/xwiki-rendering/xwiki- > rendering-tests/src/test/java/org/xwiki/rendering/ > SimpleRenderingTests.java 2009-09-14 16:22:10 UTC (rev 23517) > @@ -184,6 +184,7 @@ > suite.addTestsFromResource("escape/escape17", false); > suite.addTestsFromResource("escape/escape18", false); > suite.addTestsFromResource("escape/escape19", false); > + suite.addTestsFromResource("escape/escape20", false); > > // Other > suite.addTestsFromResource("horizontalline/horizontalline1", > false); > > Added: platform/core/branches/xwiki-core-2.0/xwiki-rendering/xwiki- > rendering-tests/src/test/resources/escape/escape20.test > =================================================================== > --- platform/core/branches/xwiki-core-2.0/xwiki-rendering/xwiki- > rendering-tests/src/test/resources/escape/ > escape20.test (rev 0) > +++ platform/core/branches/xwiki-core-2.0/xwiki-rendering/xwiki- > rendering-tests/src/test/resources/escape/escape20.test 2009-09-14 > 16:22:10 UTC (rev 23517) > @@ -0,0 +1,19 @@ > + > .#--------------------------------------------------------------------------------------------------------- > +.input|xwiki/2.0 > +.# Verify that ) is escaped if last character of a group The comment talks about ")" but the test below is about ">". copy paste? Thanks -Vincent > + > .#--------------------------------------------------------------------------------------------------------- > +~> text > +.#----------------------------------------------------- > +.expect|event/1.0 > +.#----------------------------------------------------- > +beginDocument > +beginParagraph > +onSpecialSymbol [>] > +onSpace > +onWord [text] > +endParagraph > +endDocument > +.#----------------------------------------------------- > +.expect|xwiki/2.0 > +.#----------------------------------------------------- > +~> text > \ No newline at end of file

1 0

[xwiki-devs] [UX] Edit Buttons Order
by Ecaterina Valica 14 Sep '09

14 Sep '09

Hi, Because we want to make a standard from vertical-aligned form, this means the buttons should be left-ordered with the most important action first. This should be changed also in Toucan and Albatross skin, not only just in Colibri. Right now the Edit Actions are "Cancel", "Preview", "Save&Continue", "Save&View". What do you think is the right order for them when they are left-aligned? (A) Save&View, Save&Continue, Preview, Cancel (as it is - just in reverse) (B) Save&View, Preview, Save&Continue, Cancel (C) Preview, Save&Continue, Save&View, Cancel (D) other variation Remarks: - "Cancel" should be *last* because it's a terminal (takes you out of the editor), no-saving action. This is the least important. - "Save & View" is also a terminal action (takes you out of the editor) - having it* first* you have the 2 terminal actions at extremities. - "Preview" is the least damaging action in case of accidental submit (Silvia + Marta) - should be *first*? - Some people use ("Preview" + "Save&Continue") {many times} + "Save&View" {final} - Other people just use "Save&Continue" + "Save & View" {final}, never "Preview", etc - What is the necessity for the "Preview" button in a WYSIYWG editor? On the other hand "Preview" is very important if you edit in "Wiki" mode. - Should "Preview" separate the two other SAVING actions? (Marta) - Should "Save&Continue" separate the two other VIEW actions? Thanks, Caty

8 18

[xwiki-devs] about the playground
by [Ricardo Rodriguez] Your EPEC Network ICT Team 13 Sep '09

13 Sep '09

Hi! I've being lately using the XWiki playground to test access to some sample pages with wget and simple authentication. It worked fine. No, when I login I've no access the the site contents. Here what I am seeing.... http://xen.net/images/xwikiPlayground.png I know that the functioning of the playground is not guarantee but do you expect to recover a "normal" operation soon? Thanks! All the best, Ricardo -- Ricardo Rodríguez Your EPEC Network ICT Team

2 2

[xwiki-devs] XWiki.XWikiPreferences_* properties not used anywhere?
by Vincent Massol 12 Sep '09

12 Sep '09

Hi, It seems that the XWiki.XWikiPreferences_* properties are not used anywhere. For example: # XWiki.XWikiPreferences (core) XWiki.XWikiPreferences_skin=Skin XWiki.XWikiPreferences_colorTheme=Color theme XWiki.XWikiPreferences_webbgcolor=Space Background Color XWiki.XWikiPreferences_authenticate_view=Authenticated View XWiki.XWikiPreferences_webcopyright=Space Copyright XWiki.XWikiPreferences_plugins=Plugins XWiki.XWikiPreferences_authenticate_edit=Authenticate On Edit XWiki.XWikiPreferences_menu=Menu XWiki.XWikiPreferences_meta=HTTP Meta Info XWiki.XWikiPreferences_title=Title XWiki.XWikiPreferences_version=Version XWiki.XWikiPreferences_smtp_server=Server XWiki.XWikiPreferences_smtp_port=Port XWiki.XWikiPreferences_smtp_server_username=Server username (optional) XWiki.XWikiPreferences_smtp_server_password=Server password (optional) XWiki.XWikiPreferences_javamail_extra_props=Additional JavaMail properties XWiki.XWikiPreferences_admin_email=Admin email XWiki.XWikiPreferences_validation_email_content=Validation email Content XWiki.XWikiPreferences_confirmation_email_content=Confirmation email Content XWiki.XWikiPreferences_stylesheet=Stylesheet XWiki.XWikiPreferences_stylesheets=Stylesheets XWiki.XWikiPreferences_multilingual=Multilingual XWiki.XWikiPreferences_default_language=Default Language XWiki.XWikiPreferences_editor=Default Editor XWiki.XWikiPreferences_core.defaultDocumentSyntax=Default document syntax XWiki.XWikiPreferences_editbox_width=Editbox Width XWiki.XWikiPreferences_use_email_verification=Use email Verification XWiki.XWikiPreferences_editbox_height=Editbox Height XWiki.XWikiPreferences_ad_clientid=Advertisement Client ID XWiki.XWikiPreferences_backlinks=Backlinks XWiki.XWikiPreferences_macros_languages=Macros Languages XWiki.XWikiPreferences_macros_velocity=Macros for Velocity XWiki.XWikiPreferences_macros_groovy=Macros for Groovy XWiki.XWikiPreferences_macros_wiki2=Macros for new wiki Parser XWiki.XWikiPreferences_macros_mapping=Macros Mapping XWiki.XWikiPreferences_auth_active_check=Authentication Active Check XWiki.XWikiPreferences_macros_wiki=Macros for the wiki Parser XWiki.XWikiPreferences_notification_pages=Notification Pages XWiki.XWikiPreferences_invitation_email_content=Invitation email content XWiki.XWikiPreferences_registration_anonymous=Anonymous XWiki.XWikiPreferences_registration_registered=Registered XWiki.XWikiPreferences_edit_anonymous=Anonymous XWiki.XWikiPreferences_edit_registered=Registered XWiki.XWikiPreferences_comment_anonymous=Anonymous XWiki.XWikiPreferences_comment_registered=Registered XWiki.XWikiPreferences_renderXWikiVelocityRenderer=Render velocity code XWiki.XWikiPreferences_renderXWikiGroovyRenderer=Render Groovy code XWiki.XWikiPreferences_renderXWikiRadeoxRenderer=Render Wiki syntax XWiki.XWikiPreferences_leftPanels=Panels displayed on the left XWiki.XWikiPreferences_rightPanels=Panels displayed on the right XWiki.XWikiPreferences_showLeftPanels=Display the left panel column XWiki.XWikiPreferences_showRightPanels=Display the right panel column XWiki.XWikiPreferences_pageWidth=Preferred page width XWiki.XWikiPreferences_languages=Supported languages XWiki.XWikiPreferences_convertmail=convert email type XWiki.XWikiPreferences_tags=Activate the tagging XWiki.XWikiPreferences_parent=Parent space XWiki.XWikiPreferences_documentBundles=Internationalization Document Bundles XWiki.XWikiPreferences_upload_maxsize=Maximum Upload Size Is that so? I've searched for XWiki.XWikiPreferences_editor=Default Editor and couldn't find it anywhere and XWiki.XWikiPreferences_core.defaultDocumentSyntax isn't used in the General admin page (this is why this text is not translated in French for ex). Any idea? Thanks -Vincent

2 2

[xwiki-devs] [ANN] XWiki Enterprise 2.0 RC 1 released
by Thomas Mortagne 12 Sep '09

12 Sep '09

The XWiki development team is pleased to announce the release of XWiki Enterprise 2.0 RC 1. Go grab it at http://www.xwiki.org/xwiki/bin/view/Main/Download This is the first release candidate for the XWiki enterprise 2.0 version. It will be followed by a second RC. 133 Jira issues has been closed for this release. Changes from 2.0 Milestone 4: * Many improvements and bug fixes in the new Colibri skin * Many general UI improvements * Many WYSIWYG improvements * Many Rendering 2.0 improvements ** Script macro improvements ** Introduce Python macro * Many Watchlist improvements * Activity stream improvements * Blog categories UI improvement * Update translations: fr, de, ro, sv 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://platform.xwiki.org/xwiki/bin/view/AdminGuide/DistributedEventCluster… to test the new event based clustering support. For more information see the Release notes at: http://www.xwiki.org/xwiki/bin/view/Main/ReleaseNotesXWikiEnterprise20RC1 Thanks -The XWiki dev team

3 2

[xwiki-devs] Could you recommend some good books or material which could help me overcome the learning curve of developing Xwiki?
by Leon Wang 12 Sep '09

12 Sep '09

Hi everyone, Could you recommend some books or material which could help me overcome the learning curve of developing Xwiki? I have read the book Maven Definitive Guide. Thank you all! Everyone have a wonderful weekend! Leon

2 1

[xwiki-devs] 2.0 RC1 not working with jar installer or exe installer?
by Vincent Massol 11 Sep '09

11 Sep '09

Hi, Someone just reported http://jira.xwiki.org/jira/browse/XE-492 Could it be caused by the jar installer or the exe one? I thought we had fixed this. It may be something else but it looks very close to the issue reported before. WDYT? Thanks -Vincent

1 0

[xwiki-devs] [NOTICE] Publishing gwt-incubator-july-14-2009.jar to our maven repo
by Marius Dumitru Florea 11 Sep '09

11 Sep '09

Hi devs, The WYSIWYG editor uses the GlassPanel widget from GWT incubator. The version currently used doesn't work with GWT 1.7 ( http://tinyurl.com/nwr4bm ) so we have to upgrade. Unfortunately the latest version is not yet published to the maven central repo ( http://tinyurl.com/ksuh7h ) so we have to publish it in our repo. Let me know if you have something against it. Thanks, Marius

2 1

Re: [xwiki-devs] [xwiki-notifications] r23469 - platform/core/trunk/xwiki-core/src/main/java/com/xpn/xwiki/internal
by Vincent Massol 11 Sep '09

11 Sep '09

Hi Asiri, I see you're setting the content author to "System". This hasn't been agreed yet. Could you please send a vote email on the list since it's an important decision? Thanks -Vincent On Sep 11, 2009, at 12:53 PM, asiri (SVN) wrote: > Author: asiri > Date: 2009-09-11 12:53:31 +0200 (Fri, 11 Sep 2009) > New Revision: 23469 > > Modified: > platform/core/trunk/xwiki-core/src/main/java/com/xpn/xwiki/ > internal/DefaultWikiMacroInitializer.java > Log: > XWIKI-4320: XWiki.WikiMacroClass and XWiki.WikiMacroParameterClass > are orphaned > > * Fixed. > > Modified: platform/core/trunk/xwiki-core/src/main/java/com/xpn/xwiki/ > internal/DefaultWikiMacroInitializer.java > =================================================================== > --- platform/core/trunk/xwiki-core/src/main/java/com/xpn/xwiki/ > internal/DefaultWikiMacroInitializer.java 2009-09-11 10:44:24 UTC > (rev 23468) > +++ platform/core/trunk/xwiki-core/src/main/java/com/xpn/xwiki/ > internal/DefaultWikiMacroInitializer.java 2009-09-11 10:53:31 UTC > (rev 23469) > @@ -28,10 +28,10 @@ > import org.xwiki.component.annotation.Requirement; > import org.xwiki.component.logging.AbstractLogEnabled; > import org.xwiki.context.Execution; > -import org.xwiki.rendering.macro.wikibridge.WikiMacroInitializer; > import org.xwiki.rendering.macro.wikibridge.WikiMacro; > +import org.xwiki.rendering.macro.wikibridge.WikiMacroException; > import org.xwiki.rendering.macro.wikibridge.WikiMacroFactory; > -import org.xwiki.rendering.macro.wikibridge.WikiMacroException; > +import org.xwiki.rendering.macro.wikibridge.WikiMacroInitializer; > import org.xwiki.rendering.macro.wikibridge.WikiMacroManager; > > import com.xpn.xwiki.XWikiContext; > @@ -153,29 +153,50 @@ > needsUpdate |= > bclass.addTextAreaField(MACRO_DESCRIPTION_PROPERTY, "Macro > description", 40, 5); > needsUpdate |= > bclass.addTextField(MACRO_DEFAULT_CATEGORY_PROPERTY, "Default > category", 30); > needsUpdate |= bclass.addBooleanField(MACRO_INLINE_PROPERTY, > "Supports inline mode", "select"); > - needsUpdate |= > bclass.addStaticListField(MACRO_CONTENT_TYPE_PROPERTY, "Macro > content type", 1, false, > - "Mandatory|Optional|No content", "select", "|"); > - needsUpdate |= > bclass.addTextAreaField(MACRO_CONTENT_DESCRIPTION_PROPERTY, > - "Content description (Not applicable for \"No content\" > type)", 40, 5); > + needsUpdate |= > + bclass.addStaticListField(MACRO_CONTENT_TYPE_PROPERTY, > "Macro content type", 1, false, > + "Mandatory|Optional|No content", "select", "|"); > + needsUpdate |= > + > bclass.addTextAreaField(MACRO_CONTENT_DESCRIPTION_PROPERTY, > + "Content description (Not applicable for \"No > content\" type)", 40, 5); > needsUpdate |= bclass.addTextAreaField(MACRO_CODE_PROPERTY, > "Macro code", 40, 5); > - > + > if (needsUpdate) { > - xcontext.getWiki().saveDocument(doc, xcontext); > + update(doc); > } > - > + > // Install or Upgrade XWiki.WikiMacroParameterClass > doc = > xcontext.getWiki().getDocument(WIKI_MACRO_PARAMETER_CLASS, xcontext); > bclass = doc.getxWikiClass(); > bclass.setName(WIKI_MACRO_PARAMETER_CLASS); > - > + > needsUpdate = false; > - > + > needsUpdate |= bclass.addTextField(PARAMETER_NAME_PROPERTY, > "Parameter name", 30); > needsUpdate |= > bclass.addTextAreaField(PARAMETER_DESCRIPTION_PROPERTY, "Parameter > description", 40, 5); > needsUpdate |= > bclass.addBooleanField(PARAMETER_MANDATORY_PROPERTY, "Parameter > mandatory", "select"); > - > + > if (needsUpdate) { > - xcontext.getWiki().saveDocument(doc, xcontext); > + update(doc); > } > } > + > + /** > + * Utility method for updating a wiki macro class definition > document. > + * > + * @param doc xwiki document containing the wiki macro class. > + * @throws XWikiException if an error occurs while saving the > document. > + */ > + private void update(XWikiDocument doc) throws XWikiException > + { > + XWikiContext xcontext = getContext(); > + > + if (doc.isNew()) { > + doc.setCreator("System"); > + doc.setParent("XWiki.WebHome"); > + } > + > + doc.setAuthor("System"); > + xcontext.getWiki().saveDocument(doc, xcontext); > + } > } > > _______________________________________________ > notifications mailing list > notifications(a)xwiki.org > http://lists.xwiki.org/mailman/listinfo/notifications

1 0

[xwiki-devs] A better UI for annotation module
by Lucien Pereira 11 Sep '09

11 Sep '09

Hi all, Annotation module success depends strongly of being able to provide a great user exprerience. So I think current annotation module UI should be improved, for now it has only been tested in firefox. Since I really do not have skills concerning interface ergonomy, I would propose that a designer handle it. annotation feature installation and usage instructions can be found here http://dev.xwiki.org/xwiki/bin/view/Drafts/AnnotationModule WDYT ? Lucien

6 20

[xwiki-devs] Controlling the size of the editor for editing textarea properties?
by Vincent Massol 11 Sep '09

11 Sep '09

Hi guys, Is it possible to have a textarea property for which you have a wysiwyg editor that doesn't take all the horizontal space. For ex if the textarea property says 20 chars, is it possible to have an editor that is 20 chars wide? Same question with the wiki editor. Thanks -Vincent

2 2

[xwiki-devs] Orphaned Wiki Macro Classes
by Vincent Massol 11 Sep '09

11 Sep '09

Hi Asiri, You should put a parent when you create wiki macro classes since they're now orphaned. We should do this for RC2. Thanks -Vincent

2 4

[xwiki-devs] [VOTE] Release 2.0RC1 on the 10th of Sep (tomorrow)
by Vincent Massol 10 Sep '09

10 Sep '09

Hi, I'd also like to propose to release RC1 tomorrow (and note have colibri as the default skin in it), and continue fixing colibri in RC1, and release RC2 as planned on the 17th of sep, hoping that there's no RC3. This will allow people to start testing RC1 since it's an RC for everything except the new skin. Here's my +1 Thanks -Vincent

7 12

[xwiki-devs] [UX] Devs - UXdesigners collaboration point
by Thibaut DEVERAUX 10 Sep '09

10 Sep '09

Hi devs, I get some anxiety about two facts I noticed. I'm wondering if I should. Maybe you can give me advices ? Points are : - UX design can be faster than dev. Especially when UX design is made upon rapid expertise according to the UX designer experience. - Open source devs sometime dev for them own fun. People want UX advice, which can also easily transform in a list of a bunch of things to do. Well, even when UX goes faster than dev, a brainstorming period let ideas mature, fork, merge, jump to new ones... So it is not important if the UX specifications is not implemented immediatly as it mature among analysis & dev iterations. UX designers may have to explore various dimensions too detect the major points. This process can reveal also bunches of minor points that could be capitalised for later. What amaze me is when a UX analysis create to too many potential dev work, I'm always afraid of the risk of stressing and discouraging devs that code on them free time. This is quite the same as making user tests, or a vote, so this already exists. The result is a list of points to work on, with intrinsic relative importance evaluation. This could be a good point for classifing things, yet I'm amways affraid that some devs can feel less fun if this look like a pile of things to do (beacause I may feel it, that's why). Also when this is user advices, the dev is making is own classification by analysing the comments. So it is his classification. I know that, for my part, this sort of thing can be key in my motication. The fact may be that when asking an expert advice this is a bit different. The advice come directly from one person so if the dev consider the UX designer as an authority advice this may not be anymore his own classification. An approach that may be interesting could be that if the UX designer act as a consultant. I mean he transfert his knowledge to the dev by giving the details on how he makes his analysis and detect UX implications. So that the dev can take himself the decision of classifing the by mixing UX and Dev priorities according to the importance he gives to each single point. This means the dev has a will in entering the UX process details and gaining skills. Also this could be interesting for the UX designer because it let him share the brainstorming with devs and other UX designers before the decision is taken by project manager, community or the main dev. Iterations is always good in the UX design process. So this an approach. There may be others ones better, or adaptated among each cases. I would love to have feedbacks on this points, to be able to understand how people are felling about this. Thanks ! Thibaut.

1 0

[xwiki-devs] [VOTE] New title behavior handling for the 2.0 release
by Vincent Massol 09 Sep '09

09 Sep '09

Hi, Let's vote on how to handle the title behavior for the 2.0 final release so that we're all on the same page. After talking to several people here's what I propose: 1) We remove the top level H1 only if the title compat flag is on and the title H1 is the same as the top level H1 2) The compat flag is off by default in our distributions 3) We modify the Toucan and Albatross skins to display the title (same as Colibri) 4) We modify the Default XE XAR to have titles for all its pages (and remove the header 1 in page content) This should cover both user upgrades and new behavior. Note that user custom skin will still work in most cases since they're not normally touching the contentview.vm file. Here's my +1 Thanks -Vincent

7 18

[xwiki-devs] [VOTE] Let's have a XWiki Syntax 2.1 version for the future + freeze XWiki Syntax 2.0
by Vincent Massol 09 Sep '09

09 Sep '09

Hi, Even though we're relasing XE 2.0 final along with a finalized XWiki Syntax 2.0 there are still several improvements we'd like to bring to the syntax. To name a few: * Fix 2 passes done for wiki context inside links which requires escaping some chars in link labels. * Add support for comments - http://jira.xwiki.org/jira/browse/XWIKI-4027 * Mixed list syntax - http://jira.xwiki.org/jira/browse/XWIKI-3133 * Add format parameters support for macros - http://jira.xwiki.org/jira/browse/XWIKI-3237 * Add support for list item parameters in XWiki syntax - http://jira.xwiki.org/jira/browse/XWIKI-3132 * Complete advanced table syntax for XWiki 2.0 rendering - http://jira.xwiki.org/jira/browse/XWIKI-2658 (still to be decided) * XWiki Syntax 2.0 should ignore spaces before any "standalone block" syntax - http://jira.xwiki.org/jira/browse/XWIKI-3214 * Add support for relative paths in Link and Image XWiki Syntax 2.0 - http://jira.xwiki.org/jira/browse/XWIKI-3611 * ... and a lot more... Any of these changes are potentially breaking for existing content. For example if some current content uses the same syntax as the one we'll use for comments it's going to break the content. Thus the solution Thomas and I are proposing is to evolve the syntax by creating a XWiki Syntax 2.1 version: * Start working on it in XE 2.1 timeframe * Define precisely the changes we want to bring for this evolution * Let's name it something like "XWiki 2.1 (dev)" to show that it's not final and rename it to "XWiki 2.1" when it's finished and frozen For end users they'll be able to switch from any current syntax to the 2.1 syntax very easily simply by converting page by page (or by running a converter to convert a whole wiki). The conversion should be perfect. Let's this vote be also about freezing the XWiki 2.0 syntax with the 2.0 final release. This will mean we're forbidden to modify it and all changes should go in the XWiki Syntax 2.1. Here's my +1 to have a XWiki Syntax 2.1 in some not too far future and +1 to freeze the current 2.0 syntax with the XE 2.0 release. Thanks -Vincent

5 4

[xwiki-devs] [Proposal] Change of title behavior proposal
by Vincent Massol 09 Sep '09

09 Sep '09

Hi everyone, With Colibri we've started to display the doc title as the document's rendered title. This is a big change that not only affects Colibri but in general the way people write documents. Here's what I suggest: 1) Display doc titles with <div> 2) Display document content headers using <h1>-<h6> 3) Display doc titles with a larger font size than h1 (or h1 with a smaller font size) 4) Force cursor to be in the title field when editing a new document. Force cursor in the content field when editing an existing document. This is to make it easy using the keyboard only to enter doc titles (since it's currently dead easy, we need something close in easiness) 5) Modify all our existing skins: Toucan, Albatross, Finch and Dodo so that they use they display the doc title, similarly to Colibri 6) Have a title compatibility flag in xwiki.cfg. When active, use a Javascript to do this: if there's no title specified for a page and if the first content is a H1 then use it as the page's title. We need at least 1), 3), 6) to be able to release the Colibri skin for 2.0 final IMO. WDYT? Thanks -Vincent

9 28

Re: [xwiki-devs] [xwiki-notifications] r23373 - in platform/core/trunk/xwiki-rendering: xwiki-rendering-api/src/main/java/org/xwiki/rendering/internal/renderer/xwiki xwiki-rendering-tests/src/test/resources/link
by Vincent Massol 09 Sep '09

09 Sep '09

On Sep 9, 2009, at 1:00 PM, tmortagne (SVN) wrote: > Author: tmortagne > Date: 2009-09-09 13:00:18 +0200 (Wed, 09 Sep 2009) > New Revision: 23373 > > Modified: > platform/core/trunk/xwiki-rendering/xwiki-rendering-api/src/main/ > java/org/xwiki/rendering/internal/renderer/xwiki/ > XWikiSyntaxChainingRenderer.java > platform/core/trunk/xwiki-rendering/xwiki-rendering-tests/src/test/ > resources/link/links6.test > Log: > XWIKI-4294: xhtml renderer wrong escape reference in the startlink > html comment > XWIKI-4194: Inconsistent behavior when escaping "-" symbols > * improve a little escaping in links labels (less useless escaping) > > Modified: platform/core/trunk/xwiki-rendering/xwiki-rendering-api/ > src/main/java/org/xwiki/rendering/internal/renderer/xwiki/ > XWikiSyntaxChainingRenderer.java > =================================================================== > --- platform/core/trunk/xwiki-rendering/xwiki-rendering-api/src/main/ > java/org/xwiki/rendering/internal/renderer/xwiki/ > XWikiSyntaxChainingRenderer.java 2009-09-09 10:53:09 UTC (rev 23372) > +++ platform/core/trunk/xwiki-rendering/xwiki-rendering-api/src/main/ > java/org/xwiki/rendering/internal/renderer/xwiki/ > XWikiSyntaxChainingRenderer.java 2009-09-09 11:00:18 UTC (rev 23373) > @@ -760,13 +760,6 @@ > @Override > public void onImage(Image image, boolean isFreeStandingURI, > Map<String, String> parameters) > { > - // Flush test content before the link. > - // TODO: improve the block state renderer to be able to > make the difference between what is bufferized > - // before the link and what in the label link > - getXWikiPrinter().setBeforeLink(true); > - getXWikiPrinter().flush(); > - getXWikiPrinter().setBeforeLink(false); > - > Link link = new Link(); > link.setReference("image:" + > getImageRenderer().renderImage(image)); > link.setType(LinkType.URI); > > Modified: platform/core/trunk/xwiki-rendering/xwiki-rendering-tests/ > src/test/resources/link/links6.test > =================================================================== > --- platform/core/trunk/xwiki-rendering/xwiki-rendering-tests/src/ > test/resources/link/links6.test 2009-09-09 10:53:09 UTC (rev 23372) > +++ platform/core/trunk/xwiki-rendering/xwiki-rendering-tests/src/ > test/resources/link/links6.test 2009-09-09 11:00:18 UTC (rev 23373) > @@ -55,7 +55,7 @@ > [[Label>Reference]] > [[Reference|Param=Value]] > [[[[no link]]>>Reference]] > -[[~[~[image:whatever>>Reference]] > +[[~~[~~[image:whatever>>Reference]] ah less great... Why did you have to change it back from the previous commit? Thanks -Vincent

2 1

Re: [xwiki-devs] [xwiki-notifications] r23372 - in platform/core/trunk/xwiki-rendering: xwiki-rendering-api/src/main/java/org/xwiki/rendering/internal/renderer/printer xwiki-rendering-api/src/main/java/org/xwiki/rendering/internal/renderer/xwiki xwik
by Thomas Mortagne 09 Sep '09

09 Sep '09

On Wed, Sep 9, 2009 at 13:05, Vincent Massol<vincent(a)massol.net> wrote: > > On Sep 9, 2009, at 12:53 PM, tmortagne (SVN) wrote: > >> Author: tmortagne >> Date: 2009-09-09 12:53:09 +0200 (Wed, 09 Sep 2009) >> New Revision: 23372 >> >> Modified: >> platform/core/trunk/xwiki-rendering/xwiki-rendering-api/src/main/ >> java/org/xwiki/rendering/internal/renderer/printer/ >> XWikiSyntaxEscapeWikiPrinter.java >> platform/core/trunk/xwiki-rendering/xwiki-rendering-api/src/main/ >> java/org/xwiki/rendering/internal/renderer/xwiki/ >> XWikiSyntaxChainingRenderer.java >> platform/core/trunk/xwiki-rendering/xwiki-rendering-api/src/main/ >> java/org/xwiki/rendering/internal/renderer/xwiki/ >> XWikiSyntaxEscapeHandler.java >> platform/core/trunk/xwiki-rendering/xwiki-rendering-api/src/main/ >> java/org/xwiki/rendering/internal/renderer/xwiki/ >> XWikiSyntaxLinkRenderer.java >> platform/core/trunk/xwiki-rendering/xwiki-rendering-parsers/xwiki- >> rendering-parser-wikimodel/src/main/java/org/xwiki/rendering/ >> internal/parser/wikimodel/xhtml/XWikiCommentHandler.java >> platform/core/trunk/xwiki-rendering/xwiki-rendering-tests/src/test/ >> java/org/xwiki/rendering/SimpleRenderingTests.java >> platform/core/trunk/xwiki-rendering/xwiki-rendering-tests/src/test/ >> resources/link/links14.test >> platform/core/trunk/xwiki-rendering/xwiki-rendering-tests/src/test/ >> resources/link/links6.test >> Log: >> XWIKI-4294: xhtml renderer wrong escape reference in the startlink >> html comment >> XWIKI-4194: Inconsistent behavior when escaping "-" symbols >> * improve a little escaping in links labels (less useless escaping) >> > > [snip] > >> Modified: platform/core/trunk/xwiki-rendering/xwiki-rendering-tests/ >> src/test/java/org/xwiki/rendering/SimpleRenderingTests.java >> =================================================================== >> --- platform/core/trunk/xwiki-rendering/xwiki-rendering-tests/src/ >> test/java/org/xwiki/rendering/SimpleRenderingTests.java 2009-09-09 >> 10:43:50 UTC (rev 23371) >> +++ platform/core/trunk/xwiki-rendering/xwiki-rendering-tests/src/ >> test/java/org/xwiki/rendering/SimpleRenderingTests.java 2009-09-09 >> 10:53:09 UTC (rev 23372) >> @@ -204,6 +204,26 @@ >> suite.addTestsFromResource("misc/misc7", false); >> suite.addTestsFromResource("encoding/encoding1", false); >> >> + suite.addTestsFromResource("escape/escape1", false); >> + suite.addTestsFromResource("escape/escape2", false); >> + suite.addTestsFromResource("escape/escape3", false); >> + suite.addTestsFromResource("escape/escape4", false); >> + suite.addTestsFromResource("escape/escape5", false); >> + suite.addTestsFromResource("escape/escape6", false); >> + suite.addTestsFromResource("escape/escape7", false); >> + suite.addTestsFromResource("escape/escape8", false); >> + suite.addTestsFromResource("escape/escape9", false); >> + suite.addTestsFromResource("escape/escape10", false); >> + suite.addTestsFromResource("escape/escape11", false); >> + suite.addTestsFromResource("escape/escape12", false); >> + suite.addTestsFromResource("escape/escape13", false); >> + suite.addTestsFromResource("escape/escape14", false); >> + suite.addTestsFromResource("escape/escape15", false); >> + suite.addTestsFromResource("escape/escape16", false); >> + suite.addTestsFromResource("escape/escape17", false); >> + suite.addTestsFromResource("escape/escape18", false); >> + suite.addTestsFromResource("escape/escape19", false); > > We were missing all those tests? Sorry, debugging leftover. > >> return new ComponentManagerTestSetup(suite); >> } >> } >> >> Modified: platform/core/trunk/xwiki-rendering/xwiki-rendering-tests/ >> src/test/resources/link/links14.test >> =================================================================== >> --- platform/core/trunk/xwiki-rendering/xwiki-rendering-tests/src/ >> test/resources/link/links14.test 2009-09-09 10:43:50 UTC (rev 23371) >> +++ platform/core/trunk/xwiki-rendering/xwiki-rendering-tests/src/ >> test/resources/link/links14.test 2009-09-09 10:53:09 UTC (rev 23372) >> @@ -24,7 +24,7 @@ >> .#----------------------------------------------------- >> .expect|xwiki/2.0 >> .#----------------------------------------------------- >> -[[[[image:attach.png~|~|height="100" width="100"~]~]>>http://xwiki.org >> ||param="value"]] >> +[[[[image:attach.png||height="100" width="100"]]>>http://xwiki.org|| >> param="value"]] > > great! > >> .#----------------------------------------------------- >> .input|xhtml/1.0 >> .#----------------------------------------------------- >> >> Modified: platform/core/trunk/xwiki-rendering/xwiki-rendering-tests/ >> src/test/resources/link/links6.test >> =================================================================== >> --- platform/core/trunk/xwiki-rendering/xwiki-rendering-tests/src/ >> test/resources/link/links6.test 2009-09-09 10:43:50 UTC (rev 23371) >> +++ platform/core/trunk/xwiki-rendering/xwiki-rendering-tests/src/ >> test/resources/link/links6.test 2009-09-09 10:53:09 UTC (rev 23372) >> @@ -55,7 +55,7 @@ >> [[Label>Reference]] >> [[Reference|Param=Value]] >> [[[[no link]]>>Reference]] >> -[[~~[~~[image:whatever>>Reference]] >> +[[~[~[image:whatever>>Reference]] > > great too! > > Thanks > -Vincent > _______________________________________________ > devs mailing list > devs(a)xwiki.org > http://lists.xwiki.org/mailman/listinfo/devs > -- Thomas Mortagne

1 0

Re: [xwiki-devs] [xwiki-notifications] r23372 - in platform/core/trunk/xwiki-rendering: xwiki-rendering-api/src/main/java/org/xwiki/rendering/internal/renderer/printer xwiki-rendering-api/src/main/java/org/xwiki/rendering/internal/renderer/xwiki xwiki-rendering-parsers/xwiki-rendering-parser-wikimodel/src/main/java/org/xwiki/rendering/internal/parser/wikimodel/xhtml xwiki-rendering-tests/src/test/java/org/xwiki/rendering xwiki-rendering-tests/src/test/resources/link
by Vincent Massol 09 Sep '09

09 Sep '09

On Sep 9, 2009, at 12:53 PM, tmortagne (SVN) wrote: > Author: tmortagne > Date: 2009-09-09 12:53:09 +0200 (Wed, 09 Sep 2009) > New Revision: 23372 > > Modified: > platform/core/trunk/xwiki-rendering/xwiki-rendering-api/src/main/ > java/org/xwiki/rendering/internal/renderer/printer/ > XWikiSyntaxEscapeWikiPrinter.java > platform/core/trunk/xwiki-rendering/xwiki-rendering-api/src/main/ > java/org/xwiki/rendering/internal/renderer/xwiki/ > XWikiSyntaxChainingRenderer.java > platform/core/trunk/xwiki-rendering/xwiki-rendering-api/src/main/ > java/org/xwiki/rendering/internal/renderer/xwiki/ > XWikiSyntaxEscapeHandler.java > platform/core/trunk/xwiki-rendering/xwiki-rendering-api/src/main/ > java/org/xwiki/rendering/internal/renderer/xwiki/ > XWikiSyntaxLinkRenderer.java > platform/core/trunk/xwiki-rendering/xwiki-rendering-parsers/xwiki- > rendering-parser-wikimodel/src/main/java/org/xwiki/rendering/ > internal/parser/wikimodel/xhtml/XWikiCommentHandler.java > platform/core/trunk/xwiki-rendering/xwiki-rendering-tests/src/test/ > java/org/xwiki/rendering/SimpleRenderingTests.java > platform/core/trunk/xwiki-rendering/xwiki-rendering-tests/src/test/ > resources/link/links14.test > platform/core/trunk/xwiki-rendering/xwiki-rendering-tests/src/test/ > resources/link/links6.test > Log: > XWIKI-4294: xhtml renderer wrong escape reference in the startlink > html comment > XWIKI-4194: Inconsistent behavior when escaping "-" symbols > * improve a little escaping in links labels (less useless escaping) > [snip] > Modified: platform/core/trunk/xwiki-rendering/xwiki-rendering-tests/ > src/test/java/org/xwiki/rendering/SimpleRenderingTests.java > =================================================================== > --- platform/core/trunk/xwiki-rendering/xwiki-rendering-tests/src/ > test/java/org/xwiki/rendering/SimpleRenderingTests.java 2009-09-09 > 10:43:50 UTC (rev 23371) > +++ platform/core/trunk/xwiki-rendering/xwiki-rendering-tests/src/ > test/java/org/xwiki/rendering/SimpleRenderingTests.java 2009-09-09 > 10:53:09 UTC (rev 23372) > @@ -204,6 +204,26 @@ > suite.addTestsFromResource("misc/misc7", false); > suite.addTestsFromResource("encoding/encoding1", false); > > + suite.addTestsFromResource("escape/escape1", false); > + suite.addTestsFromResource("escape/escape2", false); > + suite.addTestsFromResource("escape/escape3", false); > + suite.addTestsFromResource("escape/escape4", false); > + suite.addTestsFromResource("escape/escape5", false); > + suite.addTestsFromResource("escape/escape6", false); > + suite.addTestsFromResource("escape/escape7", false); > + suite.addTestsFromResource("escape/escape8", false); > + suite.addTestsFromResource("escape/escape9", false); > + suite.addTestsFromResource("escape/escape10", false); > + suite.addTestsFromResource("escape/escape11", false); > + suite.addTestsFromResource("escape/escape12", false); > + suite.addTestsFromResource("escape/escape13", false); > + suite.addTestsFromResource("escape/escape14", false); > + suite.addTestsFromResource("escape/escape15", false); > + suite.addTestsFromResource("escape/escape16", false); > + suite.addTestsFromResource("escape/escape17", false); > + suite.addTestsFromResource("escape/escape18", false); > + suite.addTestsFromResource("escape/escape19", false); We were missing all those tests? > return new ComponentManagerTestSetup(suite); > } > } > > Modified: platform/core/trunk/xwiki-rendering/xwiki-rendering-tests/ > src/test/resources/link/links14.test > =================================================================== > --- platform/core/trunk/xwiki-rendering/xwiki-rendering-tests/src/ > test/resources/link/links14.test 2009-09-09 10:43:50 UTC (rev 23371) > +++ platform/core/trunk/xwiki-rendering/xwiki-rendering-tests/src/ > test/resources/link/links14.test 2009-09-09 10:53:09 UTC (rev 23372) > @@ -24,7 +24,7 @@ > .#----------------------------------------------------- > .expect|xwiki/2.0 > .#----------------------------------------------------- > -[[[[image:attach.png~|~|height="100" width="100"~]~]>>http://xwiki.org > ||param="value"]] > +[[[[image:attach.png||height="100" width="100"]]>>http://xwiki.org|| > param="value"]] great! > .#----------------------------------------------------- > .input|xhtml/1.0 > .#----------------------------------------------------- > > Modified: platform/core/trunk/xwiki-rendering/xwiki-rendering-tests/ > src/test/resources/link/links6.test > =================================================================== > --- platform/core/trunk/xwiki-rendering/xwiki-rendering-tests/src/ > test/resources/link/links6.test 2009-09-09 10:43:50 UTC (rev 23371) > +++ platform/core/trunk/xwiki-rendering/xwiki-rendering-tests/src/ > test/resources/link/links6.test 2009-09-09 10:53:09 UTC (rev 23372) > @@ -55,7 +55,7 @@ > [[Label>Reference]] > [[Reference|Param=Value]] > [[[[no link]]>>Reference]] > -[[~~[~~[image:whatever>>Reference]] > +[[~[~[image:whatever>>Reference]] great too! Thanks -Vincent

1 0

Re: [xwiki-devs] [xwiki-notifications] r23347 - in platform: core/trunk/xwiki-core/src/main/resources web/trunk/standard/src/main/webapp/templates xwiki-plugins/trunk/watchlist/src/main/java/com/xpn/xwiki/plugin/watchlist
by Sergiu Dumitriu 09 Sep '09

09 Sep '09

Could you merge the changes for menuview.vm to the colibri skin? On Tue, Sep 8, 2009 at 18:09, jvdrean<platform-notifications(a)xwiki.org> wrote: > Author: jvdrean > Date: 2009-09-08 18:09:29 +0200 (Tue, 08 Sep 2009) > New Revision: 23347 > > Modified: > platform/core/trunk/xwiki-core/src/main/resources/ApplicationResources.properties > platform/web/trunk/standard/src/main/webapp/templates/menuview.vm > platform/web/trunk/standard/src/main/webapp/templates/watch.vm > platform/xwiki-plugins/trunk/watchlist/src/main/java/com/xpn/xwiki/plugin/watchlist/WatchListEvent.java > platform/xwiki-plugins/trunk/watchlist/src/main/java/com/xpn/xwiki/plugin/watchlist/WatchListEventMatcher.java > platform/xwiki-plugins/trunk/watchlist/src/main/java/com/xpn/xwiki/plugin/watchlist/WatchListJob.java > platform/xwiki-plugins/trunk/watchlist/src/main/java/com/xpn/xwiki/plugin/watchlist/WatchListPluginApi.java > platform/xwiki-plugins/trunk/watchlist/src/main/java/com/xpn/xwiki/plugin/watchlist/WatchListStore.java > Log: > XWIKI-4298 : Add watch/unwatch wiki in the Watch menu > XPWATCHLIST-60 : Watch List should support registering for user activity > > The API is now complete. The backend for the future "follow user activity" is implemented and can be used through the object editor. -- http://purl.org/net/sergiu

2 1

Re: [xwiki-devs] [xwiki-notifications] r23368 - platform/skins/trunk/colibri/src/main/resources/colibri
by Vincent Massol 09 Sep '09

09 Sep '09

Hi Sergiu, On Sep 9, 2009, at 8:28 AM, sdumitriu (SVN) wrote: > Author: sdumitriu > Date: 2009-09-09 08:28:17 +0200 (Wed, 09 Sep 2009) > New Revision: 23368 > > Modified: > platform/skins/trunk/colibri/src/main/resources/colibri/ > contentview.vm > Log: > XSCOLIBRI-68: Duplicate titles on some pages > Fixed on most pages. > > > Modified: platform/skins/trunk/colibri/src/main/resources/colibri/ > contentview.vm > =================================================================== > --- platform/skins/trunk/colibri/src/main/resources/colibri/ > contentview.vm 2009-09-09 06:07:41 UTC (rev 23367) > +++ platform/skins/trunk/colibri/src/main/resources/colibri/ > contentview.vm 2009-09-09 06:28:17 UTC (rev 23368) > @@ -33,7 +33,6 @@ > #set($content = > $content.trim().substring($content.trim().indexOf($util.newline))) > #end > #end > - ## #set($renderedContent =$cdoc.getRenderedContent()) > #set($renderedContent = $cdoc.getRenderedContent($content, > $cdoc.syntaxId)) > #end > <div id="document-title"><h1>$tdoc.displayTitle</h1></div> > @@ -42,7 +41,7 @@ > ## > ## Display the rendered content > ## > -$renderedContent > +$renderedContent.replaceFirst('^[ \n\r\t]*+<h1.*?</h1>', '') I'm not sure I understand the algorithm. Also you mention "most pages". Does it mean there are cases where this is not working? Thanks -Vincent PS: We're also missing the config flag.

1 0

Re: [xwiki-devs] [xwiki-notifications] r23356 - in platform/core/trunk/xwiki-rendering: . xwiki-rendering-parsers/xwiki-rendering-parser-wikimodel/src/main/java/org/xwiki/rendering/internal/parser/wikimodel
by Vincent Massol 08 Sep '09

08 Sep '09

On Sep 8, 2009, at 8:52 PM, tmortagne (SVN) wrote: > Author: tmortagne > Date: 2009-09-08 20:52:51 +0200 (Tue, 08 Sep 2009) > New Revision: 23356 > > Modified: > platform/core/trunk/xwiki-rendering/pom.xml > platform/core/trunk/xwiki-rendering/xwiki-rendering-parsers/xwiki- > rendering-parser-wikimodel/src/main/java/org/xwiki/rendering/ > internal/parser/wikimodel/XDOMGeneratorListener.java > Log: > XWIKI-4177: Verbatim block and monospace break table > > Modified: platform/core/trunk/xwiki-rendering/pom.xml > =================================================================== > --- platform/core/trunk/xwiki-rendering/pom.xml 2009-09-08 18:12:11 > UTC (rev 23355) > +++ platform/core/trunk/xwiki-rendering/pom.xml 2009-09-08 18:52:51 > UTC (rev 23356) > @@ -41,7 +41,7 @@ > <dependency> > <groupId>org.wikimodel</groupId> > <artifactId>org.wikimodel.wem</artifactId> > - <version>2.0.7-20090811</version> > + <version>2.0.7-20090908</version> > </dependency> > </dependencies> > </dependencyManagement> > > Modified: platform/core/trunk/xwiki-rendering/xwiki-rendering- > parsers/xwiki-rendering-parser-wikimodel/src/main/java/org/xwiki/ > rendering/internal/parser/wikimodel/XDOMGeneratorListener.java > =================================================================== > --- platform/core/trunk/xwiki-rendering/xwiki-rendering-parsers/ > xwiki-rendering-parser-wikimodel/src/main/java/org/xwiki/rendering/ > internal/parser/wikimodel/XDOMGeneratorListener.java 2009-09-08 > 18:12:11 UTC (rev 23355) > +++ platform/core/trunk/xwiki-rendering/xwiki-rendering-parsers/ > xwiki-rendering-parser-wikimodel/src/main/java/org/xwiki/rendering/ > internal/parser/wikimodel/XDOMGeneratorListener.java 2009-09-08 > 18:52:51 UTC (rev 23356) > @@ -302,55 +302,57 @@ > */ > public void endFormat(WikiFormat format) > { > - // Get the styles: the styles are wiki syntax styles (i.e. > styles which have a wiki syntax such as bold, italic ,etc). > - // As opposed to format parameters which don't have any > specific wiki syntax (they have a generic wiki syntax such as > + // Get the styles: the styles are wiki syntax styles (i.e. > styles which have a wiki syntax such as bold, italic > + // ,etc). > + // As opposed to format parameters which don't have any > specific wiki syntax (they have a generic wiki syntax > + // such as > // (% a='b' %) for example in XWiki Syntax 2.0. > List<WikiStyle> styles = format.getStyles(); > - > - // If there's any style or parameter defined, do something. > The reason we need to check for this is because wikimodel > + > + // If there's any style or parameter defined, do something. > The reason we need to check for this is because > + // wikimodel > // sends an empty begin/endFormat event before starting an > inline block (such as a paragraph). > if ((styles.size() > 0) || (format.getParams().size() > 0)) { > > // Generate nested FormatBlock blocks since XWiki uses > nested Format blocks whereas Wikimodel doesn't. > // > // Simple Use Case: (% a='b' %)**//hello//**(%%) > - // WikiModel Events: > - // beginFormat(params: a='b', styles = BOLD, ITALIC) > - // onWord(hello) > - // endFormat(params: a='b', styles = BOLD, ITALIC) > + // WikiModel Events: > + // beginFormat(params: a='b', styles = BOLD, ITALIC) > + // onWord(hello) > + // endFormat(params: a='b', styles = BOLD, ITALIC) > // XWiki Blocks: > - // FormatBLock(params: a='b', format = BOLD) > - // FormatBlock(format = ITALIC) > + // FormatBLock(params: a='b', format = BOLD) > + // FormatBlock(format = ITALIC) > // > // More complex Use Case: **(% a='b' %)hello**world > - // WikiModel Events: > - // beginFormat(params: a='b', styles = BOLD) > - // onWord(hello) > - // endFormat(params: a='b', styles = BOLD) > - // beginFormat(params: a='b') > - // onWord(world) > - // endFormat(params: a='b') > + // WikiModel Events: > + // beginFormat(params: a='b', styles = BOLD) > + // onWord(hello) > + // endFormat(params: a='b', styles = BOLD) > + // beginFormat(params: a='b') > + // onWord(world) > + // endFormat(params: a='b') > // XWiki Blocks: > - // FormatBlock(params: a='b', format = BOLD) > - // WordBlock(hello) > - // FormatBlock(params: a='b') > - // WordBlock(world) > - > + // FormatBlock(params: a='b', format = BOLD) > + // WordBlock(hello) > + // FormatBlock(params: a='b') > + // WordBlock(world) > + > // TODO: We should instead have the following which > would allow to simplify XWikiSyntaxChaining Renderer > // which currently has to check if the next format has > the same params as the previous format to decide > // whether to print it or not. > - // FormatBlock(params: a='b') > - // FormatBlock(format = BOLD) > - // WordBlock(hello) > - // WordBlock(world) > - > + // FormatBlock(params: a='b') > + // FormatBlock(format = BOLD) > + // WordBlock(hello) > + // WordBlock(world) Thomas there are lots of reformatting in your commit. In general it would be great to not reformat during a normal commit since it makes it harder to read. In addition I have the feeling the reformatting has broken all my formatting. Thanks -Vincent > + > FormatBlock block; > if (styles.size() > 0) { > block = new FormatBlock(generateListFromStack(), > convertFormat(styles.get(styles.size() - 1))); > } else { > block = new FormatBlock(generateListFromStack(), > Format.NONE); > } > - > > if (styles.size() > 1) { > ListIterator<WikiStyle> it = > styles.listIterator(styles.size() - 1); > @@ -377,7 +379,7 @@ > } > > } else { > - // Empty format. We need to remove our marker so pop > all blocks after our marker and push them back on > + // Empty format. We need to remove our marker so pop > all blocks after our marker and push them back on > // the stack. > for (Block block : generateListFromStack()) { > this.stack.push(block); > @@ -559,10 +561,11 @@ > > /** > * {@inheritDoc} > - * > - * <p>Called when WikiModel finds an reference (link or image) > such as a URI located directly in the text > - * (free-standing URI), as opposed to a link/image inside wiki > link/image syntax delimiters.</p> > - * > + * <p> > + * Called when WikiModel finds an reference (link or image) > such as a URI located directly in the text > + * (free-standing URI), as opposed to a link/image inside wiki > link/image syntax delimiters. > + * </p> > + * > * @see org.wikimodel.wem.IWemListener#onLineBreak() > */ > public void onReference(String reference) > @@ -613,8 +616,8 @@ > */ > public void onImage(WikiReference ref) > { > - this.stack.push(new > ImageBlock(this.imageParser.parse(ref.getLink()), false, > convertParameters(ref > - .getParameters()))); > + this.stack.push(new > ImageBlock(this.imageParser.parse(ref.getLink()), false, > + convertParameters(ref.getParameters()))); > } > > /** > @@ -784,4 +787,28 @@ > > return resultBlock; > } > + > + public void beginSection(int docLevel, int headerLevel, > WikiParameters params) > + { > + // TODO add support for it > + > + } > + > + public void beginSectionContent(int docLevel, int headerLevel, > WikiParameters params) > + { > + // TODO add support for it > + > + } > + > + public void endSection(int docLevel, int headerLevel, > WikiParameters params) > + { > + // TODO add support for it > + > + } > + > + public void endSectionContent(int docLevel, int headerLevel, > WikiParameters params) > + { > + // TODO add support for it > + > + } > }

1 0

[xwiki-devs] Does it make sense to add a method for saving many docs in one transaction?
by Caleb James DeLisle 08 Sep '09

08 Sep '09

It seems like there is increasing need for saving groups of documents in a single transaction. I was thinking maybe this would be a good method: XWiki.saveDocuments(List<XWikiDocument> XWikiContext) It would be up to the calling method to set the comment and isMinorEdit field in the documents before sending them to saveDocuments. Is this deserving of a jira improvement issue? What do you folks think? Caleb James DeLisle

2 1

[xwiki-devs] Translation Wiki
by hel-o 08 Sep '09

08 Sep '09

Hi, there seems to be a problem with the translation wiki, just logged in, only language available is zh and theres a application "hallo" hel. ----- semantic-web.hel.at hel(a)hel.at -- View this message in context: http://n2.nabble.com/Translation-Wiki-tp3601693p3601693.html Sent from the XWiki- Dev mailing list archive at Nabble.com.

3 3

Re: [xwiki-devs] [xwiki-notifications] r23335 - platform/core/trunk/xwiki-rendering/xwiki-rendering-macros/xwiki-rendering-macro-python/src/main/java/org/xwiki/rendering/internal/macro/python
by Vincent Massol 08 Sep '09

08 Sep '09

Thomas, Be careful that you need to update the jython macro doc on code.xwiki.org too since it says both macro names can be used I think. Thanks -Vincent On Sep 8, 2009, at 10:08 AM, tmortagne (SVN) wrote: > Author: tmortagne > Date: 2009-09-08 10:08:09 +0200 (Tue, 08 Sep 2009) > New Revision: 23335 > > Modified: > platform/core/trunk/xwiki-rendering/xwiki-rendering-macros/xwiki- > rendering-macro-python/src/main/java/org/xwiki/rendering/internal/ > macro/python/PythonMacro.java > Log: > XWIKI-2798: Create jython macro for rendering 2.0 > * remove "jython" hint until we find a better solution from the > WYSIWYG POV > > Modified: platform/core/trunk/xwiki-rendering/xwiki-rendering-macros/ > xwiki-rendering-macro-python/src/main/java/org/xwiki/rendering/ > internal/macro/python/PythonMacro.java > =================================================================== > --- platform/core/trunk/xwiki-rendering/xwiki-rendering-macros/xwiki- > rendering-macro-python/src/main/java/org/xwiki/rendering/internal/ > macro/python/PythonMacro.java 2009-09-08 06:38:19 UTC (rev 23334) > +++ platform/core/trunk/xwiki-rendering/xwiki-rendering-macros/xwiki- > rendering-macro-python/src/main/java/org/xwiki/rendering/internal/ > macro/python/PythonMacro.java 2009-09-08 08:08:09 UTC (rev 23335) > @@ -30,7 +30,7 @@ > * @version $Id$ > * @since 2.0M2 > */ > -@Component(hints = {"python", "jython" }) > +@Component("python") > public class PythonMacro extends > AbstractJSR223ScriptMacro<JSR223ScriptMacroParameters> > { > /**

1 0

Re: [xwiki-devs] Blog Plugin Proposal
by Guillaume Lerouge 08 Sep '09

08 Sep '09

Hi Andreas, On Mon, Aug 31, 2009 at 1:11 AM, Andreas Schaefer <schaefera(a)me.com> wrote: > My try to deploy the Blog Plugin together with the updated Blog > Application failed miserably today and my dislike of Velocity reach a > new high. > > Because I see the value of the scripting nature of the Blog allowing > users to customize their Blog to a quite large degree I don't want to > ditch that but I have a lot of problems with Velocity and the way is > plastering over issues. I rather fail fast than late with hardly a > trail to understand what is going on. > My personal experience with velocity is more of a try & fail, try & fail, try and succeed one than anything else. What I found out is that I was msot of the time better off rewriting stuff starting with small chunks rather than trying to take existing code and reuse it all at once. The current blog is a fairly complex piece of velocity code (that is, given the lack of debugging tools when coding in velocity in the wiki). This is one of the reasons I think Sergiu's argument that "devs will be able to look at the code and learn from it" is not entirely true ;-) What's really important for the blog is that it can be customized easily at 2 levels: - Look: an user should be able to use the panels she wants for her blog - Deployment: an user should be able to create a new space blog or global wiki blog in any space she wants Besides that the way the blog is code doesn't matter much for the end user. That said I still think that it might be a good idea to convert the > scripted part of the Blog over to Groovy and keep the rest in the Blog > Plugin. I don't have any experience with Groovy inside XWiki but for > sure the documentation of Groovy outside is excellent compared to > Velocity. I will use the next week to get up to speed and try to > convert a piece of the Blog over to Groovy. Then go ahead and give it a go :-) One thing you need to be aware of when using Groovy inside the wiki is that your pages will haveto be saved using programming rights. This can cause a number of issues, don't forget to code with an user that has them, it will save yo ua lot of hassle ;-) > Cheers - Andy > Good luck and thanks for all the nice work, Guillaume > _______________________________________________ > devs mailing list > devs(a)xwiki.org > http://lists.xwiki.org/mailman/listinfo/devs > -- Guillaume Lerouge Product Manager - XWiki Skype: wikibc Twitter: glerouge http://guillaumelerouge.com/

3 3

[xwiki-devs] Can't find descriptor for the component DocumentAccessBridge
by Juri Kühn 05 Sep '09

05 Sep '09

Hi all, first of all, thanks for the great work, xwiki is a great product i'm trying to integrate the rendering component of xwiki into our application for hours, without success. I included all the libraries from XWiki 2.0 M4 and was running following code in a standalone application (not within servlet container, but thats no problem?) -- EmbeddableComponentManager componentManager = new EmbeddableComponentManager(); componentManager.initialize(this.getClass().getClassLoader()); Parser parser = (Parser)componentManager.lookup(Parser.class, Syntax.XWIKI_2_0.toIdString()); XDOM xdom = parser.parse(new StringReader("test")); // Generate XHTML PrintRendererFactory rf = componentManager.lookup(PrintRendererFactory.class, Syntax.XHTML_1_0.toIdString()); DefaultWikiPrinter printer = new DefaultWikiPrinter(); Renderer htmlRenderer = rf.createRenderer(printer); // Perform the rendering - the exception is raised here xdom.traverse(htmlRenderer); -- The stacktrace is attached below. The DocumentAccessBridge component cannot be loaded. I tried to figure out what is going on and debugged around. The loop that loads all descriptors for xwiki components doesnt include DocumentAccessBridge. There is no META-INF/components.txt in the xwiki-core-bridge-2.0-milestone-4.jar and no class in this library has the @Component annotation. I just cannot figure out what is going wrong. Different parsers and printrenderers (other than XWIKI_2_0 and XHTML_1_0) as the use of the Converter instead of Parser produce the same result. What am i doing wrong? Any help would be really appreciated. Best regards, Juri Output and Stacktrace: 05.09.2009 00:50:35 org.xwiki.component.logging.CommonsLoggingLogger warn WARNUNG: Component [org.xwiki.rendering.internal.configuration.DefaultRenderingConfiguration] is being overwritten by component [org.xwiki.rendering.internal.configuration.XWikiRenderingConfiguration] for Role/Hint [role = [org.xwiki.rendering.configuration.RenderingConfiguration] hint = [default]]. It will not be possible to look it up. 05.09.2009 00:50:35 org.xwiki.component.logging.CommonsLoggingLogger warn WARNUNG: Component [org.xwiki.rendering.internal.renderer.DefaultLinkLabelGenerator] is being overwritten by component [org.xwiki.rendering.internal.renderer.XWikiLinkLabelGenerator] for Role/Hint [role = [org.xwiki.rendering.renderer.LinkLabelGenerator] hint = [default]]. It will not be possible to look it up. 05.09.2009 00:50:35 org.xwiki.component.logging.CommonsLoggingLogger warn WARNUNG: Failed to load configuration file [/WEB-INF/xwiki.properties]. Using default configuration. Internal error [null] Exception in thread "main" java.lang.RuntimeException: Failed to create [XHTML 1.0] renderer at org.xwiki.rendering.internal.renderer.AbstractPrintRendererFactory.createRenderer(AbstractPrintRendererFactory.java:51) at de.lernbase.XWikiRenderTest.doit(XWikiRenderTest.java:30) at de.lernbase.XWikiRenderTest.main(XWikiRenderTest.java:58) Caused by: org.xwiki.component.manager.ComponentLookupException: Failed to lookup component [role = [org.xwiki.rendering.renderer.PrintRenderer] hint = [xhtml/1.0]] at org.xwiki.component.embed.EmbeddableComponentManager.initialize(EmbeddableComponentManager.java:311) at org.xwiki.component.embed.EmbeddableComponentManager.lookup(EmbeddableComponentManager.java:109) at org.xwiki.component.internal.DefaultComponentManager.lookup(DefaultComponentManager.java:85) at org.xwiki.rendering.internal.renderer.AbstractPrintRendererFactory.createRenderer(AbstractPrintRendererFactory.java:49) ... 2 more Caused by: org.xwiki.component.manager.ComponentLookupException: Failed to lookup component [role = [org.xwiki.rendering.renderer.xhtml.XHTMLLinkRenderer] hint = [default]] at org.xwiki.component.embed.EmbeddableComponentManager.initialize(EmbeddableComponentManager.java:311) at org.xwiki.component.embed.EmbeddableComponentManager.lookup(EmbeddableComponentManager.java:109) at org.xwiki.component.embed.EmbeddableComponentManager.createInstance(EmbeddableComponentManager.java:347) at org.xwiki.component.embed.EmbeddableComponentManager.createInstance(EmbeddableComponentManager.java:328) at org.xwiki.component.embed.EmbeddableComponentManager.initialize(EmbeddableComponentManager.java:304) ... 5 more Caused by: org.xwiki.component.manager.ComponentLookupException: Failed to lookup component [role = [org.xwiki.rendering.renderer.LinkLabelGenerator] hint = [default]] at org.xwiki.component.embed.EmbeddableComponentManager.initialize(EmbeddableComponentManager.java:311) at org.xwiki.component.embed.EmbeddableComponentManager.lookup(EmbeddableComponentManager.java:109) at org.xwiki.component.embed.EmbeddableComponentManager.createInstance(EmbeddableComponentManager.java:347) at org.xwiki.component.embed.EmbeddableComponentManager.createInstance(EmbeddableComponentManager.java:328) at org.xwiki.component.embed.EmbeddableComponentManager.initialize(EmbeddableComponentManager.java:304) ... 9 more Caused by: org.xwiki.component.manager.ComponentLookupException: Failed to lookup component [role = [org.xwiki.rendering.configuration.RenderingConfiguration] hint = [default]] at org.xwiki.component.embed.EmbeddableComponentManager.initialize(EmbeddableComponentManager.java:311) at org.xwiki.component.embed.EmbeddableComponentManager.lookup(EmbeddableComponentManager.java:109) at org.xwiki.component.embed.EmbeddableComponentManager.createInstance(EmbeddableComponentManager.java:347) at org.xwiki.component.embed.EmbeddableComponentManager.createInstance(EmbeddableComponentManager.java:328) at org.xwiki.component.embed.EmbeddableComponentManager.initialize(EmbeddableComponentManager.java:304) ... 13 more Caused by: org.xwiki.component.manager.ComponentLookupException: Failed to lookup component [role = [org.xwiki.configuration.ConfigurationSource] hint = [default]] at org.xwiki.component.embed.EmbeddableComponentManager.initialize(EmbeddableComponentManager.java:311) at org.xwiki.component.embed.EmbeddableComponentManager.lookup(EmbeddableComponentManager.java:109) at org.xwiki.component.embed.EmbeddableComponentManager.createInstance(EmbeddableComponentManager.java:347) at org.xwiki.component.embed.EmbeddableComponentManager.createInstance(EmbeddableComponentManager.java:328) at org.xwiki.component.embed.EmbeddableComponentManager.initialize(EmbeddableComponentManager.java:304) ... 17 more Caused by: org.xwiki.component.manager.ComponentLookupException: Failed to lookup component [role = [org.xwiki.configuration.ConfigurationSource] hint = [wiki]] at org.xwiki.component.embed.EmbeddableComponentManager.initialize(EmbeddableComponentManager.java:311) at org.xwiki.component.embed.EmbeddableComponentManager.lookup(EmbeddableComponentManager.java:109) at org.xwiki.component.embed.EmbeddableComponentManager.createInstance(EmbeddableComponentManager.java:347) at org.xwiki.component.embed.EmbeddableComponentManager.createInstance(EmbeddableComponentManager.java:328) at org.xwiki.component.embed.EmbeddableComponentManager.initialize(EmbeddableComponentManager.java:304) ... 21 more Caused by: org.xwiki.component.manager.ComponentLookupException: Failed to lookup component [role = [org.xwiki.bridge.DocumentAccessBridge] hint = [default]] at org.xwiki.component.embed.EmbeddableComponentManager.initialize(EmbeddableComponentManager.java:311) at org.xwiki.component.embed.EmbeddableComponentManager.lookup(EmbeddableComponentManager.java:109) at org.xwiki.component.embed.EmbeddableComponentManager.createInstance(EmbeddableComponentManager.java:347) at org.xwiki.component.embed.EmbeddableComponentManager.createInstance(EmbeddableComponentManager.java:328) at org.xwiki.component.embed.EmbeddableComponentManager.initialize(EmbeddableComponentManager.java:304) ... 25 more Caused by: org.xwiki.component.manager.ComponentLookupException: Can't find descriptor for the component [role = [org.xwiki.bridge.DocumentAccessBridge] hint = [default]] at org.xwiki.component.embed.EmbeddableComponentManager.createInstance(EmbeddableComponentManager.java:325) at org.xwiki.component.embed.EmbeddableComponentManager.initialize(EmbeddableComponentManager.java:304) ... 29 more

4 5

Re: [xwiki-devs] [xwiki-users] [Vote] Default Color Theme
by Ecaterina Valica 05 Sep '09

05 Sep '09

Current Votes: (0) +0.5 Anca (1) (2) +1 Lucien, +0.66 Marta, +0.5 Jean C, +1 Gaëtan, +0.66 Raluca, +0.5 Vincent G, +1 Emilie, (3) +1 G, +1 Christophe P, +0.33 Raluca, (4) +1 Caty, +1 Vincent, +1 Ricardo R, +1 Florin, +1 Silvia, +0.5 Trevor, +1 Marius (5) +0.33 Marta, (A) (B) +1 Oana, +1 Thomas M, +1 Sergiu, +0.5 Vincent G, +1 Philipp, +1 Martijn, +0.5 Trevor (C) +0.5 Anca, +0.5 Jean C (D) (E) (F) (G) (H)

4 7

[xwiki-devs] documenting changes in trusted rights
by [Ricardo Rodriguez] Your EPEC Network ICT Team 04 Sep '09

04 Sep '09

Hi! One of the biggest problems I've been facing concerning changes in a property, or the access rights to a document or space is how to keep track of the reasons that cause them. I mean, for instance, how could we document the reason (a message sent by the responsible of some contents, a detected abuse,...) why some rights have been granted or denied to one or several users or a group? Is this a matter of programming, data model or it is an absolutely absurd idea? Having the wiki model in charge of documenting who, when and why a change is done in a document, I truly miss a system to keep track on the assigned rights as a metaphor of the trusting relationship on a given document or space. Thanks in advance for your thoughts! Ricardo -- Ricardo Rodríguez Your EPEC Network ICT Team

1 0

[xwiki-devs] Annotation module source code review
by Lucien Pereira 04 Sep '09

04 Sep '09

Hi all, In order to start integration of annotation module to XWiki, I would encourage you to review annotation module source code. Lucien

1 2

[xwiki-devs] [VOTE] Ensure that getRenderedContent(String, String, String) is executed in its own context
by Vincent Massol 04 Sep '09

04 Sep '09

Hi, We currently have a bug with script macros and contexts: http://jira.xwiki.org/jira/browse/XWIKI-4279 I can easily solve it by backuping and restoring the Execution Context in getRenderedContent(String, String, String). I think this is the correct way since the context should be isolated when rendering IMO. Now, note that isolating the EC means the velocitycontext will be cloned (shallow cloning though right now). Which means that if some calls to getRenderedContent(String, String, String) save stuff in the velo context for the caller they may fail. I don't know if this happens anywhere in our code but it's unlikely since the calls from vm files are usually calls to getRenderedContent() without parameters which doesn't save/Restore the contexts. Here's my +1 for isolating the contexts in getRenderedContent(String, String, String) and my +1 to apply this change now for RC1. Thanks -Vincent

4 3

Re: [xwiki-devs] [xwiki-notifications] r23282 - platform/core/trunk/xwiki-core/src/main/java/com/xpn/xwiki/objects/classes
by Vincent Massol 04 Sep '09

04 Sep '09

On Sep 4, 2009, at 4:08 PM, tmortagne (SVN) wrote: > Author: tmortagne > Date: 2009-09-04 16:08:55 +0200 (Fri, 04 Sep 2009) > New Revision: 23282 > > Modified: > platform/core/trunk/xwiki-core/src/main/java/com/xpn/xwiki/objects/ > classes/DBListClass.java > Log: > [misc] Improve log > > Modified: platform/core/trunk/xwiki-core/src/main/java/com/xpn/xwiki/ > objects/classes/DBListClass.java > =================================================================== > --- platform/core/trunk/xwiki-core/src/main/java/com/xpn/xwiki/ > objects/classes/DBListClass.java 2009-09-04 13:46:26 UTC (rev 23281) > +++ platform/core/trunk/xwiki-core/src/main/java/com/xpn/xwiki/ > objects/classes/DBListClass.java 2009-09-04 14:08:55 UTC (rev 23282) > @@ -286,8 +286,7 @@ > try { > sql = context.getWiki().parseContent(sql, context); > } catch (Exception e) { > - LOG.warn("Failed to parse SQL script [" + sql + "]. > Internal error [" + e.getMessage() > - + "]. Continuing with non-rendered script."); > + LOG.warn("Failed to parse SQL script [" + sql + "]. > Continuing with non-rendered script.", e); Thomas, why is that better? Thanks -Vincent

2 3

Re: [xwiki-devs] [UX] Edit Buttons Order
by PERINAUD Christophe 04 Sep '09

04 Sep '09

+1 (C) For my opinion the "Preview" button is necessary because the final structure of the page is different then the edition one. Because of panels, colors etc, you can want to check the global look and integration of your page And also all buttons should be in one group. It's all actions that you can iniate from the editor. Subgroups don't sound necessary for me. > -----Message d'origine----- > De : devs-bounces(a)xwiki.org [mailto:[email protected]] > De la part de Ecaterina Valica > Envoyé : vendredi 4 septembre 2009 13:09 > À : XWiki Mailinglist; XWiki Mailinglist > Objet : [xwiki-devs] [UX] Edit Buttons Order > > Hi, > > Because we want to make a standard from vertical-aligned > form, this means > the buttons should be left-ordered with the most important > action first. > This should be changed also in Toucan and Albatross skin, not > only just in > Colibri. > > Right now the Edit Actions are "Cancel", "Preview", "Save&Continue", > "Save&View". > > What do you think is the right order for them when they are > left-aligned? > > (A) Save&View, Save&Continue, Preview, Cancel (as it is - > just in reverse) > > (B) Save&View, Preview, Save&Continue, Cancel > > (C) Preview, Save&Continue, Save&View, Cancel > > (D) other variation > > Remarks: > > - "Cancel" should be *last* because it's a terminal (takes > you out of the > editor), no-saving action. This is the least important. > > - "Save & View" is also a terminal action (takes you out of > the editor) - > having it* first* you have the 2 terminal actions at extremities. > - "Preview" is the least damaging action in case of accidental submit > (Silvia + Marta) - should be *first*? > > - Some people use ("Preview" + "Save&Continue") {many times} > + "Save&View" > {final} > - Other people just use "Save&Continue" + "Save & View" {final}, never > "Preview", etc > > - What is the necessity for the "Preview" button in a WYSIYWG > editor? On the > other hand "Preview" is very important if you edit in "Wiki" mode. > > - Should "Preview" separate the two other SAVING actions? (Marta) > - Should "Save&Continue" separate the two other VIEW actions? > > Thanks, > Caty > _______________________________________________ > devs mailing list > devs(a)xwiki.org > http://lists.xwiki.org/mailman/listinfo/devs > -------------------------------------------------------------------------------- This e-mail is intended only for the addressee named above. It does not bind the sender, except in the case of an existing written convention with the addressee. This e-mail may contain material that is confidential and privileged for the sole use of the intended recipient. Any review, reliance or distribution by others or forwarding without express permission is strictly prohibited and may be unlawful. If you are not the intended recipient, please contact the sender and delete all copies. While reasonable precautions have been taken to ensure that this e-mail and any attachments are free from any computer virus or similar defect, no liability will be accepted in that respect. Anyone accessing this e-mail must take their own precautions as to security and virus protection. KBL European Private Bankers S.A., 43 boulevard Royal L-2955 Luxembourg, R.C.S. Luxembourg B 6395, T (352) 47 97 1

1 0

[xwiki-devs] [Proposal] Adding attachment JARs in a URL classloader for scripts
by Vincent Massol 04 Sep '09

04 Sep '09

Hi, I'd like to implement this behavior: {{script language="..." jarPages="Space1.Page1, Space2.Page, ..."}} ... {{/script}} Optional: - offer a way to specify explcitley the jars. For example: Space1.Page1(a)myjar.jar It would add the jars located in the specified pages to a URLClassLoader used to execute the script. Obviously programming rights would be checked. WDYT? Thanks -Vincent

3 4

[xwiki-devs] Adding pages and panels externally
by Alexandre Souza 04 Sep '09

04 Sep '09

Thanks, Guillaume But I think that PUT method doesn't work for Panels, only for Pages. I trying another way, using a velocity script in a panel already created, but I have a doubt. Do you known how I can get all existing pages in specific Space to show in panel, as following? #panelheader('Test') #set($page = $xwiki.search("***all pages in Space.Main, for example***")) #foreach($docname in $page) #set($rdoc = $xwiki.getDocument($docname).getTranslatedDocument()) <span class="panelitem"><a href="$rdoc.getURL('view')">$xwiki.getXMLEncoded($rdoc.displayTitle)</a></span> #end #panelfooter() Alexandre 2009/9/3 <devs-request(a)xwiki.org> > Send devs mailing list submissions to > devs(a)xwiki.org > > To subscribe or unsubscribe via the World Wide Web, visit > http://lists.xwiki.org/mailman/listinfo/devs > or, via email, send a message with subject or body 'help' to > devs-request(a)xwiki.org > > You can reach the person managing the list at > devs-owner(a)xwiki.org > > When replying, please edit your Subject line so it is more specific > than "Re: Contents of devs digest..." > > > Today's Topics: > > 1. Re: [xwiki-users] [Vote] Default Color Theme (Eduard Moraru) > 2. Re: [xwiki-users] [Vote] Default Color Theme (Ecaterina Valica) > 3. Translations for XWiki Enterprise 2.0 (Guillaume Lerouge) > 4. Adding pages and panels externally (Alexandre Souza) > 5. Re: Adding pages and panels externally (Guillaume Lerouge) > 6. Re: [VOTE] Add the IRC Bot application to SVN > (Marius Dumitru Florea) > 7. Re: [Proposal] New Release Dates for the 2.0 Release > (Vincent Massol) > 8. Re: [Proposal] New Release Dates for the 2.0 Release > (Jean-Vincent Drean) > 9. Re: [Proposal] New Release Dates for the 2.0 Release > (Asiri Rathnayake) > 10. Re: [Proposal] New Release Dates for the 2.0 Release > (Guillaume Lerouge) > > > ---------------------------------------------------------------------- > > Message: 1 > Date: Wed, 02 Sep 2009 17:18:15 +0300 > From: Eduard Moraru <eduard.moraru(a)xwiki.com> > Subject: Re: [xwiki-devs] [xwiki-users] [Vote] Default Color Theme > To: XWiki Developers <devs(a)xwiki.org> > Message-ID: <4A9E7EA7.9070102(a)xwiki.com> > Content-Type: text/plain; charset=ISO-8859-1; format=flowed > > +1 for (2) > > On 09/02/2009 05:37 PM, Ecaterina Valica wrote: > > Hi, > > > > So the final decision is between (2), (4), (B).* > > > > (2)* > > > http://incubator.myxwiki.org/xwiki/bin/download/ColorThemes/Proposal2/Propo… > > > > *(4)* > > > http://incubator.myxwiki.org/xwiki/bin/download/ColorThemes/Proposal4/Propo… > > > > *(B) * > > > http://incubator.myxwiki.org/xwiki/bin/download/ColorThemes/BColorTheme/Sch… > > * * > > > > > > I preserved the existing votes: > > > > (4) +1 Caty, +1 Vincent, +1 Ricardo R, +1 Florin, +1 Silvia, +0.5 Trevor, > +1 > > Marius > > (B) +1 Oana, +1 Thomas M, +1 Sergiu, +0.5 Vincent G, +1 Philipp, +1 > Martijn, > > +0.5 Trevor > > (2) +1 Lucien, +0.66 Marta, +0.5 Jean C, +1 Ga?tan, +0.66 Raluca, +0.5 > > Vincent G, +1 Emilie, > > > > > > For the ones that changed their mind and want to change their vote just > > reply again and reset your vote. > > > > Thanks, > > Caty > > _______________________________________________ > > devs mailing list > > devs(a)xwiki.org > > http://lists.xwiki.org/mailman/listinfo/devs > > > > > ------------------------------ > > Message: 2 > Date: Wed, 2 Sep 2009 19:12:10 +0200 > From: Ecaterina Valica <valicac(a)gmail.com> > Subject: Re: [xwiki-devs] [xwiki-users] [Vote] Default Color Theme > To: XWiki Users <users(a)xwiki.org>, XWiki Mailinglist <devs(a)xwiki.org> > Message-ID: > <a7bce70e0909021012w5eeac28br62dd50de508958d2(a)mail.gmail.com> > Content-Type: text/plain; charset=ISO-8859-1 > > (4) > > http://incubator.myxwiki.org/xwiki/bin/download/ColorThemes/Proposal4/Propo… > > (B) > > http://incubator.myxwiki.org/xwiki/bin/download/ColorThemes/BColorTheme/Sch… > > (2) > http://incubator.myxwiki.org/xwiki/bin/download/ColorThemes/Proposal2/Propo… > > Votes: > > (4) +1 Caty, +1 Vincent, +1 Ricardo R, +1 Florin, +1 Silvia, +0.5 Trevor, > +1 > Marius, +1 Christophe P > (B) +1 Oana, +1 Thomas M, +1 Sergiu, +0.5 Vincent G, +1 Philipp, +1 > Martijn, > +0.5 Trevor > (2) +1 Lucien, +0.66 Marta, +0.5 Jean C, +1 Ga?tan, +0.66 Raluca, +0.5 > Vincent G, +1 Emilie, +1 Guillaume, +1 Eduard > > > ------------------------------ > > Message: 3 > Date: Wed, 2 Sep 2009 19:16:46 +0200 > From: Guillaume Lerouge <guillaume(a)xwiki.com> > Subject: [xwiki-devs] Translations for XWiki Enterprise 2.0 > To: XWiki Developers <devs(a)xwiki.org>, XWiki Users <users(a)xwiki.org> > Message-ID: > <1c35d2320909021016n5f8fd583weff86414703bb7b3(a)mail.gmail.com> > Content-Type: text/plain; charset=UTF-8 > > Hi XWikiers, > I know some of you regularly update translations for languages on > http://l10n.xwiki.org/ . I've just refreshed the list of translations, > which > created a slew of new empty strings :-) > > It would be great if we could fill as much of them as possible before > releasing XWiki Enterprise 2.0. I'll handle the French ones. > > You can find empty translations for your language on > http://l10n.xwiki.org/xwiki/bin/view/XE/XWikiCoreResources > > Thanks in advance for your help, > > Guillaume > > -- > Guillaume Lerouge > Product Manager - XWiki > Skype: wikibc > Twitter: glerouge > http://guillaumelerouge.com/ > > > ------------------------------ > > Message: 4 > Date: Wed, 2 Sep 2009 15:29:45 -0300 > From: Alexandre Souza <siqsou(a)gmail.com> > Subject: [xwiki-devs] Adding pages and panels externally > To: devs(a)xwiki.org > Message-ID: > <230a3f4f0909021129o6971cc48p5befd2883c81bc34(a)mail.gmail.com> > Content-Type: text/plain; charset=ISO-8859-1 > > Hi, > > I am development a bash script for adding a lot pages and panels > automatically in my xwiki. > I got to add pages with 'curl' command, as following: > > *curl -u Admin:admin -X PUT -d @newpage.html -H "Content-Type: text/plain" > http://localhost:8080/xwiki/rest/wikis/xwiki/spaces/Main/pages/NewPage > * > This works, but I'm having difficulty to add links in a side panel for the > pages created. > Is it possible make this with 'curl' too? If not, is there another way? > > > Thanks, > Alexandre Souza > > > ------------------------------ > > Message: 5 > Date: Wed, 2 Sep 2009 22:22:39 +0200 > From: Guillaume Lerouge <guillaume(a)xwiki.com> > Subject: Re: [xwiki-devs] Adding pages and panels externally > To: XWiki Developers <devs(a)xwiki.org> > Message-ID: > <1c35d2320909021322x1945069ch7aa1791378dd9477(a)mail.gmail.com> > Content-Type: text/plain; charset=UTF-8 > > Hi Alexandre, > > On Wed, Sep 2, 2009 at 8:29 PM, Alexandre Souza <siqsou(a)gmail.com> wrote: > > > Hi, > > > > I am development a bash script for adding a lot pages and panels > > automatically in my xwiki. > > I got to add pages with 'curl' command, as following: > > > > *curl -u Admin:admin -X PUT -d @newpage.html -H "Content-Type: > text/plain" > > http://localhost:8080/xwiki/rest/wikis/xwiki/spaces/Main/pages/NewPage > > * > > This works, but I'm having difficulty to add links in a side panel for > the > > pages created. > > Is it possible make this with 'curl' too? If not, is there another way? > > > > > You simply need to access the panel XObject within the document holding > your > panel and edit its content property to add the links to your pages. I think > there's an API for this since it's supported by XEclipse. You'll have to > dig > a bit more into it to see how it works though. > > Guillaume > > > > > Thanks, > > Alexandre Souza > > _______________________________________________ > > devs mailing list > > devs(a)xwiki.org > > http://lists.xwiki.org/mailman/listinfo/devs > > > > > > -- > Guillaume Lerouge > Product Manager - XWiki > Skype: wikibc > Twitter: glerouge > http://guillaumelerouge.com/ > > > ------------------------------ > > Message: 6 > Date: Thu, 03 Sep 2009 07:40:35 +0300 > From: Marius Dumitru Florea <mariusdumitru.florea(a)xwiki.com> > Subject: Re: [xwiki-devs] [VOTE] Add the IRC Bot application to SVN > To: XWiki Developers <devs(a)xwiki.org> > Message-ID: <4A9F48C3.9080300(a)xwiki.com> > Content-Type: text/plain; charset=ISO-8859-1; format=flowed > > +0 > > Thanks, > Marius > > Vincent Massol wrote: > > Hi, > > > > I've rewritten the IRC Bot application to make it more generic and > > using XWiki 2.0 syntax and the new Observation mechanism. I'm looking > > for a place where to save the sources. > > > > I'd like to propose to put it in platform/applications/ircbot > > > > Rationale: > > * Since we use it it'll be actively maintained > > * It could be useful for others too > > > > It would have its own JIRA project and its own release cycles of course. > > > > Here's my +1 > > > > Thanks > > -Vincent > > > > _______________________________________________ > > devs mailing list > > devs(a)xwiki.org > > http://lists.xwiki.org/mailman/listinfo/devs > > > ------------------------------ > > Message: 7 > Date: Thu, 3 Sep 2009 11:25:13 +0200 > From: Vincent Massol <vincent(a)massol.net> > Subject: Re: [xwiki-devs] [Proposal] New Release Dates for the 2.0 > Release > To: XWiki Developers <devs(a)xwiki.org> > Message-ID: > <c0c158f80909030225x33e7f335y431d6b8b4067aa2a(a)mail.gmail.com> > Content-Type: text/plain; charset=ISO-8859-1 > > Guys, > > Seen that we're now the 3rd of Sep and we're not ready to release the > new colibri skin (lots of remaining issues), I'd like to propose to > postpone the release by 1 week with the new timetable: > > * XE 2.0RC1: 10th of Sep > * XE 2.0 final (if no RC2): 15th of Sep > * XE 2.0RC2 (if blockers found in RC1): 17th of Sep > * XE 2.0 final (if RC2): 22nd of Sep > > Here's my +1 > > Thanks > -Vincent > > On Thu, Aug 27, 2009 at 11:02 AM, Vincent Massol<vincent(a)massol.net> > wrote: > > Hi, > > > > Since we've just released 2.0M4 we need to reschedule the date for the > 2.0 > > release. > > > > I'm proposing: > > > > * 2.0RC1: 2nd of Sep > > * If no blocking bug found in RC1: > > ** 2.0 final: 4th of Sept (it's just a re-release of RC1 in this case) > > * If blocking bugs found in RC1: > > ** 2.0RC2: 9th of Sep > > ** 2.0 final: 11th of Sep (it's just a re-release of RC2 in this case) > > > > WDYT? > > > > Thanks > > -Vincent > > > > > > > ------------------------------ > > Message: 8 > Date: Thu, 3 Sep 2009 11:28:55 +0200 > From: Jean-Vincent Drean <jean-vincent(a)drean.org> > Subject: Re: [xwiki-devs] [Proposal] New Release Dates for the 2.0 > Release > To: XWiki Developers <devs(a)xwiki.org> > Message-ID: > <c58832290909030228s69fc0cc0o2893e9027083e6eb(a)mail.gmail.com> > Content-Type: text/plain; charset=ISO-8859-1 > > +1, > > JV. > > > On Thu, Sep 3, 2009 at 11:25 AM, Vincent Massol <vincent(a)massol.net> > wrote: > > > > Guys, > > > > Seen that we're now the 3rd of Sep and we're not ready to release the > > new colibri skin (lots of remaining issues), I'd like to propose to > > postpone the release by 1 week with the new timetable: > > > > * XE 2.0RC1: 10th of Sep > > * XE 2.0 final (if no RC2): 15th of Sep > > * XE 2.0RC2 (if blockers found in RC1): 17th of Sep > > * XE 2.0 final (if RC2): 22nd of Sep > > > > Here's my +1 > > > > Thanks > > -Vincent > > > > On Thu, Aug 27, 2009 at 11:02 AM, Vincent Massol<vincent(a)massol.net> > wrote: > > > Hi, > > > > > > Since we've just released 2.0M4 we need to reschedule the date for the > 2.0 > > > release. > > > > > > I'm proposing: > > > > > > * 2.0RC1: 2nd of Sep > > > * If no blocking bug found in RC1: > > > ** 2.0 final: 4th of Sept (it's just a re-release of RC1 in this case) > > > * If blocking bugs found in RC1: > > > ** 2.0RC2: 9th of Sep > > > ** 2.0 final: 11th of Sep (it's just a re-release of RC2 in this case) > > > > > > WDYT? > > > > > > Thanks > > > -Vincent > > > > > > > > _______________________________________________ > > devs mailing list > > devs(a)xwiki.org > > http://lists.xwiki.org/mailman/listinfo/devs > > > ------------------------------ > > Message: 9 > Date: Thu, 3 Sep 2009 15:05:41 +0530 > From: Asiri Rathnayake <asiri.rathnayake(a)gmail.com> > Subject: Re: [xwiki-devs] [Proposal] New Release Dates for the 2.0 > Release > To: XWiki Developers <devs(a)xwiki.org> > Message-ID: > <9fd36c290909030235p219b3e98h951b6d1ec9502ad4(a)mail.gmail.com> > Content-Type: text/plain; charset=ISO-8859-1 > > +1 > > On Thu, Sep 3, 2009 at 2:55 PM, Vincent Massol <vincent(a)massol.net> wrote: > > > Guys, > > > > Seen that we're now the 3rd of Sep and we're not ready to release the > > new colibri skin (lots of remaining issues), I'd like to propose to > > postpone the release by 1 week with the new timetable: > > > > * XE 2.0RC1: 10th of Sep > > * XE 2.0 final (if no RC2): 15th of Sep > > * XE 2.0RC2 (if blockers found in RC1): 17th of Sep > > * XE 2.0 final (if RC2): 22nd of Sep > > > > Here's my +1 > > > > Thanks > > -Vincent > > > > On Thu, Aug 27, 2009 at 11:02 AM, Vincent Massol<vincent(a)massol.net> > > wrote: > > > Hi, > > > > > > Since we've just released 2.0M4 we need to reschedule the date for the > > 2.0 > > > release. > > > > > > I'm proposing: > > > > > > * 2.0RC1: 2nd of Sep > > > * If no blocking bug found in RC1: > > > ** 2.0 final: 4th of Sept (it's just a re-release of RC1 in this case) > > > * If blocking bugs found in RC1: > > > ** 2.0RC2: 9th of Sep > > > ** 2.0 final: 11th of Sep (it's just a re-release of RC2 in this case) > > > > > > WDYT? > > > > > > Thanks > > > -Vincent > > > > > > > > _______________________________________________ > > devs mailing list > > devs(a)xwiki.org > > http://lists.xwiki.org/mailman/listinfo/devs > > > > > ------------------------------ > > Message: 10 > Date: Thu, 3 Sep 2009 11:38:05 +0200 > From: Guillaume Lerouge <guillaume(a)xwiki.com> > Subject: Re: [xwiki-devs] [Proposal] New Release Dates for the 2.0 > Release > To: XWiki Developers <devs(a)xwiki.org> > Message-ID: > <1c35d2320909030238x7e54fe9dga05a71e042206e84(a)mail.gmail.com> > Content-Type: text/plain; charset=UTF-8 > > +1 > Guillaume > > On Thu, Sep 3, 2009 at 11:35 AM, Asiri Rathnayake < > asiri.rathnayake(a)gmail.com> wrote: > > > +1 > > > > On Thu, Sep 3, 2009 at 2:55 PM, Vincent Massol <vincent(a)massol.net> > wrote: > > > > > Guys, > > > > > > Seen that we're now the 3rd of Sep and we're not ready to release the > > > new colibri skin (lots of remaining issues), I'd like to propose to > > > postpone the release by 1 week with the new timetable: > > > > > > * XE 2.0RC1: 10th of Sep > > > * XE 2.0 final (if no RC2): 15th of Sep > > > * XE 2.0RC2 (if blockers found in RC1): 17th of Sep > > > * XE 2.0 final (if RC2): 22nd of Sep > > > > > > Here's my +1 > > > > > > Thanks > > > -Vincent > > > > > > On Thu, Aug 27, 2009 at 11:02 AM, Vincent Massol<vincent(a)massol.net> > > > wrote: > > > > Hi, > > > > > > > > Since we've just released 2.0M4 we need to reschedule the date for > the > > > 2.0 > > > > release. > > > > > > > > I'm proposing: > > > > > > > > * 2.0RC1: 2nd of Sep > > > > * If no blocking bug found in RC1: > > > > ** 2.0 final: 4th of Sept (it's just a re-release of RC1 in this > case) > > > > * If blocking bugs found in RC1: > > > > ** 2.0RC2: 9th of Sep > > > > ** 2.0 final: 11th of Sep (it's just a re-release of RC2 in this > case) > > > > > > > > WDYT? > > > > > > > > Thanks > > > > -Vincent > > > > > > > > > > > _______________________________________________ > > > devs mailing list > > > devs(a)xwiki.org > > > http://lists.xwiki.org/mailman/listinfo/devs > > > > > _______________________________________________ > > devs mailing list > > devs(a)xwiki.org > > http://lists.xwiki.org/mailman/listinfo/devs > > > > > > -- > Guillaume Lerouge > Product Manager - XWiki > Skype: wikibc > Twitter: glerouge > http://guillaumelerouge.com/ > > > ------------------------------ > > _______________________________________________ > devs mailing list > devs(a)xwiki.org > http://lists.xwiki.org/mailman/listinfo/devs > > > End of devs Digest, Vol 27, Issue 13 > ************************************ >

2 1

[xwiki-devs] [Proposal] New Release Dates for the 2.0 Release
by Vincent Massol 03 Sep '09

03 Sep '09

Hi, Since we've just released 2.0M4 we need to reschedule the date for the 2.0 release. I'm proposing: * 2.0RC1: 2nd of Sep * If no blocking bug found in RC1: ** 2.0 final: 4th of Sept (it's just a re-release of RC1 in this case) * If blocking bugs found in RC1: ** 2.0RC2: 9th of Sep ** 2.0 final: 11th of Sep (it's just a re-release of RC2 in this case) WDYT? Thanks -Vincent

8 12

[xwiki-devs] [VOTE] Add the IRC Bot application to SVN
by Vincent Massol 03 Sep '09

03 Sep '09

Hi, I've rewritten the IRC Bot application to make it more generic and using XWiki 2.0 syntax and the new Observation mechanism. I'm looking for a place where to save the sources. I'd like to propose to put it in platform/applications/ircbot Rationale: * Since we use it it'll be actively maintained * It could be useful for others too It would have its own JIRA project and its own release cycles of course. Here's my +1 Thanks -Vincent

6 7

[xwiki-devs] Preparing 2.1 roadmap for architecture features
by Vincent Massol 03 Sep '09

03 Sep '09

Hi, In order to prepare what we could in the 2.1 roadmap on the domain of architecture features (ie not user-oriented features), here's a list of stuff I have in mind for working on myself (and/or with some of you): * Services Bridge (between scripts and components) * Velocity JSR223 implementation * Finish xwiki-url * Finish xwiki-action * Finish xwiki-localization * Generic Rendering Markers for Transformations * Move XHTML parser from wikimodel to our code base * Rendering: make script/include/useravatar macros usable standalone too * Component Manager: introduce Realms * Move to JSR299 annotations + move to Guice. (I think this one is too early though - JSR330 public review is for 15th of Sep) * I10n of Renderng module / WYSIWYG module * Implement xwiki-search (rewrite using new archi) (We might want to fix existing lucene plugin first before tackling this one) * App Manager (too big to start now - I think beg of next year) Any other stuff that we'd need to work on from an architecture pov? Thanks -Vincent

3 4

[xwiki-devs] Adding pages and panels externally
by Alexandre Souza 02 Sep '09

02 Sep '09

Hi, I am development a bash script for adding a lot pages and panels automatically in my xwiki. I got to add pages with 'curl' command, as following: *curl -u Admin:admin -X PUT -d @newpage.html -H "Content-Type: text/plain" http://localhost:8080/xwiki/rest/wikis/xwiki/spaces/Main/pages/NewPage * This works, but I'm having difficulty to add links in a side panel for the pages created. Is it possible make this with 'curl' too? If not, is there another way? Thanks, Alexandre Souza

2 1

[xwiki-devs] Translations for XWiki Enterprise 2.0
by Guillaume Lerouge 02 Sep '09

02 Sep '09

Hi XWikiers, I know some of you regularly update translations for languages on http://l10n.xwiki.org/ . I've just refreshed the list of translations, which created a slew of new empty strings :-) It would be great if we could fill as much of them as possible before releasing XWiki Enterprise 2.0. I'll handle the French ones. You can find empty translations for your language on http://l10n.xwiki.org/xwiki/bin/view/XE/XWikiCoreResources Thanks in advance for your help, Guillaume -- Guillaume Lerouge Product Manager - XWiki Skype: wikibc Twitter: glerouge http://guillaumelerouge.com/

1 0

Re: [xwiki-devs] [xwiki-users] [Vote] Default Color Theme
by PERINAUD Christophe 02 Sep '09

02 Sep '09

+1 for (4) > -----Message d'origine----- > De : devs-bounces(a)xwiki.org [mailto:[email protected]] > De la part de Ecaterina Valica > Envoyé : mercredi 2 septembre 2009 16:38 > À : XWiki Users; XWiki Mailinglist > Objet : Re: [xwiki-devs] [xwiki-users] [Vote] Default Color Theme > > Hi, > > So the final decision is between (2), (4), (B).* > > (2)* > http://incubator.myxwiki.org/xwiki/bin/download/ColorThemes/Pr > oposal2/Proposal2.png > > *(4)* > http://incubator.myxwiki.org/xwiki/bin/download/ColorThemes/Pr > oposal4/Proposal4.png > > *(B) * > http://incubator.myxwiki.org/xwiki/bin/download/ColorThemes/BC > olorTheme/SchemeB.png > * * > > > I preserved the existing votes: > > (4) +1 Caty, +1 Vincent, +1 Ricardo R, +1 Florin, +1 Silvia, > +0.5 Trevor, +1 > Marius > (B) +1 Oana, +1 Thomas M, +1 Sergiu, +0.5 Vincent G, +1 > Philipp, +1 Martijn, > +0.5 Trevor > (2) +1 Lucien, +0.66 Marta, +0.5 Jean C, +1 Gaëtan, +0.66 Raluca, +0.5 > Vincent G, +1 Emilie, > > > For the ones that changed their mind and want to change their > vote just > reply again and reset your vote. > > Thanks, > Caty > _______________________________________________ > devs mailing list > devs(a)xwiki.org > http://lists.xwiki.org/mailman/listinfo/devs > -------------------------------------------------------------------------------- This e-mail is intended only for the addressee named above. It does not bind the sender, except in the case of an existing written convention with the addressee. This e-mail may contain material that is confidential and privileged for the sole use of the intended recipient. Any review, reliance or distribution by others or forwarding without express permission is strictly prohibited and may be unlawful. If you are not the intended recipient, please contact the sender and delete all copies. While reasonable precautions have been taken to ensure that this e-mail and any attachments are free from any computer virus or similar defect, no liability will be accepted in that respect. Anyone accessing this e-mail must take their own precautions as to security and virus protection. KBL European Private Bankers S.A., 43 boulevard Royal L-2955 Luxembourg, R.C.S. Luxembourg B 6395, T (352) 47 97 1

2 1

[xwiki-devs] [VOTE] Rename xwiki-bridge in xwiki-model
by Vincent Massol 02 Sep '09

02 Sep '09

Hi, Since we have some final classes (final in the sense with a good architecture) in xwiki-bridge I'd like to rename it into xwiki-model so that we can start this model module. Note: We'd still have a org.xwiki.model.bridge package for the time being in that xwiki-model module. Here's my +1 Thanks -Vincent

2 1

[xwiki-devs] [VOTE] Add the IRC Bot application to SVN
by Guillaume Lerouge 02 Sep '09

02 Sep '09

Hi, On Wed, Sep 2, 2009 at 11:02 AM, Sergiu Dumitriu <sergiu(a)xwiki.com> wrote: > [Ricardo Rodriguez] Your EPEC Network ICT Team wrote: > > Hi, Vincent, > > > > Vincent Massol wrote: > >> Hi, > >> > >> I've rewritten the IRC Bot application to make it more generic and > >> using XWiki 2.0 syntax and the new Observation mechanism. I'm looking > >> for a place where to save the sources. > >> > >> I'd like to propose to put it in platform/applications/ircbot > >> > >> Rationale: > >> * Since we use it it'll be actively maintained > >> * It could be useful for others too > >> > >> It would have its own JIRA project and its own release cycles of course. > >> > >> Here's my +1 > >> > I might be misunderstanding something about our process, but aren't new projects supposed to spend some time in the sandbox before they get their own SVN branch? Other than that I'm +1 with having it in our repo, Guillaume > >> Thanks > >> -Vincent > >> > >> > > Thanks for this initiative. We are considering the use of IRC or Jabber > > chat rooms for virtual meetings and this application will help us to > > avoid losing discussions and having the chat room "warned" about what is > > going on in the wiki. > > > > As far as I've understood, you, XWiki devs, are considering to move to > > Jabber. Please, will this or a similar application work with Jabber? > > Yes, we will make it also work with Jabber at some time. > > -- > Sergiu Dumitriu > http://purl.org/net/sergiu/ > _______________________________________________ > devs mailing list > devs(a)xwiki.org > http://lists.xwiki.org/mailman/listinfo/devs > -- Guillaume Lerouge Product Manager - XWiki Skype: wikibc Twitter: glerouge http://guillaumelerouge.com/

2 1

[xwiki-devs] [Vote] Make the colibri skin the default one in XE 2.0 RC1
by Guillaume Lerouge 02 Sep '09

02 Sep '09

Hi Thibaut, thanks for your feedback, we need more of it even if we sometimes welcome it a bit roughly :-) On Wed, Sep 2, 2009 at 2:17 AM, Thibaut DEVERAUX <thibaut.deveraux(a)gmail.com > wrote: > To be more precise, personas : > > Jo, > Know what is a wiki. > > "Where is the "edit button??? Ho, at the top ! " > > Mike > Don't know what is a wiki > > "What can I do now?" > Mike is looking arond the page, looking fo something logical. > Mike may not notice the edit button since he is looking near the content. > Now iimagine Mike sees the edit button. > (Interesting : If he scroll he will se that the bar is scrolling to so it > may help him to notice it) > "So there is an edit link, I gess I will edit somehing, but what?" > Mike click on the edit button. > It open the editor with the content of the page. > It take a few miliseconds to mike to understand. > "Ho ok, this is editing the content of the page." > > 9 lines for mike... > > > If the edit button btton was near the content mike would have nticed it > more > easily. > Also He would have linked it more easily with the fact it is editing the > content. > > > This is what makes the difference between the two designs... I happen to agree about the fact that the page action buttons should be located in the content area of the page. Additionally, power users can also get accustomed to keyboard shortcuts and they're even better than the non-moving top bar: 1. fingers don't need to leave the keyboard -> faster 2. always available wherever you are on the page So this global discussion could go on for ages before we come to an ideal solution :-) We'll definitely keep working on improving XWiki's UI / UX in the coming releases (XE 2.1 is scheduled for the end of the year) and sharing the work with the community in order to assess all options and come to an optimal choice. Many corporate users are not familiar with wikis at all and we'll explore all the ways to make the UI / UX easier to understand and use for them. We'll be looking for your feedback during that time and the 2 mails you just wrote will definitely be useful. Now when it comes to releasing XWiki Enterprise 2.0 with or without colibri, I'm definitely in favor of using Colibri. As Vincent stated it, the new skin: - Doesn't have drawbacks toucan doesn't already have - the action bar is in the same location - all important items are in the same location -> no new UX issues (no regressions) - Brings a lot of improvements - scrolling issue fixed - ability to change colors and select a theme - panels no longer go up to the top of the page -> allows for more flexible layouts - new visual identity which is an important part of XWiki Enterprise 2.0 - the page title is displayed automatically (we get a lot of strong feedback from our corporate users on this and they will like it a lot - even though we need to fix the double title issue on a number of pages) So I don't see a compelling reason not to use it. You're right about the fact that it means splitting XWiki's renovation in 2 (new look today, new ergonomics tomorrow) but this isn't an issue by itself as long as we keep working on improving it in the future. Thanks for your feedback, Guillaume > > > 2009/9/2 Thibaut DEVERAUX <thibaut.deveraux(a)gmail.com> > > > Ho that's it. It is a design decision based about scrolling. I forgot > this > > point. > > > > So I understand now. Yet I still have some remarks about this because > what > > you choose now is not neutral at all. > > I don't say it is good or bad. I say everybody have to understand the > > implications. > > > > /***************************** > > Disclaimer : > > All of this is mainly theorical, UX is not an exact science when you > can't > > make tests. Also I can be biaised by my own eperience (I'm definitivly > not a > > newbee user, more probably a geek user). > > The only manner to really be sure about it is, like usual, to make tests > on > > a few real newbee users... > > *****************************/ > > > > > > Situation : > > > > Just imagine you are in a supermarket and you search for butter. > > > > First of all you assume butter is somewhere in the food aera. > > > > Then you may think that butter is with all prooducts based on milk. > > > > Also it should be in a freezer aera. > > > > So you will find easily the butter. > > > > > > Information architecture and ergonomy use a lot a methode called "card > > sorting" to create such logic aeras. They write the elements of the > > interface on paper. Then they ask people to group card they think to be > > linked. Then they make stats on groups to define an architecture of > elements > > grouped in a logic way. > > > > More information : > > French : http://www.ergolab.net/articles/tri-cartes-ergonomie-web.php > > English : > > http://www.boxesandarrows.com/view/card_sorting_a_definitive_guide > > > > > > You understand, I think, what I mean. In a "logic aeras" way the edit > > button and all what is related specifically to the content on the page > > should be near the page. (I dont mind it is moving or not, since it is in > > the content aera) > > > > > > Ok. Now, you will say me that anyone found a solution to get at the same > > time the content related links near the content and at the same time > having > > the content related links always accessible. So : "the menu becomes > > inaccessible once you scroll down". > > > > > > This is right. So they're is a deal... > > > > > > Will I choose something : > > > > * Efficient ? Quicly accessible user bar. > > > > * Newbee friendly ? Put the information where they will search it. > > > > > > > > It really depends on the targeted users : > > > > * If users know the should be an edit button somewhere, choose something > > effcient. > > * If users will use the wiki all the days choose something efficient. > > / > > * If firms have a problematic of adoption and at the same time a lot of > > people not skilled in computers choose something newbee friendly. > > * If yo want anybody can contribute quicly, even if not at ease with > > computers choose something newbee friendly. > > > > > > For my part, not knowing who are the personas, I would have choosen the > > version where the content related actions are in the content aera because > : > > * Imo and according to what I read, scrolling back to someting he has > > already noticed is not the greatest problem for casual users. > > * A newbee oriented design avoid getting people lost since a regular > users > > design only deserve regular users confort. > > > > > > Yet I guess the main clients xwiki are people who have to use regulary > the > > tool or people who know that they here to edit page and that it can be > done > > cliking on an "edit" button somewhere on the page. > > > > > > So... Imo this decision is not about a blind vote in a mailing list where > > evryone is biaised by the fact he know the tool. This decision is to : > > > > * Have its implications evaluated. Best by tests, else by brainstorming > > like we are doing. > > * Being linked with political and marketing orientations. Project leader, > > marketing personas, community... I don't know who.... > > > > > > > > > > > > > > > > > > > > 2009/9/1 Sergiu Dumitriu <sergiu(a)xwiki.com> > > > > Thibaut DEVERAUX wrote: > >> > The skin is still the provisory skin isn't it ? > >> > > >> > I would prefer to wait for the nice version being programmed. > >> > > >> > I think the provisory version has no real advantage on the old one. It > >> is > >> > the same information architecture (worst indeed) with only the > >> minimalist > >> > layout as a plus. > >> > > >> > Imo the minimalist layout is made to work with the exellent ergonomics > >> from > >> > first Caty versions. This is what makes it emotionaly coherent. So I > >> would > >> > prefer to wait the skin being developed. > >> > >> Actually, one of the main reasons why the menu had been moved (at the > >> expense of loosing permanent access to it) was to eliminate the > >> flickering effect when scrolling. Now that a community member provided a > >> nice fix for this issue, it is possible that we will end up not changing > >> the layout in that direction after all. > >> > >> As Vincent said, this skin has the great advantage of being easy to > >> change, and we need this in 2.0 . Please let us know what are the > >> specific bad points from your perspective, what you think is worse than > >> in the previous skin, and what makes the proposed layout (where the menu > >> becomes inaccessible once you scroll down) have better ergonomics than > >> the current one, where you have immediate access to the actions all the > >> time. > >> > >> Thanks in advance for a more detailed feedback. > >> > >> > > >> > > >> > I would propose : > >> > > >> > 1 - Start from the nice proposition > >> > 2 - Work on the menu UX design, wich was the discussion point. (use > >> > "advanced" button ?) > >> > 3 - Develop it... > >> > 4 - relase Colibri skin > >> > > >> > > >> > So unless I missed something and the colibri skin is not still in his > >> old > >> > provisory state, it will be -1 for my part. > >> > > >> > > >> > > >> > 2009/9/1 Th > >> > omas Mortagne <thomas.mortagne(a)xwiki.com> > >> > > >> >> On Tue, Sep 1, 2009 at 14:29, Vincent Massol<vincent(a)massol.net> > >> wrote: > >> >>> On Sep 1, 2009, at 2:28 PM, Guillaume Lerouge wrote: > >> >>> > >> >>>> Hi devs, > >> >>>> I think we should make colibri the default skin in XE 2.0 RC1 if we > >> >>>> want it > >> >>>> to be tested and ready for the release. > >> >>>> > >> >>>> Here's my +1 > >> >>> +1 but only provided we agree on the default colors. Right now I'm > -1 > >> >>> with the current colors. I've had several negative feedbacks about > >> >>> them (too light). > >> >> +1 > >> >> > >> >>> Thanks > >> >>> -Vincent > >> >>> > >> >>> _______________________________________________ > >> >>> devs mailing list > >> >>> devs(a)xwiki.org > >> >>> http://lists.xwiki.org/mailman/listinfo/devs > >> >>> > >> >> > >> >> > >> >> -- > >> >> Thomas Mortagne > >> >> _______________________________________________ > >> >> devs mailing list > >> >> devs(a)xwiki.org > >> >> http://lists.xwiki.org/mailman/listinfo/devs > >> >> > >> > _______________________________________________ > >> > devs mailing list > >> > devs(a)xwiki.org > >> > http://lists.xwiki.org/mailman/listinfo/devs > >> > > >> > >> > >> -- > >> Sergiu Dumitriu > >> http://purl.org/net/sergiu/ > >> _______________________________________________ > >> devs mailing list > >> devs(a)xwiki.org > >> http://lists.xwiki.org/mailman/listinfo/devs > >> > > > > > _______________________________________________ > devs mailing list > devs(a)xwiki.org > http://lists.xwiki.org/mailman/listinfo/devs > -- Guillaume Lerouge Product Manager - XWiki Skype: wikibc Twitter: glerouge http://guillaumelerouge.com/

2 1

[xwiki-devs] [Vote] Default Color Theme
by Ecaterina Valica 02 Sep '09

02 Sep '09

13 15

[xwiki-devs] [Vote] Make the colibri skin the default one in XE 2.0 RC1
by Guillaume Lerouge 02 Sep '09

02 Sep '09

Hi devs, I think we should make colibri the default skin in XE 2.0 RC1 if we want it to be tested and ready for the release. Here's my +1 Guillaume -- Guillaume Lerouge Product Manager - XWiki Skype: wikibc Twitter: glerouge http://guillaumelerouge.com/

7 12

[xwiki-devs] jython 2.5.1 rc1 released
by Vincent Massol 01 Sep '09

01 Sep '09

for information: http://fwierzbicki.blogspot.com/2009/09/jython-251-release-candidate-1-is-o… Release notes: Jython 2.5.1rc1 New Features - Upgraded to ANTLR 3.1.3 - [ 1859477 ] Dynamically loaded ServletFilters like PyServlet - Built in JSR 223 scripting engine, with LiveTribe JSR 223 implementation for JDK 5 - Jython "-J-classpath cp_args_here" now works as expected for unix shell. Bugs Fixed - [ 645615 ] cannot import through symbolic links - [ 1366 ] parsing of lamda expression fails - [ 1365 ] continuation lines fail in interactive interpreter - [ 1377 ] Event names shadowed by a field name on Java types leads to a NPE - [ 1381 ] Redundant declarations of interface implementation hides overriden methods - [ 1189 ] MD5 hash is incorrectly calculated when string contains non-latin chars and using python md5 lib - [ 1802339 ] Problem printing unicode when stdout intercepted - [ 1145 ] Jython 2.5 compatibility problem with JSR 223 - [ 1400 ] Evaluating expression via JSR 223 ScriptEngine returns null instead of True/False - [ 1413 ] Array data type (PostgreSQL) is not supported (NPE) - [ 1434 ] Cannot get return code from a process started with os.popen with Jython 2.5 (worked in 2.2) - [ 1391 ] socket.getaddrinfo() breaks ftplib FTP client - [ 1409 ] JSR-233 engine version numbers backwards - [ 1408 ] JSR-223 engine doesn't implement I/O redirection - [ 1393 ] TypeError: _new_impl(): expected 1 args; got 0 - [ 1415 ] ast Node creation fails with no arg constructors - [ 1405 ] Executing __run__.py from .jar throws exception(SystemExit: 0) in main when sys.exit(0) is called - [ 1439 ] Can't write() array.array - [ 1139 ] crashes on isinstance - [ 1430 ] Oracle JDBC Connection close - [ 1406 ] Parsing a simple PEP 342 coroutine crashes Jython 2.5 - [ 1407 ] ClassCastException in plain Python coroutine - [ 1424 ] Relative imports do not work in some cases The JSR223 part sounds cool. Maybe we can have a jython macro at last? Thanks -Vincent

1 0

Re: [xwiki-devs] [Vote] Default Color Theme
by Guillaume Lerouge 01 Sep '09

01 Sep '09

> > Hi, > +1 for 3) > > Guillaume > > > On Tue, Sep 1, 2009 at 6:28 PM, Anca Luca <ancapaula.luca(a)xwiki.com>wrote: > >> I love the Halloween theme, but it's a bit too much for a default theme, >> same as >> Bordo. >> >> +0.5 for each of current (0) & BlueSky (C) as it is. >> >> Happy styling, >> Anca >> >> Ecaterina Valica wrote: >> > Hi, >> > >> > Please vote to set the default Color Theme for XWiki. >> > >> > The existing themes were: >> > >> > *(0) * >> > >> http://incubator.myxwiki.org/xwiki/bin/download/ColorThemes/DefaultColorThe… >> > SchemeDefault.png< >> http://incubator.myxwiki.org/xwiki/bin/download/ColorThemes/DefaultColorThe… >> >[ >> > *Currently Default*] >> > >> > *(A) * >> > >> http://incubator.myxwiki.org/xwiki/bin/download/ColorThemes/AColorTheme/ >> > SchemeA.png< >> http://incubator.myxwiki.org/xwiki/bin/download/ColorThemes/AColorTheme/Sch… >> >[ >> > *Nature*] >> > >> > *(B) * >> > >> http://incubator.myxwiki.org/xwiki/bin/download/ColorThemes/BColorTheme/ >> > SchemeB.png< >> http://incubator.myxwiki.org/xwiki/bin/download/ColorThemes/BColorTheme/Sch… >> > >> > * *[*Nightfall*] >> > >> > *(C)* >> > >> http://incubator.myxwiki.org/xwiki/bin/download/ColorThemes/CColorTheme/ >> > SchemeC.png< >> http://incubator.myxwiki.org/xwiki/bin/download/ColorThemes/CColorTheme/Sch… >> >[ >> > *Blue Sky*] >> > >> > *(D) * >> > >> http://incubator.myxwiki.org/xwiki/bin/download/ColorThemes/DColorTheme/ >> > SchemeD.png< >> http://incubator.myxwiki.org/xwiki/bin/download/ColorThemes/DColorTheme/Sch… >> >[ >> > *Inner Dark*] >> > >> > *(E) * >> > >> http://incubator.myxwiki.org/xwiki/bin/download/ColorThemes/EColorTheme/ >> > SchemeE.png< >> http://incubator.myxwiki.org/xwiki/bin/download/ColorThemes/EColorTheme/Sch… >> >[ >> > *Bordo*] >> > >> > Since then there were added 3 more themes: >> > >> > *(F)* >> > >> http://incubator.myxwiki.org/xwiki/bin/download/ColorThemes/FColorTheme/Pea…<http://incubator.myxwiki.org/xwiki/bin/download/ColorThemes/FColorTheme/Pea…> >> > *Peach*] >> > >> > *(G)* >> > >> http://incubator.myxwiki.org/xwiki/bin/download/ColorThemes/GColorTheme/Cho…<http://incubator.myxwiki.org/xwiki/bin/download/ColorThemes/GColorTheme/Cho…> >> > *Choco Blues*] >> > >> > *(H)* >> > >> http://incubator.myxwiki.org/xwiki/bin/download/ColorThemes/Halloween/Hallo…<http://incubator.myxwiki.org/xwiki/bin/download/ColorThemes/Halloween/Hallo…> >> > *Halloween*] >> > >> > Because Theme *(C) Blue Sky* was mentioned as a candidate for the >> Default >> > Theme, I've done some variations with those colors: >> > >> > *(1)* >> > >> http://incubator.myxwiki.org/xwiki/bin/download/ColorThemes/Proposal1/Propo… >> > >> > *(2)* >> > >> http://incubator.myxwiki.org/xwiki/bin/download/ColorThemes/Proposal2/Propo… >> > >> > *(3)* >> > >> http://incubator.myxwiki.org/xwiki/bin/download/ColorThemes/Proposal3/Propo… >> > >> > *(4)* >> > >> http://incubator.myxwiki.org/xwiki/bin/download/ColorThemes/Proposal4/Propo… >> > >> > So please cast your vote or your Theme proposal. >> > >> > Thanks, >> > Caty >> > _______________________________________________ >> > devs mailing list >> > devs(a)xwiki.org >> > http://lists.xwiki.org/mailman/listinfo/devs >> _______________________________________________ >> devs mailing list >> devs(a)xwiki.org >> http://lists.xwiki.org/mailman/listinfo/devs >> > > -- Guillaume Lerouge Product Manager - XWiki Skype: wikibc Twitter: glerouge http://guillaumelerouge.com/

1 0

Re: [xwiki-devs] [Vote] Default Color Theme
by PERINAUD Christophe 01 Sep '09

01 Sep '09

+1 (3) -------------------------------------------------------------------------------- This e-mail is intended only for the addressee named above. It does not bind the sender, except in the case of an existing written convention with the addressee. This e-mail may contain material that is confidential and privileged for the sole use of the intended recipient. Any review, reliance or distribution by others or forwarding without express permission is strictly prohibited and may be unlawful. If you are not the intended recipient, please contact the sender and delete all copies. While reasonable precautions have been taken to ensure that this e-mail and any attachments are free from any computer virus or similar defect, no liability will be accepted in that respect. Anyone accessing this e-mail must take their own precautions as to security and virus protection. KBL European Private Bankers S.A., 43 boulevard Royal L-2955 Luxembourg, R.C.S. Luxembourg B 6395, T (352) 47 97 1

1 0

Re: [xwiki-devs] [xwiki-notifications] r23184 - platform/xwiki-plugins/trunk/watchlist/src/main/java/com/xpn/xwiki/plugin/watchlist
by Vincent Massol 01 Sep '09

01 Sep '09

On Sep 1, 2009, at 2:25 PM, jvdrean (SVN) wrote: > Author: jvdrean > Date: 2009-09-01 14:25:49 +0200 (Tue, 01 Sep 2009) > New Revision: 23184 > > Modified: > platform/xwiki-plugins/trunk/watchlist/src/main/java/com/xpn/xwiki/ > plugin/watchlist/WatchListStore.java > Log: > Fixed wrong listener name wow, glad my log allowed to catch this! That would have caused some serious problems ;) -Vincent > Modified: platform/xwiki-plugins/trunk/watchlist/src/main/java/com/ > xpn/xwiki/plugin/watchlist/WatchListStore.java > =================================================================== > --- platform/xwiki-plugins/trunk/watchlist/src/main/java/com/xpn/ > xwiki/plugin/watchlist/WatchListStore.java 2009-09-01 12:21:27 UTC > (rev 23183) > +++ platform/xwiki-plugins/trunk/watchlist/src/main/java/com/xpn/ > xwiki/plugin/watchlist/WatchListStore.java 2009-09-01 12:25:49 UTC > (rev 23184) > @@ -92,7 +92,7 @@ > /** > * The name of the listener. > */ > - private static final String LISTENER_NAME = "rightsmanager"; > + private static final String LISTENER_NAME = "watchliststore"; > > /** > * The events to match. > @@ -619,4 +619,4 @@ > { > return LISTENER_NAME; > } > -} > \ No newline at end of file > +}

1 0

[xwiki-devs] [Proposal] Define a set of User Experience guidelines for XWiki
by Guillaume Lerouge 01 Sep '09

01 Sep '09

Hi Devs, Following-up on Caty's email ( http://markmail.org/message/3vukpehxeiflfjfw) I'd like us to get a bit more organized when it comes to improving XWiki's User Experience. This would allow us to make the product better and to gather more feedback from the community (such as Thibaut's email, see http://markmail.org/message/3bdk4jaziuqs6zvi ). In order to make our product great I think it would be good for us to agree on a set of standards and best practices related to UX. There are 2 levels to this initiative: 1. Agree on a set of broad rules 2. Agree on the implementation specifics for each rule A broad rule is a general rule that has to be followed when designing & coding a new feature: 1. "Always design a feature with one or more specific personas in mind" 2. "Respect consistency -> all UI items in XWiki should look & behave in the same way" Specifics are details related to the implementation of any given rule: 1. Choose the style to use for all buttons (see http://incubator.myxwiki.org/xwiki/bin/view/Standards/ for examples) 2. Define the personas we're targetting (see http://dev.xwiki.org/xwiki/bin/view/Design/ImproveXWikiUserExperience for examples) I'd like to get your feedback on the following points: - Is that a good idea overall? - Do you think we can make it an integral part of our development process? If the feedback is positive I'll start a discussion about the general UX rules we should make XWiki follow, then new ones for the specifics of each rule once we've agreed on some or all of them. Thanks, Guillaume -- Guillaume Lerouge Product Manager - XWiki Skype: wikibc Twitter: glerouge http://guillaumelerouge.com/

8 11

[xwiki-devs] [Proposal] Making "Edit this attachment" an advanced feature in the advanced edit mode
by Silvia Rusu 01 Sep '09

01 Sep '09

Hi devs, I propose we make "Edit this attachment" in the "Attachments" tab an advanced feature in the advanced edit mode. When trying to use "Edit this attachment": - in IE you get the following message: "Could not initialize a required ActiveX object" - in FF 3.5.2 installing the extension delivers the following message:"FoxWiki 1.0b could not be installed because it is not compatible with Firefox 3.5.2". - installing the extension on an older version of FF requires additional configuration, which the average user may not know how to perform. Under the above circumstances I think "Edit this attachment" will cause confusion for the average user instead of providing a useful tool. WDYT? ----- Silvia Rusu Tester & Documentation Writer - XWiki http://twitter.com/silviarusu -- View this message in context: http://n2.nabble.com/Proposal-Making-Edit-this-attachment-an-advanced-featu… Sent from the XWiki- Dev mailing list archive at Nabble.com.

6 11

[xwiki-devs] [Proposal] Remove "History" from the "Choose editor" panel
by Silvia Rusu 01 Sep '09

01 Sep '09

Hi Devs, I propose we remove "History" from the "Choose editor" panel in Edit mode. If you look at the "Edit" entry in the XWiki action menu you will see the following sub-menus: - WIKI - WYSIWYG - INLINE FORM - PAGE ACCESS RIGHTS - OBJECTS - CLASS The entries in the "Choose editor" panel are all "Edit" sub-menus, except for "History". I think the "History" tab in View mode should be enough. WDYT? Silvia ----- Silvia Rusu Tester & Documentation Writer - XWiki http://twitter.com/silviarusu -- View this message in context: http://n2.nabble.com/Proposal-Remove-History-from-the-Choose-editor-panel-t… Sent from the XWiki- Dev mailing list archive at Nabble.com.

6 5

Re: [xwiki-devs] Blog Plugin Proposal
by Andreas Schaefer 01 Sep '09

01 Sep '09

On Monday, August 31, 2009, at 12:46AM, "Vincent Massol" <vincent(a)massol.net> wrote: > >On Aug 31, 2009, at 9:28 AM, Guillaume Lerouge wrote: > >> Hi Andreas, >> >> On Mon, Aug 31, 2009 at 1:11 AM, Andreas Schaefer <schaefera(a)me.com> >> wrote: >> >>> My try to deploy the Blog Plugin together with the updated Blog >>> Application failed miserably today and my dislike of Velocity reach a >>> new high. >>> >>> Because I see the value of the scripting nature of the Blog allowing >>> users to customize their Blog to a quite large degree I don't want to >>> ditch that but I have a lot of problems with Velocity and the way is >>> plastering over issues. I rather fail fast than late with hardly a >>> trail to understand what is going on. >>> >> >> My personal experience with velocity is more of a try & fail, try & >> fail, >> try and succeed one than anything else. > >This is not really related to velocity which is the simplest language >on earth. It's related to any language you type without an IDE to help >you. Try using groovy in wiki pages you'll have the same problem (I >know I have it, I need to preview 10 times to get something right). > >That said, there are some velocity editing support in IntellilJ IDEA >and I think there's also a plugin for Eclipse which might help. You >can also use XEclipse which has syntax highlighting and some >autocompletion for velocity (you'd need to use the 1.2RC1 version). I can agree with that. Velocity might be the simplest language for you but for started I could not find a good Velocity language tutorial. Even though the support I get from IntelliJ is really helpful the strange syntax is making it difficult to code (return values through parameters for example) but the real difficulty comes from the fact that I cannot debug velocity in any efficient way but the real thing I cannot stand is the fact that Velocity just ignore any problems. This might be good for a simple web site but for an application like a blog this is not good in my view. At least with Groovy I have a fairly well defined language and some mailing lists that can help me with problems and it ensures that NPEs, undefined methods etc are handled. >> What I found out is that I was msot >> of the time better off rewriting stuff starting with small chunks >> rather >> than trying to take existing code and reuse it all at once. The >> current blog >> is a fairly complex piece of velocity code (that is, given the lack of >> debugging tools when coding in velocity in the wiki). This is one of >> the >> reasons I think Sergiu's argument that "devs will be able to look at >> the >> code and learn from it" is not entirely true ;-) >> >> What's really important for the blog is that it can be customized >> easily at >> 2 levels: >> >> - Look: an user should be able to use the panels she wants for her >> blog >> - Deployment: an user should be able to create a new space blog or >> global >> wiki blog in any space she wants >> >> Besides that the way the blog is code doesn't matter much for the >> end user. >> >> That said I still think that it might be a good idea to convert the >>> scripted part of the Blog over to Groovy and keep the rest in the >>> Blog >>> Plugin. I don't have any experience with Groovy inside XWiki but for >>> sure the documentation of Groovy outside is excellent compared to >>> Velocity. I will use the next week to get up to speed and try to >>> convert a piece of the Blog over to Groovy. >> >> >> Then go ahead and give it a go :-) >> >> One thing you need to be aware of when using Groovy inside the wiki >> is that >> your pages will haveto be saved using programming rights. This can >> cause a >> number of issues, don't forget to code with an user that has them, >> it will >> save yo ua lot of hassle ;-) > >Yes and we might not be able to include it in the default distribution >since our rule so far was only velocity in the default XE XAR. I rather have a good, robust and reliable Blog application even if I would have to download it separately. But first I need to see how well a Blog in Groovy would work and what the limitations (like the programming rights) mean. To keep it easy I think I will start with implementing what we have in BlogSheet/BlogCode to just list the current entries in a blog. If I can then create a Blog Post Entry with Groovy I should pretty much be able to compare the two. Personally I am more interested to get the stuff going well for my own Blog but I am willing to go the extra mile to provide it to the community. Cheers - Andy

2 1

[xwiki-devs] [VOTE] Use PNG instead of GIF for the silk icons
by Sergiu Dumitriu 01 Sep '09

01 Sep '09

Hi devs, Short version: we need to replace GIFs with transparent PNGs for the Silk icon set. 3 options: A. use "filter: AlphaImageLoader" in our CSS, time consuming for our devs B. serverside content negotiation to send GIFs only to IE6, doesn't really fix the problem for IE6 C. use a third party library that handles this for us, but does not work under certain security restrictions Long version: Originally, silk icons are PNGs, with alpha transparency. The problem with them is that in IE6 they don't display nice, since they have a gray background. So, instead we're currently using GIFs, but this approach has some big issues: - GIFs are indexed, so they have at most 256 colors out of the millions possible in PNGs. This is not such a big issue, since most icons don't use so many colors. - PNGs are smaller (in bytes) than GIFs. - Since gifs don't have alpha transparency, they have an almost-white border around the colored pixels, which makes them ugly on non-white backgrounds (this is obvious on really dark backgrounds). This is a real blocker for using darker themes in Colibri. Now, switching to PNGs directly is not a good option, since most of our end users are (forced to be) using IE6. Some tricks are possible: A. Change the CSSs to contain a filter which enables the PNG transparency. This can be done in several ways: A1 - manually (hard for developers, breaks CSS validity) A2 - automatically at build time (breaks CSS validity) A3 - dynamically in the SkinAction (won't work if the CSS is served by the container) The advantage is that we can control which images are transformed. The disadvantage is that it might not work under certain security restrictions. B. Implement a kind of content-negotiation trick that sends PNGs or GIFs depending on the user agent. This is easy to do with a few Apache HTTPD settings, but it's not cross-platform at all. We can also do it in the SkinAction, but again, doesn't work if the request does not pass through it. The advantage is that it always works, since it's always an image. The disadvantage is that icons will continue to look ugly in IE6, since they are GIFs. C. Use http://www.twinhelix.com/css/iepngfix/ which automatically fixes all images in IE. The advantages are that it is the most easy solution to implement, with the least amount of effort, it fixes most problems, and requires little maintenance. The disadvantage is that it won't work under certain security restrictions, and that a clean and fast integration will requirer to add some mechanism of identifying which images to fix (it can be incompatible with other tools that do their own PNG fix, like Google Maps). None of the alternatives is perfect, but my personal preference goes to C. -- Sergiu Dumitriu http://purl.org/net/sergiu/

4 5