- xwiki-devs@xwiki.org - lists.xwiki.org

[xwiki-devs] Profiling: Why do attachments require so much memory

by Sergiu Dumitriu

Hi devs, Last night I checked what happens when uploading a file, and why does that action require huge amounts of memory. So, whenever uploading a file, there are several places where the file content is loaded into memory: - as an XWikiAttachment as byte[] ~= filesize - as an XWikiAttachmentArchive as Base64 encoded string ~= 2*4*filesize - as hibernate tokens that are sent to the database, clones of the XWikiAttachment and XWikiAttachmentArchive data ~= 9*filesize - as Cached attachments and attachment archive, clones of the same 2 objects ~= 9*filesize Total: ~27*filesize bytes in memory. So, out of a 10M file, we get at least 270M of needed memory. Worse, if this is not the first version of the attachment, then the complete attachment history is loaded in memory, so add another 24*versionsize*versions of memory needed during upload. After the upload is done, most of these are cleared, only the cached objects will remain in memory. However, a problem still remains with the cache. It is a LRU cache with a fixed capacity, so even if the memory is full, the cached attachments will not be released. Things we can improve: - Make the cache use References. This will allow cached attachments to be removed from memory when there's a need for more memory - Do a better attachment archive system. I'm not sure it is a good idea to have diff-based versioning of attachments. In theory, it saves space when versions are much alike, but it does not really work in practice because it does a line-diff, and a base64 encoded string does not have newlines. What's more, the space gain would be efficient when there are many versions, as one version alone takes 4 times more space than a binary dump of the content. Suppose we switch to a "one version per table row" for attachment history, with direct binary dump, then the memory needed for uploading would be 6*filesize, which is much less. -- Sergiu Dumitriu http://purl.org/net/sergiu/

17 years, 6 months

3
6
0 0

[xwiki-devs] XWiki XMLRPC

by Fabio Mancinelli

Dear all, I am working on adding XWikiObject-editing support to XEclipse and this requires some kind of re-engineering on the server side, so I writing this mail to discuss about some issues. From my understanding, please correct me if I'm wrong, the current XMLRPC API defined in com.xpn.xwiki.xmlrpc.ConfluenceRpcHandler exposes several methods for accessing to XWiki functionalities using a set of domain objects that mimic the ones defined in the CodeHaus' SWIZZLE-Confluence package (com.xpn.xwiki.xmlrpc.model.* and com.xpn.xwiki.xmlrpc.model.swizzle.*). On the client (XEclipse) side the CodeHaus' SWIZZLE-Confluence project (though slighty patched) is used in order to communicate with the XMLRPC extension. Things are fine because the APIs and the domain objects defined on both the server and the client side are basically the same (there is some kind of code duplication between XWiki and SWIZZLE). Now, in order to handle XWikiObjects I am in need of adding both APIs for accessing the functionality (getObjects, putObject, etc.) and the domain objects for modeling XWikiObjects. Actually some of the APIs are already implemented on the server side (e.g, Object[] ConfluenceRpcHandler.getObjects(String token, String pageId, String className), actually returning Comment objects(?!?!)). However they return unstructured data, while the other methods return incapsulated data in objects where the user can conveniently call accessor methods (e.g. Page.getSpace(), Page.getVersion(), etc.). So domain objects and client side interfaces for the new methods are still missing. From my understanding I see the following alternatives: 1) Extend the current confluence compatible API and add the needed API and domain objects in the core. This has the implication that those extensions should be provided on the client side as well: 1.1) We fork the SWIZZLE-Confluence project and add those extensions. (Note that this should almost be the way it is done now because the XEclipse embedded xmlrpc client is a patched version of the original CodeHaus' SWIZZLE-Confluence) 1.2) We add the extensions in the SWIZZLE-Confluence project on the current Codehaus' codebase. 2) We refactor the XMLRPC API by implementing the current XWiki Object Model and we provide a facade for making CodeHaus' SWIZZLE-Confluence interacting with XWiki seamlessly. 3) ... Add your own if I have missed something. From my point of view and understanding (again, please correct me if I am wrong), there is an architectural problem in the current implementation. It seems to me that we are providing a facade for accessing Confluence using XWiki interfaces instead of doing the opposite. This is not completely correct since we are leveraging the SWIZZLE API for modeling the "common part" between the XWiki and the Confluence models... But still, we need extensions because XWiki has more stuff with respect to Confluence. Looking at the solutions: 1.1) Is a viable way that preserves most of the infrastructure already implemented. However we need to fork in order to make all our extensions freely and independently. A way for doing this might be to create an XMLRPC component by getting the com.xpn.xwiki.xmlrpc.* out of the core, and providing two jars: com.xpn.xwiki.xmlrpc.client (or whatever) with the interfaces that the client can use (i.e., something like the jar currently embedded in XEclipse) and com.xpn.xwiki.xmlrpc (or whatever) with the server implementation. 1.2) Is weird and not feasible. Weird because I don't see how and why a getObjects() method and a XWikiObject class should be present in a Confluence API, and infeasible because we don't have access and we don't manage the CodeHaus' SWIZZLE-Confluence project. 2) Is a solution that requires more work and that gives the maximum flexibility, but since there has been already an implementation that has settled on the principle "the Confluence API is ok for accessing XWiki", part of this solution is already implemented and it's fine so we fall back on 1.1 3) ... Add your consideration here. To conclude I think that 1.1 is the best way to proceed... Provided that we are sure that the Confluence API is really OK for accessing XWiki (with respect to the "common" parts). Otherwise 2 should be the way to go. Maybe the "compatibility" principle deserves some additional analysis in order to be more confident that in the future we will not be locked in a limited interface when dealing, for example, with simple Pages or Spaces. WDYT? Cheers, Fabio P.S.: Or we might get rid of XMLRPC and go fully REST... But maybe this could be another nice independent extension :)

17 years, 6 months

1
1
0 0

[xwiki-devs] [proposal] upgrade web-gwt to gwt 1.4

by ancapaula.luca＠xwiki.com

Hi developers! I'd like to upgrade the web-gwt module to gwt 1.4, as in the dedicated branch https://svn.xwiki.org/svnroot/xwiki/xwiki-platform/web/branches/xwiki-web-g… . A stable upgrade will be finalized tomorrow, although there will still remain a couple of appearance issues to be solved until the xwiki-web 1.4 milestone release. WDYT?

17 years, 6 months

4
3
0 0

[xwiki-devs] GWT 1.4 upgrade

by ancapaula.luca＠xwiki.com

Hi devs, We have planned the GWT 1.4 upgrade for the next XWatch milestone at the end of march. For this, we need to make a decision regarding the web-gwt dependencies (for the moment, the xwiki gwt dialogs rely on the gwt-tk library that does not yet have a release for gwt 1.4) so we must choose from: - using another library to provide this functionality, particularly the MyGwt library pros: nice looks and good API + the possibility of using the library components in including projects. cons: code changes required by the clean switch (updating all involved classes to use library API instead of GWT API), the lack of a maven repository with all available MyGwt versions (only 0.5.0 rc). As well, while testing, I experienced a couple of rendering issues (caused, seemingly by the use of the strict or xhtml DTD). - using the native gwt modal dialogs introduced in 1.4: pros: not styled (we totally control the styling process and can build an uniform look); widgets consistency, at least at this level. A big advantage is that the web-gwt module will not depend on any other library anymore. cons: not styled, the usual GWT API (which can be poor in some situations); GWT also has some problems caused by the standard mode interpretation in browsers (caused by the doctype declaration) but in this situation the code seems to be stable. What do you think?

17 years, 6 months

