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

[xwiki-devs] [Announcement] XWiki Platform and XWiki Enterprise 1.1 Release Candidate 1 released

by Sergiu Dumitriu

Hi, This is first release candidate for the final 1.1 release. It brings only several bug fixes and improvements, as the 1.1 release is almost ready. It was delayed a bit by unexpected bugs introduced by some fixes, but we managed to get it along. Unfortunately, there will have to be another release candidate, as right after finishing the release we detected several things that could be improved, and we're also trying to make the installer a bit more user-friendly. See the release notes ( http://www.xwiki.org/xwiki/bin/view/Main/ReleaseNotesXWikiEnterprise11RC1 ) for more details on this release. With release candidates we need your help more than ever for testing and reporting any remaining bug (and eventually provide a patch, too). Thanks! The XWiki developers team -- http://purl.org/net/sergiu _______________________________________________ devs mailing list devs(a)xwiki.org http://lists.xwiki.org/mailman/listinfo/devs

18 years

1
0
0 0

[xwiki-devs] FixRCS problem

by Raffaello Pelagalli

Hi everyone, After upgrading xwiki.org from XWiki 1.1b3 to 1.1RC1, I tryed to run the FixRCS script. I got an error "while parsing velocity page Wrapped Exception: Invocation of method 'getRenderedContent' in class com.xpn.xwiki.api.Document threw exception java.lang.StackOverflowError @ [7,7]" Here is the stack trace : Error number 4001 in 4: Error while parsing velocity page Wrapped Exception: Invocation of method 'getRenderedContent' in class com.xpn.xwiki.api.Document threw exception java.lang.StackOverflowError @ <unknown template>[7,7] com.xpn.xwiki.XWikiException: Error number 4001 in 4: Error while parsing velocity page Wrapped Exception: Invocation of method 'getRenderedContent' in class com.xpn.xwiki.api.Document threw exception java.lang.StackOverflowError @ <unknown template>[7,7] at com.xpn.xwiki.render.XWikiVelocityRenderer.evaluate(XWikiVelocityRenderer.java:148) at com.xpn.xwiki.XWiki.parseTemplate(XWiki.java:1240) at com.xpn.xwiki.XWiki.parseTemplate(XWiki.java:1201) at com.xpn.xwiki.api.XWiki.parseTemplate(XWiki.java:511) at sun.reflect.GeneratedMethodAccessor65.invoke(Unknown Source) at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25) at java.lang.reflect.Method.invoke(Method.java:585) at org.apache.velocity.util.introspection.UberspectImpl$VelMethodImpl.invoke(UberspectImpl.java:295) at org.apache.velocity.runtime.parser.node.ASTMethod.execute(ASTMethod.java:245) at org.apache.velocity.runtime.parser.node.ASTReference.execute(ASTReference.java:203) at org.apache.velocity.runtime.parser.node.ASTReference.render(ASTReference.java:294) at org.apache.velocity.runtime.parser.node.SimpleNode.render(SimpleNode.java:318) at org.apache.velocity.runtime.directive.VelocimacroProxy.render(VelocimacroProxy.java:194) at org.apache.velocity.runtime.parser.node.ASTDirective.render(ASTDirective.java:170) at org.apache.velocity.runtime.parser.node.ASTBlock.render(ASTBlock.java:74) at org.apache.velocity.runtime.parser.node.ASTIfStatement.render(ASTIfStatement.java:88) at org.apache.velocity.runtime.parser.node.ASTBlock.render(ASTBlock.java:74) at org.apache.velocity.runtime.parser.node.SimpleNode.render(SimpleNode.java:318) at org.apache.velocity.runtime.parser.node.ASTIfStatement.render(ASTIfStatement.java:107) at org.apache.velocity.runtime.parser.node.SimpleNode.render(SimpleNode.java:318) at com.xpn.xwiki.render.XWikiVelocityRenderer.evaluate(XWikiVelocityRenderer.java:240) at com.xpn.xwiki.render.XWikiVelocityRenderer.evaluate(XWikiVelocityRenderer.java:143) at com.xpn.xwiki.XWiki.parseTemplate(XWiki.java:1240) at com.xpn.xwiki.XWiki.parseTemplate(XWiki.java:1201) at com.xpn.xwiki.web.Utils.parseTemplate(Utils.java:94) at com.xpn.xwiki.web.XWikiAction.execute(XWikiAction.java:157) at org.apache.struts.action.RequestProcessor.processActionPerform(RequestProcessor.java:431) at org.apache.struts.action.RequestProcessor.process(RequestProcessor.java:236) at org.apache.struts.action.ActionServlet.process(ActionServlet.java:1196) at org.apache.struts.action.ActionServlet.doGet(ActionServlet.java:414) at javax.servlet.http.HttpServlet.service(HttpServlet.java:689) at javax.servlet.http.HttpServlet.service(HttpServlet.java:802) at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:252) at org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:173) at com.xpn.xwiki.web.SetCharacterEncodingFilter.doFilter(SetCharacterEncodingFilter.java:117) at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:202) at org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:173) at org.apache.catalina.core.StandardWrapperValve.invoke(StandardWrapperValve.java:213) at org.apache.catalina.core.StandardContextValve.invoke(StandardContextValve.java:178) at org.apache.catalina.core.StandardHostValve.invoke(StandardHostValve.java:126) at org.apache.catalina.valves.ErrorReportValve.invoke(ErrorReportValve.java:105) at org.apache.catalina.core.StandardEngineValve.invoke(StandardEngineValve.java:107) at org.apache.catalina.connector.CoyoteAdapter.service(CoyoteAdapter.java:148) at org.apache.coyote.http11.Http11Processor.process(Http11Processor.java:869) at org.apache.coyote.http11.Http11BaseProtocol$Http11ConnectionHandler.processConnection(Http11BaseProtocol.java:664) at org.apache.tomcat.util.net.PoolTcpEndpoint.processSocket(PoolTcpEndpoint.java:527) at org.apache.tomcat.util.net.LeaderFollowerWorkerThread.runIt(LeaderFollowerWorkerThread.java:80) at org.apache.tomcat.util.threads.ThreadPool$ControlRunnable.run(ThreadPool.java:684) at java.lang.Thread.run(Thread.java:595) Wrapped Exception: java.lang.StackOverflowError at java.util.regex.Pattern.atom(Pattern.java:1863) at java.util.regex.Pattern.sequence(Pattern.java:1743) at java.util.regex.Pattern.expr(Pattern.java:1687) at java.util.regex.Pattern.compile(Pattern.java:1397) at java.util.regex.Pattern.<init>(Pattern.java:1124) at java.util.regex.Pattern.compile(Pattern.java:817) at java.lang.String.replaceAll(String.java:2000) at org.codehaus.groovy.runtime.Invoker.format(Invoker.java:699) at org.codehaus.groovy.runtime.Invoker.format(Invoker.java:673) at org.codehaus.groovy.runtime.Invoker.format(Invoker.java:675) at org.codehaus.groovy.runtime.Invoker.format(Invoker.java:675) at org.codehaus.groovy.runtime.Invoker.format(Invoker.java:675) at org.codehaus.groovy.runtime.Invoker.format(Invoker.java:675) at org.codehaus.groovy.runtime.Invoker.format(Invoker.java:675) at org.codehaus.groovy.runtime.Invoker.format(Invoker.java:675) at org.codehaus.groovy.runtime.Invoker.format(Invoker.java:675) at org.codehaus.groovy.runtime.Invoker.format(Invoker.java:675) at org.codehaus.groovy.runtime.Invoker.format(Invoker.java:675) at org.codehaus.groovy.runtime.Invoker.format(Invoker.java:675) at org.codehaus.groovy.runtime.Invoker.format(Invoker.java:675) at org.codehaus.groovy.runtime.Invoker.format(Invoker.java:675) at org.codehaus.groovy.runtime.Invoker.format(Invoker.java:675) [...] last line x 1000 It seems like a recursion problem. -- Raffaello Pelagalli XPertNet - XWiki.com _______________________________________________ devs mailing list devs(a)xwiki.org http://lists.xwiki.org/mailman/listinfo/devs

