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

[xwiki-devs] [vuoe] Adding attached jar classloader in 1.1RC2

by Ludovic Dubost

Hi, I'd like to propose to vote to add this new feature in 1.1RC2 http://jira.xwiki.org/jira/browse/XWIKI-1671 I know we should not add features, but this one would allow to run groovy script requiring libs not included in the xwiki release. For example this could allow to package the Google Docs Summer of Code project as a pure extension without configuration and even restart. It's implementatin is very safe, as nothing changes unless you add a param or a value in the context. <http://fisheye2.cenqua.com/browse/xwiki/xwiki-platform/xwiki-applications/b…> Ludovic -- Ludovic Dubost Blog: http://www.ludovic.org/blog/ XWiki: http://www.xwiki.com Skype: ldubost GTalk: ldubost AIM: nvludo Yahoo: ludovic _______________________________________________ devs mailing list devs(a)xwiki.org http://lists.xwiki.org/mailman/listinfo/devs

18 years

5
6
0 0

[xwiki-devs] Fwd: [xwiki-dev] [Proposal] Document comments should not create new versions

by Erin Schnabel

New list address.. see what happens when you go on vacation? ---------- Forwarded message ---------- From: Erin Schnabel <ebullient.rain(a)gmail.com> Date: Sep 4, 2007 2:14 PM Subject: Re: [xwiki-dev] [Proposal] Document comments should not create new versions To: xwiki-dev(a)objectweb.org I don't think adding comments should increment the version, while adding tags, perhaps, should. Tags are an attribute of the document, in that they classify the document text. Comments are not part of the document content, are often edited separately (by the comment author), and can be deleted. The sticky issue is that attached objects are stored as part of the versioned content in the archive... How are changes that don't bump the version currently handled RE: archive? (sorry for being ignorant w/ this part..) On 8/28/07, Catalin Hritcu <catalin.hritcu(a)gmail.com> wrote: > Hi, > > This is not only related to comments but also to tags (also objects) > and maybe also attachments. The behavior you describe here for > comments is taken by confluence and I personally find it more > intuitive -- since it preserves the "forum metaphor" for the comments > (on a forum you can't "revert" what other people say). However it's > very hard to tell what would be best for the users (unless you do a > case study in which you ask 100+ users). > > The only question about having it as an option (for each class I > suppose if you want something generic) is how hard it is to implement > and roll-in ? > > Catalin > > On 8/24/07, Sergiu Dumitriu <sergiu.dumitriu(a)gmail.com> wrote: > > 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 > > > > > > > > -- > > You receive this message as a subscriber of the xwiki-dev(a)objectweb.org mailing list. > > To unsubscribe: mailto:xwiki-dev-unsubscribe@objectweb.org > > For general help: mailto:sympa@objectweb.org?subject=help > > ObjectWeb mailing lists service home page: http://www.objectweb.org/wws > > > > > > > > -- > You receive this message as a subscriber of the xwiki-dev(a)objectweb.org mailing list. > To unsubscribe: mailto:xwiki-dev-unsubscribe@objectweb.org > For general help: mailto:sympa@objectweb.org?subject=help > ObjectWeb mailing lists service home page: http://www.objectweb.org/wws > > -- 'Waste of a good apple' -Samwise Gamgee -- 'Waste of a good apple' -Samwise Gamgee _______________________________________________ devs mailing list devs(a)xwiki.org http://lists.xwiki.org/mailman/listinfo/devs

18 years

3
2
0 0

OC4J - JavaScript

by adoro

I had no problem to install Xwiki in the Tomcat environment. But when I deployed Xwiki under OC4J followed the OC4J Installation instructions ("http://www.xwiki.org/xwiki/bin/view/AdminGuide/InstallationOC4J"), javascript did not work properly – it looks like the path to external .js-files couldn't be found. Both IE and Firefox show javascript errors nearly on each page, although JavaScript is not deactivated in browser. I can open the home page, go to xwiki/bin/admin/XWiki/XWikiPreferences, upload xwiki-enterprise-wiki-1.1~.xar, but cannot expand it to choose the files I want to import. I have tried to include some JavaScript functions from import.js direct in the importinline.vm source – it works fine. What's the difference between: <script type="text/javascript" src="$xwiki.getSkinFile("import.js")"></script> - it generates path to /xwiki/skins/albatross/import.js and <script type="text/javascript" src="$xwiki.getSkinFile("import.js", true)"></script> - generates path to /xwiki/bin/skin/skins/albatross/import.js Why only some paths to js- and css files are defined with the parameter “true”? Is there something specific to keep in mind concerning path under OC4J? Should I make additional entries in some xml-files? Any tips please? Regards, adoro -- View this message in context: http://www.nabble.com/OC4J---JavaScript-tf4310450.html#a12271014 Sent from the XWiki- Dev mailing list archive at Nabble.com.

18 years

5
6
0 0

[xwiki-devs] Switching to JMock 2.0?

by Vincent Massol

Hi developers, Was just reading about JMock 2.0 this morning on http://jmock.org. I think it's great and we should swtich to it. It makes unit tests much easier to write. For example, check this: http://www.jmock.org/ ignoring.html WDYT? Thanks -Vincent

18 years

1
0
0 0

[xwiki-devs] getting error

by Anuj

_____ From: Anuj [mailto:86anuj@gmail.com] Sent: Wednesday, September 05, 2007 1:04 PM To: 'XWiki Developers' Subject: getting error Hi, I am getting error com.xpn.xwiki.XWikiException: Error number 3 in 0: Could not initialize main XWiki context Wrapped Exception: Error number 3202 in 3: Exception while reading document XWiki.XWikiPreferences Wrapped Exception: Could not create a DBCP pool while pointing my browser to http://localhost:8080/xwiki/ Thanks, Anuj _______________________________________________ devs mailing list devs(a)xwiki.org http://lists.xwiki.org/mailman/listinfo/devs

18 years

2
1
0 0

[xwiki-devs] error importing Xwiki.XwikiPreferences

by anuj sharma

Hi, I am getting error while importing Xwiki.XwikiPreferences. Can you please tell me why this is happening? I am using tomcat and Oracle 10g database. -- Thanks, ANUJ _______________________________________________ devs mailing list devs(a)xwiki.org http://lists.xwiki.org/mailman/listinfo/devs

18 years

4
3
0 0

Re: [xwiki-devs] [xwiki-notifications] r4670 - xwiki-products/curriki/branches

by Vincent Massol

Hi David, On Aug 30, 2007, at 7:51 PM, David Ward wrote: > Author: dward > Date: 2007-08-30 19:51:15 +0200 (Thu, 30 Aug 2007) > New Revision: 4670 > > Added: > xwiki-products/curriki/branches/curiki-1.2/ > Log: > - Branch created for Curriki 1.2 release > > > Copied: xwiki-products/curriki/branches/curiki-1.2 (from rev 4669, > xwiki-products/curriki/trunk) It seems the version numbers in the pom.xml files for curriki are wrong since that you're tagging some old revs with 1.2.x. Poms says 1.0-SNAPSHOT. Should that be fixed? Thanks -Vincent PS: I think we should have dedicated SVN/Mailing lists for curriki since it's not meant to follow the same practices than xwiki. Also every time curriki makes a commit, it increases the svn revs for xwiki and vice-versa. We need to think about that. Last trunks-devs/ users for xwiki/curriki should be separate IMO. WDY? _______________________________________________ devs mailing list devs(a)xwiki.org http://lists.xwiki.org/mailman/listinfo/devs

18 years

2
2
0 0

Re: [xwiki-devs] [xwiki-dev] Documentation and issue closing

by Vincent Massol

Hi Marc, On Jan 6, 2007, at 2:47 PM, Marc Lijour wrote: > On Saturday 06 January 2007 06:41, Vincent Massol wrote: > > Hi, > > > > I think we need to improve the way we update the documentation. > Right now I > > see several issues are marked as closed even though we haven't > documented > > them. Typical examples include new macros. They should be > documented on > > xwiki.org before we close the issue IMO. At the very least if for > some good > > reason we cannot do it immediately at least a new issue for > documenting > > them should be created at the same time so that it's not > forgotten and so > > that it's implemented in the future. > > > > Nobody likes documenting stuff so my belief is that someone who does > > something must do it completely, i.e. design, implement, > *document* and > > support. > > > > WDYT? > > Excellent idea. > I'd like to see some explanations in the javadoc as well. > > Is there already some guidelines about documenting code and project > (I mean > tutorial, dev guide, the web site content)? Here are some links: - http://www.xwiki.org/xwiki/bin/view/Community/DevelopmentPractices - http://www.xwiki.org/xwiki/bin/view/Community/CodeStyle and the Community space in general. Not much as been done since I proposed this idea however... Thanks -Vincent

18 years

1
0
0 0

Re: [xwiki-devs] error importing Xwiki.XwikiPreferences

by adoro

I have the similar problem with saving XwikiPreferences: the attempt to work with tabs "Preferences" and "Rights" comes to java errors: Error number 3201 in 3: Exception while saving document XWiki.XWikiPreferences Wrapped Exception: could not update: [com.xpn.xwiki.doc.XWikiDocumentArchive#104408758] com.xpn.xwiki.XWikiException: Error number 3201 in 3: Exception while saving document XWiki.XWikiPreferences Wrapped Exception: could not update: [com.xpn.xwiki.doc.XWikiDocumentArchive#104408758] at com.xpn.xwiki.store.XWikiHibernateStore.saveXWikiDoc(XWikiHibernateStore.java:317) at com.xpn.xwiki.store.XWikiCacheStore.saveXWikiDoc(XWikiCacheStore.java:97) at com.xpn.xwiki.store.XWikiCacheStore.saveXWikiDoc(XWikiCacheStore.java:91) at com.xpn.xwiki.XWiki.saveDocument(XWiki.java:924) at com.xpn.xwiki.web.SaveAction.save(SaveAction.java:113) at com.xpn.xwiki.web.SaveAndContinueAction.action(SaveAndContinueAction.java:64) at com.xpn.xwiki.web.XWikiAction.execute(XWikiAction.java:147) 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.doPost(ActionServlet.java:432) at javax.servlet.http.HttpServlet.service(HttpServlet.java:760) at javax.servlet.http.HttpServlet.service(HttpServlet.java:853) at com.evermind.server.http.ResourceFilterChain.doFilter(ResourceFilterChain.java:65) at com.xpn.xwiki.web.SetCharacterEncodingFilter.doFilter(SetCharacterEncodingFilter.java:117) at com.evermind.server.http.ServletRequestDispatcher.invoke(ServletRequestDispatcher.java:673) at com.evermind.server.http.ServletRequestDispatcher.forwardInternal(ServletRequestDispatcher.java:340) at com.evermind.server.http.HttpRequestHandler.processRequest(HttpRequestHandler.java:830) at com.evermind.server.http.AJPRequestHandler.run(AJPRequestHandler.java:228) at com.evermind.server.http.AJPRequestHandler.run(AJPRequestHandler.java:133) at com.evermind.util.ReleasableResourcePooledExecutor$MyWorker.run(ReleasableResourcePooledExecutor.java:186) at java.lang.Thread.run(Thread.java:595) Wrapped Exception: java.sql.SQLException: setString can only process strings of less than 32766 chararacters at oracle.jdbc.driver.DatabaseError.throwSqlException(DatabaseError.java:137) at oracle.jdbc.driver.DatabaseError.throwSqlException(DatabaseError.java:174) at oracle.jdbc.driver.DatabaseError.throwSqlException(DatabaseError.java:239) at oracle.jdbc.driver.OraclePreparedStatement.setStringInternal(OraclePreparedStatement.java:4771) at oracle.jdbc.driver.OraclePreparedStatement.setString(OraclePreparedStatement.java:4742) at org.apache.commons.dbcp.DelegatingPreparedStatement.setString(DelegatingPreparedStatement.java:131) at org.apache.commons.dbcp.DelegatingPreparedStatement.setString(DelegatingPreparedStatement.java:131) at org.hibernate.type.StringType.set(StringType.java:26) at org.hibernate.type.NullableType.nullSafeSet(NullableType.java:85) at org.hibernate.type.NullableType.nullSafeSet(NullableType.java:58) at org.hibernate.persister.entity.AbstractEntityPersister.dehydrate(AbstractEntityPersister.java:1826) at org.hibernate.persister.entity.AbstractEntityPersister.update(AbstractEntityPersister.java:2172) at org.hibernate.persister.entity.AbstractEntityPersister.updateOrInsert(AbstractEntityPersister.java:2118) at org.hibernate.persister.entity.AbstractEntityPersister.update(AbstractEntityPersister.java:2374) at org.hibernate.action.EntityUpdateAction.execute(EntityUpdateAction.java:84) at org.hibernate.engine.ActionQueue.execute(ActionQueue.java:243) at org.hibernate.engine.ActionQueue.executeActions(ActionQueue.java:227) at org.hibernate.engine.ActionQueue.executeActions(ActionQueue.java:141) at org.hibernate.event.def.AbstractFlushingEventListener.performExecutions(AbstractFlushingEventListener.java:296) at org.hibernate.event.def.DefaultFlushEventListener.onFlush(DefaultFlushEventListener.java:27) at org.hibernate.impl.SessionImpl.flush(SessionImpl.java:1009) at org.hibernate.impl.SessionImpl.managedFlush(SessionImpl.java:356) at org.hibernate.transaction.JDBCTransaction.commit(JDBCTransaction.java:106) at com.xpn.xwiki.store.XWikiHibernateBaseStore.endTransaction(XWikiHibernateBaseStore.java:611) at com.xpn.xwiki.store.XWikiHibernateBaseStore.endTransaction(XWikiHibernateBaseStore.java:585) at com.xpn.xwiki.store.XWikiHibernateStore.saveXWikiDoc(XWikiHibernateStore.java:307) at com.xpn.xwiki.store.XWikiCacheStore.saveXWikiDoc(XWikiCacheStore.java:97) at com.xpn.xwiki.store.XWikiCacheStore.saveXWikiDoc(XWikiCacheStore.java:91) at com.xpn.xwiki.XWiki.saveDocument(XWiki.java:924) at com.xpn.xwiki.web.SaveAction.save(SaveAction.java:113) at com.xpn.xwiki.web.SaveAndContinueAction.action(SaveAndContinueAction.java:64) at com.xpn.xwiki.web.XWikiAction.execute(XWikiAction.java:147) 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.doPost(ActionServlet.java:432) at javax.servlet.http.HttpServlet.service(HttpServlet.java:760) at javax.servlet.http.HttpServlet.service(HttpServlet.java:853) at com.evermind.server.http.ResourceFilterChain.doFilter(ResourceFilterChain.java:65) at com.xpn.xwiki.web.SetCharacterEncodingFilter.doFilter(SetCharacterEncodingFilter.java:117) at com.evermind.server.http.ServletRequestDispatcher.invoke(ServletRequestDispatcher.java:673) at com.evermind.server.http.ServletRequestDispatcher.forwardInternal(ServletRequestDispatcher.java:340) at com.evermind.server.http.HttpRequestHandler.processRequest(HttpRequestHandler.java:830) at com.evermind.server.http.AJPRequestHandler.run(AJPRequestHandler.java:228) at com.evermind.server.http.AJPRequestHandler.run(AJPRequestHandler.java:133) at com.evermind.util.ReleasableResourcePooledExecutor$MyWorker.run(ReleasableResourcePooledExecutor.java:186) at java.lang.Thread.run(Thread.java:595) ------- At the same time I get the following javascript error messages in javascript debugger (Firefox): Error ``ActiveXObject is not defined'' [xs] in file ``http://server/xwiki/skins/albatross/rico/prototype.js'', line 549, character 0. Error ``ActiveXObject is not defined'' [xs] in file ``http://server/xwiki/skins/albatross/rico/prototype.js'', line 550, character 0. I've installed XWiki 1.1 Enterprise M4 under Unix and use Oracle 10g and OC4J as container. Regards, adoro -- View this message in context: http://www.nabble.com/error-importing-Xwiki.XwikiPreferences-tf4351920.html… Sent from the XWiki- Dev mailing list archive at Nabble.com.

18 years

1
0
0 0

[xwiki-devs] XWiki needs your help for its continuous build

by Vincent Massol

Hi everyone, Some of you may have seen that we're now using TeamCity (http:// www.jetbrains.com/teamcity/) for XWiki's continuous build: http://teamcity.xwiki.org The nice thing is that TC allows to distribute the build work to build agents. XPertNet is currently providing one agent on the teamcity.xwiki.org machine. However we've found that the builds are stacking up and are a bit too long to run. Since TC supports parallel builds on different agents we'd like to call the community for help. If you have a machine that has some spare cycles for running XWiki builds then we could hook it up to the teamcity.xwiki.org server to distribute the build load. We don't need that many agents. Probably 1 or 2 (in addition to the one we have) would be enough for starters. Thanks! -Vincent, on behalf of the xwiki dev team _______________________________________________ devs mailing list devs(a)xwiki.org http://lists.xwiki.org/mailman/listinfo/devs

18 years

4
5
0 0

[xwiki-devs] [XEM] Dependencies on XWiki platform for 1.0

by Thomas Mortagne

Hi xwikiers, Some of XEM actual beta features need XWiki platform modifications. Problem is that XWIKI 1.1 is feature closed and 1.2 will be released too later for the first XEM release. I will comment theses feature here to see what can be done as reduce features, overload platform feature in place of modify etc. 1 – Create wiki from template wiki with includes (in place of copy) on the fly : Jira issues with patch : - http://jira.xwiki.org/jira/browse/XWIKI-1647 - http://jira.xwiki.org/jira/browse/XWIKI-1648 - http://jira.xwiki.org/jira/browse/XWIKI-1646 - Can make just simple wiki copy and postpone the "include on the fly feature" - Can duplicate actual copy wiki process but code copy is always very dangerous 2 – SuperClass and SuperDocument java convenient java classes to manage documents containing xwiki objects : Jira issues with patch : - http://jira.xwiki.org/jira/browse/XWIKI-1685 : can use the actual function with Class.getName() - http://jira.xwiki.org/jira/browse/XWIKI-1576 : can be "hosted" by muliwiki plugin for now 3 – XWikiServer user admin selection : Jira issues with patch : - http://jira.xwiki.org/jira/browse/XWIKI-1666 : can replace user list field by a simple string field 4 – Really delete wiki : Jira issues with patch : - http://jira.xwiki.org/jira/browse/XWIKI-1672 : really delete the database, we can just delete XWikiServer document and let a phantom database 5 – Easier error management in Velocity scripts : Jira issues with patch : - http://jira.xwiki.org/jira/browse/XWIKI-1571 : can be "hosted" by multiwiki plugin for now Regards, -- Thomas Mortagne

18 years

1
1
0 0

Re: [xwiki-devs] 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 Catalin Hritcu

Hi, On 9/4/07, Catalin Hritcu <catalin.hritcu(a)gmail.com> wrote: > Hello Vincent, > > I thought more about this and I think you are right, we should use a > facade. I will implement this in the following days. > Created http://jira.xwiki.org/jira/browse/XWIKI-1706 for this. Is there any way to reference this discussion from there ? Is there any working archive of the new devs mailing list ? Catalin > 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

2
5
0 0

[xwiki-devs] [Proposal/XEM] XWiki Enterprise Manager roadmap

by Thomas Mortagne

Hi xwikiers, As I discuss this with Ludovic, I propose a XEM (http://jira.xwiki.org/jira/browse/XEM) 1.0 roadmap : - 1.0 M1 : 2007-09-17 - wiki management - installer including default template wiki - 1.0 M2 : 2007-10-01 - basic statistics (just some informations in text) - user management based on new rights management system (http://jira.xwiki.org/jira/browse/XE-99) - 1.0 M3 : 2007-10-08 - advanced statistics (with graphical schemes) - 1.0 M4 : 2007-10-22 - dashboard - multi-wiki search based on Lucent - 1,0 RC1 : 2007-10-29 - 1,0 RC2 – Final : 2007-11-05 WDYT ? -- Thomas Mortagne _______________________________________________ devs mailing list devs(a)xwiki.org http://lists.xwiki.org/mailman/listinfo/devs

18 years

2
4
0 0

[xwiki-devs] getting error

by Anuj

Hi, I am getting error "Could not create a DBCP pool" while pointing my browser to http://localhost:8080/xwiki Thanks, Anuj _______________________________________________ devs mailing list devs(a)xwiki.org http://lists.xwiki.org/mailman/listinfo/devs

18 years

1
0
0 0

[xwiki-devs] [XEM] Automatic installation

by Thomas Mortagne

Hi all, Before launch the very first version of XEM (XWiki Enterprise Manager) I need to make some automatic installation system. At minimum XEM need : - root wiki which manage wiki farm - default template wiki from which other sub wiki can be created First the actual existing tools to manage package/installation : XE has generic installation system base on HSQLDB and Jetty that simply generate the HSQL database file at build time and package this in installation system. XEM can reuse most of this mechanism except for one part : HSQLDB. This database system can manage only one database which is unusable for multi-wiki purpose. It's mainly on that part I need to discuss what can be done and how. I already made some work around and think of what solutions I see. 1 - First I made an "automatic installation page" that is a root wiki document with attached xar. When that page is rendered, it check if there already exists at least one template wiki and, if not, create it from attached xar. Base on that it will be possible to make maven plugin able to attach XE xar at build time. 2 - Another solution is to work more on installation runtime and to ask user all necessary informations (database host, user, login, etc.) and initialize database with root wiki and all template or sub wiki we need. The first solution strength is that it doesn't depend on the way root wiki is deployed on database (installation init, import xar, etc.) but it load down root wiki with attached xar file and need to always check if XEM is already initialized. I think at long term the two solutions has to be possible but what of these (and other solutions I forget I'm sure) is most useful for other project or much more fast to implement that can be the first step ? Regards, -- Thomas Mortagne _______________________________________________ devs mailing list devs(a)xwiki.org http://lists.xwiki.org/mailman/listinfo/devs

18 years

1
0
0 0

[xwiki-devs] multi-wikies environment

by Miriam Natanzon

Hi all! I'm a programmer in an educational association called “Snunit” which located in Jerusalem, Israel. We want to create multi-wikies environment, such that every teacher can create his class's wiki. I want to build it, in one db. I think to add column of "wiki_id" to each relevant table, and in that way to hold the data about all the wikies. Is XWiki database support many wikies? (Without creating db for each specific wiki) Thank you! Miriam N. _______________________________________________ devs mailing list devs(a)xwiki.org http://lists.xwiki.org/mailman/listinfo/devs

18 years

2
1
0 0

[xwiki-devs] Form too large error!

by Ricardo Pinto

Good morning! I copied the contents of an excel (11 columns and 132 rows) to the wysiwyg editor of a new document and it pasted the data... but when I clicked on "Preview" the browser stalled for a while and then displayed the following message: «HTTP ERROR: 500 Form too large RequestURI=/xwiki/bin/preview/AGR/DocTabelaRegulacaoDT *Powered by Jetty:// <http://jetty.mortbay.org/>**»* ** In the console was printed the following message: *09:23:07.715 WARN!! [P1-18] org.mortbay.jetty.servlet.ServletHandler.handle (Serv letHandler.java:589) >11> /xwiki/bin/preview/AGR/DocTabelaRegulacaoDT: java.lang.IllegalStateException: Form too large at org.mortbay.http.HttpRequest.extractParameters(HttpRequest.java :840) at org.mortbay.http.HttpRequest.getParameter(HttpRequest.java:908) at org.mortbay.jetty.servlet.ServletHttpRequest.getParameter (ServletHttp Request.java:650) at com.xpn.xwiki.web.XWikiServletRequest.getParameter (XWikiServletReques t.java:193) at com.xpn.xwiki.web.EditForm.readRequest(EditForm.java:54) at com.xpn.xwiki.web.XWikiForm.reset(XWikiForm.java:59) at org.apache.struts.action.RequestProcessor.processPopulate (RequestProc essor.java:809) at org.apache.struts.action.RequestProcessor.process( RequestProcessor.ja va:203) at org.apache.struts.action.ActionServlet.process(ActionServlet.java :119 6) at org.apache.struts.action.ActionServlet.doPost(ActionServlet.java :432)* * at javax.servlet.http.HttpServlet.service(HttpServlet.java:616) at javax.servlet.http.HttpServlet.service(HttpServlet.java:689) at org.mortbay.jetty.servlet.ServletHolder.handle(ServletHolder.java :428 ) at org.mortbay.jetty.servlet.WebApplicationHandler$CachedChain.doFilter( WebApplicationHandler.java:830) at com.xpn.xwiki.web.SetCharacterEncodingFilter.doFilter (SetCharacterEnc odingFilter.java:118) at org.mortbay.jetty.servlet.WebApplicationHandler$CachedChain.doFilter( WebApplicationHandler.java:821) at org.mortbay.jetty.servlet.WebApplicationHandler.dispatch (WebApplicati onHandler.java:471) at org.mortbay.jetty.servlet.ServletHandler.handle( ServletHandler.java:5 68) at org.mortbay.http.HttpContext.handle(HttpContext.java:1565) at org.mortbay.jetty.servlet.WebApplicationContext.handle (WebApplication Context.java:633) at org.mortbay.http.HttpContext.handle(HttpContext.java:1517) at org.mortbay.http.HttpServer.service(HttpServer.java:954) at org.mortbay.http.HttpConnection.service(HttpConnection.java:816) at org.mortbay.http.HttpConnection.handleNext(HttpConnection.java :983) at org.mortbay.http.HttpConnection.handle(HttpConnection.java:833) at org.mortbay.http.SocketListener.handleConnection( SocketListener.java: 244) at org.mortbay.util.ThreadedServer.handle(ThreadedServer.java:357) at org.mortbay.util.ThreadPool$PoolThread.run(ThreadPool.java:534)* Is there any known limit to the amount of information a form can handle? Thanks for your tips, Ricardo. _______________________________________________ devs mailing list devs(a)xwiki.org http://lists.xwiki.org/mailman/listinfo/devs

18 years

1
0
0 0

[xwiki-devs] Passing arguments to a page to set IFrame source

by Ricardo Pinto

Hello! How can I pass some arguments to a wiki page? I'd like to have a page with a list of objects of the ApplicationClass (with some properties like Name, Description, Version, Type, Url/Path, etc.). Then there will be a button for each one that will redirect to a new page, passing the name and url/path of the chosen app. In this new page I'll have an iframe, for instance, that will show the web app according to the passed url (for local apps it could somehow launch the app), as well as a "AppFinding" ClassTemplate form for create new objects. What do you think? Again a plugin could be the better way of doing this... Thanks in advance for your help :) Best regards, Ricardo. _______________________________________________ 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] r4689 - xwiki-platform/core/trunk/xwiki-core/src/main/java/com/xpn/xwiki/store

by Vincent Massol

Hi Sergiu, On Sep 2, 2007, at 3:37 AM, Sergiu Dumitriu wrote: [snip] > catch (Exception e) { > - if ( log.isErrorEnabled() ) log.error("Failed updating > schema: " + e.getMessage()); > + if ( log.isErrorEnabled() ) { > + log.error("While executing query: " + sql); > + log.error("Failed updating schema: " + e.getMessage > ()); > + } > } > finally { > try { I have 2 comments: * I think a single line is better as having the same sentence on 2 differents log statements is strange. Something like: "Failed updating schema while executing query [" + sql + "]" * I think we need to pass "e" and not "e.getMessage()" so that we log the wrapped exceptions if any and get to the root of the problem. Especially as this is an error and I think we need to have stack traces for errors. So I propose something like: log.error("Failed updating schema while executing query [" + sql + "]", e); WDYT? Note: I had meant to improve storage errors in the past, see http:// jira.xwiki.org/jira/browse/XWIKI-466 Thanks -Vincent _______________________________________________ devs mailing list devs(a)xwiki.org http://lists.xwiki.org/mailman/listinfo/devs

18 years

1
0
0 0

[Proposal] Make XE the default maven build profile

by Sergiu Dumitriu

Hi, The current default profile, when building trunks-devs or trunks-users, is to build all components, including curriki, XEM, multiwiki. There is a profile defined for building only XE, but it is not the default one. Given the fact that most users only want to build XE, this should be the default profile. So I'd like to: - make the default profile = 'xe' - add an 'all' profile, which builds all the modules WDYT? Sergiu -- http://purl.org/net/sergiu

18 years

6
6
0 0

[xwiki-devs] Database Schema Doesn't matched

by Colin Tay

Hi all, I deploying Xwiki-1.0.exe on windows xp. However, i noticed the database schema provided in the installation xwiki_db.script doesn't matched with the one online at http://www.xwiki.org/xwiki/bin/view/DevGuide/DatabaseSchema. Why issit so? Regards --------------------------------- Real people. Real questions. Real answers. Share what you know. _______________________________________________ devs mailing list devs(a)xwiki.org http://lists.xwiki.org/mailman/listinfo/devs

18 years

2
1
0 0

[xwiki-devs] Database Schema Doesn't matched

by Colin Tay

Hi all, I deploying Xwiki-1.0.exe on windows xp. However, i noticed the database schema provided in the installation xwiki_db.script doesn't matched with the one online at http://www.xwiki.org/xwiki/bin/view/DevGuide/DatabaseSchema. Why issit so? Regards --------------------------------- Real people. Real questions. Real answers. Share what you know. _______________________________________________ devs mailing list devs(a)xwiki.org http://lists.xwiki.org/mailman/listinfo/devs

18 years

1
0
0 0

[xwiki-devs] Improvement to release process - Idea

by Vincent Massol

I think we need to test a new version in real before we release it. This will allow reducing the bugs we find. I propose we add the strategy of deploying a candidate release on xwiki.org first and play with it for 1 or 2 days before we release new version. This should allow us to validate that existing installs can be migrated to the new version as this is something we are currently not checking (since our build creates a new version from scratch). WDYT? If you're ok I'll add it to the release notes and we'll need to get Raffaello's help for this. Maybe we could stage xwiki.org and xwiki.com on a separate machine by copying the existing DBs to try them out rather than using the real system? Thanks -Vincent _______________________________________________ devs mailing list devs(a)xwiki.org http://lists.xwiki.org/mailman/listinfo/devs

18 years

1
0
0 0

[xwiki-devs] 1.1RC1 Full Screen editor not working

by shivshan

Hi Congratulations on this release. The full screen editing mode introduced in 1.1m4 is not working in RC1. I just get an empty screen with no icons or text area. Is this planned to be fixed in the next release? Or should is ubmit a Jira for this? Shiva -- View this message in context: http://www.nabble.com/1.1RC1-Full-Screen-editor-not-working-tf4354275.html#… Sent from the XWiki- Dev mailing list archive at Nabble.com. _______________________________________________ devs mailing list devs(a)xwiki.org http://lists.xwiki.org/mailman/listinfo/devs

18 years

2
3
0 0

[xwiki-devs] 1.1RC1 Zip file corrupted?

by shivshan

Hi The 1.1Rc1 war zip file for use with other containers seems to be corrupted. Shiva -- View this message in context: http://www.nabble.com/1.1RC1-Zip-file-corrupted--tf4353388.html#a12404677 Sent from the XWiki- Dev mailing list archive at Nabble.com. _______________________________________________ devs mailing list devs(a)xwiki.org http://lists.xwiki.org/mailman/listinfo/devs

18 years

2
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