3
5
0 0

Re: [xwiki-devs] [xwiki-notifications] r8184 - xwiki-platform/core/branches/xwiki-core-1.3/xwiki-core/src/main/java/com/xpn/xwiki

by Vincent Massol

hmmm.... I'm really against adding new features, in a RC phase! I'll prefer this to be rolled back to be honest. However if we want to keep it then we need some tests that'll prove it's not breaking anything. We shouldn't add dangerous stuff like this in a RC phase and especially not without a vote IMO. Thanks -Vincent On Mar 3, 2008, at 10:18 PM, sdumitriu (SVN) wrote: > Author: sdumitriu > Date: 2008-03-03 22:18:54 +0100 (Mon, 03 Mar 2008) > New Revision: 8184 > > Modified: > xwiki-platform/core/branches/xwiki-core-1.3/xwiki-core/src/main/ > java/com/xpn/xwiki/XWiki.java > Log: > XWIKI-2170: Allow inactive users to see specific pages > Done. > Patch submitted by David Ward, applied with minor changes. > Merged from trunk@8181 > > > Modified: xwiki-platform/core/branches/xwiki-core-1.3/xwiki-core/src/ > main/java/com/xpn/xwiki/XWiki.java > =================================================================== > --- xwiki-platform/core/branches/xwiki-core-1.3/xwiki-core/src/main/ > java/com/xpn/xwiki/XWiki.java 2008-03-03 21:18:14 UTC (rev 8183) > +++ xwiki-platform/core/branches/xwiki-core-1.3/xwiki-core/src/main/ > java/com/xpn/xwiki/XWiki.java 2008-03-03 21:18:54 UTC (rev 8184) > @@ -4211,13 +4211,26 @@ > null, > args); > } else if (checkActive(context) == 0) { > - Object[] args = {context.getUser()}; > - setPhonyDocument(docName, context, vcontext); > - throw new > XWikiException(XWikiException.MODULE_XWIKI_USER, > - XWikiException.ERROR_XWIKI_USER_INACTIVE, > - "User {0} account is inactive", > - null, > - args); > + boolean allow = false; > + String allowed = > Param("xwiki.inactiveuser.allowedpages", ""); > + if (context.getAction().equals("view") && ! > allowed.equals("")) { > + String[] allowedList = StringUtils.split(allowed, > " ,"); > + for (int i=0; i < allowedList.length; i++) { > + if (allowedList[i].equals(doc.getFullName())) { > + allow = true; > + break; > + } > + } > + } > + if (!allow) { > + Object[] args = {context.getUser()}; > + setPhonyDocument(docName, context, vcontext); > + throw new > XWikiException(XWikiException.MODULE_XWIKI_USER, > + XWikiException.ERROR_XWIKI_USER_INACTIVE, > + "User {0} account is inactive", > + null, > + args); > + } > } > > context.put("doc", doc);

17 years, 6 months

1
0
0 0

Re: [xwiki-devs] [xwiki-notifications] r8181 - xwiki-platform/core/trunk/xwiki-core/src/main/java/com/xpn/xwiki

by Vincent Massol

On Mar 3, 2008, at 9:57 PM, sdumitriu (SVN) wrote: > Author: sdumitriu > Date: 2008-03-03 21:57:43 +0100 (Mon, 03 Mar 2008) > New Revision: 8181 > > Modified: > xwiki-platform/core/trunk/xwiki-core/src/main/java/com/xpn/xwiki/ > XWiki.java > Log: > XWIKI-2170: Allow inactive users to see specific pages What's an inactive user? I think the code below would benefit from some comment and from a separate method, like boolean checkAccessForInactiveUsers() Do we have tests to prove this works? :) Since this seems to be a new feature, I think we really need some tests. Thanks -Vincent > Done. > Patch submitted by David Ward, applied with minor changes. > > > Modified: xwiki-platform/core/trunk/xwiki-core/src/main/java/com/xpn/ > xwiki/XWiki.java > =================================================================== > --- xwiki-platform/core/trunk/xwiki-core/src/main/java/com/xpn/xwiki/ > XWiki.java 2008-03-03 20:01:33 UTC (rev 8180) > +++ xwiki-platform/core/trunk/xwiki-core/src/main/java/com/xpn/xwiki/ > XWiki.java 2008-03-03 20:57:43 UTC (rev 8181) > @@ -4209,13 +4209,26 @@ > null, > args); > } else if (checkActive(context) == 0) { > - Object[] args = {context.getUser()}; > - setPhonyDocument(docName, context, vcontext); > - throw new > XWikiException(XWikiException.MODULE_XWIKI_USER, > - XWikiException.ERROR_XWIKI_USER_INACTIVE, > - "User {0} account is inactive", > - null, > - args); > + boolean allow = false; > + String allowed = > Param("xwiki.inactiveuser.allowedpages", ""); > + if (context.getAction().equals("view") && ! > allowed.equals("")) { > + String[] allowedList = StringUtils.split(allowed, > " ,"); > + for (int i=0; i < allowedList.length; i++) { > + if (allowedList[i].equals(doc.getFullName())) { > + allow = true; > + break; > + } > + } > + } > + if (!allow) { > + Object[] args = {context.getUser()}; > + setPhonyDocument(docName, context, vcontext); > + throw new > XWikiException(XWikiException.MODULE_XWIKI_USER, > + XWikiException.ERROR_XWIKI_USER_INACTIVE, > + "User {0} account is inactive", > + null, > + args); > + } > } > > context.put("doc", doc); > > _______________________________________________ > notifications mailing list > notifications(a)xwiki.org > http://lists.xwiki.org/mailman/listinfo/notifications

17 years, 6 months

1
0
0 0

Re: [xwiki-devs] Building Xwiki core (Kamna Jain)

by sachin mittal

Hi, Can you paste the console output. You can add the maven bin directory to the path variable so that you dont have to type the full path to mvn.bat every time you run the mvn scripts. Also what do you get when you type mvn -version in the command prompt. Thanks Sachin > ---------------------------------------------------------------------- > > Message: 1 > Date: Mon, 3 Mar 2008 15:32:30 -0600 > From: "Kamna Jain" <kammy.scorpi(a)gmail.com> > Subject: Re: [xwiki-devs] Building Xwiki core > To: devs(a)xwiki.org > Message-ID: > <fb681d280803031332y756f2f66g72f65d3b687ca66(a)mail.gmail.com> > Content-Type: text/plain; charset="iso-8859-1" > > Yes, > I am setting the JAVA_HOME variable with DOS prompt > and after I set it, I log of and then it is available in the list of env. > variables after I log back in. > But, when I try to run mvn install, it still gives me the same error. > > Also, although, I set the M2_HOMe variable, I am not able to use mvn > command > without its location! (I have to write the full path of the mvn.bat file > and > then say install after a space) > I dont know what I am doing wrong. > > Thanks for your replies. >

17 years, 6 months

1
0
0 0

Re: [xwiki-devs] Building Xwiki core

by Kamna Jain