18 years

1
0
0 0

[xwiki-devs] [Announcement] XWiki Platform and XWiki Enterprise 1.1 Release Candidate 1 released

by Sergiu Dumitriu

Hi, This is first release candidate for the final 1.1 release. It brings only several bug fixes and improvements, as the 1.1 release is almost ready. It was delayed a bit by unexpected bugs introduced by some fixes, but we managed to get it along. Unfortunately, there will have to be another release candidate, as right after finishing the release we detected several things that could be improved, and we're also trying to make the installer a bit more user-friendly. See the release notes ( http://www.xwiki.org/xwiki/bin/view/Main/ReleaseNotesXWikiEnterprise11RC1 ) for more details on this release. With release candidates we need your help more than ever for testing and reporting any remaining bug (and eventually provide a patch, too). Thanks! The XWiki developers team -- http://purl.org/net/sergiu _______________________________________________ devs mailing list devs(a)xwiki.org http://lists.xwiki.org/mailman/listinfo/devs

18 years

1
0
0 0

[xwiki-devs] XEclipse issues from 1.0M1

by Vincent Massol

Hi Tharindu/Asiri, As you've seen I've moved XEclipse to the trunk proper and released version 1.0M1. While testing it for the release, I've found some issues for which I've raised JIRA issues. Do you think you could schedule the ones you'd like to fix for 1.0M2 and also update the 1.0M2 plan so that we have a list of jira issues that are realistic for 1.0M2 (planned for the 10th of Sep). Again, well done for the 1.0M1 release. I'm eager to move xwiki.org to 1.1M4 or later to start using the XEclipse plugin :) Thanks -Vincent _______________________________________________ devs mailing list devs(a)xwiki.org http://lists.xwiki.org/mailman/listinfo/devs

18 years

3
2
0 0

[xwiki-devs] Exception While building xwiki

by Dinesh Chothe

