Hi,
I too wish to checkout the source code of xwiki and build the application
from it.
Could anyone please tell me the svn url for the same.
I tried accessing the old links pasted in this forum for the same ie:
http://www.xwiki.org/xwiki/bin/view/Community/SourceRepositoryhttp://www.xwiki.org/xwiki/bin/view/Community/Building
but since the xwiki site has been migrated to new version, these links are
not longer reachable.
It would be great if someone can get these links back up or tell what are
the new links to access the content under these.
Thanks
Sachin
SAi Kumar wrote:
>
> Hi,
> I am new to Xwiki.I need Xwiki source code to build and Xwiki application.
> Can you tel me where can i download the following modules
> xwiki-platform-tools
> xwiki-platform-core
> xwiki-platform-web
> xwiki-platform-plugins
> xwiki-platform-applications
> xwiki-product-enterprise
> xwiki-product-enterprise-manager
> xwiki-product-curriki
>
> Thanks in Advance,
> Saikumar B
>
--
View this message in context: http://www.nabble.com/Where-to-get-the-Xwiki-source-code.--tp13080439p14370…
Sent from the XWiki- Dev mailing list archive at Nabble.com.
Hi Sergiu,
Shouldn't this have been a new migrator instead? Artem had a comment
about leaving the old XWD_ARCHIVE column in the document table. Lots
of users have already executed this migrator so they won't execute
this. So if it's important to have everyone in the same state, I think
a new migrator would be maybe better. But then, maybe it's not
important?
Thanks
-Vincent
On Dec 14, 2007, at 2:14 PM, sdumitriu (SVN) wrote:
> Author: sdumitriu
> Date: 2007-12-14 14:14:08 +0100 (Fri, 14 Dec 2007)
> New Revision: 6377
>
> Modified:
> xwiki-platform/core/trunk/xwiki-core/src/main/java/com/xpn/xwiki/
> store/migration/hibernate/R4359XWIKI1459Migrator.java
> Log:
> XWIKI-1954: When migrating the document archive format from 1.1 to
> 1.2, delete the contents of the old XWD_ARCHIVE field
> Fixed.
>
>
> Modified: xwiki-platform/core/trunk/xwiki-core/src/main/java/com/xpn/
> xwiki/store/migration/hibernate/R4359XWIKI1459Migrator.java
> ===================================================================
> --- xwiki-platform/core/trunk/xwiki-core/src/main/java/com/xpn/xwiki/
> store/migration/hibernate/R4359XWIKI1459Migrator.java 2007-12-14
> 13:08:02 UTC (rev 6376)
> +++ xwiki-platform/core/trunk/xwiki-core/src/main/java/com/xpn/xwiki/
> store/migration/hibernate/R4359XWIKI1459Migrator.java 2007-12-14
> 13:14:08 UTC (rev 6377)
> @@ -19,6 +19,7 @@
> */
> package com.xpn.xwiki.store.migration.hibernate;
>
> +import java.sql.PreparedStatement;
> import java.sql.ResultSet;
> import java.sql.SQLException;
> import java.sql.Statement;
> @@ -88,7 +89,7 @@
> Statement stmt =
> session.connection().createStatement();
> ResultSet rs;
> try {
> - rs = stmt.executeQuery("select XWD_ID,
> XWD_ARCHIVE, XWD_FULLNAME from xwikidoc");
> + rs = stmt.executeQuery("select XWD_ID,
> XWD_ARCHIVE, XWD_FULLNAME from xwikidoc where XWD_ARCHIVE is not
> null order by XWD_VERSION");
> } catch (SQLException e) {
> // most likely there is no XWD_ARCHIVE
> column, so migration is not needed
> // is there easier way to find what column
> is not exist?
> @@ -97,6 +98,7 @@
> Transaction originalTransaction =
> ((XWikiHibernateVersioningStore
> )context.getWiki().getVersioningStore()).getTransaction(context);
>
> ((XWikiHibernateVersioningStore
> )context.getWiki().getVersioningStore()).setSession(null, context);
>
> ((XWikiHibernateVersioningStore
> )context.getWiki().getVersioningStore()).setTransaction(null,
> context);
> + PreparedStatement deleleteStatement =
> session.connection().prepareStatement("update xwikidoc set
> XWD_ARCHIVE=null where XWD_ID=?");
>
> while (rs.next()) {
> if (logger.isInfoEnabled()) {
> @@ -104,13 +106,13 @@
> }
> long docId = Long.parseLong(rs.getString(1));
> String sArchive = rs.getString(2);
> - if (sArchive==null) {
> - continue;
> - }
> XWikiDocumentArchive docArchive = new
> XWikiDocumentArchive(docId);
> docArchive.setArchive(sArchive);
>
> context
> .getWiki().getVersioningStore().saveXWikiDocArchive(docArchive,
> true, context);
> + deleleteStatement.setLong(1, docId);
> + deleleteStatement.executeUpdate();
> }
> + deleleteStatement.close();
> stmt.close();
>
> ((XWikiHibernateVersioningStore
> )context.getWiki().getVersioningStore()).setSession(session, context);
>
> ((XWikiHibernateVersioningStore
> )context
> .getWiki().getVersioningStore()).setTransaction(originalTransaction,
> context);
>
> _______________________________________________
> notifications mailing list
> notifications(a)xwiki.org
> http://lists.xwiki.org/mailman/listinfo/notifications
Hi,
I spent most of today profiling XWiki, and here is a summary of my findings.
First, I tested the following three situations:
(1) Creating many documents with 500 versions each, using XWiki 1.1
(2) Updating those documents to XWiki 1.2
(3) Creating many documents with 500 versions each, using XWiki 1.2
(1) spent most of the time in Hibernate and RCS. And by most, I mean
almost all time. For rcs, each new version required parsing all the
history, adding the new version, reserializing the history. And the RCS
implementation we're using (org.suigeneris.jrcs) seems very inefficient,
a lot of calls ending at charAt, substring, split. And since each update
requires sending all the history back, the rest of the time was spent in
hibernate, sending large strings to mysql. Creating one document with
all its 500 versions takes several minutes.
(2) spent most of the time doing one thing: parsing the old RCS archive.
Still, a lot less time was spent in Hibernate, about 2% of all the
execution time, as opposed to 80% in (1). Updating one 500 versions long
archive took 6 seconds. Updating a 300 version document takes 2 seconds,
while a document with one version is almost instantly updated.
(3) spends incredibly much less time in rcs, as expected (1% of all the
running time). So the new archive mechanism is a major performance
boost. Instead, most of the time is spent in saveBacklinks, which goes
to Radeox. This is even more serious, given the fact that the document
content was very small (200 random characters). I'd say that a major
flaw is that the backlinks gathering process uses the radeox engine with
all the filters and macros enabled, while all we need is the links
filter. Here, creating a document requires a few seconds (2-3).
From the remaining (little) time that is left, a big part is consumed
with document cloning. See http://jira.xwiki.org/jira/browse/XWIKI-1950
for this. This is true both for XWiki 1.1 and 1.2.
On the database performance, beside the fact that Hibernate is slow, too
much time is spent on saveOrUpdate. It seems that instead of checking
the document object to see if it needs to be saved or updated, Hibernate
retrieves the document from the database and compares the retrieved
versions with the provided object to see if it is a new object that
needs to be inserter or an existing one that needs updating.
As a total for (3): 90% of the time is spent in saveDocument, of which
38% in saveLinks (most of which is spent in radeox), 22% in
hibernate.saveOrUpdate, 16% in hibernate.endTransaction (actual saving
of the document to the database) and 13% in updateArchive.
Thus, gathering backlinks with only one filter enabled will probably
reduce 35% of the running time, and improving the calls to saveOrUpdate
will give another 10-20%.
Remarks:
- This shows only the performance when saving documents, so I will need
another day to test the performance on view. I'd say that most of the
time will be spent in radeox, parsing the wiki content.
- As it is known, observing a process modifies it. All the numbers would
probably be (a little) different under real usage, without a profiler
sniffing everything.
Sergiu
Hi all,
I made a tool to easily manage wiki class and wiki class's objets bundled in
application manager some times ago. Problem is theses tools changed since
it's creation and new has very wrong names and I would like to rename it.
There is two java classes :
- SuperClass : manage wiki class with it's attached document/sheet/template
(assume the wiki class exist in the wiki we working on) and give methods to
search, etc. in documents containing objects of this class
- SuperDocument : the default implementation overload Document and manage
one object of a particular wiki class in its document (to be able to save or
delete it), this class is generally overloaded to add some acces methods
like getDocuments() in Application java class.
These tools are also usable from Velocity.
For some examples you can view Application Manager plugin (Application and
ApplicationClass classes) and Wiki Manager plugin (XWikiServer and
XWikiServerClass classes).
I propose :
- SuperClass -> ClassManager
- SuperDocument -> ObjectDocument (or ObjectManager but i don't like it
because it does not imply object in a document)
--
Thomas Mortagne
Hi all,
Currently XWiki right service does not allow users that are not creators
of a document to delete it with only the "delete" right allowed on that
document, they must, to be able to actually delete it, have the "admin"
right allowed.
This is not totally clear to me if it is the behaviour we should expect,
but I would tend to say no, for two reasons :
* The delete right is a specific right entry, so it should provide what it
says : the right to delete. It is different from edit, so you can share
edition on (your) documents with your fellow co-workers, without
necessarily allowing them to delete those, and using this right entry, you
can also allow users & groups to delete documents without giving them the
"admin" right (which would allow them to program in groovy for example).
* For a document that hasn't been created by me, but on which I've got the
delete right (for example inherited from the space or wiki level), if I'm
not an admin (do not have the "admin" right) and I call
$doc.hasAccessLevel("delete"), the API will answer "true", but I won't be
able to actually delete the doc, which is misleading.
I've created a JIRA (http://jira.xwiki.org/jira/browse/XWIKI-1944) issue
for this and will provide a possible patch, please tell me what you think,
so that we can decide if indeed we can allow non-creators to delete
documents provided they have the delete right.
Thanks,
Jerome.
Hi,
In one of your tutorials (referencing FAQ application) you have shown how to
create custom classes, add properties to it and create objects of these
classes.
This was well understood and thanks for the easy to understand tutorial.
Following the steps I create a space called aeternam and added a page
SupplierClass under it.
Further I create a page "Suppliers" under aeternam space, on which I pasted
the velocity template code to create objects of the SupplierClass and view
create objects.
All works fine. Only problem is the objects are created under the parent
SupplierClass and not under parent Suppliers.
I have explicitly mentioned the parent using the code:
#set( $class = "Supplier")
#set( $defaultparent = "Suppliers")
#set( $defaultweb = "aeternam")
#set( $doc1new =
$xwiki.getDocument("${doc.space}.${class}ClassSheet").isNew())
#set( $doc2new =
$xwiki.getDocument("${doc.space}.${class}ClassTemplate").isNew())
#if (!($doc1new||$doc2new))
1.1 Create a new Supplier
To create a new supplier, you should first choose a name for your supplier.
<form action="" id="newdoc" method="post">
<div>
<input type="hidden" name="parent" value="${defaultparent}"/>
<input type="hidden" name="template"
value="${doc.web}.${class}ClassTemplate"/>
<input type="hidden" name="sheet" value="1"/>
Space: <input type="text" readonly="true" name="webname"
value="${defaultweb}" size="8"/>
Supplier: <input type="text" name="name" value="Supplier Name"/>
<br/>
<br/>
## TODO: remove this onclick
<input type="button" value="Create this supplier" onclick='if
(updateName(this.form.name)) {this.form.action="../../inline/" +
this.form.webname.value + "/" + this.form.name.value; this.form.submit();
}'/>
</div>
</form>
1.1 Existing Suppliers
#set ($sql = ", BaseObject as obj where obj.name=doc.fullName and
obj.className='${doc.web}.${class}Class' and
obj.name<>'${doc.web}.${class}ClassTemplate'")
#foreach ($item in $xwiki.searchDocuments($sql))
* [$item]
#end
#end
So what do I have to do to create objects of a class under some other parent
page not under the default class page.
Next after a document object is created I would like to update the same
document, just like in create is there a template or tutorial that would
help me in understanding how to update a object, so as to complete the CRUD
flow.
Thanks
Sachin
--
View this message in context: http://www.nabble.com/Creating-structured-objects-tp14268015p14268015.html
Sent from the XWiki- Dev mailing list archive at Nabble.com.
Hi,
I'm trying to use XEclipse with https, does this work under the covers
and just not exposed in the UI?
Thanks,
Jason
----------------------------------------------------------
Jason van Zyl
Founder, Apache Maven
jason at sonatype dot com
----------------------------------------------------------
We all have problems. How we deal with them is a measure of our worth.
-- Unknown
Hi everyone,
We now have a new version of the xwiki.org web site up and running on http://xwiki.org
Let us know if you find any issue.
I'd like to thank the following persons who helped:
- Laurent Lunati for the skin
- Thomas Mortagne for helping me with the migration
- Guillaume Lerouge also for helping with the migration
- Raffaello for the admin part
I really like the new site, hope you'll like it too :)
-Vincent, on behalf of the xwiki dev team
Now my objects are persistents. But i don't know how to access their
properties.
Should i create an annotation class through the XWiki class editor?
It seems that in my database, none of the properties of my annotations
are stored.
I define an annotation for a document:
$xwiki.annotation.addNewAnnotation($doc,"blablablaAnnotation",0,10,"blablaSelection","auteur")
I retrieve all annotations of a document:
#set($annots=$doc.getObjects("annotation"))
And i try to get the selection field of my annotations:
#foreach($annot in $annots)
"$annot.get("selection")"
#end
But all i have is "".
What should i do?
--
Antoine SEILLES
Doctorant (phd student)
Pikko software
Cap Omega - Rond Point Benjamin Franklin
CS 39521
34960 Montpellier Cedex 2
FRANCE
LIRMM CNRS
UMR 5506 - 161 rue Ada
34392 Montpellier Cedex 5
FRANCE
Tel: +33 (0)6 10 192 055
http://www.pikko-software.comhttp://www.lirmm.fr
On Dec 11, 2007, at 10:35 AM, BOUSQUET Jeremie wrote:
> Hi,
>
> The new web site is really fine, and the virtual wiki mngt is very
> interesting ... ;)
>
> I'd like just to signal a rights management problem (I guess), as
> guest I can browse all virtual wikis from home page, but if I log in
> with my account I have no rights at all on pages in XWiki Watch
> wiki ... I still have rights on other wikis.
ok fixed, thanks.
-Vincent
> -----Original Message-----
> From: users-bounces(a)xwiki.org [mailto:users-bounces@xwiki.org] On
> Behalf Of Vincent Massol
> Sent: lundi 10 décembre 2007 20:55
> To: XWiki Users
> Cc: XWiki Developers
> Subject: [xwiki-users] New xwiki.org web site
>
> Hi everyone,
>
> We now have a new version of the xwiki.org web site up and running
> on http://xwiki.org
>
> Let us know if you find any issue.
>
> I'd like to thank the following persons who helped:
>
> - Laurent Lunati for the skin
> - Thomas Mortagne for helping me with the migration
> - Guillaume Lerouge also for helping with the migration
> - Raffaello for the admin part
>
> I really like the new site, hope you'll like it too :)
>
> -Vincent, on behalf of the xwiki dev team
>
> _______________________________________________
> users mailing list
> users(a)xwiki.org
> http://lists.xwiki.org/mailman/listinfo/users
> _______________________________________________
> users mailing list
> users(a)xwiki.org
> http://lists.xwiki.org/mailman/listinfo/users
My colleague and I have a Table of Contents within the Show/Hide snippet (code below) but would like the cursor to change to the pointed finger when the user rolls over the statement "Click here to show/hide Table of Contents". Any ideas? Thanks in advance. Chris
<div id="DIV ID" class="hidden">*__Table of Contents__*#toc("" "" "")</div><div onclick="toggleClass($('DIV ID'), 'hidden')">Click here to show/hide Table of Contents</div>
_________________________________________________________________
Your smile counts. The more smiles you share, the more we donate. Join in.
www.windowslive.com/smile?ocid=TXT_TAGLM_Wave2_oprsmilewlhmtagline
Hi,
As previously proposed, today (Friday 7th) is the planned day for the
second (and hopefully last) 1.2 Release Candidate. If there are no
critical bugs discovered, this release will be promoted as 1.2 next week.
Thanks,
Sergiu and my +1
Hi,
We should reintroduce the Resolved state in the issue workflow, and it
should work like this:
- When closing an issue, it will go in the Resolved state, which means
that somebody provided a fix and it is committed in the repository.
- Somebody else can test (manually) that the issue is indeed
fixed/implemented, and it works as expected. If no, then it goes back
to Open, otherwise it goes to Verified.
- When all the needed tests and documentation are written, the issue
can be closed completely, entering the Closed state.
This should improve the way we write code, meaning that we don't just
commit some quick fix code which nobody sees, and claim that the issue
is fixed. Right now we're trying to do peer reviewing either by first
attaching patches to the issue and have somebody review it, or by
hoping that someone is reading the commit mails and notices if
something is wrong. We should never make a release that has issues in
the Resolved state, as it has unverified code, probably with missing
documentation and proper tests. We should reserve a few days before
each release for moving any Resolved issue to the Closed state, by
verifying, testing and documenting it.
Verifying issues can be done by outsiders, too, so we could involve
the community more. Perhaps it would be a good idea to require two
verifiers before moving the issue to verified, as testing on different
systems can spot some bugs, like the full screen editor not working in
Safari issue.
Sergiu
--
http://purl.org/net/sergiu
Well, my annotation plugin is in progress.
I join my new version.
Now i can add annotation to doc but this is not permanent. :'(
I have another problem, i did annotations.vm and annotationsinline.vm
templates to list annotations of a document.
Well, i don't understand how to acces attributes of my annotations to
display them.
If someone can help, please.
antoine SEILLES a écrit :
> Hi
> i'm doing an annotation plugin and i need some help.
>
> An annotation is a comment linked to a document (like a XWikiComment).
> More precisely, an annotation is linked to a selected part of a document.
>
> My objective is to get something like in attached picture (.jpg).
>
> I have created three classes for my plugin (view attached pieces)
> inspired of helloworldplugin and XWikiComment class.
>
> What i need is:
> * to create an annotation.
> * to add an annotation to a document
> * to modify an annotation
> * to delete an annotation
> * to list annotations linked to a document
>
> If someone had some advices.
> Thank
>
>
> ------------------------------------------------------------------------
>
--
Antoine SEILLES
Doctorant (phd student)
Pikko software
Cap Omega - Rond Point Benjamin Franklin
CS 39521
34960 Montpellier Cedex 2
FRANCE
LIRMM CNRS
UMR 5506 - 161 rue Ada
34392 Montpellier Cedex 5
FRANCE
Tel: +33 (0)6 10 192 055
http://www.pikko-software.comhttp://www.lirmm.fr
###
### Annotations page in the "view" mode
###
###
<h2>$xwiki.parseMessage("viewannotationstitle")</h2>
#template("annotationsinline.vm")
###
### List document annotations
###
### TODO: web service?
###
#if($xwiki.getWebPreferenceAsInt("commentsorder",1)==1)
#set($annotations = $xwiki.annotation.getAnnotations($doc))
#end
<div id="annotationscontent" class="xwikiintracontent">
#if($inline && ($inline == true)) <div class="xwikititlewrapper" onclick="toggleClass($('annotations'), 'hidden'); toggleClass($('annotationscontent'), 'exp')"><h3 class="xwikiintratitle">$msg.get("annotations")<span class="hidden">:</span> <span class="annotationsno"><span>$annotations.size()</span></span></h3></div>#end
<div id="annotations">
#if($annotations.size()>0)
#foreach($annotation in $annotations)
#if($velocityCount > 1) <hr class="annotationspacer"/>
#end
<div id="xwikiannotation_${velocityCount}" class="xwikiannotation #if($velocityCount % 2 == 1) odd #else even #end">
## <div class="annotationavatar">#useravatar($annotation.getAuthor())</div>
<div class="annotationheader"><span class="annotationauthor">$!xwiki.getLocalUserName($doc.display('author','view', $annotation))</span>
## #set($date = $doc.display("date","view",$annotation))
#set($date = $xwiki.annotation.getCreationDate($annotation).value)
#if($date)
| <span class="annotationdate">$xwiki.formatDate($date, "dd.MM.yyyy") $msg.get("at") $xwiki.formatDate($date, "hh:mm a")</span>
#end
#if($hasedit) <span class="annotationdelete"><a class="annotationremove" href="$doc.getURL("objectremove" , "classname=XWiki.XWikiAnnotations&classid=${annotation.number}&xredirect=${request.getRequestURL()}")"
onclick="return confirm('$msg.get("confirmannotationremove")')">[$msg.get("removethisannotation")]</a></span>#end
</div>
<div class="annotationcontent">$doc.getRenderedContent($doc.display("content","view",$annotation)) </div>
</div>
#end
#else
$msg.get("noannotations")
#end
</div> ## annotations
</div> ## annotationscontent
#if($inline && ($inline == true))
<script type="text/javascript">
//<!--
if(document.getElementById("annotationform")) {
document.getElementById("annotationform").className = "collapsed";
}
document.getElementById("annotations").className += " hidden";
//-->
</script>
#end
The XWiki Watch development team is pleased to announce the release of
XWiki Watch 1.0 Milestone 2.
You can grab it here :
http://www.xwiki.org/xwiki/bin/view/Main/Download#HXWikiWatch
Reminder : XWiki Watch is a collaborative RSS/Atom feed reader that allows
teams to read, tag, comment and flag articles in a AJAX/GWT interface
integrated inside the wiki. Features include also filtering, text
analysis, press reviews generation, English and French user interfaces,
and more! Note that Watch is delivered as a full Watch+Wiki or as a XAR
package installable in a standard XWiki 1.1 or 1.2
This release include both bug fixes and new features, among which you can
find :
- A Wiki integration : now every data collected/created (feeds, fetched
feed articles, tags, keywords and groups) through the AJAX/GWT UI is
accessible via classical XWiki pages
- UI improvements/bugfixes : Editing and deleting feeds is easier,
filtering both keywords + groups has been fixed, the feed tree does not
collapse unexpectedly anymore
- A m2 build matching the XWiki development process : now developers can
build XWiki Watch with a single line command
- Other bug fixes and improvements
You can read the full release notes at:
http://www.xwiki.org/xwiki/bin/view/Main/ReleaseNotesWatch10M2
And the installation guide :
http://www.xwiki.org/xwiki/bin/view/Code/Watch
Have fun!
The XWiki Watch development team
Here's the result:
* 3 +1 (+1 non binding vote from Anca)
* 0 0
* 0 -1
I will make it on trunk after 1.2 branch and 1.2 first RC release
(planned for this Friday). So this will be the first new 1.3 feature
:)
2007/11/22, Thomas Mortagne <thomas.mortagne(a)xwiki.com>:
> Hi all,
>
> Having xwiki document with no extension in the files names is a real
> mess for subversion and IDEs like Eclipse and IntelliJ IDEA and it
> will also be very useful in any editor that takes extension to
> determine the content or simply for most OS Explorers/Finders.
>
> As the XWiki maven xar plugin now support files with any name when
> creating the xar package (see
> http://jira.xwiki.org/jira/browse/XTOOLS-19) I propose to add .xml
> extension to exported document files names.
>
> Import document with any names is already supported by xwiki core
> importer plugin since at least svn1387 (October 2006) and I think
> since it's creation so it seems it will not break older version
> import.
>
> --
> Thomas Mortagne
>
--
Thomas Mortagne
Result of the vote : 7 +1, no 0, no -1 :
* Jérôme +1
* Vincent +1
* JV +1
* Stéphane +1
* Marta +1
* Thomas +1
* Sergiu +1
Thus Anca, you are a XWiki Watch commiter now !
Welcome aboard!
Jérôme.
> Dear XWikiers,
>
> I'd like to propose voting Anca Luca as a XWatch committer.
> Anca has submitted several good patches for XWiki Watch. (see
> http://tinyurl.com/2x3psb) She writes clean code and shows a strong focus
> on design and separation of concerns. I propose she now commit her own
> patches on XWatch!
>
> Here's my +1 for Anca.
>
> Note: For full disclosure, Anca is working for XPertNet, the company
> behind the creation of XWiki. FWIW, out of the 26 committers
> (http://www.xwiki.org/xwiki/bin/view/Community/HallOfFame), 9 are working
> for XPertNet. Note that the XWiki project is driven as a meritocratic
> project (trying to follow the Apache rules as much as possible) and thus
> anyone can become a committer (see
> http://www.xwiki.org/xwiki/bin/view/Community/Committership). The more the
> merrier!
>
> Regards,
> Jérôme.
>
>
On Dec 3, 2007, at 4:26 PM, hritcu (SVN) wrote:
> Author: hritcu
> Date: 2007-12-03 16:26:54 +0100 (Mon, 03 Dec 2007)
> New Revision: 6263
>
> Modified:
> xwiki-platform/core/trunk/xwiki-core/src/main/java/com/xpn/xwiki/
> xmlrpc/ConfluenceRpcHandler.java
> Log:
> Testing that I can commit (updated comment)
>
> Modified: xwiki-platform/core/trunk/xwiki-core/src/main/java/com/xpn/
> xwiki/xmlrpc/ConfluenceRpcHandler.java
> ===================================================================
> --- xwiki-platform/core/trunk/xwiki-core/src/main/java/com/xpn/xwiki/
> xmlrpc/ConfluenceRpcHandler.java 2007-12-03 14:59:03 UTC (rev 6262)
> +++ xwiki-platform/core/trunk/xwiki-core/src/main/java/com/xpn/xwiki/
> xmlrpc/ConfluenceRpcHandler.java 2007-12-03 15:26:54 UTC (rev 6263)
> @@ -83,6 +83,7 @@
> // -- user management could be a part of the test setup
>
> // Q: Where are access rights checked ? Ensure they are !
> + // Vincent discovered that they are not checked ... was it fixed?
Not across the board, just in getDocFromPageId().
-Vincent
Hi,
Marius has asked me for commit access to the sandbox since he's
working with Jerome and Ludovic on the new space manager feature.
Since Marius has been providing good patches and this is only an
access to the Sandbox, I'll go ahead and give him access.
Note that this does not allow Marius to commit elsewhere yet (a vote
will be needed for that). However since we only have coarse-grained
permissions at this stage Marius would be able to commit elsewhere but
he shouldn't do that (I talked to him and he knows that).
Thanks
-Vincent
The XWiki development team is pleased to announce the release of
XEclipse 1.0.1
You can find it at http://www.xwiki.org/xwiki/bin/view/Main/Download#HXWikiEclipse
XEclipse is an Eclipse plug-in that allows the user to interact with
an XWiki server directly from within the Eclipse IDE. It comes in two
flavors: as an Eclipse plugin that can be directly integrated in the
Eclipse IDE or as a standalone RCP application.
This release is mostly a maintenance release that fixes some serious
bugs that prevented XEclipse version 1.0 to work correctly.
Main changes from 1.0:
* Solved XMLRPC issues when connecting to XWiki version 1.2
* Solved problems in XWiki Explorer structure visualization.
* Added some minor user interface improvements (e.g., page loading
progress bars).
Thanks
-The XWiki dev team
Hi,
As previously proposed, today (Friday 30th) is the planned day for the
first 1.2 Release Candidate. There are still a few issues remaining
http://jira.xwiki.org/jira/secure/IssueNavigator.jspa?reset=true&&pid=10010…
which I'd like to see fixed before noon (CET), when I'll start the
release process.
There will probably be another RC shortly, as there are a few more tasks
that should be fixed for improving the stability of the 1.2 version of
XE, but there should be a final 1.2 before Javapolis.
Thanks,
Sergiu and my +1
Hi,
I'd like to move the current trunk (1.2-SNAPSHOT) to a branch right
after the release planned for today, given the fact that after the first
RC no new features or major changes in the code can be committed. The
only projects that need to be branched are platform-core, platform-web
and products-enterprise, as the others will not see major modifications
in less than two weeks. However, if someone does need to commit new code
in a dependency for XE/platform, we can create a branch on the fly.
Thanks,
Sergiu and my +1