Yes, I am setting the JAVA_HOME variable with DOS prompt and after I set it, I log of and then it is available in the list of env. variables after I log back in. But, when I try to run mvn install, it still gives me the same error. Also, although, I set the M2_HOMe variable, I am not able to use mvn command without its location! (I have to write the full path of the mvn.bat file and then say install after a space) I dont know what I am doing wrong. Thanks for your replies. On 3/3/08, devs-request(a)xwiki.org <devs-request(a)xwiki.org> wrote: > > 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: Building Xwiki core (Asiri Rathnayake) > > > ---------------------------------------------------------------------- > > Message: 1 > Date: Tue, 4 Mar 2008 01:43:58 +0530 > From: "Asiri Rathnayake" <asiri.rathnayake(a)gmail.com> > Subject: Re: [xwiki-devs] Building Xwiki core > To: "XWiki Developers" <devs(a)xwiki.org> > Message-ID: > <9fd36c290803031213r60305c48qbc2c0e5996b402d1(a)mail.gmail.com> > Content-Type: text/plain; charset="iso-8859-1" > > Hi, > > Did you check whether JAVA_HOME is available in dos prompt as well ? > Perhaps > you should try "set JAVA_HOME=C:\abc\Java\jdk1.5.0_14" prior to running > "mvn > install" ? > > - Asiri > > On Tue, Mar 4, 2008 at 1:16 AM, Kamna Jain <kammy.scorpi(a)gmail.com> wrote: > > > Hello, > > > > I am trying to learn how to build XWiki from the source. > > > > I checked out the source code in Eclipse 3.3 using Sunclipse and then I > > created a Java Project out of the XWiki Core/src folder. > > Now, I am trying to follow directions from the links - > > http://dev.xwiki.org/xwiki/bin/view/Community/Building > > I downloaded maven-2.1-SNAPSHOT and create dthe .m2/settings.xml. > > I also created M2_HOME varibale and set the PATH variable with M2_HOME. > > Set the JAVA_HOME to the jdk installed on my system. > > > > But, when I try "mvn install" from the directory where I have the > > XWiki/src checked out (Eclipse workspace), it says that JAVA_HOME is not > set > > and gives me the following error: > > > > ERROR: JAVA_HOME not found in your environment. > > Please set the JAVA_HOME variable in your environment to match the > > location of your Java installation > > > > I have JAVA_HOME set and it shows up in the list of env. variables in my > > system like this: > > > > JAVA_HOME = C:\abc\Java\jdk1.5.0_14 > > PATH = C:\WINDOWS;C:\WINDOWS\System32;C:\Program > > Files\Subversion\bin;C:\Program Files\TortoiseSVN\bin;C:\Program > Files\Quest > > Software\PuTTY\;C:\Program Files\QuickTime\QTSystem\;C:\Program > Files\Quest > > Software\PuTTY\;%JAVA_HOME%\bin;%M2_HOME%\bin > > > > Could you please tell me what I am doing wrong and what I should change > to > > get this right! > > > > Also, am I on the irght path when I I say I am trying to buildthe src of > > XWiki -core? and nothing else! As an eclipse project, it is all compiled > and > > does not show errors implying that it has all the files that it needs > for it > > to complie. > > > > > > Thanks > > > > > > > > > > > > > > On 3/3/08, devs-request(a)xwiki.org <devs-request(a)xwiki.org> wrote: > > > > > > 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: Profiling: Why do attachments require so much memory > > > (Sergiu Dumitriu) > > > 2. [VOTE] Change the attachment archive storage (Sergiu Dumitriu) > > > 3. Re: [VOTE] Change the attachment archive storage (Vincent Massol) > > > 4. Re: [VOTE] Change the attachment archive storage (Sergiu > Dumitriu) > > > 5. [Proposal] XE 1.3 final release date (Vincent Massol) > > > 6. Re: Xwiki Enterprise 1.3 RC1 release date? (Vincent Massol) > > > 7. Re: About GSoC 2008 (Asiri Rathnayake) > > > 8. Re: Xwiki Enterprise 1.3 RC1 release date? (Sergiu Dumitriu) > > > > > > > > > ---------------------------------------------------------------------- > > > > > > Message: 1 > > > Date: Mon, 03 Mar 2008 17:28:21 +0100 > > > From: Sergiu Dumitriu <sergiu(a)xwiki.com> > > > Subject: Re: [xwiki-devs] Profiling: Why do attachments require so > > > much memory > > > To: XWiki Developers <devs(a)xwiki.org> > > > Message-ID: <47CC2725.40707(a)xwiki.com> > > > Content-Type: text/plain; charset=ISO-8859-1; format=flowed > > > > > > Vincent Massol wrote: > > > > Nice work Sergiu. We should transform this into a jira issue to not > > > > forget it. > > > > > > > > > > We should vote for it first. > > > > > > > One other idea: store attachments on the file system and not in the > > > DB. > > > > > > > > Thanks > > > > -Vincent > > > > > > > > On Feb 27, 2008, at 3:48 PM, Sergiu Dumitriu wrote: > > > > > > > >> Hi devs, > > > >> > > > >> Last night I checked what happens when uploading a file, and why > does > > > >> that action require huge amounts of memory. > > > >> > > > >> So, whenever uploading a file, there are several places where the > > > file > > > >> content is loaded into memory: > > > >> - as an XWikiAttachment as byte[] ~= filesize > > > >> - as an XWikiAttachmentArchive as Base64 encoded string ~= > > > >> 2*4*filesize > > > >> - as hibernate tokens that are sent to the database, clones of the > > > >> XWikiAttachment and XWikiAttachmentArchive data ~= 9*filesize > > > >> - as Cached attachments and attachment archive, clones of the same > 2 > > > >> objects ~= 9*filesize > > > >> > > > >> Total: ~27*filesize bytes in memory. > > > >> > > > >> So, out of a 10M file, we get at least 270M of needed memory. > > > >> > > > >> Worse, if this is not the first version of the attachment, then the > > > >> complete attachment history is loaded in memory, so add another > > > >> 24*versionsize*versions of memory needed during upload. > > > >> > > > >> After the upload is done, most of these are cleared, only the > cached > > > >> objects will remain in memory. > > > >> > > > >> However, a problem still remains with the cache. It is a LRU cache > > > >> with > > > >> a fixed capacity, so even if the memory is full, the cached > > > >> attachments > > > >> will not be released. > > > >> > > > >> Things we can improve: > > > >> - Make the cache use References. This will allow cached attachments > > > to > > > >> be removed from memory when there's a need for more memory > > > >> - Do a better attachment archive system. I'm not sure it is a good > > > >> idea > > > >> to have diff-based versioning of attachments. In theory, it saves > > > >> space > > > >> when versions are much alike, but it does not really work in > practice > > > >> because it does a line-diff, and a base64 encoded string does not > > > have > > > >> newlines. What's more, the space gain would be efficient when there > > > >> are > > > >> many versions, as one version alone takes 4 times more space than a > > > >> binary dump of the content. > > > >> > > > >> Suppose we switch to a "one version per table row" for attachment > > > >> history, with direct binary dump, then the memory needed for > > > uploading > > > >> would be 6*filesize, which is much less. > > > > > > > > > -- > > > Sergiu Dumitriu > > > http://purl.org/net/sergiu/ > > > > > > > > > ------------------------------ > > > > > > Message: 2 > > > Date: Mon, 03 Mar 2008 17:34:07 +0100 > > > From: Sergiu Dumitriu <sergiu(a)xwiki.com> > > > Subject: [xwiki-devs] [VOTE] Change the attachment archive storage > > > To: XWiki Developers <devs(a)xwiki.org> > > > Message-ID: <47CC287F.9090609(a)xwiki.com> > > > Content-Type: text/plain; charset=ISO-8859-1; format=flowed > > > > > > Hi devs, > > > > > > As detailed in another mail > > > (http://lists.xwiki.org/pipermail/devs/2008-February/005344.html), the > > > current attachment archive mechanism is very inefficient. We should > > > write a new one, which stores attachment versions as plain binary > data, > > > and see if the current core is pluggable enough to allow the old > > > mechanism to be preserved as a plugin, and possibly define other > storage > > > mechanisms, like a filesystem based one. > > > > > > Artem, do you think you can help, as this is something related to what > > > you've been working on? > > > -- > > > Sergiu Dumitriu > > > http://purl.org/net/sergiu/ > > > > > > > > > ------------------------------ > > > > > > Message: 3 > > > Date: Mon, 3 Mar 2008 17:40:39 +0100 > > > From: Vincent Massol <vincent(a)massol.net> > > > Subject: Re: [xwiki-devs] [VOTE] Change the attachment archive storage > > > To: XWiki Developers <devs(a)xwiki.org> > > > Message-ID: <D5354D29-6FB9-41CB-A450-C77DE4E9BB54(a)massol.net> > > > Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes > > > > > > > > > On Mar 3, 2008, at 5:34 PM, Sergiu Dumitriu wrote: > > > > > > > Hi devs, > > > > > > > > As detailed in another mail > > > > (http://lists.xwiki.org/pipermail/devs/2008-February/005344.html), > the > > > > current attachment archive mechanism is very inefficient. We should > > > > write a new one, which stores attachment versions as plain binary > > > > data, > > > > and see if the current core is pluggable enough to allow the old > > > > mechanism to be preserved as a plugin, and possibly define other > > > > storage > > > > mechanisms, like a filesystem based one. > > > > > > > > Artem, do you think you can help, as this is something related to > what > > > > you've been working on? > > > > > > My only worry is that last time we changed the database format we > > > spent several months stabilizing it... since there were lots of > > > problems. I'm not even sure we've finished stabilizing it fully... > > > > > > So is there any chance that this would be simpler? :) > > > > > > Thanks > > > -Vincent > > > > > > > > > > > > ------------------------------ > > > > > > Message: 4 > > > Date: Mon, 03 Mar 2008 18:00:12 +0100 > > > From: Sergiu Dumitriu <sergiu(a)xwiki.com> > > > Subject: Re: [xwiki-devs] [VOTE] Change the attachment archive storage > > > To: XWiki Developers <devs(a)xwiki.org> > > > Message-ID: <47CC2E9C.8070404(a)xwiki.com> > > > Content-Type: text/plain; charset=ISO-8859-1; format=flowed > > > > > > Vincent Massol wrote: > > > > On Mar 3, 2008, at 5:34 PM, Sergiu Dumitriu wrote: > > > > > > > >> Hi devs, > > > >> > > > >> As detailed in another mail > > > >> (http://lists.xwiki.org/pipermail/devs/2008-February/005344.html), > > > the > > > >> current attachment archive mechanism is very inefficient. We should > > > >> write a new one, which stores attachment versions as plain binary > > > >> data, > > > >> and see if the current core is pluggable enough to allow the old > > > >> mechanism to be preserved as a plugin, and possibly define other > > > >> storage > > > >> mechanisms, like a filesystem based one. > > > >> > > > >> Artem, do you think you can help, as this is something related to > > > what > > > >> you've been working on? > > > > > > > > My only worry is that last time we changed the database format we > > > > spent several months stabilizing it... since there were lots of > > > > problems. I'm not even sure we've finished stabilizing it fully... > > > > > > > > So is there any chance that this would be simpler? :) > > > > > > > > Thanks > > > > -Vincent > > > > > > > > > > It should be simpler, as attachments are just binary blobs, while the > > > XML history is much too fragile. > > > -- > > > Sergiu Dumitriu > > > http://purl.org/net/sergiu/ > > > > > > > > > ------------------------------ > > > > > > Message: 5 > > > Date: Mon, 3 Mar 2008 18:18:18 +0100 > > > From: Vincent Massol <vincent(a)massol.net> > > > Subject: [xwiki-devs] [Proposal] XE 1.3 final release date > > > To: XWiki Developers <devs(a)xwiki.org> > > > Message-ID: <FE2B2F15-5128-47CC-90B7-CAF96398BADE(a)massol.net> > > > Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes > > > > > > Hi, > > > > > > I'm proposing to revise the 1.3 Final release date to this Friday 7th > > > of March 2007. > > > > > > We've already fixed the major issues raised in 1.3RC1 but I think we > > > need a few days to let people report any issues they might have had > > > with 1.3RC1. > > > > > > Let me know what you think and especially if you don't agree. I'm > > > proposing to do the release. > > > > > > Thanks > > > -Vincent > > > > > > > > > > > > ------------------------------ > > > > > > Message: 6 > > > Date: Mon, 3 Mar 2008 18:23:39 +0100 > > > From: Vincent Massol <vincent(a)massol.net> > > > Subject: Re: [xwiki-devs] Xwiki Enterprise 1.3 RC1 release date? > > > To: XWiki Developers <devs(a)xwiki.org> > > > Message-ID: <161441E7-DC86-48ED-A91A-A8F143A2FC4B(a)massol.net> > > > Content-Type: text/plain; charset="us-ascii" > > > > > > > > > On Feb 27, 2008, at 3:17 PM, Everitt, Glenn wrote: > > > > > > > Is the plan to provide a xwiki-enterprise-web1-1.3-rc1.war file on > > > > the Xwiki Download page? When do you think this would be > > > > available? Would it be better to pull it directly from svn? If I > > > > get it from svn how is the RC1 release marked? > > > > > > > It's been released a few days ago... > > > > I noticed that you were looking at using GWT Html editor. Doesn't > > > > GWT Html editor just wrap the FCKEditor? What is the advantage of > > > > using GWT Html Editor instead of just using the FCKEditor? > > > > > > > I have no idea. Anyone knows? > > > > > > Thanks > > > -Vincent > > > > > >