Hi, I am developing Xwiki from source code. I am using maven-2.1-SNAPSHOTto build xwiki. Also using Linux,java1.6. While building I have came across following Exception... ignu@sixteen:~/xwiki_build/xwiki_src/trunks-users/xwiki-product-enterprise/distribution-test$ mvn install [INFO] Scanning for projects... [INFO] Reactor build order: [INFO] XWiki Products - Enterprise - Functional Tests [INFO] XWiki Products - Enterprise - Functional XMLRPC Tests [INFO] XWiki Products - Enterprise - Functional Selenium Tests [INFO] ---------------------------------------------------------------------------- [INFO] Building XWiki Products - Enterprise - Functional Tests [INFO] task-segment: [install] [INFO] ---------------------------------------------------------------------------- [INFO] [site:attach-descriptor] [INFO] [install:install] [INFO] Installing /media/sda6/xwiki_build/xwiki_src/trunks-users/xwiki-product-enterprise/distribution-test/pom.xml to /home/ignu/.m2/repository/com/xpn/xwiki/products/xwiki-enterprise-test/1.2-SNAPSHOT/xwiki- enterprise-test-1.2-SNAPSHOT.pom [INFO] ---------------------------------------------------------------------------- [INFO] Building XWiki Products - Enterprise - Functional XMLRPC Tests [INFO] task-segment: [install] [INFO] ---------------------------------------------------------------------------- Downloading: http://maven.xwiki.org/externals/groovy/groovy-all-1.0-jsr/06/groovy-all-1.… Downloading: http://maven.xwiki.org/releases/groovy/groovy-all-1.0-jsr/06/groovy-all-1.0… Downloading: http://repo1.maven.org/maven2/groovy/groovy-all-1.0-jsr/06/groovy-all-1.0-j… [INFO] [compiler:testCompile] [INFO] Nothing to compile - all classes are up to date [INFO] [site:attach-descriptor] [INFO] [dependency:unpack] [INFO] Configured Artifact: com.xpn.xwiki.products:xwiki-enterprise:hsqldb:1.2-SNAPSHOT:zip Downloading: http://maven.xwiki.org/snapshots/com/xpn/xwiki/products/xwiki-enterprise/1.… 40645K downloaded [INFO] Expanding: /home/ignu/.m2/repository/com/xpn/xwiki/products/xwiki-enterprise/1.2-SNAPSHOT/xwiki- enterprise-1.2-SNAPSHOT-hsqldb.zip into /media/sda6/xwiki_build/xwiki_src/trunks-users/xwiki-product-enterprise/distribution-test/xmlrpc-tests/target Downloading: http://maven.xwiki.org/externals/com/xpn/xwiki/platform/xwiki-core/1.2-SNAP… Downloading: http://maven.xwiki.org/snapshots/com/xpn/xwiki/platform/xwiki-core/1.2-SNAP… 19K downloaded [INFO] [surefire:test] [INFO] Surefire report directory: /media/sda6/xwiki_build/xwiki_src/trunks-users/xwiki-product-enterprise/distribution-test/xmlrpc-tests/target/surefire-reports org.apache.maven.surefire.booter.SurefireExecutionException: com.xpn.xwiki.it.xmlrpc.AllTests; nested exception is java.io.FileNotFoundException: /home/ignu/.m2/repository/com/xpn/xwiki/products/xwiki-enterprise-wiki/1.2-SNAPSHOT/xwiki- enterprise-wiki-1.2-SNAPSHOT.xar (No such file or directory); nested exception is org.apache.maven.surefire.testset.TestSetFailedException: com.xpn.xwiki.it.xmlrpc.AllTests; nested exception is java.io.FileNotFoundException : /home/ignu/.m2/repository/com/xpn/xwiki/products/xwiki-enterprise-wiki/1.2-SNAPSHOT/xwiki- enterprise-wiki-1.2-SNAPSHOT.xar (No such file or directory) org.apache.maven.surefire.testset.TestSetFailedException: com.xpn.xwiki.it.xmlrpc.AllTests ; nested exception is java.io.FileNotFoundException: /home/ignu/.m2/repository/com/xpn/xwiki/products/xwiki-enterprise-wiki/1.2-SNAPSHOT/xwiki- enterprise-wiki-1.2-SNAPSHOT.xar (No such file or directory) java.io.FileNotFoundException : /home/ignu/.m2/repository/com/xpn/xwiki/products/xwiki-enterprise-wiki/1.2-SNAPSHOT/xwiki- enterprise-wiki-1.2-SNAPSHOT.xar (No such file or directory) at java.io.FileInputStream.open(Native Method) at java.io.FileInputStream.<init>(FileInputStream.java:106) at java.io.FileInputStream.<init>(FileInputStream.java:66) at com.xpn.xwiki.it.xmlrpc.XhtmlValidityTest.readXarContents( XhtmlValidityTest.java :166) at com.xpn.xwiki.it.xmlrpc.XhtmlValidityTest.suite( XhtmlValidityTest.java:94) at com.xpn.xwiki.it.xmlrpc.AllTests.suite(AllTests.java:53) at sun.reflect.NativeMethodAccessorImpl.invoke0 (Native Method) at sun.reflect.NativeMethodAccessorImpl.invoke( NativeMethodAccessorImpl.java:39) at sun.reflect.DelegatingMethodAccessorImpl.invoke( DelegatingMethodAccessorImpl.java:25) at java.lang.reflect.Method.invoke(Method.java:597) at org.apache.maven.surefire.junit.JUnitTestSet.createInstanceFromSuiteMethod( JUnitTestSet.java:180) at org.apache.maven.surefire.junit.JUnitTestSet.constructTestObject( JUnitTestSet.java:140) at org.apache.maven.surefire.junit.JUnitTestSet.getTestCount( JUnitTestSet.java:247) at org.apache.maven.surefire.suite.AbstractDirectoryTestSuite.locateTestSets( AbstractDirectoryTestSuite.java :104) at org.apache.maven.surefire.Surefire.createSuiteFromDefinition( Surefire.java:150) at org.apache.maven.surefire.Surefire.run(Surefire.java:111) at sun.reflect.NativeMethodAccessorImpl.invoke0 (Native Method) at sun.reflect.NativeMethodAccessorImpl.invoke( NativeMethodAccessorImpl.java:39) at sun.reflect.DelegatingMethodAccessorImpl.invoke( DelegatingMethodAccessorImpl.java:25) at java.lang.reflect.Method.invoke(Method.java:597) at org.apache.maven.surefire.booter.SurefireBooter.runSuitesInProcess( SurefireBooter.java:290) at org.apache.maven.surefire.booter.SurefireBooter.main ( SurefireBooter.java:818) [INFO] ------------------------------------------------------------------------ [ERROR] BUILD ERROR [INFO] ------------------------------------------------------------------------ [INFO] There are test failures. [INFO] ------------------------------------------------------------------------ [INFO] For more information, run Maven with the -e switch [INFO] ------------------------------------------------------------------------ [INFO] Total time: 44 minutes 19 seconds [INFO] Finished at: Wed Aug 29 14:02:36 IST 2007 [INFO] Final Memory: 10M/17M [INFO] ------------------------------------------------------------------------ [INFO] [INFO] [INFO] ------------------------------------------------------------------------ [INFO] Reactor Summary: [INFO] ------------------------------------------------------------------------ [INFO] XWiki Products - Enterprise - Functional Tests ........ SUCCESS [ 0.665s] [INFO] XWiki Products - Enterprise - Functional XMLRPC Tests . FAILED [44: 18.231s] [INFO] XWiki Products - Enterprise - Functional Selenium Tests NOT BUILT [INFO] ------------------------------------------------------------------------ [INFO] Error for project: XWiki Products - Enterprise - Functional XMLRPC Tests (during org.apache.maven.plugins:maven-surefire-plugin:2.3:test) [INFO] ------------------------------------------------------------------------ [INFO] There are test failures. [INFO] ------------------------------------------------------------------------ [INFO] For more information, run Maven with the -e switch [INFO] ------------------------------------------------------------------------ [INFO] BUILD ERRORS [INFO] ------------------------------------------------------------------------ [INFO] Total time: 44 minutes 19 seconds [INFO] Finished at: Wed Aug 29 14:02:36 IST 2007 [INFO] Final Memory: 10M/17M [INFO] ------------------------------------------------------------------------ FATAL ERROR: Unable to configure the Maven application -- Dinesh P. Chothe INDICTRANS Computing in Indian Languages Mobile : +91 9850076045 Email : chothe.dinesh(a)gmail.com _______________________________________________ devs mailing list devs(a)xwiki.org http://lists.xwiki.org/mailman/listinfo/devs

