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

Re: [xwiki-devs] [xwiki-notifications] r21266 - platform/xwiki-tools/trunk/xwiki-archetype-macro

by Sergiu Dumitriu

vmassol (SVN) wrote: > Author: vmassol > Date: 2009-06-12 20:20:40 +0200 (Fri, 12 Jun 2009) > New Revision: 21266 > > Added: > platform/xwiki-tools/trunk/xwiki-archetype-macro/archetype-catalog.xml > Log: > XWIKI-3977: Create a Maven Archetype to make it easy to create XWiki Macros > > * Added a catalog so that users can create macro archetype using: mvn archetype:generate -DarchetypeCatalog=http://svn.xwiki.org/svnroot/xwiki/platform/xwiki-tools/trunk/xwiki-archetype-macro/archetype-catalog.xml > * In the future we'll ask the Maven team to add our archetype to the default list of archetypes > > Added: platform/xwiki-tools/trunk/xwiki-archetype-macro/archetype-catalog.xml > =================================================================== > --- platform/xwiki-tools/trunk/xwiki-archetype-macro/archetype-catalog.xml (rev 0) > +++ platform/xwiki-tools/trunk/xwiki-archetype-macro/archetype-catalog.xml 2009-06-12 18:20:40 UTC (rev 21266) > @@ -0,0 +1,11 @@ > +<?xml version="1.0" encoding="UTF-8"?> > +<archetype-catalog> > + <archetypes> > + <archetype> > + <groupId>com.xpn.xwiki.platform.tools</groupId> > + <artifactId>xwiki-archetype-macro</artifactId> > + <version>1.0-SNAPSHOT</version> > + <description>Make it easy to create a maven project for creating XWiki Macros.</description> I think that "XWiki macro" is not a good term. These are rendering macros, and if we want to make the rendering generic, usable by other apps, then the macros should not be "XWiki macros". > + </archetype> > + </archetypes> > +</archetype-catalog> > -- Sergiu Dumitriu http://purl.org/net/sergiu/

16 years, 3 months

2
2
0 0

by Sergiu Dumitriu

lucaa (SVN) wrote: > Author: lucaa > Date: 2009-06-12 14:17:53 +0200 (Fri, 12 Jun 2009) > New Revision: 21251 > > Modified: > watch/trunk/gwt-client/src/main/java/com/xpn/xwiki/watch/client/Constants.java > watch/trunk/gwt-client/src/main/java/com/xpn/xwiki/watch/client/NewArticlesMonitoring.java > watch/trunk/gwt-client/src/main/java/com/xpn/xwiki/watch/client/Watch.java > watch/trunk/gwt-client/src/main/java/com/xpn/xwiki/watch/client/data/Config.java > watch/trunk/gwt-client/src/main/java/com/xpn/xwiki/watch/client/data/DataManager.java > watch/trunk/gwt-client/src/main/java/com/xpn/xwiki/watch/client/data/Feed.java > watch/trunk/gwt-client/src/main/java/com/xpn/xwiki/watch/client/data/FeedArticle.java > watch/trunk/gwt-client/src/main/java/com/xpn/xwiki/watch/client/data/FeedArticleComment.java > watch/trunk/gwt-client/src/main/java/com/xpn/xwiki/watch/client/data/FilterStatus.java > watch/trunk/gwt-client/src/main/java/com/xpn/xwiki/watch/client/data/Keyword.java > watch/trunk/gwt-client/src/main/java/com/xpn/xwiki/watch/client/ui/UserInterface.java > watch/trunk/gwt-client/src/main/java/com/xpn/xwiki/watch/client/ui/WatchWidget.java > watch/trunk/gwt-client/src/main/java/com/xpn/xwiki/watch/client/ui/articles/ActionBarWidget.java > watch/trunk/gwt-client/src/main/java/com/xpn/xwiki/watch/client/ui/articles/ArticleListWidget.java > watch/trunk/gwt-client/src/main/java/com/xpn/xwiki/watch/client/ui/articles/NavigationBarWidget.java > watch/trunk/gwt-client/src/main/java/com/xpn/xwiki/watch/client/ui/dialog/AnalysisDialog.java > watch/trunk/gwt-client/src/main/java/com/xpn/xwiki/watch/client/ui/dialog/CommentAddDialog.java > watch/trunk/gwt-client/src/main/java/com/xpn/xwiki/watch/client/ui/dialog/EditTagsDialog.java > watch/trunk/gwt-client/src/main/java/com/xpn/xwiki/watch/client/ui/dialog/FeedDialog.java > watch/trunk/gwt-client/src/main/java/com/xpn/xwiki/watch/client/ui/dialog/GroupDialog.java > watch/trunk/gwt-client/src/main/java/com/xpn/xwiki/watch/client/ui/dialog/KeywordDialog.java > watch/trunk/gwt-client/src/main/java/com/xpn/xwiki/watch/client/ui/dialog/LoadingStatusDialog.java > watch/trunk/gwt-client/src/main/java/com/xpn/xwiki/watch/client/ui/dialog/PressReviewDialog.java > watch/trunk/gwt-client/src/main/java/com/xpn/xwiki/watch/client/ui/dialog/PressReviewMailDialog.java > watch/trunk/gwt-client/src/main/java/com/xpn/xwiki/watch/client/ui/dialog/PreviewFeedDialog.java > watch/trunk/gwt-client/src/main/java/com/xpn/xwiki/watch/client/ui/dialog/SearchEngineFeedDialog.java > watch/trunk/gwt-client/src/main/java/com/xpn/xwiki/watch/client/ui/dialog/StandardFeedDialog.java > watch/trunk/gwt-client/src/main/java/com/xpn/xwiki/watch/client/ui/feedtree/FeedTreeWidget.java > watch/trunk/gwt-client/src/main/java/com/xpn/xwiki/watch/client/ui/filterbar/FilterBarWidget.java > watch/trunk/gwt-client/src/main/java/com/xpn/xwiki/watch/client/ui/filterbar/KeywordsWidget.java > watch/trunk/gwt-client/src/main/java/com/xpn/xwiki/watch/client/ui/filterbar/TagCloudWidget.java > watch/trunk/gwt-client/src/main/java/com/xpn/xwiki/watch/client/ui/title/SearchWidget.java > watch/trunk/gwt-client/src/main/java/com/xpn/xwiki/watch/client/ui/title/TitleBarWidget.java > watch/trunk/gwt-client/src/main/java/com/xpn/xwiki/watch/client/ui/utils/ImageTextButton.java > watch/trunk/gwt-client/src/main/java/com/xpn/xwiki/watch/client/ui/wizard/ConfigWizard.java > watch/trunk/gwt-client/src/main/java/com/xpn/xwiki/watch/client/ui/wizard/PressReviewWizard.java > watch/trunk/gwt-client/src/main/resources/com/xpn/xwiki/watch/public/Watch.css > watch/trunk/gwt-client/src/main/resources/com/xpn/xwiki/watch/public/minimal.css > Log: > Converted client code to unix style new lines. You should have set svn:eol-style instead. -- Sergiu Dumitriu http://purl.org/net/sergiu/