17 years, 6 months

2
1
0 0

[xwiki-devs] Building Xwiki core

by Kamna Jain

Hello, I am trying to learn how to build XWiki from the source. I checked out the source code in Eclipse 3.3 using Sunclipse and then I created a Java Project out of the XWiki Core/src folder. Now, I am trying to follow directions from the links - http://dev.xwiki.org/xwiki/bin/view/Community/Building I downloaded maven-2.1-SNAPSHOT and create dthe .m2/settings.xml. I also created M2_HOME varibale and set the PATH variable with M2_HOME. Set the JAVA_HOME to the jdk installed on my system. But, when I try "mvn install" from the directory where I have the XWiki/src checked out (Eclipse workspace), it says that JAVA_HOME is not set and gives me the following error: ERROR: JAVA_HOME not found in your environment. Please set the JAVA_HOME variable in your environment to match the location of your Java installation I have JAVA_HOME set and it shows up in the list of env. variables in my system like this: JAVA_HOME = C:\abc\Java\jdk1.5.0_14 PATH = C:\WINDOWS;C:\WINDOWS\System32;C:\Program Files\Subversion\bin;C:\Program Files\TortoiseSVN\bin;C:\Program Files\Quest Software\PuTTY\;C:\Program Files\QuickTime\QTSystem\;C:\Program Files\Quest Software\PuTTY\;%JAVA_HOME%\bin;%M2_HOME%\bin Could you please tell me what I am doing wrong and what I should change to get this right! Also, am I on the irght path when I I say I am trying to buildthe src of XWiki -core? and nothing else! As an eclipse project, it is all compiled and does not show errors implying that it has all the files that it needs for it to complie. Thanks On 3/3/08, devs-request(a)xwiki.org <devs-request(a)xwiki.org> wrote: > > 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: Profiling: Why do attachments require so much memory > (Sergiu Dumitriu) > 2. [VOTE] Change the attachment archive storage (Sergiu Dumitriu) > 3. Re: [VOTE] Change the attachment archive storage (Vincent Massol) > 4. Re: [VOTE] Change the attachment archive storage (Sergiu Dumitriu) > 5. [Proposal] XE 1.3 final release date (Vincent Massol) > 6. Re: Xwiki Enterprise 1.3 RC1 release date? (Vincent Massol) > 7. Re: About GSoC 2008 (Asiri Rathnayake) > 8. Re: Xwiki Enterprise 1.3 RC1 release date? (Sergiu Dumitriu) > > > ---------------------------------------------------------------------- > > Message: 1 > Date: Mon, 03 Mar 2008 17:28:21 +0100 > From: Sergiu Dumitriu <sergiu(a)xwiki.com> > Subject: Re: [xwiki-devs] Profiling: Why do attachments require so > much memory > To: XWiki Developers <devs(a)xwiki.org> > Message-ID: <47CC2725.40707(a)xwiki.com> > Content-Type: text/plain; charset=ISO-8859-1; format=flowed > > Vincent Massol wrote: > > Nice work Sergiu. We should transform this into a jira issue to not > > forget it. > > > > We should vote for it first. > > > One other idea: store attachments on the file system and not in the DB. > > > > Thanks > > -Vincent > > > > On Feb 27, 2008, at 3:48 PM, Sergiu Dumitriu wrote: > > > >> Hi devs, > >> > >> Last night I checked what happens when uploading a file, and why does > >> that action require huge amounts of memory. > >> > >> So, whenever uploading a file, there are several places where the file > >> content is loaded into memory: > >> - as an XWikiAttachment as byte[] ~= filesize > >> - as an XWikiAttachmentArchive as Base64 encoded string ~= > >> 2*4*filesize > >> - as hibernate tokens that are sent to the database, clones of the > >> XWikiAttachment and XWikiAttachmentArchive data ~= 9*filesize > >> - as Cached attachments and attachment archive, clones of the same 2 > >> objects ~= 9*filesize > >> > >> Total: ~27*filesize bytes in memory. > >> > >> So, out of a 10M file, we get at least 270M of needed memory. > >> > >> Worse, if this is not the first version of the attachment, then the > >> complete attachment history is loaded in memory, so add another > >> 24*versionsize*versions of memory needed during upload. > >> > >> After the upload is done, most of these are cleared, only the cached > >> objects will remain in memory. > >> > >> However, a problem still remains with the cache. It is a LRU cache > >> with > >> a fixed capacity, so even if the memory is full, the cached > >> attachments > >> will not be released. > >> > >> Things we can improve: > >> - Make the cache use References. This will allow cached attachments to > >> be removed from memory when there's a need for more memory > >> - Do a better attachment archive system. I'm not sure it is a good > >> idea > >> to have diff-based versioning of attachments. In theory, it saves > >> space > >> when versions are much alike, but it does not really work in practice > >> because it does a line-diff, and a base64 encoded string does not have > >> newlines. What's more, the space gain would be efficient when there > >> are > >> many versions, as one version alone takes 4 times more space than a > >> binary dump of the content. > >> > >> Suppose we switch to a "one version per table row" for attachment > >> history, with direct binary dump, then the memory needed for uploading > >> would be 6*filesize, which is much less. > > > -- > Sergiu Dumitriu > http://purl.org/net/sergiu/ > > > ------------------------------ > > Message: 2 > Date: Mon, 03 Mar 2008 17:34:07 +0100 > From: Sergiu Dumitriu <sergiu(a)xwiki.com> > Subject: [xwiki-devs] [VOTE] Change the attachment archive storage > To: XWiki Developers <devs(a)xwiki.org> > Message-ID: <47CC287F.9090609(a)xwiki.com> > Content-Type: text/plain; charset=ISO-8859-1; format=flowed > > Hi devs, > > As detailed in another mail > (http://lists.xwiki.org/pipermail/devs/2008-February/005344.html), the > current attachment archive mechanism is very inefficient. We should > write a new one, which stores attachment versions as plain binary data, > and see if the current core is pluggable enough to allow the old > mechanism to be preserved as a plugin, and possibly define other storage > mechanisms, like a filesystem based one. > > Artem, do you think you can help, as this is something related to what > you've been working on? > -- > Sergiu Dumitriu > http://purl.org/net/sergiu/ > > > ------------------------------ > > Message: 3 > Date: Mon, 3 Mar 2008 17:40:39 +0100 > From: Vincent Massol <vincent(a)massol.net> > Subject: Re: [xwiki-devs] [VOTE] Change the attachment archive storage > To: XWiki Developers <devs(a)xwiki.org> > Message-ID: <D5354D29-6FB9-41CB-A450-C77DE4E9BB54(a)massol.net> > Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes > > > On Mar 3, 2008, at 5:34 PM, Sergiu Dumitriu wrote: > > > Hi devs, > > > > As detailed in another mail > > (http://lists.xwiki.org/pipermail/devs/2008-February/005344.html), the > > current attachment archive mechanism is very inefficient. We should > > write a new one, which stores attachment versions as plain binary > > data, > > and see if the current core is pluggable enough to allow the old > > mechanism to be preserved as a plugin, and possibly define other > > storage > > mechanisms, like a filesystem based one. > > > > Artem, do you think you can help, as this is something related to what > > you've been working on? > > My only worry is that last time we changed the database format we > spent several months stabilizing it... since there were lots of > problems. I'm not even sure we've finished stabilizing it fully... > > So is there any chance that this would be simpler? :) > > Thanks > -Vincent > > > > ------------------------------ > > Message: 4 > Date: Mon, 03 Mar 2008 18:00:12 +0100 > From: Sergiu Dumitriu <sergiu(a)xwiki.com> > Subject: Re: [xwiki-devs] [VOTE] Change the attachment archive storage > To: XWiki Developers <devs(a)xwiki.org> > Message-ID: <47CC2E9C.8070404(a)xwiki.com> > Content-Type: text/plain; charset=ISO-8859-1; format=flowed > > Vincent Massol wrote: > > On Mar 3, 2008, at 5:34 PM, Sergiu Dumitriu wrote: > > > >> Hi devs, > >> > >> As detailed in another mail > >> (http://lists.xwiki.org/pipermail/devs/2008-February/005344.html), the > >> current attachment archive mechanism is very inefficient. We should > >> write a new one, which stores attachment versions as plain binary > >> data, > >> and see if the current core is pluggable enough to allow the old > >> mechanism to be preserved as a plugin, and possibly define other > >> storage > >> mechanisms, like a filesystem based one. > >> > >> Artem, do you think you can help, as this is something related to what > >> you've been working on? > > > > My only worry is that last time we changed the database format we > > spent several months stabilizing it... since there were lots of > > problems. I'm not even sure we've finished stabilizing it fully... > > > > So is there any chance that this would be simpler? :) > > > > Thanks > > -Vincent > > > > It should be simpler, as attachments are just binary blobs, while the > XML history is much too fragile. > -- > Sergiu Dumitriu > http://purl.org/net/sergiu/ > > > ------------------------------ > > Message: 5 > Date: Mon, 3 Mar 2008 18:18:18 +0100 > From: Vincent Massol <vincent(a)massol.net> > Subject: [xwiki-devs] [Proposal] XE 1.3 final release date > To: XWiki Developers <devs(a)xwiki.org> > Message-ID: <FE2B2F15-5128-47CC-90B7-CAF96398BADE(a)massol.net> > Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes > > Hi, > > I'm proposing to revise the 1.3 Final release date to this Friday 7th > of March 2007. > > We've already fixed the major issues raised in 1.3RC1 but I think we > need a few days to let people report any issues they might have had > with 1.3RC1. > > Let me know what you think and especially if you don't agree. I'm > proposing to do the release. > > Thanks > -Vincent > > > > ------------------------------ > > Message: 6 > Date: Mon, 3 Mar 2008 18:23:39 +0100 > From: Vincent Massol <vincent(a)massol.net> > Subject: Re: [xwiki-devs] Xwiki Enterprise 1.3 RC1 release date? > To: XWiki Developers <devs(a)xwiki.org> > Message-ID: <161441E7-DC86-48ED-A91A-A8F143A2FC4B(a)massol.net> > Content-Type: text/plain; charset="us-ascii" > > > On Feb 27, 2008, at 3:17 PM, Everitt, Glenn wrote: > > > Is the plan to provide a xwiki-enterprise-web1-1.3-rc1.war file on > > the Xwiki Download page? When do you think this would be > > available? Would it be better to pull it directly from svn? If I > > get it from svn how is the RC1 release marked? > > > It's been released a few days ago... > > I noticed that you were looking at using GWT Html editor. Doesn't > > GWT Html editor just wrap the FCKEditor? What is the advantage of > > using GWT Html Editor instead of just using the FCKEditor? > > > I have no idea. Anyone knows? > > Thanks > -Vincent > >