18 years

1
0
0 0

Platform Core directory change for introducing components

by Vincent Massol

Hi, I'd like to make the following changes: * Move current code in platform/core/trunk/* to platform/core/trunk/ xwiki-core/*. In the future the goal is that this module is broken down into several other modules. * Create platform/core/trunk/xwiki-plexus: Will hold the classes to bootstrap plexus. * Create platform/core/trunk/xwiki-component: Will hold xwiki classes related to the component architecture. For example: XWiki's ComponentManager and the lifecycle classes (like Initializable for example). These are independent of the underlying component framework used (Plexus, OSGi, etc) I'll do that in the coming few days. Let me know if there's any issue. Thanks -Vincent

18 years

3
4
0 0

[xwiki-devs] Releasing 1.1 RC1

by Sergiu Dumitriu

Hi, I'm starting the release for XWiki 1.1 RC1. It was planned for yesterday, but was delayed due to several reasons: no mailing lists, some uncommitted code, some unresolved important bugs... It was already tested yesterday, and no bugs were discovered. There should be another RC in a few days, fixing some installer problems and the eventual bugs that might block a final 1.1 release. Sergiu -- http://purl.org/net/sergiu _______________________________________________ devs mailing list devs(a)xwiki.org http://lists.xwiki.org/mailman/listinfo/devs

18 years

1
0
0 0

[xwiki-devs] Fwd: Use Swizzle directly or use a facade (was Re: XEclipse 1.0M1 will only work for xwiki-core-1.1M4 (but not for xwiki-core-1.2-SNAPSHOT))

by Asiri Rathnayake

