xwiki-devs

xwiki-devs@xwiki.org

9400 discussions

[Proposal] New SVN directory structure to accommodate the different applications we have

by Vincent Massol

Hi, Note: This email supercedes all my other proposals on the SVN directory structure. The rationale for this mail is that we're starting to have lots of applications built on top of the xwiki platform: XWiki Enterprise (default wiki), XEM, Watch, Curriki, Chronopolys, etc. We need to accomodate them in our directory structure. Top level structure =============== /svnroot/xwiki/ |_ xwiki-platform/ |_ xwiki-applications/ |_ xwiki-enterprise/ |_ xwiki-enterprise-manager/ |_ xwiki-watch/ |_ curriki/ |_ chronopolys/ |_ xwiki-extensions/ |_ xwiki-eclipse/ |_ xwiki-concerto/ |_ sandbox/ where: * xwiki-platform is the xwiki platform on which all the applications are built. * xwiki-applications are applications that extend the platform with: skins, xwiki pages (XAR), plugins * xwiki-enterprise is the name of our previously known "default wiki" application. * xwiki-extensions are any other extensions of xwiki not fitting in xwiki-applications. For example the XWiki Eclipse integration, etc. I've put concerto there but I'm not sure what it'll look like. Definition of xwiki-platform ===================== /svnroot/xwiki/xwiki-platform/ |_ tools/ |_ core/ (JAR) |_ plugins/ (JARs) |_ skins/ (ZIPs) |_ dodo/ |_ finch/ |_ albatross/ |_ web/ (WARs) |_ gwt/ |_ standard/ |_ xarlets (XARs) |_ selenium/ |_ blog/ |_ calendar/ |_ ... where: * tools/ contains tools used to build the platform and xwiki applications * xarlets/ contains independent xwiki apps (we need a word better than xarlets and different than applications which we should reserve for things like curriki, xwiki enterprise, xem, etc) that can be installed in any running xwiki app * In the future core/ will be replaced with: |_ components/ (JARs) |_ xwiki-model/ |_ xwiki-storage/ |_ ... * In the future web/ will be replaced with UI components (see the UI proposal for more) Definition of xwiki-enterprise/ ======================= /svnroot/xwiki/xwiki-applications/xwiki-enterprise/ |_ wiki/ |_ distribution/ |_ distribution-test/ where: * wiki/ contains the xar pages Generic definition of an xwiki-application/ ================================= /svnroot/xwiki/xwiki-applications/<app name>/ |_ wiki/ |_ web/ (optional) |_ plugins/ (optional) |_ skin/ (optional) |_ distribution/ |_ distribution-test/ For example for xwiki-watch/: /svnroot/xwiki/xwiki-applications/xwiki-watch/ |_ wiki/ |_ web/ (the gwt stuff) |_ distribution/ |_ distribution-test/ I think this pretty much includes everything we currently have in SVN. WDYT? Thanks -Vincent

18 years

Proposal for full-editing mode

by evelyne24＠gmail.com