16 years, 3 months

1
0
0 0

[xwiki-devs] [Proposal] MathTex plugin integration

by Guillaume Legris

Hi dev folks, I developed a math plugin ("MathTex") to render LaTeX math expressions in XWiki. Currently the plugin supports two formula renderer: - The default one (contained in xwiki-plugin-mathtex-core.jar) is LGPL and thus can be embedded in the XWiki packages - The other one is GPL (powered by JMathTex) and gives better results. It can used by adding the xwiki-plugin-mathtex-ext.jar to the classpath and adding a parameter to the xwiki.cfg to override the default renderer (xwiki.plugins.mathtex.builder=org.thenesis.xwiki.plugin.mathtex.JMathTexFormulaImageBuilder) In order to work this plugin requires modifications of some parts of the XWiki default classes/files: - xwiki.cfg - macros.txt/macros.vm - struts-config.xml - XWikiRightServiceImpl.java (privileges for actions) So an admin couldn't just grab it from the plugin zone and make it work out-of-the-box. Hence I would like to propose this plugin for integration in XWiki with two alternatives: 1) Full integration 2) Partial integration (macros, struts-config.xml, XWikiRightServiceImpl.java changes) + users still have to load the plugin jar(s) from the plugin zone. --Guillaume Legris

16 years, 3 months

5
7
0 0

[xwiki-devs] [ANN] XWiki Office Release Candidate 1 Released!

by Florin Ciubotaru

The XWiki development team is pleased to announce the release of XWiki Office 1.0 Milestone RC1. XWiki Office is a XWiki.org project that provides integration between Microsoft Office and XWiki servers. Go grab it at: - http://www.xwiki.org/xwiki/bin/view/Main/Download#HXWikiOffice For more information about XOffice go at: - http://xoffice.xwiki.org/xwiki/bin/view/Main/ Main improvements introduces in version 1.0 RC1: - Faster Word startup - Fixed page publishing issues - Better & cleaner output - Improved html tables - Better lists and bullets - Cleaned grammar and spelling output - Small improvements on UI dialogs. All active XWord M3 clients and snapshot instances will be automatically updated to the latest version. For details about this release see the Release Notes at: - http://www.xwiki.org/xwiki/bin/view/Main/ReleaseNotesXOffice10RC1 You can also view the roadmap here: - http://xoffice.xwiki.org/xwiki/bin/view/Main/Roadmap Thanks -The XWiki dev team

16 years, 3 months

1
0
0 0

[xwiki-devs] [ANN] XWiki Enterprise Manager 1.7 Released

by Jean-Vincent Drean

The XWiki development team is pleased to announce the release of XWiki Enterprise Manager 1.7. Go grab it at http://www.xwiki.org/xwiki/bin/view/Main/Download XWiki Enterprise Manager 1.7 uses XWiki Enterprise 1.9. For more information see the release notes at: http://www.xwiki.org/xwiki/bin/view/Main/ReleaseNotesXWikiEnterprise19 Thanks, The XWiki dev team

16 years, 3 months

1
0
0 0

[xwiki-devs] [ANN] XWiki Enterprise 1.9 Released

by Jean-Vincent Drean

The XWiki development team is pleased to announce the release of XWiki Enterprise 1.9. Go grab it at http://www.xwiki.org/xwiki/bin/view/Main/Download Final release of the XWiki Enterprise 1.9 version. Main changes: * UI improvements ** Quick Jump to any Page navigation ** Faster Save and Continue using AJAX ** Improved Full Screen editing ** New Live Table UI ** Improved comments UI and functionality ** Multiple attachment upload in one request ** New UI for the Class and Object editors ** Improved toolbar in the wiki editor ** Preliminary support for Autosave * PDF export improvements * JavaScript improvements * Switched to UTF-8 as the default encoding * Mailsender improvements * New Office Importer feature: document splitting * XWiki 2.0 Syntax is enabled by default For more information see the Release notes at: http://www.xwiki.org/xwiki/bin/view/Main/ReleaseNotesXWikiEnterprise19 Thanks, The XWiki dev team

16 years, 3 months

1
0
0 0

[xwiki-devs] [VOTE] Require servlets 2.4

by Sergiu Dumitriu

Hi devs, Since XWIKI-3652, the web.xml is no longer valid servlet-2.3, since the 2.3 spec doesn't allow filters and the request dispatcher to mix. Given that currently 2.5 is the most implemented standard, I'd say that we require from now on a 2.4-compliant container. This will leave out only very old versions of the popular containers (tomcat <=4). Any objections? -- Sergiu Dumitriu http://purl.org/net/sergiu/

