xwiki-devs March 2008

xwiki-devs@xwiki.org

52 participants
193 discussions

by Vincent Massol

Hi, I'm moving our CI build to continuum today. More precisely: * I've modified the TC build so that it does only "mvn clean install" instead of "mvn clean deploy". I've left the site deployment for now though. I've also removed the email notifications. * I've modified our continuum instance to do "mvn clean deploy". I'm going to work today on stabilizing the build to ensure all is ok and when this is the case I'll add the email notifications. http://continuum.xwiki.org/continuum/projectGroupSummary.action?projectGrou… Thanks -Vincent

16 years, 9 months

Re: [xwiki-devs] [xwiki-notifications] r8202 - xwiki-platform/xwiki-tools/trunk/xwiki-jetty-resources/src/main/resources

by Vincent Massol

Hi Sergiu, Can you explain when the "form too large" error is happening and under what conditions? I read http://www.xwiki.org/xwiki/bin/view/FAQ/FormTooLargeError but didn't understand when it happens. Also, we must add comments in the files you've modified below to explain why we're doing this since this is not something obvious. Thanks -Vincent On Mar 5, 2008, at 1:43 AM, sdumitriu (SVN) wrote: > Author: sdumitriu > Date: 2008-03-05 01:43:57 +0100 (Wed, 05 Mar 2008) > New Revision: 8202 > > Modified: > xwiki-platform/xwiki-tools/trunk/xwiki-jetty-resources/src/main/ > resources/start_xwiki.bat > xwiki-platform/xwiki-tools/trunk/xwiki-jetty-resources/src/main/ > resources/start_xwiki.sh > xwiki-platform/xwiki-tools/trunk/xwiki-jetty-resources/src/main/ > resources/start_xwiki_debug.bat > xwiki-platform/xwiki-tools/trunk/xwiki-jetty-resources/src/main/ > resources/start_xwiki_debug.sh > Log: > XTJETTY-6: Increase the default maximum form content size on Jetty > Done. The new default is 1 million bytes. > > > Modified: xwiki-platform/xwiki-tools/trunk/xwiki-jetty-resources/src/ > main/resources/start_xwiki.bat > =================================================================== > --- xwiki-platform/xwiki-tools/trunk/xwiki-jetty-resources/src/main/ > resources/start_xwiki.bat 2008-03-04 23:38:30 UTC (rev 8201) > +++ xwiki-platform/xwiki-tools/trunk/xwiki-jetty-resources/src/main/ > resources/start_xwiki.bat 2008-03-05 00:43:57 UTC (rev 8202) > @@ -2,7 +2,7 @@ > set LANG=fr_FR.ISO8859-1 > set JETTY_HOME=jetty > set JETTY_PORT=8080 > -set JAVA_OPTS=-Xmx300m > +set JAVA_OPTS=-Xmx300m - > Dorg.mortbay.http.HttpRequest.maxFormContentSize=1000000 > > REM Ensure the logs directory exists as otherwise Jetty reports an > error > if not exist %JETTY_HOME%\logs mkdir %JETTY_HOME%\logs > > Modified: xwiki-platform/xwiki-tools/trunk/xwiki-jetty-resources/src/ > main/resources/start_xwiki.sh > =================================================================== > --- xwiki-platform/xwiki-tools/trunk/xwiki-jetty-resources/src/main/ > resources/start_xwiki.sh 2008-03-04 23:38:30 UTC (rev 8201) > +++ xwiki-platform/xwiki-tools/trunk/xwiki-jetty-resources/src/main/ > resources/start_xwiki.sh 2008-03-05 00:43:57 UTC (rev 8202) > @@ -17,7 +17,7 @@ > cd "$PRGDIR" > > JETTY_HOME=jetty > -JAVA_OPTS=-Xmx300m > +JAVA_OPTS=-Xmx300m - > Dorg.mortbay.http.HttpRequest.maxFormContentSize=1000000 > > # The port on which to start Jetty can be passed to this script as > the first argument > if [ -n "$1" ]; then > > Modified: xwiki-platform/xwiki-tools/trunk/xwiki-jetty-resources/src/ > main/resources/start_xwiki_debug.bat > =================================================================== > --- xwiki-platform/xwiki-tools/trunk/xwiki-jetty-resources/src/main/ > resources/start_xwiki_debug.bat 2008-03-04 23:38:30 UTC (rev 8201) > +++ xwiki-platform/xwiki-tools/trunk/xwiki-jetty-resources/src/main/ > resources/start_xwiki_debug.bat 2008-03-05 00:43:57 UTC (rev 8202) > @@ -2,7 +2,7 @@ > set LANG=fr_FR.ISO8859-1 > set JETTY_HOME=jetty > set JETTY_PORT=8080 > -set JAVA_OPTS=-Xmx300m -Xdebug -Xnoagent -Djava.compiler=NONE - > Xrunjdwp:transport=dt_socket,server=y,suspend=n,address=5005 > +set JAVA_OPTS="-Xmx300m -Xdebug -Xnoagent -Djava.compiler=NONE - > Xrunjdwp:transport=dt_socket,server=y,suspend=n,address=5005 - > Dorg.mortbay.http.HttpRequest.maxFormContentSize=1000000" > > # Jetty requires a logs directory to exist > if not exist %JETTY_HOME%\logs mkdir %JETTY_HOME%\logs > > Modified: xwiki-platform/xwiki-tools/trunk/xwiki-jetty-resources/src/ > main/resources/start_xwiki_debug.sh > =================================================================== > --- xwiki-platform/xwiki-tools/trunk/xwiki-jetty-resources/src/main/ > resources/start_xwiki_debug.sh 2008-03-04 23:38:30 UTC (rev 8201) > +++ xwiki-platform/xwiki-tools/trunk/xwiki-jetty-resources/src/main/ > resources/start_xwiki_debug.sh 2008-03-05 00:43:57 UTC (rev 8202) > @@ -17,7 +17,7 @@ > cd "$PRGDIR" > > JETTY_HOME=jetty > -JAVA_OPTS="-Xmx300m -Xdebug -Xnoagent -Djava.compiler=NONE - > Xrunjdwp:transport=dt_socket,server=y,suspend=n,address=5005" > +JAVA_OPTS="-Xmx300m -Xdebug -Xnoagent -Djava.compiler=NONE - > Xrunjdwp:transport=dt_socket,server=y,suspend=n,address=5005 - > Dorg.mortbay.http.HttpRequest.maxFormContentSize=1000000" > > # For enabling YourKit Profiling: > # JAVA_OPTS="$JAVA_OPTS -agentlib:yjpagent"