Hello all, First of all, thank you for your replays and please forgive my short absence....I was left without electricity and Internet for a few days because a short storm. Sergiu has given me the task to implement a fullscreen editing mode, similar to WYSIWYG or WIKI and I thought about it and found several solutions, each one with advantages and disadvantages. I will present them now and I would like to receive some feedback from you, to know which of the solutions (or maybe other solution if none of mines is good enough) will be better. Ideeas for a new way of editing in xwiki (like WYSIWYG and WIKI in FULLSCREEN) --------------------------------------------------------------------------------- Ideea no. 1: A button in the editor itself, like in FCK editor --------------------------------------------------------------------------------- Sample here: http://www.fckeditor.net/demo (the one next to Help button) Advantages: 1. it doesn't need any other graphical implementation in xwiki (like a new tab for instance), because xwiki has already 2 rows of tabs 2. with a good, expressive icon it can be easily spotted by the user 3. it's very easy and intuitive to use, even for a non-initiated user (specially with a tooltip); the user can use tabs to move to the button, if he doesn't have a mouse 4. it can appear anywhere the editor toolbar is needed, therefore allowing full editing for all those cases (not only for wysiwyg and wiki...) 5. can be more impressive with a nice transition animation 6. it covers all the area in xwiki (no elements visible like panels, header etc, otherwise it will not be fullscreen editing, it will be just like the existing WYSIWYG editing mode) 7. by reducing the size of the textarea, the user is brough back to normal wysiwyg editor and has access to other elements in xwiki...like panels... just like in the existing editing mode. Disadvantages: 1. it's depedent of the editor toolbar 2. in order to save or cancel or save and continue, the user has to reduce the size by pressing the same button and then press the submit button(save, cancel...) --------------------------------------------------------------------------------- Ideea no. 2: Two small buttons, in the corner of both WYSIWYG and WIKI editor, just like in Gmail (composing), which opens a new fullscreen window with the editor, the textarea and save, cancel...buttons --------------------------------------------------------------------------------- Advantages: 1. the user can have acces to other xwiki elements (panels...) in the parent window 2. independent of the editor itself 3. pretty intuitive to use Disadvantages: 1. when the new window is opened, the parent window must be redirected to the view mode -> reloading the page 2. if the user clicks cancel, to edit again he must press Edit (WYSIWYG or WIKI) and then press the little button on the tab -> 2 reloadings 3. what happens if the user opens twice the same editor? the modifications from one must be seen in all other open editor -> quite difficult to implement 4. harder to implement 5. a button like this can be placed in each tab (wysiswyg and wiki) and it a new tab is added in xwiki which supports full screen editing, the button has to be place in it too. --------------------------------------------------------------------------------- Ideea no. 3: Resizable textarea --------------------------------------------------------------------------------- Advantages: 1. the user can resize the textarea as much as he wants, not necessarily fullscreen 2. pretty easy to use, but only if the user has a mouse to drag the textarea Disadvantages: 1. the resizing of the textarea can damage the xwiki interface (all the page has to be resized) -> pretty nasty distorsions 2. the user will have to scroll down a lot to see the footer if the textarea is resized a lot. --------------------------------------------------------------------------------- Ideea no. 4: Like the no. 1 except that when pressed, the button will open a floating pane with a nice animation, that will cover about 60% -70% of the page which will contain only a resizable textarea, the editor and the save, cance,..buttons, while the rest of the page will be covered by a translucent blocking background (similar to those which appear when you have to fill in the username and password in order to access something). When the user finishes editing and presses one of the buttons, the panel closes and the text is put back in the tab from which the editor button was pressed (i.e wysiwyg or wiki or other tab that has the editor) --------------------------------------------------------------------------------- Advantages: 1. advantages of no. 1 and the fact that will be more spectaculous (with a nice effect) Disadvantages: 1. same as no. 1 (dependent of editor etc..) So, these are my ideas for now... I would like to know which seems more appealing to you and also, if you have other opinions, ideeas... Thanks, Evelina Slatineanu

18 years

Re: Headless X11 with Xvfb (for running selenium tests without the browser popping up)

by Vincent Massol