---------- Forwarded message ---------- From: Asiri Rathnayake <asiri.rathnayake(a)gmail.com> Date: Aug 29, 2007 1:33 AM Subject: Re: Use Swizzle directly or use a facade (was Re: XEclipse 1.0M1will only work for xwiki-core-1.1M4 (but not for xwiki-core-1.2-SNAPSHOT)) To: Vincent Massol <vincent(a)massol.net> Cc: Catalin Hritcu <catalin.hritcu(a)gmail.com>, XWiki Dev < xwiki-dev(a)objectweb.org>, Tharindu Jayasuriya <djtharindu(a)gmail.com>, Sergiu Dumitriu <sergiu.dumitriu(a)gmail.com> Hi All, With Catalin's patch we (Catalin & Myself worked together on this) were able to modify XEclipse to use swizzle underneath. XEclipse - XWiki object model is still preserved. For an example, IXWikiConnection, IXWikiSpace, IXWikiPage are all there but they delegate method calls to internal swizzle implementation rather than handling them ourselves. Currently we have XEclipse (modified to use swizzle) working against current xwiki trunk (not commited yet). Once we have make it work with XWiki 1.1, we'll commit it out (possibly by tomorrow). Thanks Catalin for all the help. - Asiri On 8/28/07, Vincent Massol <vincent(a)massol.net> wrote: > > Hi Catalin, > > A new healthy fight! :) > > See below. > > On Aug 27, 2007, at 10:32 PM, Catalin Hritcu wrote: > > [snip] > > >> Pros: > >> * A single way for all xwiki clients to connect to XWiki servers > >> * Less maintenance, less documentation, less work in general since > >> someone > >> else is developing swizzle :). This point only is huge. > >> > > I would not stress this. Actually I already worked quite a lot on > > improving swizzle so far and I think there are many other ways we will > > have to improve swizzle. What is nice about it was having a visible > > working project to start from, rather than implementing it from > > scratch. Having David to "guard" the source is just the cherry on top > > of the cake. > > You didn't spend even 1% of the time it took to create Swizzle as it > is today and if you think about how swizzle will evolve in the future > that percentage drops down to 0.01%. This is why I thought this > should be stressed out :) > > [snip] > > >> * If swizzle goes away or is abandonned then it'll be bad for > >> xwiki and we'd > >> need to support it/reintegrate it. > >> > > First, swizzle is open source so can't "go away", we can always > > continue to maintain it. > > That's harder than you think. Radeox went away and are we maintaining > it? Nope. Of course we can always say that it's because its > architecture was too limited, etc but had it been maintained its > architecture could have evolved too. The same would happen with > swizzle if it goes away IMO. But it's not only an issue of Swizzle > going away because it's abandoned. Imagine a competitor project > appears and it's better than swizzle for XWiki. How do we tell all > our users that they have to redo all their client code. We won't and > thus we probably won't move to this better project because we have > standardized on Swizzle. > > It's about having a stable client-side interface. > > I much prefer the approach where we define our model objects (we need > them anyway on the server so it may even be possible to share some of > them on the client - Not sure about this but it's a thought) and our > interfaces and we keep the implementation separate. I'm 100% for > implementing those interfaces with Swizzle. > > In addition we need to offer a XWiki-specific API so instead of > offering several remoting APIs I propose we offer only one. Then it's > up to the implementations to implement them. The confluence > implementation (using Swizzle) could throw NotImplementedException > for stuff it doesn't implement so that client code using it will be > 100% confluence-compatible if that's the user's desire. And we would > be able to have a single unified API that has all the XWiki-specific > stuff. > > > And if it ever goes abandoned how would this > > be any worse than what we have now? Now we have two "little-swizzle" > > implementations one of them was _already_ abandoned, and the other is > > very likely to grow into a full fledged "swizzle". Even if we have to > > maintain one swizzle it's a big gain over having to maintain many. > > See above. > > > > >> Actually this is a point that is > >> bothering me Catalin. I think we'd need our own object model and > >> expose that > >> as a component and then provide a default implementation using > >> swizzle > >> behind the hood. Same as what we're doing for everything. This > >> will also > >> make the API seamless WRT extra APIs we have for xwiki (like getting > >> objects, etc). > >> > > It is true that swizzle provides an implementation but not an > > interface. However, why can't we provide interfaces as part of the > > swizzle project ? Why can't we make swizzle more component-friendly by > > just changing it? Why would we need another XWiki-specific wrapper > > layer? > > Swizzle is not our project. We could become committers to it of > course but I assure you it's still going to be 100 times more > difficult to evolve Swizzle than to evolve XWiki code. For 2 reasons: > * We "own" XWiki. All committers on XWiki are interested by XWiki only. > * Swizzle has to stay generic and making a generic change is always > more difficult than making a specific change. The same applies to the > fact that Swizzle if confluence-specific. > > Regarding the confluence-specific, it bothers me that the only > remoting interface we're providing is confluence-specific and has > confluence written all over. I think we should offer a XWiki-specific > API and let the user choose the implementation he wants transparently > (confluence or not). > > > One advantage I see of improving swizzle rather than hiding it away is > > that this way we are guaranteed(!) to stay compatible with confluence > > on the common features. While if you start to develop wrappers on top > > of swizzle that may or may not be the case. > > We wouldn't loose this feature by using Swizzle as an implementation > of our API. > > >> So IMO: > >> * We shouldn't use swizzle directly > >> * We should develop our own client side Java Objects and API > >> *interface* for > >> people interacting with XWiki remotely. > >> > > Why can't interfaces be done inside the swizzle project ? Why should > > we try to hide swizzle away ? > > See above. > > >> - That API should be independent of the protocol used. > >> > > Swizzle is actually already independent of the protocol used. It could > > work with SOAP as well as XML-RPC if somebody went into the trouble to > > reimplement everything for SOAP. The interface would be the same and a > > client would not be able to tell any difference. > > Then all the best. We can benefit from that. > > >> - A default implementation should be done using swizzle. It'll > >> be mostly > >> empty and only call out swizzle objects/swizzle APIs > >> * XEClipse should be refactored to use this API > >> * This API should be developed using components and using the new > >> org.xwiki > >> namespace. > >> > > Why can't this be done in an interoperable fashion part of the swizzle > > project ? Why can't the namespace be org.codehaus.swizzle :) ? Isn't > > this "not-made-here" attitude? > > Yep and that's important IMO (see above). The strategy I'd like to > have for XWiki from now on is to develop components and provide XWiki > interface classes. The implementations can be done using whatever > external frameworks. > > >> WDYT? > >> > > I think that we have no good reason to hide swizzle away under more > > wrapper layers since _swizzle_is_a_wrapper_itself_, and I think that > > we can solve any modularity/componentization problems inside the > > swizzle project. > > See above again. > > Let's see what others say. > > Thanks > -Vincent > > _______________________________________________ devs mailing list devs(a)xwiki.org http://lists.xwiki.org/mailman/listinfo/devs

18 years

1
0
0 0

[xwiki-devs] Mailing lists: svn notifications working again

by Vincent Massol

Hi, We had some issues with scm mails not making it to the new lists. It's now been fixed. However this means we've lost a few commit emails (the ones done this morning till now). Sorry about that. Thanks -Vincent _______________________________________________ devs mailing list devs(a)xwiki.org http://lists.xwiki.org/mailman/listinfo/devs

18 years

1
1
0 0

Re: [xwiki-devs] Proposal: Breaking API changes in the XML-RPC implementation

by Marta Girdea

+1 On 8/28/07, Catalin Hritcu <catalin.hritcu(a)gmail.com> wrote: > Hello, > > In a previous message I explained that I will soon do breaking API > changes in the XML-RPC implementation, but I was not explicit enough > about. Here is what I plan to implement ASAP if everybody agrees: > > 1) Remove the ConfluenceRpcInterface interface. We have already > discussed about dropping xmlrpc dynamic proxies in favor of swizzle > and the advantages this brings. This would be the last step towards > dropping dynamic proxies, and would ensure that there is no confusion > for users (of course this will also be documented on xwiki.org). > > 2) Remove the domain objects in the xwiki xmlrpc package. Again, we > are already using the swizzle domain objects. The only thing we still > have to settle is whether we will do it directly or through a facade, > and whether this facade will be part of xwiki or part of swizzle, but > this is the subject of another discussion. > > 3) Remove XWikiRpcHandler and XWikiRpcInterface. They are an attempt > to implement the JSPWiki interface that was not put into practice so > far. Currently only 2 methods are implemented: getPage and getAllPages > which return a string and a list of strings respectively. Even if > fully implemented I don't think that the JSPWiki interface would be > useful, since we already have the confluence api which is much more > powerful. > > The other xwiki modules will probably not be affected by these > changes. Existing users of the removed classes and interfaces will > have to adapt their code. However, since we just went from an "almost > working" implementation of XML-RPC to a working one, I believe that > this is the best moment to clean things up and make everything more > maintainable for the future. > > WDYT? > > Regards, > Catalin > _______________________________________________ > devs mailing list > devs(a)xwiki.org > http://lists.xwiki.org/mailman/listinfo/devs > _______________________________________________ devs mailing list devs(a)xwiki.org http://lists.xwiki.org/mailman/listinfo/devs