17 years, 6 months

3
2
0 0

[xwiki-devs] [Proposal] XE 1.3 final release date

by Vincent Massol

Hi, I'm proposing to revise the 1.3 Final release date to this Friday 7th of March 2007. We've already fixed the major issues raised in 1.3RC1 but I think we need a few days to let people report any issues they might have had with 1.3RC1. Let me know what you think and especially if you don't agree. I'm proposing to do the release. Thanks -Vincent

17 years, 6 months

4
3
0 0

[xwiki-devs] Xwiki Enterprise 1.3 RC1 release date?

by Everitt, Glenn

Is the plan to provide a xwiki-enterprise-web1-1.3-rc1.war file on the Xwiki Download page? When do you think this would be available? Would it be better to pull it directly from svn? If I get it from svn how is the RC1 release marked? I noticed that you were looking at using GWT Html editor. Doesn't GWT Html editor just wrap the FCKEditor? What is the advantage of using GWT Html Editor instead of just using the FCKEditor? Thanks Glenn Everitt The contents of this e-mail are intended for the named addressee only. It contains information that may be confidential. Unless you are the named addressee or an authorized designee, you may not copy or use it, or disclose it to anyone else. If you received it in error please notify us immediately and then destroy it.

17 years, 6 months

3
2
0 0

