July 2007 - xwiki-devs@xwiki.org

Build Tip: offline mode
by Vincent Massol 06 Jul '07

06 Jul '07

A new very useful tip: http://www.xwiki.org/xwiki/bin/view/Community/ Building#HBuildingasinglemodule Thanks -Vincent

1 0

Thoughts about the ID assigned to documents, etc.
by Erin Schnabel 05 Jul '07

05 Jul '07

Now, I've sent about 4 of these to the dev list, and they'll probably all show up at once in a week. *sigh* I am a big proponent of the principles of this bug: http://jira.xwiki.org/jira/browse/XWIKI-1021 I don't think the whole ID scheme currently used should be thrown out, however, as it might break anyone with an existing XWiki installation of any size (which I have). I would like to see the following: a) go ahead and use a hash of the name to find an initial ID b) increment the number if necessary to ensure it's unique. c) stay with that ID, period. Don't change it when something is renamed, etc. I've been seeing some issues with renames where the name hash collides, or all of the attachments associated with an ID aren't updated correctly (so the attachments effectively "disappear"..) There is no reason to keep the ID associated with a hash of the name, as the initial lookup is almost always based on the document's name... I think this is pretty important, especially with document renaming now possible. I was talking to Vincent about this, and I'll see if I can find a patch. This also seems to line up with a Google Summer of Code item: http://www.xwiki.org/xwiki/bin/view/GoogleSummerOfCode/Storage+Improvements Erin -- Waste of a good apple. --Samwise Gamgee

1 0

[help] XWiki-Eclipse-Plugin
by tharindu jayasuriya 05 Jul '07

05 Jul '07

Hi All! We have been implementing the editing part of the above plug-in and came across a little problem. Basically the editor (inside eclipse work-bench) consists of two tabs; one for editing the XWiki markup and the other for viewing the results. The XWiki markup editor tab is quite ok ( may be we can worry about some syntax highlighting later on), this is shown in edit_view.png ( see attachment ). But the problem is with rendered out put. output_view_1.png shows the output from a browser widget (using the URL of the page being edited). Here the problem is that navigation panel is repeated, one in XWiki Navigator (Plug-in component) and the other one in the browser itself (a.k.a in web page). output_view_2.png shows the output rendered with the renderContent() (refer to Confluence XML RPC API<http://confluence.atlassian.com/display/DOC/Remote+API+Specification>) method. Here the problem is that we only get a basic html output which is ugly. Ideally we should have the browser output (output_view_1.png) without the navigation panel. We're currently stuck here unable to make a decision or find an alternative method. So, any help would be really appreciated. Thanks - Tharindu & Asiri PS : We have formatted the code into standards but still working on the Maven2 build l, will finish it soon.

5 5

Thoughts about the ID assigned to documents, etc.
by Erin Schnabel 05 Jul '07

05 Jul '07

I am a big proponent of the principles of this bug: http://jira.xwiki.org/jira/browse/XWIKI-1021 I don't think the whole ID scheme currently used should be thrown out, however, as it might break anyone with an existing XWiki installation of any size (which I have). I would like to see the following: a) go ahead and use a hash of the name to find an initial ID b) increment the number if necessary to ensure it's unique. c) stay with that ID, period. Don't change it when something is renamed, etc. I've been seeing some issues with renames where the name hash collides, or all of the attachments associated with an ID aren't updated correctly (so the attachments effectively "disappear"..) There is no reason to keep the ID associated with a hash of the name, as the initial lookup is almost always based on the document's name... I think this is pretty important, especially with document renaming now possible. I was talking to Vincent about this, and I'll see if I can find a patch. This also seems to line up with a Google Summer of Code item: http://www.xwiki.org/xwiki/bin/view/GoogleSummerOfCode/Storage+Improvements Erin -- 'Waste of a good apple' -Samwise Gamgee

1 0

[RFC] minor edit feature
by Artem Melentyev 05 Jul '07

05 Jul '07

Hi. I work on minor edit feature (http://en.wikipedia.org/wiki/Minor_edit) http://jira.xwiki.org/jira/browse/XWIKI-1447 (patches attached) I would like to hear your opinions about it. Here is my solution: The major change is document versioning: major document edits(default) increase 1st version number (1.2->2.1) minor document edits(selected by checkbox) increase 2nd version number (2.1->2.2) New checkbox "Minor edit" will be added to document edit form Minor changes will be hidden in history UI by default (Show only latest minor versions before major version. ex: 1.2, 2.1, 3.3) It will be stored as normal changes with special mark (doc.isMinorEdit) Adding objects,attachments,comments,rights to document is minor changes. Implementation is like XWIKI-114 1. Is it OK, to change document versioning? Or how to mark minor changes otherwise? 2. How edit and history UI would be? (you may see My UI in patches, attached to jira issue or at http://212.193.74.172/xwiki/bin/view/Main/WebHome ) -- Artem Melentyev

1 0

Is the Maven2 build for Curriki ok?
by Vincent Massol 05 Jul '07

05 Jul '07

Hi Curriki developers, I haven't worked on Curriki so I'm not the best person placed to verify if the new Maven2 build works fine. Could someone check that all is fine? Thanks -Vincent

1 0

XEM releases?
by Vincent Massol 05 Jul '07

05 Jul '07

Hi, JIRA says XEM 1.0M1 should be released on 14th of June and 1.0M2 on 29th of June. Obviously JIRA is lying! :) JV, you're the Release Manager for XEM. Could you please let us know the new dates and update JIRA accordingly? (or remove any date if we don't know...) Thanks -Vincent

1 0

Questions about the ID assigned to documents, etc.
by Erin Schnabel 05 Jul '07

05 Jul '07

I am a big proponent of the principles of this bug: http://jira.xwiki.org/jira/browse/XWIKI-1021 I don't think the whole ID scheme currently used should be thrown out, however, as it might break anyone with an existing XWiki installation of any size (which I have). I would like to see the following: a) go ahead and use a hash of the name to find an initial ID b) increment the number if necessary to ensure it's unique. c) stay with that ID, period. Don't change it when something is renamed, etc. I've been seeing some issues with renames where the name hash collides, or all of the attachments associated with an ID aren't updated correctly (so the attachments effectively "disappear"..) There is no reason to keep the ID associated with a hash of the name, as the initial lookup is almost always based on the document's name... I think this is pretty important, especially with document renaming now possible... -- 'Waste of a good apple' -Samwise Gamgee

1 2

[ANN] XWiki Top level POM and XWiki Platforms tools released
by Vincent Massol 05 Jul '07

05 Jul '07

Hi, Just to inform you that I have released the following packages: - XWiki Top Level POM in version 1 - XWiki Platform Tools in version 1.0 All using Maven2 (a first for XWiki ;)). They are available in our new release repo at http://maven.xwiki.org/releases/ Thanks -Vincent

1 0

Adding stuff to Maven build to create a plugin
by Radu Danciu 05 Jul '07

05 Jul '07

I've been told that the Google Docs functionality should be built as a plugin, yet there is no documentation about building plugins for xwiki. I need to start adding code to the build to test it, but I need to know how I should go about it. Also, what was the decision regarding the migration to JDK 1.5? I need to add some libs to the build that require it. The libs are provided by google as source that is supposed to be built, and then the jars imported, which I'm told Maven can handle... how? I'd like it if somebody could take the time guide me through the process. Thanks, Radu

2 2