16 years, 9 months

[xwiki-devs] MetadataLuceneTutorial on xwiki.org - Where should it go?

by Vincent Massol

Hi everyone and Jean-Vivien, Jean-Vivien has done a lot of good work adding a tutorial on xwiki.org. See http://platform.xwiki.org/xwiki/bin/view/DevGuide/MetadataLuceneTutorial However I'm wondering where we should put it. Here's my current thinking: * This tutorial reflects Jean-Vivien's point of view only since it's never been discussed AFAIK and there's no general agreement about its content with the rest of the xwiki developers. As such I don't think it can be located in at the same level as the other tutorials which have been "endorsed" by the xwiki community. I see 2 solutions: 1) We move it to the draft area and Jean-Vivien submits it for review to the xwiki dev community. If the community agrees this is the right way to implement it we put it with the other tutorials/ 2) We move it to a contribution area that clearly marks the document as a contributor's view and not as endorsed by the xwiki development community. We don't have such a place today so we'll need to create it. We could create it as a subpage of the Tutorial page in the DevGuide or we could move it to the code zone to the code snippet space since what Jean-Vivien has done is basically provide code snippets to extend xwiki. It's a little bit more than a code snippet since it's also a tutorial so I'm not sure the code zone is the best place for it. WDYT? Jean-Vivien, some quick comments/questions on the content: * Jens Karmer was the original author of the Lucene plugin. Since then it's been worked on by numerous people. * You shouldn't put ":" in titles * The tutorial is missing a section at the beginning to explain what the tutorial is about * I haven't read the tutorial yet but if what you've done is useful why not consider improving xwiki's core to support what you need? For example it seems to me you're asking for a way to add custom metadata to the lucene plugin. This could easily be added as part of the lucene plugin API. Thanks -Vincent