[xwiki-devs] [idea] Velocity uberspector + annotations + deprecated code

by Sergiu Dumitriu

Hi, Since we decided to switch to Java 1.5, I found a nice use for annotations. We can detect usage of deprecated APIs in java, but it is hard to do in velocity. One way we can accomplish this is by writing our own velocity uberspector, that checks if a method call is deprecated or not, and logs the calls to deprecated methods. This will allow us to easily spot deprecated code in our templates and fix them. The drawback is that it could slow things down a bit. The advantage is that as long as we properly use annotations, any deprecated method used will be listed in the log. -- Sergiu Dumitriu http://purl.org/net/sergiu/

17 years, 6 months

2
2
0 0

[xwiki-devs] XWiki - J2EE best pattern

by Iwan S

Hi developers, Do you have any "best pattern" that can be shared for XWiki integration to J2EE platform? And where can i found any comprehensive documentation for this? Thanks & regards, - iwan _________________________________________________________________ Get your free suite of Windows Live services today! http://www.get.live.com/wl/all

17 years, 6 months

2
1
0 0

[Proposal] Internationalizing XWiki Applications

by Vincent Massol

Hi, Here's my proposal for internationalizing XWiki apps. The idea is to propose several solutions for XWiki apps writers: * Use case 1: I have lots of text on my page - solution: use XWiki's mechanism for translating page by creating several editions of the page in the different languages * Use case 2: I want translation resources for my application only and I'd like to share resources between pages - solution: use: $msg("mykey", "MySpace.MyTranslationDocForThisApplication") - MySpace.MyTranslationDocForThisApplication is a standard document to which a XWiki.PropertiesClass object is attached - It'll search first in that doc's PropertiesClass and if not found in XWiki's registered document bundles and if not there in XWiki's static resource bundle files * Use case 3: I want translation resources only for a given page - solution: use: $msg("mykey", $doc) - You'll need to have attached a PropertieClass object to the page where $msg is used - It'll search first in that object and if not found in XWiki's registered document bundles and if not there in XWiki's static resource bundle files * Use case 4: I want to have a global translation resources for all my apps in the wiki - solution: use: $msg("mykey") - You'll need to have created ad registered resource bundle documents in the Wiki preferences - It'll search first in XWiki's registered document bundles and if not there in XWiki's static resource bundle files Implementation details: * Add XWikiMessageTool.get(String, String) API * Add XWiki.PropertiesClass class in XE in the Administration Application + a class sheet for presenting the properties nicely WDYT? Thanks -Vincent

17 years, 6 months

5
8
0 0

Re: [xwiki-devs] About GSoC 2008

by Vincent Massol

Hi Evelina, On Mar 2, 2008, at 11:06 AM, Evelina Slatineanu wrote: > Hi, > > Since the mail I’ve sent with a pdf attachment is quite big and has > to be moderated…my proposal for GsoC (codi.pdf) can also be found > here: > http://intranet.xpertnet.biz/xwiki/bin/view/XWiki/Evelina I don't think it's such a good idea to put your gsoc proposal on a private intranet... ;) Doesn't make it easy for others to see it. I've created this page for the proposals: http://dev.xwiki.org/xwiki/bin/view/GoogleSummerOfCode/ Maybe you could move your proposal there? Thanks -Vincent > From: devs-bounces(a)xwiki.org [mailto:devs-bounces@xwiki.org] On > Behalf Of Vincent Massol > Sent: Saturday, March 01, 2008 4:24 PM > To: XWiki Developers > Subject: Re: [xwiki-devs] About GSoC 2008 > > > On Mar 1, 2008, at 3:12 PM, Asiri Rathnayake wrote: > > > Hi All, > > Sorry if this is the wrong place / time to ask this question. > > I wanted to know whether XWiki will participate in GSoC 2008. ( care > to hint some project ideas ? ) > > answer is yes! > > We all need to think about cool project ideas we want to achieve. We > could start by reviewing the leftovers from last year + add some new > ones. > > If anyone has cool ideas please send them on this list. I'll > organize a new space for collating them on xwiki.org in a few days. > > Thanks > -Vincent > _______________________________________________ > devs mailing list > devs(a)xwiki.org > http://lists.xwiki.org/mailman/listinfo/devs

17 years, 6 months

2
1
0 0

[xwiki-devs] New notification tutorial

by Vincent Massol

For those interested I've started a tutorial on the notifications mechanism. It explains how to write a Groovy class to intercept document change events. http://platform.xwiki.org/xwiki/bin/view/DevGuide/Notifications It events demonstrates how to send an IRC message when a document is modified. Hope it's useful. Have fun! -Vincent

17 years, 6 months

1
0
0 0

[xwiki-devs] Tracking modules to fix/release for XE 1.3 final

by Vincent Massol

Hi, I'm tracking the list of modules to fix and thus to release again before we can release XE 1.3 final. See http://dev.xwiki.org/xwiki/bin/view/Drafts/XE13RC1Modules Please add other modules if you know of issues that need to be fixed before XE 1.3 final is released (bugs only). Thanks -Vincent

17 years, 6 months

1
0
0 0

[xwiki-devs] Error building from source - xwiki-platform-web - standard

by Sachn Mittal