18 years

1
0
0 0

Re: [xwiki-devs] [xwiki-notifications] Build XWiki Platform Web::Default (HSQLDB) #184 failed

by Vincent Massol

Sorry about that, I committed some pom modifications by error. I've now reverted it. Thanks -Vincent On Aug 28, 2007, at 5:51 PM, teamcity(a)xwiki.org wrote: > Build XWiki Platform Web::Default (HSQLDB) #184 failed > Agent: Default agent > Build results: http://teamcity.xwiki.org/viewLog.html? > buildId=2160&buildTypeId=bt4 > > Changes included (1 change) > ==================================================== > Change 4535 by vmassol (1 file): > Uncomment the buildnumber plugin which was commented out by error > > see more information about changed files: http://teamcity.xwiki.org/ > viewLog.html?tab=buildChangesDiv&buildId=2160&buildTypeId=bt4 > > > ====================================================================== > ====== > Configure email notifications: http://teamcity.xwiki.org/ > profile.html?init=1#notifications > _______________________________________________ > notifications mailing list > notifications(a)xwiki.org > http://lists.xwiki.org/mailman/listinfo/notifications _______________________________________________ devs mailing list devs(a)xwiki.org http://lists.xwiki.org/mailman/listinfo/devs

18 years

1
0
0 0

[xwiki-devs] Fwd: Re: [xwiki-dev] xwiki database backup

by Catalin Hritcu

---------- Forwarded message ---------- From: anujssharma86(a)yahoo.co.in <anujssharma86(a)yahoo.co.in> Date: Aug 28, 2007 4:38 PM Subject: Re: Re: [xwiki-dev] xwiki database backup To: catalin.hritcu(a)gmail.com Hi Catalin, I am able to take the database backup. But what's happening is when i am restoring it the attachments are showing in the database but its not showing in xwiki interface where i had actually stored it. Thanks, Anuj _______________________________________________ devs mailing list devs(a)xwiki.org http://lists.xwiki.org/mailman/listinfo/devs

18 years

1
0
0 0

Re: [xwiki-devs] Proposal: Breaking API changes in the XML-RPC implementation

by Sergiu Dumitriu

+1 On 8/28/07, Catalin Hritcu <catalin.hritcu(a)gmail.com> wrote: > Hello, > > In a previous message I explained that I will soon do breaking API > changes in the XML-RPC implementation, but I was not explicit enough > about. Here is what I plan to implement ASAP if everybody agrees: > > 1) Remove the ConfluenceRpcInterface interface. We have already > discussed about dropping xmlrpc dynamic proxies in favor of swizzle > and the advantages this brings. This would be the last step towards > dropping dynamic proxies, and would ensure that there is no confusion > for users (of course this will also be documented on xwiki.org). > > 2) Remove the domain objects in the xwiki xmlrpc package. Again, we > are already using the swizzle domain objects. The only thing we still > have to settle is whether we will do it directly or through a facade, > and whether this facade will be part of xwiki or part of swizzle, but > this is the subject of another discussion. > > 3) Remove XWikiRpcHandler and XWikiRpcInterface. They are an attempt > to implement the JSPWiki interface that was not put into practice so > far. Currently only 2 methods are implemented: getPage and getAllPages > which return a string and a list of strings respectively. Even if > fully implemented I don't think that the JSPWiki interface would be > useful, since we already have the confluence api which is much more > powerful. > > The other xwiki modules will probably not be affected by these > changes. Existing users of the removed classes and interfaces will > have to adapt their code. However, since we just went from an "almost > working" implementation of XML-RPC to a working one, I believe that > this is the best moment to clean things up and make everything more > maintainable for the future. > > WDYT? > > Regards, > Catalin Sergiu -- http://purl.org/net/sergiu _______________________________________________ devs mailing list devs(a)xwiki.org http://lists.xwiki.org/mailman/listinfo/devs

18 years

1
0
0 0

[IMPORTANT] Mailing lists migration

by Vincent Massol

Hi everyone, We're currently undergoing mailing lists migration. As you've observed we've had some issues in the past and we're setting up a new mailing list server and new lists. We're automatically existing subscribers so you won't have anything to do. You'll just need to use the new lists when they're up. We'll send more information real soon. Thanks -Vincent

18 years

1
0
0 0

Setting up Xwiki for development

by xwicaforrica＠gmail.com

Greetings! I'm currently working on my master thesis, I've chosen XWiki as the wiki system that will support my platform. I used the Windows Installer in http://www.xwiki.org/xwiki/bin/view/Main/Download and easily set up a local xwiki instance, in order to explore it and learn how it works. But I shall probably have to adapt or create some functionality related to the Audit requirements I have defined (I'll save this for future posts ;) ), so I'd like to set up a development xwiki project using Eclipse. I followed the instructions in http://www.xwiki.org/xwiki/bin/view/Community/BuildingInEclipse: I checked out the source from the trunks-devs, ran mvn eclipse:eclipse and created a new eclipse workspace, which I included in a new variable M2_REPO. Finally I created a java project and did an import from the folder with all the code (xwiki-platform-tools, xwiki-platform-core, xwiki-platform-web, xwiki-platform-plugins and the others). The result was 22070 errors and 390 warnings in the 'Problems' tab! I think I must have missing something related to the building process.. being my first experience with eclipse, besides the tutorials, surely doesn't help! Could you guys help me? Thanks in advance and congratulations for the xwiki platform. I hope I can contribute with some code or plugins :) Best regards, Ricardo Pinto. Ps: By the way, I'm using Windows XP, Eclipse 3.2, JDK 1.5.10, Tortoise SVN (and will use mySQL after setting up the IDE environment).