Hi catalin, I've checked and yes the selenium plugin we're using is too old. That xvfb support has been added recently. Actually the selenium plugin has been completely rewritten recently (it was in java it's now in groovy... first time I see a maven plugin in groovy). BTW it now supports running HTML selenium tests. I've set up our CI with Raffaello on http://teamcity.xwiki.org and I've discussed the need for an X display. Raffaello is setting up a vncserver which will act as an X server. He prefers this over xvfb as he's more experienced with it and knows it works for sure. I guess we could do the same locally if we wanted. I think the steps are: 1- set up the DISPLAY env variable 2- start vncserver 3- start the selenium RC server 4- launch the browser 5- execute the tests I guess we could integrate steps 1 and 2 in the m2 build in a profile. Of course I think the best solution is http://www.realityqa.com/ realityview.jsp (which I'm working on getting - I've asked Patrick if it's ready to be used) but this vncserver solution would be a nice backup solution in case the realityqa server is down or in offline mode. WDYT? Thanks -Vincent PS: I'm copying the xwiki dev list so that others know what we're working on. On Jun 23, 2007, at 12:30 PM, Catalin Hritcu wrote: > Hi Vincent, > > I was not able to run the tests in headless mode, because I'm getting > a strange error. When you have some time maybe you can have a look. > > So what I did was modify Step 3 in the > xwiki-product-enterprise/distribution-test/pom.xml as documented here: > http://mojo.codehaus.org/selenium-maven-plugin/examples/headless- > with-xvfb.html > Now that part looks like this: > >  > <plugin> > <groupId>org.codehaus.mojo</groupId> > <artifactId>selenium-maven-plugin</artifactId> > <version>1.0-beta-2-SNAPSHOT</version> > <executions> > <execution> > <id>xvfb</id> > <phase>pre-integration-test</phase> > <goals> > <goal>xvfb</goal> > </goals> > </execution> > <execution> > <id>start-selenium</id> > <phase>pre-integration-test</phase> > <goals> > <goal>start-server</goal> > </goals> > <configuration> > <background>true</background> > </configuration> > </execution> > </executions> > <configuration> > <background>true</background> > <multiWindow>true</multiWindow> > </configuration> > </plugin> > > > The error I get is as follows: > catalin-4:~/JavaApps/xwiki-trunks-devs/xwiki-product-enterprise/ > distribution-test > hritcu$ mvn install > [INFO] Scanning for projects... > [INFO] > ---------------------------------------------------------------------- > ------ > [INFO] Building XWiki Products - Enterprise - Functional Tests > [INFO] task-segment: [install] > [INFO] > ---------------------------------------------------------------------- > ------ > [INFO] > ---------------------------------------------------------------------- > -- > [ERROR] BUILD ERROR > [INFO] > ---------------------------------------------------------------------- > -- > [INFO] Failed to construct build plan for: > com.xpn.xwiki.products:xwiki-enterprise-test:pom:1.1-SNAPSHOT ( > task-segment: [install] ). Reason: Mojo: xvfb does not exist in > plugin: org.codehaus.mojo:selenium-maven-plugin:1.0-beta-2-SNAPSHOT. > [INFO] > ---------------------------------------------------------------------- > -- > [INFO] For more information, run Maven with the -e switch > [INFO] > ---------------------------------------------------------------------- > -- > [INFO] Total time: 1 second > [INFO] Finished at: Sat Jun 23 12:22:06 CEST 2007 > [INFO] Final Memory: 6M/11M > [INFO] > ---------------------------------------------------------------------- > -- > [INFO] > ---------------------------------------------------------------------- > -- > [INFO] BUILD SUCCESSFUL > [INFO] > ---------------------------------------------------------------------- > -- > [INFO] Total time: 1 second > [INFO] Finished at: Sat Jun 23 12:22:06 CEST 2007 > [INFO] Final Memory: 6M/11M > [INFO] > ---------------------------------------------------------------------- > -- > catalin-4:~/JavaApps/xwiki-trunks-devs/xwiki-product-enterprise/ > distribution-test > hritcu$ > > > However the documentation says this mojo exists > http://mojo.codehaus.org/selenium-maven-plugin/xvfb-mojo.html > So this is really strange for me. > > I tried deleting the selenium-maven-plugin from the local repository > and the usual stuff but without any result. It gets downloaded again > from the XWiki(!) repository: > > [INFO] snapshot > org.codehaus.mojo:selenium-maven-plugin:1.0-beta-2-SNAPSHOT: checking > for updates from xwiki.plugin.snapshot > [INFO] snapshot > org.codehaus.mojo:selenium-maven-plugin:1.0-beta-2-SNAPSHOT: checking > for updates from xwiki.plugins > [INFO] snapshot > org.codehaus.mojo:selenium-maven-plugin:1.0-beta-2-SNAPSHOT: checking > for updates from xwiki > [INFO] snapshot > org.codehaus.mojo:selenium-maven-plugin:1.0-beta-2-SNAPSHOT: checking > for updates from openqa.org > Downloading: http://maven.xwiki.org/org/codehaus/mojo/selenium- > maven-plugin/1.0-beta-2-SNAPSHOT/selenium-maven-plugin-1.0-beta-2- > SNAPSHOT.pom > 8K downloaded > Downloading: http://maven.xwiki.org/org/codehaus/mojo/selenium- > maven-plugin/1.0-beta-2-SNAPSHOT/selenium-maven-plugin-1.0-beta-2- > SNAPSHOT.jar > 12K downloaded > > Is it possible that the snapshot in the xwiki repository is too old? > Otherwise how do I force it to download from the "official" > repository? > > Regards, > Catalin

18 years

XWiki Eclipse IDE Integration - Milestone 1

by tharindu jayasuriya

Hi All, We have completed milestone-1 of the eclipse xwiki plug-in binary and source (eclipse project) are available via, http://jira.xwiki.org/jira/browse/XWIKI-1360 Implemented features, 1. Login to XWiki 2. Selectively import spaces 3. Navigate through document hierarchy Thanks. - Tharindu

18 years

RE: [xwiki-dev] XWiki Eclipse IDE Integration - Milestone 1

by Kito D. Mann

Thanks for the clarification, Tharindu. Really smart idea! From: tharindu jayasuriya [mailto:djtharindu@gmail.com] Sent: Monday, June 25, 2007 3:32 AM To: kmann(a)virtua.com Subject: Re: [xwiki-dev] XWiki Eclipse IDE Integration - Milestone 1 On 6/25/07, Kito D. Mann <kmann(a)virtua.com> wrote: Tharindu, This looks extremely interesting J . However, I don't quite understand _what_ you'd be doing in Eclipse. Would you use Eclipse for editing and creating pages, Yes, this is the main intension of the plug-in; letting developers manage their documentation within the IDE itself. administration, creating objects and classes, or all of the above? You can add/remove spaces/pages as well as edit/view them within eclipse IDE. But authoring objects or classes will not be possible (yet) since we are using Confluence <http://confluence.atlassian.com/display/DOC/Remote+API+Specification> XMLRPC API which does not have remote methods for such manipulations. But that is a nice feature to have; may be later ... ;-) ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ Kito D. Mann - Author, JavaServer Faces in Action <http://www.virtua.com/> http://www.virtua.com - JSF/Java EE consulting, training, and mentoring <http://www.jsfcentral.com/> http://www.JSFCentral.com - JavaServer Faces FAQ, news, and info * Sign up for the JSF Central newsletter! http://oi.vresp.com/?fid=ac048d0e17 * From: tharindu jayasuriya [mailto:djtharindu@gmail.com] Sent: Saturday, June 23, 2007 7:31 AM To: xwiki-dev(a)objectweb.org Subject: [xwiki-dev] XWiki Eclipse IDE Integration - Milestone 1 Hi All, We have completed milestone-1 of the eclipse xwiki plug-in binary and source (eclipse project) are available via, http://jira.xwiki.org/jira/browse/XWIKI-1360 Implemented features, 1. Login to XWiki 2. Selectively import spaces 3. Navigate through document hierarchy Thanks. - Tharindu -- You receive this message as a subscriber of the xwiki-dev(a)objectweb.org mailing list. To unsubscribe: mailto: xwiki-dev-unsubscribe(a)objectweb.org For general help: mailto: <mailto:sympa@objectweb.org> sympa(a)objectweb.org?subject=help ObjectWeb mailing lists service home page: http://www.objectweb.org/wws

18 years

XWiki-Eclipse Integration

by tharindu jayasuriya

Hi All, We ( myself and Asiri ) have implemented the logging and xwiki navigation components of the above plug-in. We have tested the components on a local installation but need a remote url (confluence) to test it further. We tried to connect to www.xwiki.org using our usernames and passwords but could not connect ( verfied with XMLRPCExample too ). Is it not possible to connect to www.xwiki.org with XML RPC ? if it is possible, can any of you give us the correct url ? One more thing, the XMLRPCExample uses the server url http://<server>/xwiki/xmlrpc/confluence. We followed the same convention and get user input for the <server> part only (append the rest). Is it ok to do this ? or shall we let the user to provide whole url ? Thanks a million. - Tharindu & Asiri

18 years

What happened with build.xml

by evelyne24＠gmail.com

Hello, I updated yesterday my xwiki sources and I see you've changed all the svn directories. The problem is that when I try to build it in Eclipse I can't find the build.xml file and also, I create a new project based on xwiki-platform-core and it gives me lots of errors in eclipse, like some files missing or some classes not found. Can anyone tell me how to build the standalone now that there is no build file? I would very much appreciate it. Thank you. Evelina

18 years

Big problem with building the xwiki-platform-core

by evelyne24＠gmail.com

Hello, Sorry if this mail arrives twice...I sent one in the morning but no reply so...I guess no one's got it. The problem is that after this change in the svn repository I can't build the xwiki-platform-core in Eclipse. There is no build.xml file and there are a lot of errors when I create a new project based on xwiki-platform-core directory (lots of libraries missing and othes errors). Sergiu has been trying to help me since this morning, but unfortunately it still doesn't work. I tried with mvn, in order to build the war and then put in the tomcat or jetty but when I run mvn install in the xwiki=platform-core directory I get a lot of errors, like D:\XWiki\src2\xwiki-platform-core>mvn install [INFO] Scanning for projects... [INFO] ------------------------------------------------------------------------ [ERROR] FATAL ERROR [INFO] ------------------------------------------------------------------------ [INFO] Error building POM (may not be this project's POM). Project ID: null:xwiki-core:jar:1.1-SNAPSHOT Reason: Cannot find parent: com.xpn.xwiki:xwiki for project: null:xwiki-core:jar :1.1-SNAPSHOT for project null:xwiki-core:jar:1.1-SNAPSHOT [INFO] ------------------------------------------------------------------------ [INFO] Trace org.apache.maven.reactor.MavenExecutionException: Cannot find parent: com.xpn.xw iki:xwiki for project: null:xwiki-core:jar:1.1-SNAPSHOT for project null:xwiki-c ore:jar:1.1-SNAPSHOT at org.apache.maven.DefaultMaven.getProjects(DefaultMaven.java:378) at org.apache.maven.DefaultMaven.doExecute(DefaultMaven.java:290) at org.apache.maven.DefaultMaven.execute(DefaultMaven.java:125) at org.apache.maven.cli.MavenCli.main(MavenCli.java:280) at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl. java:39) at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAcces sorImpl.java:25) at java.lang.reflect.Method.invoke(Method.java:597) at org.codehaus.classworlds.Launcher.launchEnhanced(Launcher.java:315) at org.codehaus.classworlds.Launcher.launch(Launcher.java:255) at org.codehaus.classworlds.Launcher.mainWithExitCode(Launcher.java:430) at org.codehaus.classworlds.Launcher.main(Launcher.java:375) Caused by: org.apache.maven.project.ProjectBuildingException: Cannot find parent : com.xpn.xwiki:xwiki for project: null:xwiki-core:jar:1.1-SNAPSHOT for project null:xwiki-core:jar:1.1-SNAPSHOT at org.apache.maven.project.DefaultMavenProjectBuilder.assembleLineage(D efaultMavenProjectBuilder.java:1261) at org.apache.maven.project.DefaultMavenProjectBuilder.buildInternal(Def aultMavenProjectBuilder.java:747) at org.apache.maven.project.DefaultMavenProjectBuilder.buildFromSourceFi leInternal(DefaultMavenProjectBuilder.java:479) at org.apache.maven.project.DefaultMavenProjectBuilder.build(DefaultMave nProjectBuilder.java:200) at org.apache.maven.DefaultMaven.getProject(DefaultMaven.java:553) at org.apache.maven.DefaultMaven.collectProjects(DefaultMaven.java:467) at org.apache.maven.DefaultMaven.getProjects(DefaultMaven.java:364) ... 11 more Caused by: org.apache.maven.project.ProjectBuildingException: POM 'com.xpn.xwiki :xwiki' not found in repository: Unable to download the artifact from any reposi tory etc..... I have no access to svn://svn.forge.objectweb.org/svnroot/xwiki/trunks-devs (apparently Sergiu is not getting this errors but he's using this while I'm using svn://svn.forge.objectweb.org/svnroot/xwiki/trunks-users ) So, if anyone has succeeded in building the xwiki after the change in the svn directory, please help me, I'm in big trouble and I can' continue working. Thank you very much. Evelina

