July 2010 - xwiki-devs@xwiki.org

[xwiki-devs] [Proposal] Portlet Integration - Client Side
by Marius Dumitru Florea 08 Jul '10

08 Jul '10

Hi devs, In order to integrate XWiki in a portal ( http://dev.xwiki.org/xwiki/bin/view/Drafts/PortletIntegration ) we need to change a bit the front end to: * ensure XWiki's HTML element IDs are unique within the portal page * ensure XWiki's stylesheets doesn't affect other portlets and the portal page itself * ensure XWiki content is not affected by stylesheets of other portlets or the portal page itself We could do the following: (1) "Mark" IDs and class names whenever they are used in JavaScript code, both in-line and stand-alone, using two identify functions: id(String) and className(String). This is required because identifying automatically IDs and class names in JavaScript code is not always possible. (2) Automatically rewrite IDs and class names in CSS and HTML (except in-line JavaScript) and "marked" IDs and class names in both in-line and stand-alone JavaScript code before the response for each of the resources (page included) reaches the client. This can be easily done in the XWiki portlet bridge ( http://svn.xwiki.org/svnroot/xwiki/contrib/sandbox/xwiki-portlet/ ). Final IDs and class names will include the portlet identifier and the XWiki namespace (e.g. a simple 'x' prefix). (3) Split XWiki's stylesheets (e.g. colibri.css) in two: (a) general rules, including skin reset (b) XWiki specific rules (i.e. with selectors including class names or IDs) and import only (b) in portlet mode. WDYT? Thanks, Marius

1 0

[xwiki-devs] [ANN] XWiki Enterprise 2.4 Release Candidate 1 Released
by Thomas Mortagne 08 Jul '10

08 Jul '10

The XWiki development team is pleased to announce the release of XWiki Enterprise 2.4 Release Candidate 1. Go grab it at http://www.xwiki.org/xwiki/bin/view/Main/Download First and hopefully last release candidate of the XWiki Enterprise 2.4 version. This is mostly a bugfixing release before the 2.4 final. For more information see the Release notes at: http://www.xwiki.org/xwiki/bin/view/Main/ReleaseNotesXWikiEnterprise24RC1 Thanks - The XWiki dev team

1 0

Re: [xwiki-devs] [xwiki-notifications] r29813 - platform/web/trunk/standard/src/main/webapp/resources/js/xwiki/table
by Sergiu Dumitriu 08 Jul '10

08 Jul '10

On 06/30/2010 10:28 AM, vmassol (SVN) wrote: > Author: vmassol > Date: 2010-06-30 10:28:11 +0200 (Wed, 30 Jun 2010) > New Revision: 29813 > > Modified: > platform/web/trunk/standard/src/main/webapp/resources/js/xwiki/table/livetable.js > Log: > XWIKI-5316: Send a livetable event when the livetable has finished displaying/updating the rows > > > Modified: platform/web/trunk/standard/src/main/webapp/resources/js/xwiki/table/livetable.js > =================================================================== > --- platform/web/trunk/standard/src/main/webapp/resources/js/xwiki/table/livetable.js 2010-06-30 00:07:16 UTC (rev 29812) > +++ platform/web/trunk/standard/src/main/webapp/resources/js/xwiki/table/livetable.js 2010-06-30 08:28:11 UTC (rev 29813) > @@ -285,6 +285,14 @@ > } > } > if (this.paginator) this.paginator.refreshPagination(); > + > + // Let code know displaying is finished > + // 1. Named event (for code interested by that table only) > + document.fire("xwiki:livetable:" + self.domNodeName + ":displayComplete") > + // 2. Generic event (for code potentially interested in any livetable) > + document.fire("xwiki:livetable:displayComplete", { > + "tableId" : self.domNodeName > + }); You should also send an event on the livetable root element as well. > }, > > /** > @@ -386,6 +394,14 @@ > } > > if (this.paginator) this.paginator.refreshPagination(); > + > + // Let code know displaying is finished > + // 1. Named event (for code interested by that table only) > + document.fire("xwiki:livetable:" + self.domNodeName + ":displayComplete") > + // 2. Generic event (for code potentially interested in any livetable) > + document.fire("xwiki:livetable:displayComplete", { > + "tableId" : self.domNodeName > + }); > }, > > /** -- Sergiu Dumitriu http://purl.org/net/sergiu/

1 0