18 years

6
10
0 0

xwiki database backup

by anujssharma86＠yahoo.co.in

I am working on XWiki MySQL database backup. I have to take the database backup and export it to other system within xwiki, so that the other system will have all the data . Can you please me, is there any plugin available for it or I have to create one new page and do some programming? If yes, then what code I have to write for the same. Thanks, Anuj

18 years

2
1
0 0

[VOTE] Release XEclipse 1.0M1

by Vincent Massol

Hi, I'd like to release XEclipse 1.0M1. Release notes: ** New Feature * [XECLIPSE-1] - Navigate the Documents tree and viewing XWiki pages. * [XECLIPSE-2] - Delete existing pages/spaces * [XECLIPSE-3] - Login to xwiki from Eclipse and import spaces selectively * [XECLIPSE-9] - Edit and Save pages * [XECLIPSE-10] - Add new pages/spaces ** Task * [XECLIPSE-11] - Clean up source code and apply XWiki development practices * [XECLIPSE-12] - Create Maven2 build for the Eclipse integration * [XECLIPSE-20] - Write a quick installation and using page for XEclipse * [XECLIPSE-25] - Move XEclipse to xwiki-extensions/ and out of the Sandbox Here's my +1 The list being down I'll take the risk of releasing it without more votes... I think we have already all agreed we wanted that release to happen ASAP. In addition, I've pinged on IRC and I got 3 +1: - Sergiu - Catalin - Stephane Thanks -Vincent

18 years

2
1
0 0

[Proposal] Document comments should not create new versions

by Sergiu Dumitriu

Hi, This is more a matter of opinions. Should a comment increase the version of a document? I'd say yes, but the view of simple users is that a comment should not affect the document, as it is something describing the document, not belonging to the document. So we should have a parameter that configures this. WDYT? Sergiu -- http://purl.org/net/sergiu

18 years

2
1
0 0

Use Swizzle directly or use a facade (was Re: XEclipse 1.0M1 will only work for xwiki-core-1.1M4 (but not for xwiki-core-1.2-SNAPSHOT))

by Vincent Massol