Hi, I have been building xwiki directly from source for past some time and everything is going fine. Very recently I tried to build xwiki-platform-web using the maven script under pom.xml for the first time. This got failed when building the standard module under web. Here is the console output of the script: Please tell me where I am going wrong. Thanks and advance Sachin ============================================================================= [INFO] Scanning for projects... [INFO] ---------------------------------------------------------------------------- [INFO] Building XWiki Platform - Web - Standard [INFO] task-segment: [install] [INFO] ---------------------------------------------------------------------------- [INFO] artifact org.apache.maven.plugins:maven-resources-plugin: checking for updates from xwiki-plugins-externals [INFO] artifact org.apache.maven.plugins:maven-resources-plugin: checking for updates from xwiki-plugins-releases [INFO] artifact org.apache.maven.plugins:maven-remote-resources-plugin: checking for updates from xwiki-plugins-externals [INFO] artifact org.apache.maven.plugins:maven-remote-resources-plugin: checking for updates from xwiki-plugins-releases [INFO] artifact org.apache.maven.plugins:maven-surefire-plugin: checking for updates from xwiki-plugins-externals [INFO] artifact org.apache.maven.plugins:maven-surefire-plugin: checking for updates from xwiki-plugins-releases [INFO] artifact org.apache.maven.plugins:maven-war-plugin: checking for updates from xwiki-plugins-externals [INFO] artifact org.apache.maven.plugins:maven-war-plugin: checking for updates from xwiki-plugins-releases [INFO] artifact org.apache.maven.plugins:maven-install-plugin: checking for updates from xwiki-plugins-externals [INFO] artifact org.apache.maven.plugins:maven-install-plugin: checking for updates from xwiki-plugins-releases [INFO] resources:resources [INFO] Using default encoding to copy filtered resources. [INFO] snapshot com.xpn.xwiki.platform:xwiki-core-parent:1.3-SNAPSHOT: checking for updates from xwiki-externals [INFO] snapshot com.xpn.xwiki.platform:xwiki:9-SNAPSHOT: checking for updates from xwiki-externals [INFO] snapshot com.xpn.xwiki.platform:xwiki-core-parent:1.3-SNAPSHOT: checking for updates from xwiki-externals [INFO] snapshot com.xpn.xwiki.platform:xwiki:9-SNAPSHOT: checking for updates from xwiki-externals [INFO] snapshot com.xpn.xwiki.platform:xwiki-web-gwt:1.3-SNAPSHOT: checking for updates from xwiki-externals [INFO] snapshot com.xpn.xwiki.platform:xwiki-web:1.3-SNAPSHOT: checking for updates from gwt-maven [INFO] snapshot com.xpn.xwiki.platform:xwiki-web:1.3-SNAPSHOT: checking for updates from xwiki-externals [INFO] snapshot com.xpn.xwiki.platform:xwiki:8-SNAPSHOT: checking for updates from gwt-maven [INFO] snapshot com.xpn.xwiki.platform:xwiki:8-SNAPSHOT: checking for updates from xwiki-externals [INFO] snapshot com.xpn.xwiki.platform:xwiki:8-SNAPSHOT: checking for updates from xwiki-snapshots [WARN] Cannot find parent POM: com.xpn.xwiki.platform:xwiki::8-SNAPSHOT for child: [inherited]:xwiki-web:pom:1.3-SNAPSHOT. Using stub model instead. [INFO] snapshot org.xwiki.platform:xwiki-core-plexus:1.3-SNAPSHOT: checking for updates from xwiki-externals [INFO] snapshot com.xpn.xwiki.platform:xwiki-core-parent:1.3-SNAPSHOT: checking for updates from xwiki-externals [INFO] snapshot com.xpn.xwiki.platform:xwiki:9-SNAPSHOT: checking for updates from xwiki-externals [INFO] snapshot org.xwiki.platform:xwiki-core-container-api:1.3-SNAPSHOT: checking for updates from xwiki-externals [INFO] snapshot org.xwiki.platform:xwiki-core-containers-parent:1.3-SNAPSHOT: checking for updates from xwiki-externals [INFO] snapshot com.xpn.xwiki.platform:xwiki-core-parent:1.3-SNAPSHOT: checking for updates from xwiki-externals [INFO] snapshot com.xpn.xwiki.platform:xwiki:9-SNAPSHOT: checking for updates from xwiki-externals [INFO] snapshot org.xwiki.platform:xwiki-core-url:1.3-SNAPSHOT: checking for updates from xwiki-externals [INFO] snapshot com.xpn.xwiki.platform:xwiki-core-parent:1.3-SNAPSHOT: checking for updates from xwiki-externals [INFO] snapshot com.xpn.xwiki.platform:xwiki:9-SNAPSHOT: checking for updates from xwiki-externals [INFO] snapshot org.xwiki.platform:xwiki-core-container-servlet:1.3-SNAPSHOT: checking for updates from xwiki-externals [INFO] snapshot org.xwiki.platform:xwiki-core-containers-parent:1.3-SNAPSHOT: checking for updates from xwiki-externals [INFO] snapshot com.xpn.xwiki.platform:xwiki-core-parent:1.3-SNAPSHOT: checking for updates from xwiki-externals [INFO] snapshot com.xpn.xwiki.platform:xwiki:9-SNAPSHOT: checking for updates from xwiki-externals [INFO] snapshot org.xwiki.platform:xwiki-core-action:1.3-SNAPSHOT: checking for updates from xwiki-externals [INFO] snapshot com.xpn.xwiki.platform:xwiki-core-parent:1.3-SNAPSHOT: checking for updates from xwiki-externals [INFO] snapshot com.xpn.xwiki.platform:xwiki:9-SNAPSHOT: checking for updates from xwiki-externals [INFO] snapshot com.xpn.xwiki.platform:xwiki-web-gwt:1.3-SNAPSHOT: checking for updates from xwiki-externals [INFO] snapshot org.xwiki.platform:xwiki-core-plexus:1.3-SNAPSHOT: checking for updates from xwiki-externals [INFO] snapshot org.xwiki.platform:xwiki-core-container-api:1.3-SNAPSHOT: checking for updates from xwiki-externals [INFO] snapshot org.xwiki.platform:xwiki-core-url:1.3-SNAPSHOT: checking for updates from xwiki-externals [INFO] snapshot org.xwiki.platform:xwiki-core-container-servlet:1.3-SNAPSHOT: checking for updates from xwiki-externals [INFO] snapshot org.xwiki.platform:xwiki-core-action:1.3-SNAPSHOT: checking for updates from xwiki-externals [INFO] Setting property: classpath.resource.loader.class => 'org.codehaus.plexus.velocity.ContextClassLoaderResourceLoader'. [INFO] Setting property: velocimacro.messages.on => 'false'. [INFO] Setting property: resource.loader => 'classpath'. [INFO] Setting property: resource.manager.logwhenfound => 'false'. [INFO] remote-resources:process [WARN] Attempting to build MavenProject instance for Artifact (org.codehaus.swizzle:swizzle-confluence:1.1-20070908) of type: jar; constructing POM artifact instead. [WARN] Attempting to build MavenProject instance for Artifact (xmlrpc:xmlrpc-client:3.0) of type: jar; constructing POM artifact instead. [WARN] Attempting to build MavenProject instance for Artifact (velocity:velocity:1.5) of type: jar; constructing POM artifact instead. [WARN] Attempting to build MavenProject instance for Artifact (xmlrpc:xmlrpc-server:3.0) of type: jar; constructing POM artifact instead. [WARN] Attempting to build MavenProject instance for Artifact (groovy:groovy-all-1.0-jsr:06) of type: jar; constructing POM artifact instead. [INFO] ---------------------------------------------------------------------------- [ERROR] BUILD FAILURE [INFO] ---------------------------------------------------------------------------- [INFO] org.apache.maven.model.Repository [INFO] ---------------------------------------------------------------------------- [INFO] Total time: 56 second [INFO] Finished at: Tue Jan 15 23:09:13 IST 2008 [INFO] Memory 19M/70M [INFO] ---------------------------------------------------------------------------- -- View this message in context: http://www.nabble.com/Error-building-from-source---xwiki-platform-web---sta… Sent from the XWiki- Dev mailing list archive at Nabble.com.