16 years, 9 months

Re: [xwiki-devs] Building XWiki Core

by sachin mittal

Hi, JAVA_HOME points to jdk installation directory. JRE_HOME points to jre installation directory. I too have both installed and variables set. Try removing JRE_HOME for a change and see if this works. Also do the following: delete existing mvn folder. unzip mvn2.1 snapshot zip available on dev.xwiki in c folder. You can add the path to mvn bin in your system path. Then try mvn -version I have been building xwiki from source for quiet some time on windows and it works fine. If this still does not work you can connect me on sachin_mittal on skype and I would try to help you with the same. Thanks Sachin ---------------------------------------------------------------------- > > Message: 1 > Date: Tue, 4 Mar 2008 15:55:31 -0600 > From: "Kamna Jain" <kammy.scorpi(a)gmail.com> > Subject: Re: [xwiki-devs] Building XWiki Core > To: devs(a)xwiki.org > Message-ID: > <fb681d280803041355q1b3dd893uf1769a2ba41156c1(a)mail.gmail.com> > Content-Type: text/plain; charset="iso-8859-1" > > Yes, I have both JDK and JRE installed in the same location. (is that a > problem?) > Sachin, I did add the bin dir. of mvn install to the Path variable but it > does not seem to help. > mvn --version also gives the same error as mvn install: > > 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 > > This is the error I get. > > Thanks >

16 years, 9 months

Re: [xwiki-devs] Building XWiki Core

by Kamna Jain