Hi Catalin, A new healthy fight! :) See below. On Aug 27, 2007, at 10:32 PM, Catalin Hritcu wrote: [snip] >> Pros: >> * A single way for all xwiki clients to connect to XWiki servers >> * Less maintenance, less documentation, less work in general since >> someone >> else is developing swizzle :). This point only is huge. >> > I would not stress this. Actually I already worked quite a lot on > improving swizzle so far and I think there are many other ways we will > have to improve swizzle. What is nice about it was having a visible > working project to start from, rather than implementing it from > scratch. Having David to "guard" the source is just the cherry on top > of the cake. You didn't spend even 1% of the time it took to create Swizzle as it is today and if you think about how swizzle will evolve in the future that percentage drops down to 0.01%. This is why I thought this should be stressed out :) [snip] >> * If swizzle goes away or is abandonned then it'll be bad for >> xwiki and we'd >> need to support it/reintegrate it. >> > First, swizzle is open source so can't "go away", we can always > continue to maintain it. That's harder than you think. Radeox went away and are we maintaining it? Nope. Of course we can always say that it's because its architecture was too limited, etc but had it been maintained its architecture could have evolved too. The same would happen with swizzle if it goes away IMO. But it's not only an issue of Swizzle going away because it's abandoned. Imagine a competitor project appears and it's better than swizzle for XWiki. How do we tell all our users that they have to redo all their client code. We won't and thus we probably won't move to this better project because we have standardized on Swizzle. It's about having a stable client-side interface. I much prefer the approach where we define our model objects (we need them anyway on the server so it may even be possible to share some of them on the client - Not sure about this but it's a thought) and our interfaces and we keep the implementation separate. I'm 100% for implementing those interfaces with Swizzle. In addition we need to offer a XWiki-specific API so instead of offering several remoting APIs I propose we offer only one. Then it's up to the implementations to implement them. The confluence implementation (using Swizzle) could throw NotImplementedException for stuff it doesn't implement so that client code using it will be 100% confluence-compatible if that's the user's desire. And we would be able to have a single unified API that has all the XWiki-specific stuff. > And if it ever goes abandoned how would this > be any worse than what we have now? Now we have two "little-swizzle" > implementations one of them was _already_ abandoned, and the other is > very likely to grow into a full fledged "swizzle". Even if we have to > maintain one swizzle it's a big gain over having to maintain many. See above. > >> Actually this is a point that is >> bothering me Catalin. I think we'd need our own object model and >> expose that >> as a component and then provide a default implementation using >> swizzle >> behind the hood. Same as what we're doing for everything. This >> will also >> make the API seamless WRT extra APIs we have for xwiki (like getting >> objects, etc). >> > It is true that swizzle provides an implementation but not an > interface. However, why can't we provide interfaces as part of the > swizzle project ? Why can't we make swizzle more component-friendly by > just changing it? Why would we need another XWiki-specific wrapper > layer? Swizzle is not our project. We could become committers to it of course but I assure you it's still going to be 100 times more difficult to evolve Swizzle than to evolve XWiki code. For 2 reasons: * We "own" XWiki. All committers on XWiki are interested by XWiki only. * Swizzle has to stay generic and making a generic change is always more difficult than making a specific change. The same applies to the fact that Swizzle if confluence-specific. Regarding the confluence-specific, it bothers me that the only remoting interface we're providing is confluence-specific and has confluence written all over. I think we should offer a XWiki-specific API and let the user choose the implementation he wants transparently (confluence or not). > One advantage I see of improving swizzle rather than hiding it away is > that this way we are guaranteed(!) to stay compatible with confluence > on the common features. While if you start to develop wrappers on top > of swizzle that may or may not be the case. We wouldn't loose this feature by using Swizzle as an implementation of our API. >> So IMO: >> * We shouldn't use swizzle directly >> * We should develop our own client side Java Objects and API >> *interface* for >> people interacting with XWiki remotely. >> > Why can't interfaces be done inside the swizzle project ? Why should > we try to hide swizzle away ? See above. >> - That API should be independent of the protocol used. >> > Swizzle is actually already independent of the protocol used. It could > work with SOAP as well as XML-RPC if somebody went into the trouble to > reimplement everything for SOAP. The interface would be the same and a > client would not be able to tell any difference. Then all the best. We can benefit from that. >> - A default implementation should be done using swizzle. It'll >> be mostly >> empty and only call out swizzle objects/swizzle APIs >> * XEClipse should be refactored to use this API >> * This API should be developed using components and using the new >> org.xwiki >> namespace. >> > Why can't this be done in an interoperable fashion part of the swizzle > project ? Why can't the namespace be org.codehaus.swizzle :) ? Isn't > this "not-made-here" attitude? Yep and that's important IMO (see above). The strategy I'd like to have for XWiki from now on is to develop components and provide XWiki interface classes. The implementations can be done using whatever external frameworks. >> WDYT? >> > I think that we have no good reason to hide swizzle away under more > wrapper layers since _swizzle_is_a_wrapper_itself_, and I think that > we can solve any modularity/componentization problems inside the > swizzle project. See above again. Let's see what others say. Thanks -Vincent

18 years

1
0
0 0

database backup

by anujssharma86＠yahoo.co.in

I am working on XWiki MySQL database backup. I want to take the database backup and export it to other system so that the other system will have all the data . Can you please help me whether I shall take a database backup in XWiki, or I have to create one new page for it? If yes, then what code I have to write for the same. Please Reply. Thanks, Anuj

18 years

1
0
0 0

XEclipse 1.0M1 will only work for xwiki-core-1.1M4 (but not for xwiki-core-1.2-SNAPSHOT)

by Catalin Hritcu

Hello, Until now I have refrained from making API breaking changes in XML-RPC in order to keep compatibility with XEclipse. However, these changes are necessary and cannot be delayed forever, so after the release of XEclipse 1.0M1 (scheduled for today) XEclipse 1.0-SNAPSHOT will need to be moved to swizzle-confluence. I volunteer to make this change happen in the XEclipse trunk once XEclipse 1.0M1 is released. To sum things up: - XEclipse 1.0M1 will only work for xwiki-core-1.1M4 (and all the remaining releases on the 1.1 branch) - XEclipse 1.0M2 will only work for xwiki-core-1.2M1 or later WDYT ? Catalin

18 years

3
8
0 0

[ANN] XWiki Eclipse 1.0 Milestone 1 Released

by Vincent Massol

Hi, We're delighted to release this first version of the XWiki Eclipse plugin. Announcement: http://www.xwiki.org/xwiki/bin/view/Blog/ XWikiEclipse10M1Released See the Eclipse plugin page for installation instructions and user guide: http://www.xwiki.org/xwiki/bin/view/Code/XEclipseExtension It's the result of one project from the Google Summer of Code 2007 and was done by Tharindu Jayasuriya and Asiri Rathnayake. Well done to both of you! We're happy to have you as XWiki committers for this XWiki Eclipse plugin. Let's now continue the good work you've started and keep improving this beastie. Release notes: * [XECLIPSE-1] - Navigate the Documents tree and viewing XWiki pages. * [XECLIPSE-2] - Delete existing pages/spaces * [XECLIPSE-3] - Login to xwiki from Eclipse and import spaces selectively * [XECLIPSE-9] - Edit and Save pages * [XECLIPSE-10] - Add new pages/spaces Enjoy! -The XWiki Dev Team

18 years

1
0
0 0

[VOTE] Commit Eclipse integration source code and give Commit rights to it to Tharindu and Asiri

by Vincent Massol

Hi, I'd like to commit the eclipse integration source code in a xwiki- extensions/xwiki-eclipse directory. Of course Tharindu/Asiri shoud clean up their code and align it with XWiki's coding conventions first and I won't commit anything until they do so. I'd also like to give them commit access to that section of our SVN (and NOT as general committers). Here's my +1 to both topics. Please cast your votes. Thanks -Vincent

18 years

4
4
0 0

Creating a SVN externals for Curriki

by Vincent Massol

Hi, I've had a request to create a svn external for curriki since they want to use the 1.1 branches from now on. I'm going to create it in [root]/externals/curriki-devs Would be nice to move our trunks-users and trunks-devs there too but I fear this may cause issues so I'll leave them where they are for now unless someone has a better idea. Thanks -Vincent

18 years

1
2
0 0

Strategy for FAQ handling

by Vincent Massol

Hi, Just wanted to explain my current strategy for FAQs on xwiki.org. Whenever I review FAQ pages I do the following: 1) Check if there's a page in the wiki that discusses the question mentioned in the FAQ page 2) If there is, remove the FAQ content and instead link to that page. If there were more information in the FAQ entry, move that information to the page proper 3) if there isn't, then create a new page, in the user guide, dev guide or admin guide and then go to step 2. IMO this is the best strategy for the best of both world: 1) Have a comprehensive documentation 2) Prevent duplication 3) Still keep the FAQ entries so that people can find them easily using google or the wiki search and then get directed to the relevant documentation page. All help is welcome! Thanks -Vincent

18 years

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