17 years, 6 months

3
8
0 0

[xwiki-devs] Working on fixing TC...

by Vincent Massol

just to let you know I'm working on fixing our TC build this morning. Thanks -Vincent

17 years, 6 months

1
0
0 0

[xwiki-devs] Need some information on the javascript code in xwiki

by Sachin Mittal

Hi, I was studying the javascript code used in the xwiki UI for making some extensions to it. I have found that we use at least 4 ajax toolkits on the UI: 1. YUI (some parts of it) 2. Rico 3. script.aculo.us 4. Prototype JavaScript Framework Plus there are some other bits and pieces of ajax code in many js files. I believe prototype is the basic js framework we use as both rico and script.aculo.us are built on top of this. Also lot of other js code is built on top of prototype js framework. Could anyone please confirm this If this is true I find atealst 4 different versions of prototype.js on the UI side. I have following questions: 1. Can I keep just one (latest version of prototype.js). 2. Also what would be the advisable version of prototype.js (latest is 1.6) 3. If there is some conflicts in the dependent js files and frameworks (rico and script.aculo.us), I am ready to upgrade them and also any used js code. So can anyone please tell me if any of the js code now lies redundant ie not used anymore. 4. Lastly is there any other important ajax framework or library we are using. Any information in this regard is highly appreciated. Thanks Sachin ----- http://www.assembla.com/wiki/show/sachin_mittal about me: -- View this message in context: http://www.nabble.com/Need-some-information-on-the-javascript-code-in-xwiki… Sent from the XWiki- Dev mailing list archive at Nabble.com.

17 years, 6 months

2
1
0 0

[xwiki-devs] [vote] Allow sandbox access to Julien Maire

by Sergiu Dumitriu

Hi devs, Julien Maire is currently working on XWiki Concerto (deals with integrating P2P technologies into XWiki, see http://concerto.xwiki.com/ ), and he has some code regarding synchronization among peers and content replication. I'd like to vote him as a sandbox committer, so that he can place his code in the XWiki repository. Here's my +1 -- Sergiu Dumitriu http://purl.org/net/sergiu/

17 years, 6 months

6
8
0 0

[xwiki-devs] Need some information on the javascript code in xwiki

by Sachin Mittal

Hi, I was studying the javascript code used in the xwiki UI for making some extensions to it. I have found that we use at least 4 ajax toolkits on the UI: 1. YUI (some parts of it) 2. Rico 3. script.aculo.us 4. Prototype JavaScript Framework Plus there are some other bits and pieces of ajax code in many js files. I believe prototype is the basic js framework we use as both rico and script.aculo.us are built on top of this. Also lot of other js code is built on top of prototype js framework. Could anyone please confirm this If this is true I find atealst 4 different versions of prototype.js on the UI side. I have following questions: 1. Can I keep just one (latest version of prototype.js). 2. Also what would be the advisable version of prototype.js (latest is 1.6) 3. If there is some conflicts in the dependent js files and frameworks (rico and script.aculo.us), I am ready to upgrade them and also any used js code. So can anyone please tell me if any of the js code now lies redundant ie not used anymore. 4. Lastly is there any other important ajax framework or library we are using. Any information in this regard is highly appreciated. Thanks ----- http://www.assembla.com/wiki/show/sachin_mittal about me: -- View this message in context: http://www.nabble.com/Need-some-information-on-the-javascript-code-in-xwiki… Sent from the XWiki- Dev mailing list archive at Nabble.com.

17 years, 6 months

1
0
0 0

[xwiki-devs] Need some information on the javascript code in xwiki

by Sachin Mittal

Hi, I was studying the javascript code used in the xwiki UI for making some extensions to it. I have found that we use at least 4 ajax toolkits on the UI: 1. YUI (some parts of it) 2. Rico 3. script.aculo.us 4. Prototype JavaScript Framework Plus there are some other bits and pieces of ajax code in many js files. I believe prototype is the basic js framework we use as both rico and script.aculo.us are built on top of this. Also lot of other js code is built on top of prototype js framework. Could anyone please confirm this If this is true I find atealst 4 different versions of prototype.js on the UI side. I have following questions: 1. Can I keep just one (latest version of prototype.js). 2. Also what would be the advisable version of prototype.js (latest is 1.6) 3. If there is some conflicts in the dependent js files and frameworks (rico and script.aculo.us), I am ready to upgrade them and also any used js code. So can anyone please tell me if any of the js code now lies redundant ie not used anymore. 4. Lastly is there any other important ajax framework or library we are using. Any information in this regard is highly appreciated. Thanks Sachin ----- http://www.assembla.com/wiki/show/sachin_mittal about me: -- View this message in context: http://www.nabble.com/Need-some-information-on-the-javascript-code-in-xwiki… Sent from the XWiki- Dev mailing list archive at Nabble.com.

17 years, 6 months

1
0
0 0

[xwiki-devs] [ANN] XWiki Enterprise 1.3 RC1 Released

by Vincent Massol

The XWiki development team is pleased to announce the release of XWiki Enterprise 1.3 RC 1. Go grab it at http://www.xwiki.org/xwiki/bin/view/Main/Download First release candidate for XWiki Enterprise 1.3 (and hopefully the last one). Main changes from 1.3M2: * Lots of bugs fixed * Improved Toucan Skin with several bug fixes on IE * Added a new XWiki.XWikiSyntax page that lists XWiki syntax to replace the link to the xwiki.org web site, thus allowing the ability to see syntax information even when offline. * Generalized Ajax Suggest Feature (see XWIKI-1604 - No documentation yet). * Ability to force a default language. * Ability to enable/disable the watchlist feature by wiki. Moved the Watchlist pages to an application proper (i.e. as XWiki documents) instead of template files. * Added License/Notice files to all released files. * Added ability to customize the email template for the Watchlist feature (the email template is located in the XWiki.WatchListMessage page). * The Watchlist feature now sends the change differences in the email. + lots of other changes For more information see the Release notes at: http://www.xwiki.org/xwiki/bin/view/Main/ReleaseNotesXWikiEnterprise13RC1 Thanks -The XWiki dev team

17 years, 6 months

1
0
0 0

[xwiki-devs] please, who give me the key about CalSWIM?

by [Ricardo Rodriguez] Your EPEC Network ICT Team

Hi all Sorry for cross-posting, but I am not sure what was the list where I've read the message where one of you give me an address or information leading to these websites: http://mondego.calit2.uci.edu:7000/xwiki/bin/view/Main/ http://calswim.org/ And the name of Crista Lopes (http://www.ics.uci.edu/~lopes/) A couple of days ago Ludovic points me again in the same direction. I though it was Paul Libbrecht or Guillaume Lerouge who firstly talk to me about these projects, but I am not able to find the email of reference. Please, to whoever I've forgotten: accept my apologies! But, could you resend me the reference, or just the original message if you have still it in your sent folder? Thanks!! All the best, Ricardo -- Ricardo Rodríguez Your EPEC Network ICT Team

17 years, 6 months

1
1
0 0

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

2005

xwiki-devs