16 years, 3 months

3
2
0 0

Re: [xwiki-devs] [xwiki-notifications] r21134 - in sandbox/gsoc/xeclipse/org.xwiki.eclipse.ui: . META-INF icons lib src/main/java/org/xwiki/eclipse/ui src/main/java/org/xwiki/eclipse/ui/properties src/main/java/org/xwiki/eclipse/ui/render src/main/java/org/xwiki/eclipse/ui/views

by Sergiu Dumitriu

vnkatesh (SVN) wrote: > Author: vnkatesh > Date: 2009-06-10 02:04:02 +0200 (Wed, 10 Jun 2009) > New Revision: 21134 > > Added: > sandbox/gsoc/xeclipse/org.xwiki.eclipse.ui/lib/ > sandbox/gsoc/xeclipse/org.xwiki.eclipse.ui/lib/commons-beanutils-1.8.0.jar > sandbox/gsoc/xeclipse/org.xwiki.eclipse.ui/lib/commons-lang-2.4.jar > sandbox/gsoc/xeclipse/org.xwiki.eclipse.ui/lib/commons-logging-1.1.1.jar > sandbox/gsoc/xeclipse/org.xwiki.eclipse.ui/lib/dom4j-1.6.1.jar > sandbox/gsoc/xeclipse/org.xwiki.eclipse.ui/lib/htmlcleaner-2.1.jar > sandbox/gsoc/xeclipse/org.xwiki.eclipse.ui/lib/javacc-4.2.jar > sandbox/gsoc/xeclipse/org.xwiki.eclipse.ui/lib/jdom-1.1.jar > sandbox/gsoc/xeclipse/org.xwiki.eclipse.ui/lib/org.wikimodel.wem-2.0.7-20090407.jar > sandbox/gsoc/xeclipse/org.xwiki.eclipse.ui/lib/xercesImpl-2.9.1.jar > sandbox/gsoc/xeclipse/org.xwiki.eclipse.ui/lib/xml-apis-1.0.b2.jar > sandbox/gsoc/xeclipse/org.xwiki.eclipse.ui/lib/xwiki-core-component-api-2.0-SNAPSHOT.jar > sandbox/gsoc/xeclipse/org.xwiki.eclipse.ui/lib/xwiki-core-component-default-2.0-SNAPSHOT.jar > sandbox/gsoc/xeclipse/org.xwiki.eclipse.ui/lib/xwiki-core-container-api-2.0-SNAPSHOT.jar > sandbox/gsoc/xeclipse/org.xwiki.eclipse.ui/lib/xwiki-core-observation-2.0-SNAPSHOT.jar > sandbox/gsoc/xeclipse/org.xwiki.eclipse.ui/lib/xwiki-core-rendering-api-2.0-SNAPSHOT.jar > sandbox/gsoc/xeclipse/org.xwiki.eclipse.ui/lib/xwiki-core-rendering-parser-wikimodel-2.0-SNAPSHOT.jar > sandbox/gsoc/xeclipse/org.xwiki.eclipse.ui/lib/xwiki-core-xml-2.0-SNAPSHOT.jar > sandbox/gsoc/xeclipse/org.xwiki.eclipse.ui/src/main/java/org/xwiki/eclipse/ui/properties/XWikiEclipseAttachmentSummaryPropertiesPage.java > sandbox/gsoc/xeclipse/org.xwiki.eclipse.ui/src/main/java/org/xwiki/eclipse/ui/render/ > sandbox/gsoc/xeclipse/org.xwiki.eclipse.ui/src/main/java/org/xwiki/eclipse/ui/render/XHTMLRenderer.java > Modified: > sandbox/gsoc/xeclipse/org.xwiki.eclipse.ui/.classpath > sandbox/gsoc/xeclipse/org.xwiki.eclipse.ui/META-INF/MANIFEST.MF > sandbox/gsoc/xeclipse/org.xwiki.eclipse.ui/build.properties > sandbox/gsoc/xeclipse/org.xwiki.eclipse.ui/icons/xwiki.attachment.png > sandbox/gsoc/xeclipse/org.xwiki.eclipse.ui/plugin.xml > sandbox/gsoc/xeclipse/org.xwiki.eclipse.ui/src/main/java/org/xwiki/eclipse/ui/views/PagePreview.java > Log: > Standalone XWiki Rendering (Currently basic version, replacing the browser. no scripting support) > Attachment Property Page. > Are you sure you can't declare all these binary dependencies inside a pom? We don't usually put jars inside the sources. -- Sergiu Dumitriu http://purl.org/net/sergiu/

16 years, 3 months

2
1
0 0

[xwiki-devs] Using hibernate in xwiki plugin

by Igor Popov

Hello devs, Sorry for probably unappropriate question, but I'm new here and I'm stuck.. I'm writing my own plugin for xwiki and I need it to use hibernate. By the look of existing plugins (like ActivityStream plugin) it seems that I should somehow use XWiki hibernate configuration (after adding info about my mapping of course). How should I organize my plugin? Is there a way to create new hibernate sessions for my plugin using XWiki SessionFactory?

16 years, 3 months

1
0
0 0

[xwiki-devs] 1.9 final to be released in a few hours, need testers - Please raise blocking issues

by Vincent Massol

Hi Could everyone who has some time right now try 1.9 RC2 and test drive it, looking for regressions? Also could anyone knowing of any regression/blocking issue for 1.9 final please raise it now? We're about to release 1.9 final at the end of the day so this is the last chance to fix any blocking issue. Thanks -Vincent

16 years, 3 months

3
2
0 0

[xwiki-devs] Multiple remote DB for virtual wikis

by rupok sayeem