Yes, I have both JDK and JRE installed in the same location. (is that a problem?) Sachin, I did add the bin dir. of mvn install to the Path variable but it does not seem to help. mvn --version also gives the same error as mvn install: 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 This is the error I get. Thanks On Tue, Mar 4, 2008 at 1:45 AM, <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 (Sergiu Dumitriu) > 2. [proposal] upgrade web-gwt to gwt 1.4 (ancapaula.luca(a)xwiki.com) > 3. Re: [proposal] upgrade web-gwt to gwt 1.4 (Sergiu Dumitriu) > 4. Re: GWT 1.4 upgrade (ancapaula.luca(a)xwiki.com) > 5. Re: [proposal] upgrade web-gwt to gwt 1.4 (Jerome Velociter) > 6. Re: Building Xwiki core (Kamna Jain) (sachin mittal) > 7. Re: [xwiki-notifications] r8181 - > xwiki-platform/core/trunk/xwiki-core/src/main/java/com/xpn/xwiki > (Vincent Massol) > 8. Re: [xwiki-notifications] r8184 - > xwiki-platform/core/branches/xwiki-core-1.3 > /xwiki-core/src/main/java/com/xpn/xwiki > (Vincent Massol) > 9. Re: GWT 1.4 upgrade (Vincent Massol) > > > ---------------------------------------------------------------------- > > Message: 1 > Date: Mon, 03 Mar 2008 22:43:48 +0100 > From: Sergiu Dumitriu <sergiu(a)xwiki.com> > Subject: Re: [xwiki-devs] Building Xwiki core > To: XWiki Developers <devs(a)xwiki.org> > Message-ID: <47CC7114.4040006(a)xwiki.com> > Content-Type: text/plain; charset=ISO-8859-1; format=flowed > > Kamna Jain wrote: > > 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. > > > > > > I remember seeing this on another windows machine. It has something to > do with that crappy thing they like to call an Operating System and the > way it executes the maven script. > > Do you by any chance have installed both the JDK and the JRE? > -- > Sergiu Dumitriu > http://purl.org/net/sergiu/ > > > ------------------------------ > > Message: 2 > Date: Mon, 3 Mar 2008 23:31:15 +0100 (CET) > From: ancapaula.luca(a)xwiki.com > Subject: [xwiki-devs] [proposal] upgrade web-gwt to gwt 1.4 > To: devs(a)xwiki.org > Message-ID: <51105.130.79.213.35.1204583475.squirrel(a)mail.xwiki.com> > Content-Type: text/plain;charset=iso-8859-1 > > 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? > > > > ------------------------------ > > Message: 3 > Date: Mon, 03 Mar 2008 23:39:36 +0100 > From: Sergiu Dumitriu <sergiu(a)xwiki.com> > Subject: Re: [xwiki-devs] [proposal] upgrade web-gwt to gwt 1.4 > To: XWiki Developers <devs(a)xwiki.org> > Message-ID: <47CC7E28.90507(a)xwiki.com> > Content-Type: text/plain; charset=ISO-8859-1; format=flowed > > ancapaula.luca(a)xwiki.com wrote: > > 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? > > > > +1 > -- > Sergiu Dumitriu > http://purl.org/net/sergiu/ > > > ------------------------------ > > Message: 4 > Date: Mon, 3 Mar 2008 23:51:35 +0100 (CET) > From: ancapaula.luca(a)xwiki.com > Subject: Re: [xwiki-devs] GWT 1.4 upgrade > To: "XWiki Developers" <devs(a)xwiki.org> > Message-ID: <39500.130.79.213.35.1204584695.squirrel(a)mail.xwiki.com> > Content-Type: text/plain;charset=iso-8859-1 > > Because from the reliability point of view the native gwt solution is > better than a third-party library and produces cleaner code while the > styling drawback can easily be ameliorated, we have chosen it from the two > and applied it for the gwt 1.4 upgrade branch. > > We also didn't get any response from the gwt-tk mailing list regarding a > future release. > > > 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? > > > > _______________________________________________ > > devs mailing list > > devs(a)xwiki.org > > http://lists.xwiki.org/mailman/listinfo/devs > > > > > > > ------------------------------ > > Message: 5 > Date: Tue, 4 Mar 2008 05:34:44 +0100 (CET) > From: "Jerome Velociter" <jerome(a)xwiki.com> > Subject: Re: [xwiki-devs] [proposal] upgrade web-gwt to gwt 1.4 > To: "XWiki Developers" <devs(a)xwiki.org> > Message-ID: <57026.86.124.34.145.1204605284.squirrel(a)mail.xwiki.com> > Content-Type: text/plain;charset=iso-8859-1 > > +1, > > Jerome. > > > 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? > > > > _______________________________________________ > > devs mailing list > > devs(a)xwiki.org > > http://lists.xwiki.org/mailman/listinfo/devs > > > > > > > ------------------------------ > > Message: 6 > Date: Tue, 4 Mar 2008 10:19:36 +0530 > From: "sachin mittal" <sjmittal(a)gmail.com> > Subject: Re: [xwiki-devs] Building Xwiki core (Kamna Jain) > To: devs(a)xwiki.org > Message-ID: > <79d89bcf0803032049r49a43339hf583a9d5f5526d5e(a)mail.gmail.com> > Content-Type: text/plain; charset="iso-8859-1" > > 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. > > >

16 years, 9 months

[xwiki-devs] [VOTE] Change the attachment archive storage

by Sergiu Dumitriu

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/

16 years, 9 months

[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/

16 years, 9 months

[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 :)

16 years, 9 months

[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?

16 years, 9 months

[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?

16 years, 9 months

Jump to page:

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

2005

xwiki-devs March 2008