18 years

[Proposal] Switch to using Maven2

by Vincent Massol

Hi, I'd like to propose 2 things: 1) Use Maven2 to perform the 1.1M3 release 2) Remove the Ant build in 1.1M4 Rationale: * It's a real pain to maintain 2 builds * The m2 build is already doing more than the Ant build Things left to do on the m2 build: * Finish setting up TeamCity (I need Raffaello's help as ObjectWeb's SVN is bad and we need to set up a SVN ready only replicate on which we could plug TC) * Fix an issue with the database importer (XWIKI-1104) * Review the versions of the dependencies What this means is that you should try using Maven 2 yourself from today onward and see if can make it work. If not, ask questions here on the list and I'll help and I'll tune the build accordingly. There's already some doc on: http://www.xwiki.org/xwiki/bin/view/Community/ Building#HBuildingwithMaven2 WDYT? Thanks -Vincent

18 years

[XWIKI-1390]: "Sample mode" for PanelWizard

by Erin Schnabel

I was talking to Vincent about this on IRC, and he suggested that I open a jira issue, and send an email to the list, so here it is. When loading the PanelWizard against a fairly large XWiki, the page can take a fairly long time to load. Vincent and I talked about a few approaches: Adding a "Sample mode" field to the Panels, where the panels would render themselves w/ sample/dummy data to avoid queries to the DB. The PanelWizard would then have to somehow display these panels in "sample" mode. The other is to skip rendering of all of the panels entirely: list the title, links to edit/delete and provide a some kind of new button to "display panel" or "display panel contents", which would defer panel loading until requested... This collapsed view would apply to the drag-n-drop off to the sidebars as well... Thoughts? -- 'Waste of a good apple' -Samwise Gamgee

18 years

Jump to page:

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

2005

xwiki-devs