Hello Dev, I am relatively new with xwiki.Is it possible with xwiki that eash wiki will have there individual remote Database.we configure main wiki data base in hibernet.cfg.xml file. when we create a wiki it creates wiki schema within the main database or same database engine.but what i want is when we create a wiki it will create the database for that wiki in another remote database server.not in the same file of main wiki database.and when we load the wiki it will use the remote database not the main wiki database.please let me know if it is possible.it would be greateful if you refer me some links if exists. BR, Sayeem

16 years, 3 months

3
3
0 0

[xwiki-devs] Dropping support of Plexus (temporarily)?

by Vincent Massol

Hi, I'm having 2 problems with Plexus: 1) I tried to upgrade and it's not working. They've dropped the ability to dynamically register a new component instance for an existing role. Jason Van Zyl said he's ok to fix it but he's busy on other stuff and it's been now 2 weeks since he said he'll fix it. Generally speaking there are not many people working on Plexus core so it's not moving much. 2) I tried using events (it was there in alpha-31 but seem to have disappeared in recent versions - I may be wrong. However since there's zero documentation I had to try to find it in the code and couldn't find it) and couldn't. Even in alpha-31 it doesn't work (it works only for components located in components.xml but since we're dynamically registering components it doesn't work for us. Thus I'm more and more tempted to drop support for Plexus and instead use our Embedded component manager for now and start a xwiki-osgi module that would implement our SPI for OSGi. I've read OSGi documentation and it looks not too difficult to do. I have all the code done for sending Component Manager events but it won't work with Plexus so I'm proposing to use our Embedded CM for now. In the meantime I'll try to talk to Jason to see what can be done on the plexus side. WDYT? Note that our Embedded CM hasn't been tested for multithreading so we'll need to verify it works in the 2.0 dev cycle and fix any threading issue. Thanks -Vincent

16 years, 3 months

3
7
0 0

Re: [xwiki-devs] [xwiki-notifications] r20972 - platform/core/trunk/xwiki-rendering/xwiki-rendering-api/src/main/java/org/xwiki/rendering/parser

by Sergiu Dumitriu

vmassol (SVN) wrote: > Author: vmassol > Date: 2009-06-08 18:12:07 +0200 (Mon, 08 Jun 2009) > New Revision: 20972 > > Modified: > platform/core/trunk/xwiki-rendering/xwiki-rendering-api/src/main/java/org/xwiki/rendering/parser/ParseException.java > Log: > Removed unused stuff since WikiModel doesn't generate exception on parsing. If it does it means the underlying grammar is buggy and needs to be fixed. I would really like to have these working... -- Sergiu Dumitriu http://purl.org/net/sergiu/

16 years, 3 months

2
1
0 0

Re: [xwiki-devs] [xwiki-notifications] r20958 - platform/core/trunk/xwiki-rendering/xwiki-rendering-macros/xwiki-rendering-macro-rss/src/test/java/org/xwiki/rendering

by Vincent Massol

Do we have any code in our RSS macro that handles exception? If so all we need to have if a unit test with mocks that prove that when there's an error in the RSS access layer (rome?) then we handle it correctly. Thanks -Vincent On Jun 8, 2009, at 12:14 PM, asiri (SVN) wrote: > Author: asiri > Date: 2009-06-08 12:14:00 +0200 (Mon, 08 Jun 2009) > New Revision: 20958 > > Modified: > platform/core/trunk/xwiki-rendering/xwiki-rendering-macros/xwiki- > rendering-macro-rss/src/test/java/org/xwiki/rendering/ > RssMacroFailureConditionsTest.java > Log: > [misc] Removed the "connection timeout exception" test. This test is > non-deterministic. > > Modified: platform/core/trunk/xwiki-rendering/xwiki-rendering-macros/ > xwiki-rendering-macro-rss/src/test/java/org/xwiki/rendering/ > RssMacroFailureConditionsTest.java > =================================================================== > --- platform/core/trunk/xwiki-rendering/xwiki-rendering-macros/xwiki- > rendering-macro-rss/src/test/java/org/xwiki/rendering/ > RssMacroFailureConditionsTest.java 2009-06-08 08:43:44 UTC (rev 20957) > +++ platform/core/trunk/xwiki-rendering/xwiki-rendering-macros/xwiki- > rendering-macro-rss/src/test/java/org/xwiki/rendering/ > RssMacroFailureConditionsTest.java 2009-06-08 10:14:00 UTC (rev 20958) > @@ -44,27 +44,7 @@ > } catch (MacroExecutionException expected) { > assertTrue("The required 'feed' parameter is > missing".equals(expected.getMessage())); > } > - } > - > - /** > - * Tests the macro's behavior when the server hosting the feeds > doesn't respond. > - */ > - public void testConnectionTimeout() throws > MacroParameterException > - { > - assertNotNull(macro); > - assertNotNull(parameters); > - > - // We set the feed's URL to an unreachable address. > - parameters.setFeed("http://22.22.22.22"); > - > - try { > - macro.execute(parameters, null, null); > - fail("The macro should throw a 'Connection timeout > exception'"); > - } catch (MacroExecutionException expected) { > - String errorMessage = expected.getMessage(); > - assertTrue(errorMessage.startsWith("Connection timeout > when trying to reach")); > - } > - } > + } > > /** > * Tests the macro's behavior when the server hosting the feeds > doesn't respond.

16 years, 3 months

1
0
0 0

[xwiki-devs] [Discussion] Blacklisted/Hidden docs and spaces

by Vincent Massol

Hi everyone, Current situation ============= Right now we have 2 mechanisms in place: - hidden docs. These is done deep at the storage level and hidden docs don't appear in any HQL queries. This is - $blacklistedSpaces in xwikivars.vm which is used (or not!, that's the problem) in some wiki pages (AllDocs, Search, Dashboard, etc) Need ==== We have a need for blacklisted/hidden docs and spaces. This is different than rights. This is just for presentation purpose. The need I see is: - guest and simple users should not see blacklisted/hidden docs and spaces - advanced users and admin should see them (Note: I'm not sure we have a need to blacklist docs/spaces for everyone including admins as it's currently done for hidden docs) Issues ===== 1) In lots of spaces we don't exclude blacklisted spaces since at every location you have to add specific code to do the exclude. 2) Hidden docs are a problem since there are cases we want to see them all (like when creating a new wiki and you need to copy a template wiki containing hidden docs) Proposal ======= * I believe we need to remove the filtering at the storage level. That level should return all docs matching the queries * We modify the default XWiki.searchDocument APIs so that they filter on hidden docs and blacklisted spaces (using the velocity $blacklistedSpaces variable). This would be changed later on when we implement the new model and introduce the notion of space. When this happen we'll be able to have hidden metadata to the Space object. * We add a new XWiki.searchDocument API that doesn't do any filtering WDYT? Thanks -Vincent

16 years, 3 months

4
6
0 0

[xwiki-devs] [Proposal] Continuing work on xwiki-url

by Vincent Massol

Hi, I've progressed a bit over the weekend on our xwiki-url module. I've created a patch at http://jira.xwiki.org/jira/secure/attachment/15161/XWIKI-3951.txt Quickly the idea is to: * Make XWikiURL an interface * Add XWikiDocumentURL, XWikiAttachmentURL, etc for the various URL types * Examples of various XWiki URL types: document, attachment, skin, template, resource * Generify XWikiURLFactory * Introduce XWikiURLSerializer (for ex to generate standard URLs) Let me know what you think. I'd like to commit what I have already before progressing further. Thanks -Vincent

16 years, 3 months

2
1
0 0

[xwiki-devs] Help need in Javascriptextention

by Chathura Prabuddha

Hai... I tried to use the xwiki.javascrpitextention object to separate my javascript code.But it didn't work correctly.I included the whole javascript code in (Document Type Manager Demo) http://gsoc.myxwiki.org/xwiki/bin/view/DocTypeManagerDemo to here: http://gsoc.myxwiki.org/xwiki/bin/edit/DocTypeManagerDemo/DocTypeManagerScr… and then tried the $xwiki.jsx.use("DocTypeManagerDemo.DocTypeManagerScript"). you can see it in here (I commented it) http://gsoc.myxwiki.org/xwiki/bin/edit/DocTypeManagerDemo/WebHome?&editor=w…<http://gsoc.myxwiki.org/xwiki/bin/view/DocTypeManagerDemo> please give me some hints to fix this issue... :). Thank you. ~ Chathura Prabuddha Ganegoda~

16 years, 3 months

3
2
0 0

[xwiki-devs] XWiki Blog + Ecto3

by Andreas Schaefer

Hi Now that XWiki is up and running I can now pay attention to the little details that I would love to have. Top on my list for the Blog is to be able to create and manage entries through Ecto3. Now Ecto3 does not support XWiki or XWiki Blog and even using the Blogger type does not work even though I could connect to the server. Confluence does support Ecto (at least the Ecto2 verison) through the Blogger RPC API type. There are two ways to fix it. First a XWiki connection plugin could be created for Ecto but I would thing there are other blogging clients that would love to get access to XWiki. Another way would be to support other types of RCP APIs like Blogger (because that is what Confluence support(ed)). I don't know if that is sufficient for the entire Wiki but I think it should do the trick for the Blog. What do you think? Thanks Andreas Schaefer CEO of Madplanet.com Inc. Email: andreas.schaefer(a)madplanet.com schaefera(a)me.com Twitter; andy_mpc AIM: schaefera(a)me.com

16 years, 3 months

2
1
0 0

[xwiki-devs] Blog RSS Feed Problems with 1.8.3

by Andreas Schaefer

Hi I have a blog up and running with XWiki (http://madplanet.com/blog) but I have problems to create an RSS feed for it. I tried to use the snippet on: http://code.xwiki.org/xwiki/bin/view/Applications/BlogApplication but that does not work. The resulting XML is empty (only the XML header is there). Using the Blog Category Panel gives me links to the the Category Feeds but these feeds all point to the category 'Personal' no matter what category I put into. Could that be an issue with an outdate document (from 1.8 or so) ? How would I create a RSS Feed for the entire blog (all categories) and more specific is there a way to make the RSS feed symbol come up (on the Main.Blog site) in the address bar (blue-white RSS symbol on the right hand side) ? Thanks Andreas Schaefer CEO of Madplanet.com Inc. Email: andreas.schaefer(a)madplanet.com schaefera(a)me.com Twitter; andy_mpc AIM: schaefera(a)me.com

16 years, 3 months

4
14
0 0

Re: [xwiki-devs] [VOTE] HTML and Velocity macro NL/WS behaviors (TAKE 2)

by Vincent Massol

Hi, We really need to close this before 1.9 final. After discussing it with Thomas here's what we propose: * Introduce a "mode" parameter to the Velocity macro. It's a cleaning mode. * Implement 2 modes for now: - the current mode where no cleaning is done - the B2 mode as defined below (using $nl and $sp) * Introduce a xwiki.properties config to define the default mode (which would be B2 by default for now) This allows users who are already using the 2.0 syntax today to keep using the current mode. It also allows us to introduce new cleaning mode later on (such as the one Ludovic wanted). WDYT? Here's my +1 Thanks -Vincent PS: Please answer ASAP since 1.9 is supposed to be today and Thomas will need a few hours to implement this. On Thu, Apr 16, 2009 at 3:56 PM, Vincent Massol <vincent(a)massol.net> wrote: > Hi devs, > We need to come to a conclusion for handling New Lines(NL) and white spaces > (WS) in HTML and Velocity Macro. > If you remember from http://markmail.org/thread/mhqhxnz5twhev5se the current > problem is that we cannot indent scripts since WS and NL are meaningful. > I'd like to reiterate the proposal that was sent but not enough people voted > on it (only Thomas did). > A) For the HTML macro, we propose to make the following changes: > - strip NL/WS between elements (elements that don't accept CDATA) > - strip leading/trailing NL/WS for element content before passing them to > the wiki syntax parser > B) for the Velocity macro we have 2 choices I can think of: > 1) strip all leading spaces for all lines (but keep NL) > Note that this means that inside a velocity macro you wouldn't be able to > have a line break with the new line starting with spaces without escaping > the leading space with ~(space). > Note also that this means we will not be able to add extra new lines to > format the text nicely (since that would add new paragraphs) or split a > single line into several lines for extra readability. This is the case today > with the old syntax and it's a pain not to be able to aerate the text with > empty lines. > Ex: > some text > ~ next line #if (...) this goes on the same line #something(...) #end > This is a new paragraph > In this example notice that we need the velocity #if to be on the same line > since NL are significant. > 2) strip all leading spaces for all lines + remove all NL too. > This means we need to ensure we still have one space remaining between > "words" (same as HTML). > The user would use something like $nl and $sp to explicitely enter new lines > and spaces. > The advantage is that you control completely the formatting (no magic > anymore) at the cost of a little extra work (adding the $nl where > required). > Basically this means the same pros/cons as when you work with HTML where you > need to explicitly add <br/> when you want new lines. > Ex: > some text $nl > $sp next line > #if (...) > this goes on the same line > #something(...) <-- this is also on the same line > #end > $nl $nl > This a new paragraph > Note: I've aerated the text by putting extra new lines around the velocity > #if to show that it would work. > 3) Same as 1) + strip 1 NL (i.e. line breaks) and only allow "forced" line > breaks with "\\". > The exact algorithm is: if there's 1 NL remove it, if there's more than 1 > leave them. > Ex: > some text\\ > ~ next line > #if (...) > this goes on the same line > #something(...) <-- this is also on the same line > #end > This a new paragraph > I'm +1 for A) > For B) I think the most flexible is 2) but I'm wondering if it's too big a > change for our users or not. If not 2) then 3). > Thanks > -Vincent >

16 years, 3 months

5
9
0 0

Re: [xwiki-devs] [xwiki-notifications] r20881 - in sandbox/gsoc/xeclipse: org.xwiki.eclipse.core/src/main/java/org/xwiki/eclipse/core org.xwiki.eclipse.core/src/main/java/org/xwiki/eclipse/core/model org.xwiki.eclipse.core/src/main/java/org/xwiki/ecl

by Venkatesh Nandakumar

Hi Sergiu, Are you sure it's supposed to be OBJECT_SUMMARY_FILE_EXTENSION? Also see > the comment for the next file. > I was unsure then if I should go ahead with Attachment Caching, hence that was not the correct code. Florin and Fabio have both said not to look into that (LocalXWikiDatastorage) as of now. Why do you store both objects and attachments with the same code? > Shouldn't you create two lists instead? Why is that wrong? Both Attachments and Objects are shown in the tree as children of Pages. They are differentiated by the user with the help of icons (ImageDescriptor). I thought that was good enough. Venkatesh Nandakumar Department of Electronics & Computer Engineering Indian Institute of Technology Roorkee

16 years, 3 months

1
0
0 0

[xwiki-devs] Attachment Caching in XEclipse.

by Venkatesh Nandakumar

Hi, For the rest, I'll wait for your first contribution as soon as it's ready. > I have committed the attachment-display code, as I told you yesterday itself. Please do have a look at it. Should Attachments be cached (LocalXWikiDataStorage)? Or should it be done depending on size(I don't think xmlrpc function exists to check size)? In my opinion, Attachments should not be cached. I had initially thought of using LocalXWikiDataStorage, and then ran into some problems (At isLocallyAvailable() of DataManager class) because Attachment Class is defined by Confluence, and hence is not that flexible according to our requirements. Secondly, Caching a 2-5MB, say, attachment is not feasible. Is there any way around? What should I do when the user wants to "Open" the attachment from the Navigator? Venkatesh Nandakumar Department of Electronics & Computer Engineering Indian Institute of Technology Roorkee

16 years, 3 months

2
1
0 0

Re: [xwiki-devs] [xwiki-notifications] r20911 - enterprise/trunk/wiki/src/main/resources/XWiki

by Vincent Massol

On Jun 6, 2009, at 3:05 AM, sdumitriu (SVN) wrote: > Author: sdumitriu > Date: 2009-06-06 03:05:33 +0200 (Sat, 06 Jun 2009) > New Revision: 20911 > > Modified: > enterprise/trunk/wiki/src/main/resources/XWiki/WebSearchCode.xml > Log: > [cleanup] Minor code improvements. > > Modified: enterprise/trunk/wiki/src/main/resources/XWiki/ > WebSearchCode.xml > =================================================================== > --- enterprise/trunk/wiki/src/main/resources/XWiki/WebSearchCode.xml > 2009-06-06 00:53:45 UTC (rev 20910) > +++ enterprise/trunk/wiki/src/main/resources/XWiki/WebSearchCode.xml > 2009-06-06 01:05:33 UTC (rev 20911) > @@ -38,21 +38,20 @@ > #set($text = $text.replaceAll("'", "''").replaceAll("%", "\\%")) > #set($nbitems = 50) > ## ----------------------------------------------------------- > - ## Non-admins should not see results from XWiki, Admin and > - ## Panels spaces. Also exclude the WebPreferences doc. > - ## ----------------------------------------------------------- > - #if ($xwiki.hasAdminRights()) > - #set ($excludedWebs = '') > - #else > - #set ($excludedWebs = "doc.space<>'XWiki' and > doc.space<>'Admin' and doc.space<>'Panels' and > doc.name<>'WebPreferences' and") > - #end > - ## ----------------------------------------------------------- > ## Display only a given space if $request.space is defined > ## ----------------------------------------------------------- > #if("$!space" == '') > - #set ($webClause = $excludedWebs) > + ## ----------------------------------------------------------- > + ## Non-admins should not see results from XWiki, Admin and > + ## Panels spaces. Also exclude the WebPreferences doc. > + ## ----------------------------------------------------------- > + #if ($xwiki.hasAdminRights()) > + #set ($webClause = '') > + #else > + #set ($webClause = "doc.space<>'XWiki' and > doc.space<>'Admin' and doc.space<>'Panels' and > doc.name<>'WebPreferences' and") Actually this should use $blacklistedSpaces for excluding spaces. > > + #end > #else > - #set ($webClause = "doc.space='$space' and $excludedWebs") > + #set ($webClause = "doc.space='$space' and") > #end > #macro(addelement $item $list) > #if($xwiki.hasAccessLevel('view', $context.user, "$ > {context.database}:${item}")) Thanks -Vincent

16 years, 3 months

1
0
0 0

[xwiki-devs] Fwd: [ANN] Maven Assembly Plugin 2.2-beta-4 released

by Vincent Massol

Begin forwarded message: > From: John Casey <jdcasey(a)commonjava.org> > Date: June 5, 2009 10:35:04 PM CEDT > To: Maven Users List <users(a)maven.apache.org>, announce(a)maven.apache.org > Subject: [ANN] Maven Assembly Plugin 2.2-beta-4 released > Reply-To: "Maven Users List" <users(a)maven.apache.org> > > The Maven team is pleased to announce the release of the Maven > Assembly > Plugin, version 2.2-beta-4. > > This plugin is useful in creating project artifacts that custom > layouts. > It also includes a set of predefined standard custom artifact types > you > can choose to create. For more information, see: > > http://maven.apache.org/plugins/maven-assembly-plugin/ > > You should specify the version in your project's plugin configuration: > > <plugin> > <groupId>org.apache.maven.plugins</groupId> > <artifactId>maven-assembly-plugin</artifactId> > <version>2.2-beta-4</version> > </plugin> > > > Release Notes - Maven 2.x Assembly Plugin - Version 2.2-beta-4 > > > ** Bug > * [MASSEMBLY-238] - Assembly plugin removes file permissions this is useful for us. We can remove some todos from our pom files. -Vincent > * [MASSEMBLY-379] - Follow-up: file permissions are removed when > creating tar.gz assembly > * [MASSEMBLY-413] - Assembly plugin uses absolute paths from > project instance after interpolation > * [MASSEMBLY-414] - Allow regular expressions in include/exclude > patterns for filesets > * [MASSEMBLY-416] - outputDirectory default value in fileSet seems > changed; now seems to use directory name of fileSet sourcedir > * [MASSEMBLY-417] - regex in/exclusion patterns can fail on Windows > due to file-separator replacement. > * [MASSEMBLY-418] - Broken link to assembly-1.1.0-SNAPSHOT.xsd > * [MASSEMBLY-419] - All module directories are included with > complete system path > > ** Improvement > * [MASSEMBLY-421] - Maven repository layout like directory > structure using dependencySet > > > Enjoy, > > -The Maven team > > > --------------------------------------------------------------------- > To unsubscribe, e-mail: users-unsubscribe(a)maven.apache.org > For additional commands, e-mail: users-help(a)maven.apache.org >

16 years, 3 months

1
0
0 0

Re: [xwiki-devs] [xwiki-notifications] r20881 - in sandbox/gsoc/xeclipse: org.xwiki.eclipse.core/src/main/java/org/xwiki/eclipse/core org.xwiki.eclipse.core/src/main/java/org/xwiki/eclipse/core/model org.xwiki.eclipse.core/src/main/java/org/xwiki/eclipse/core/storage org.xwiki.eclipse.ui org.xwiki.eclipse.ui/icons org.xwiki.eclipse.ui/src/main/java/org/xwiki/eclipse/ui org.xwiki.eclipse.ui/src/main/java/org/xwiki/eclipse/ui/actions org.xwiki.eclipse.ui/src/main/java/org/xwiki/eclipse/ui/adapters

by Sergiu Dumitriu

vnkatesh (SVN) wrote: > Author: vnkatesh > Date: 2009-06-05 18:43:32 +0200 (Fri, 05 Jun 2009) > New Revision: 20881 > > Added: > sandbox/gsoc/xeclipse/org.xwiki.eclipse.core/src/main/java/org/xwiki/eclipse/core/model/ProxyXMLRpc.java > sandbox/gsoc/xeclipse/org.xwiki.eclipse.core/src/main/java/org/xwiki/eclipse/core/model/XWikiEclipseAttachmentSummary.java > sandbox/gsoc/xeclipse/org.xwiki.eclipse.ui/icons/xwiki.attachment.png > sandbox/gsoc/xeclipse/org.xwiki.eclipse.ui/src/main/java/org/xwiki/eclipse/ui/actions/XWikiEclipseAttachmentSummaryActionProvider.java > sandbox/gsoc/xeclipse/org.xwiki.eclipse.ui/src/main/java/org/xwiki/eclipse/ui/adapters/XWikiEclipseAttachmentSummaryAdapter.java > Modified: > sandbox/gsoc/xeclipse/org.xwiki.eclipse.core/src/main/java/org/xwiki/eclipse/core/DataManager.java > sandbox/gsoc/xeclipse/org.xwiki.eclipse.core/src/main/java/org/xwiki/eclipse/core/storage/LocalXWikiDataStorage.java > sandbox/gsoc/xeclipse/org.xwiki.eclipse.core/src/main/java/org/xwiki/eclipse/core/storage/RemoteXWikiDataStorage.java > sandbox/gsoc/xeclipse/org.xwiki.eclipse.ui/plugin.xml > sandbox/gsoc/xeclipse/org.xwiki.eclipse.ui/src/main/java/org/xwiki/eclipse/ui/UIConstants.java > sandbox/gsoc/xeclipse/org.xwiki.eclipse.ui/src/main/java/org/xwiki/eclipse/ui/adapters/AdapterFactory.java > sandbox/gsoc/xeclipse/org.xwiki.eclipse.ui/src/main/java/org/xwiki/eclipse/ui/adapters/XWikiEclipsePageSummaryAdapter.java > Log: > Basic Attachment Display. > No Functionality (Open/Properties) > Unsure of LocalDataStorageFunctionalities as of yet. > > Added: sandbox/gsoc/xeclipse/org.xwiki.eclipse.core/src/main/java/org/xwiki/eclipse/core/model/ProxyXMLRpc.java > =================================================================== > --- sandbox/gsoc/xeclipse/org.xwiki.eclipse.core/src/main/java/org/xwiki/eclipse/core/model/ProxyXMLRpc.java (rev 0) > +++ sandbox/gsoc/xeclipse/org.xwiki.eclipse.core/src/main/java/org/xwiki/eclipse/core/model/ProxyXMLRpc.java 2009-06-05 16:43:32 UTC (rev 20881) This is definitely not right: > + String url = "http://192.168.121.161:5005/xwiki/xmlrpc/confluence"; > + String user = "vnkatesh"; > + String pass = "ranjith"; > Added: sandbox/gsoc/xeclipse/org.xwiki.eclipse.core/src/main/java/org/xwiki/eclipse/core/model/XWikiEclipseAttachmentSummary.java > =================================================================== > --- sandbox/gsoc/xeclipse/org.xwiki.eclipse.core/src/main/java/org/xwiki/eclipse/core/model/XWikiEclipseAttachmentSummary.java (rev 0) > +++ sandbox/gsoc/xeclipse/org.xwiki.eclipse.core/src/main/java/org/xwiki/eclipse/core/model/XWikiEclipseAttachmentSummary.java 2009-06-05 16:43:32 UTC (rev 20881) > @@ -0,0 +1,47 @@ You should add the standard copyright notice header at the start of each new file. > +/** > + * > + */ > +package org.xwiki.eclipse.core.model; > + (non-Javadoc) comments are not useful. Either remove them or add a proper Javadoc. For @Override methods it's enough to turn the plain comment into a javadoc and replace the (non-Javadoc) line with {@inheritDoc}. > + /* > + * (non-Javadoc) > + * @see org.xwiki.eclipse.core.model.ModelObject#getXWikiEclipseId() > + */ > + @Override > Modified: sandbox/gsoc/xeclipse/org.xwiki.eclipse.core/src/main/java/org/xwiki/eclipse/core/storage/LocalXWikiDataStorage.java > =================================================================== > --- sandbox/gsoc/xeclipse/org.xwiki.eclipse.core/src/main/java/org/xwiki/eclipse/core/storage/LocalXWikiDataStorage.java 2009-06-05 16:37:12 UTC (rev 20880) > +++ sandbox/gsoc/xeclipse/org.xwiki.eclipse.core/src/main/java/org/xwiki/eclipse/core/storage/LocalXWikiDataStorage.java 2009-06-05 16:43:32 UTC (rev 20881) > + public List<Attachment> getAttachments(String pageId) throws XWikiEclipseException > + { > + List<Attachment> result = new ArrayList<Attachment>(); > + > + XWikiPage page = getPage(pageId); > + if (page == null) { > + return result; > + } > + > + IFolder pageFolder = baseFolder.getFolder(INDEX_DIRECTORY).getFolder(page.getSpace()).getFolder(pageId); > + if (pageFolder.exists()) { > + try { > + List<IResource> pageFolderResources = getChildResources(pageFolder, IResource.DEPTH_ONE); > + for (IResource pageFolderResource : pageFolderResources) { > + if (pageFolderResource instanceof IFile) { > + IFile file = (IFile) pageFolderResource; Are you sure it's supposed to be OBJECT_SUMMARY_FILE_EXTENSION? Also see the comment for the next file. > + if (file.getFileExtension().equals(OBJECT_SUMMARY_FILE_EXTENSION)) { > + Map<String, Object> map = (Map<String, Object>) CoreUtils.readDataFromXML(file); > + Attachment attachment = new Attachment(map); > + result.add(attachment); > + } > Modified: sandbox/gsoc/xeclipse/org.xwiki.eclipse.ui/src/main/java/org/xwiki/eclipse/ui/adapters/XWikiEclipsePageSummaryAdapter.java > =================================================================== > --- sandbox/gsoc/xeclipse/org.xwiki.eclipse.ui/src/main/java/org/xwiki/eclipse/ui/adapters/XWikiEclipsePageSummaryAdapter.java 2009-06-05 16:37:12 UTC (rev 20880) > +++ sandbox/gsoc/xeclipse/org.xwiki.eclipse.ui/src/main/java/org/xwiki/eclipse/ui/adapters/XWikiEclipsePageSummaryAdapter.java 2009-06-05 16:43:32 UTC (rev 20881) > @@ -32,7 +32,6 @@ Why do you store both objects and attachments with the same code? Shouldn't you create two lists instead? > try { > - List<XWikiEclipseObjectSummary> result = > - pageSummary.getDataManager().getObjects(pageSummary.getData().getId()); > + List result = pageSummary.getDataManager().getObjects(pageSummary.getData().getId()); > + result.addAll(pageSummary.getDataManager().getAttachments(pageSummary.getData().getId())); -- Sergiu Dumitriu http://purl.org/net/sergiu/

16 years, 3 months

1
0
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