Re: [xwiki-devs] [xwiki-notifications] r30025 - platform/core/trunk/xwiki-observation/xwiki-observation-remote
by Sergiu Dumitriu 06 Jul '10

06 Jul '10

On 07/06/2010 04:20 PM, tmortagne (SVN) wrote: > Author: tmortagne > Date: 2010-07-06 16:20:58 +0200 (Tue, 06 Jul 2010) > New Revision: 30025 > > Modified: > platform/core/trunk/xwiki-observation/xwiki-observation-remote/pom.xml > Log: > XWIKI-4917: Upgrade to jgroups 2.8 > Add comment > > Modified: platform/core/trunk/xwiki-observation/xwiki-observation-remote/pom.xml > =================================================================== > --- platform/core/trunk/xwiki-observation/xwiki-observation-remote/pom.xml 2010-07-06 13:41:04 UTC (rev 30024) > +++ platform/core/trunk/xwiki-observation/xwiki-observation-remote/pom.xml 2010-07-06 14:20:58 UTC (rev 30025) > @@ -59,6 +59,7 @@ > <artifactId>xwiki-core-context</artifactId> > <version>${pom.version}</version> > </dependency> > + Is it time for us to require Java 6 as well? > <dependency> > <groupId>jgroups</groupId> > <artifactId>jgroups</artifactId> -- Sergiu Dumitriu http://purl.org/net/sergiu/

3 4

[xwiki-devs] [Proposal] Replace download pages on code.xwiki.org with links to the maven repo
by Vincent Massol 06 Jul '10

06 Jul '10

Hi, Thomas, JV and I discussed about replacing download pages on xwiki.org with links to our maven repo (for stuff on code.xwiki.org only). The rationale: Speed up the dev process and make it a failsafe process. Advantages: * No need to upload artifacts (which means smaller wiki and faster release process) * Full history available * No risk of being not synced with the maven repo (which is the official artifact repository) * Low-tech solution http://code.xwiki.org/xwiki/bin/view/Applications/AnnotationsApplication When you click on download you go to: http://maven.xwiki.org/releases/org/xwiki/platform/applications/xwiki-appli… Thomas has already implemented it during the last release. It should have been discussed before but Thomas was in a hurry for the release. Let us know if you don't agree. Thanks -Vincent

2 2

[xwiki-devs] REST refactoring
by Fabio Mancinelli 06 Jul '10

06 Jul '10

Hi all, I did a small refactoring in the REST module which consisted in isolating the JAXB model classes in a separate module. This allows client to use JAXB classes for retrieving XML representations without dragging in all the core dependencies. The refactoring consisted in creating an xwiki-rest-model module in core, moving some files, and update the pom.xml's to make things compile. Maybe it's risky to commit it now, but if you are ok everything's ready. I include a diff so that you can check what it looks like. -Fabio

4 5

Re: [xwiki-devs] [xwiki-notifications] r30000 - platform/core/trunk/xwiki-shared-tests/src/main/java/org/xwiki/test
by Vincent Massol 05 Jul '10

05 Jul '10

On Jul 5, 2010, at 7:00 PM, vmassol (SVN) wrote: > Author: vmassol > Date: 2010-07-05 19:00:58 +0200 (Mon, 05 Jul 2010) > New Revision: 30000 yeah rev 30000 :) -Vincent > > Modified: > platform/core/trunk/xwiki-shared-tests/src/main/java/org/xwiki/test/AbstractMockingComponentTestCase.java > Log: > Added comment > > Modified: platform/core/trunk/xwiki-shared-tests/src/main/java/org/xwiki/test/AbstractMockingComponentTestCase.java > =================================================================== > --- platform/core/trunk/xwiki-shared-tests/src/main/java/org/xwiki/test/AbstractMockingComponentTestCase.java 2010-07-05 16:26:20 UTC (rev 29999) > +++ platform/core/trunk/xwiki-shared-tests/src/main/java/org/xwiki/test/AbstractMockingComponentTestCase.java 2010-07-05 17:00:58 UTC (rev 30000) > @@ -59,6 +59,7 @@ > this.componentManager = new EmbeddableComponentManager(); > > // Step 1: Register all components available > + // TODO: Remove this so that tests are executed faster. Need to offer a way to register components manually. > this.loader.initialize(this.componentManager, getClass().getClassLoader()); > > // Step 2: Inject all fields annotated with @MockingRequirement.

2 1

[xwiki-devs] [VOTE] Agree to start using AbstractMockingComponentTestCase
by Vincent Massol 05 Jul '10

05 Jul '10

Hi, Some time ago I had added the AbstractMockingComponentTestCase class in shared-test. I've refactored it a bit over the week end to make it even easier to use. The idea is to use a @MockingRequirement annotation in the test case class to get a component instance with all its @Requirement fields injected with mocks. This makes it easier to test than using the older AbstractComponentTestCase since you don't need to setup component mocks manually. Here's an example usage: public class MacroContentTableBlockDataSourceTest extends AbstractMockingComponentTestCase { @MockingRequirement private MacroContentTableBlockDataSource source; ... Another example: public class DefaultMacroManagerTest extends AbstractMockingComponentTestCase { // Mock all required components except for some for which we want to use the real implementations since they make // the test easier to write (no need to mock them). @MockingRequirement(exceptions = { ComponentManager.class, MacroIdFactory.class }) private DefaultMacroManager macroManager; As you can see in this second example, it's also possible to exclude some @Requirement from being mocked if need be. I'd like that we agree to use this new test class from now on instead of AbstractComponentTestCase (unless there are cases where it's not usable but please discuss those use cases with me since maybe there are solutions to improve AbstractMockingComponentTestCase). Here's my +1 Thanks -Vincent

5 6

[xwiki-devs] unsubscribe
by Hermes, Lars 05 Jul '10

05 Jul '10

Festo AG & Co. KG Lars Hermes Abteilung IS-PB BSP Development + User Services Plieninger Stra?e 50 73760 Ostfildern-Scharnhausen Deutschland Telefon +49(711)347-4510 Telefax +49(711)34754-4510 http://www.festo.com Der Inhalt dieses E-Mails ist ausschliesslich fuer den bezeichneten Adressaten bestimmt. Jede Form der Kenntnisnahme, Veroeffentlichung, Vervielfaeltigung oder Weitergabe des Inhalts dieses E-Mails durch unberechtigte Dritte ist unzulaessig. Wir bitten Sie, sich mit dem Absender des E-Mails in Verbindung zu setzen, falls Sie nicht der Adressat dieses E-Mails sind und das Material von Ihrem Computer zu loeschen. This e-mail and any attachments are confidential and intended solely for the addressee. The perusal, publication, copying or dissemination of the contents of this e-mail by unauthorised third parties is prohibited. If you are not the intended recipient of this e-mail, please delete it and immediately notify the sender. Rechtsform: Kommanditgesellschaft Sitz: Esslingen a.N., Registergericht Stuttgart HRA 211583, Umsatzsteuerident-Nummer: DE 145339206 Pers?nlich haftende Gesellschafterin: Festo Management Aktiengesellschaft Sitz: Wien/?sterreich, Firmenbuchgericht: Handelsgericht Wien, Firmenbuch Nr. FN 303027 d Vorstand: Dipl.-Kfm. Alfred Goll Dr. Claus Jessen Dr. Ansgar Kriwet Dr. Eberhard Veit (Vorsitzender) Dipl.- Kfm. Michael M?lleken Aufsichtsratsvorsitzender: Dr. Wilfried Stoll

1 0

[xwiki-devs] [Discussion] Integrating officepreview module into main source tree
by Asiri Rathnayake 05 Jul '10

05 Jul '10

Hi Devs, I have almost completed my work on officepreview module and I would like to discuss about integrating it into main source tree (and release it with 2.4M1). There are a couple of things to discuss: 1. officepreview module have to depend on xwiki-core for the time being because with current component approach there is no way of determining the version of an attachment (officepreview module needs to know attachment version). 2. Need a couple of tests - I'm working on this. 3. Where to place the officepreview module in main source tree. My initial idea for (3) was to create a /platform/core/trunk/xwiki-officepreview submodule. However, since officepreview module depends on officeimporter module, I'm not sure if we should create a parent module that would host both of these projects. Another problem lingering in my mind is that with recent changes xwiki-officeimporter module encapsulates two sub modules - a module capable of converting documents from one format to another (this is a generic converter api kind of thing) and another module which is importing office documents into xwiki specific formats (XDOMOfficeDocumentBuilder, PresentationBuilder etc.). I'm not sure if these two modules should be seperated out, but may be that's a separate discussion. Please let me know your comments about above points. Thanks. - Asiri

2 5