xwiki-devs

xwiki-devs@xwiki.org

9400 discussions

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

by Vincent Massol

On May 20, 2008, at 11:27 AM, Sergiu Dumitriu wrote: > vmassol (SVN) wrote: >> Author: vmassol >> Date: 2008-05-19 09:08:08 +0200 (Mon, 19 May 2008) >> New Revision: 9854 >> >> Modified: >> xwiki-platform/core/trunk/xwiki-core/src/main/java/com/xpn/xwiki/ >> xmlrpc/XWikiXmlRpcHandler.java >> Log: >> * Replaced log.info with log.debug calls since we only want to >> print in the console when there are problems or for very important >> information (such as the XWiki version) in order not to "pollute" >> the output. >> * Fixed some copy paste errors ;) > > None of the error messages uses [] around parameters; I thought that > was > a convention for XWiki... It is. Fabio could you please fix them? >> @@ -287,7 +289,7 @@ >> if (!xwiki.getSpaces().contains(spaceKey)) { >> throw new XmlRpcException(String.format("[Space '%s' >> does not exist.]", spaceKey)); > [what's with the brackets?] Same. >> @@ -345,7 +347,7 @@ >> String pageFullName = String.format("%s.%s", spaceKey, >> pageName); >> >> if (!xwiki.exists(pageFullName)) { >> - log.warn(String.format( >> + LOG.warn(String.format( >> "[Page '%s' appears to be in space '%s' but no >> information is available.]", >> pageName)); >> } else { > > This will throw an exception, since it expects 2 arguments instead > of 1. Fabio? Thanks -Vincent PS: Sergiu, this is not code I wrote. I just fixed one aspect of the code which was the usage of info instead of debug for the logs.

16 years, 9 months

Re: [xwiki-devs] FW: New Admin Design direction

by Vincent Massol

On May 20, 2008, at 8:51 AM, Evelina Slatineanu wrote: > Hi, > > Yes, I've read that document a hundred times but the implementation > proposal > changed about that much too :P > So, yes, Vincent is right about the fact that we should follow the > interface > extension direction for the new applications that we are going to > make but, > so far, since we don't have the interface extensions I am a little bit > puzzled about the whole thing. What I don't know how to do is: > > 1. In what way an application should contribute admin pages to the > administration application? For this we should have at least some > classes & > objects generically defined for each application and the > administration one > to read these objects and to be able to know what to include (even > hardcoded) in the administration menu, as Vincent says. And isn't > this what > interface extension application is suppose to do? Please correct me > if I am > wrong or I did not understand the request. Right now the admin page should hardcode the link to the admin pages of the apps. This part will be replaced when IX are there. However before printing the link we should check if the application is present and don't show it if not (we can check for a known page from the application). > For example, let's say we have the Blog application. For now we have > global > administration and space administration. We have the rights, the > panels and > the presentation preferences included in the space administration > for Blog > space (this is something fixed). Where should go the other things > that the > Blog administration application wants to include in the > administration menu? > The things that Vincent wants to be hardcoded for now. In the space > administration page? In another administration page...? And how > should I > read these things? From what kind of objects or documents or > whatever else > may be used? 1) The space preferences (i.e. rights, preferences, etc) should be separated from the applications IMO. It seems better to have a generic page that allows to change these space by space rather than delegating this to the spaces. Especially since Application doesn't mean there's a space for that application. An application is only a set of pages right now. 2) For the Blog application what I mean by the admin page for Blog is page in the Blog application that allows changing: - Blog categories (edit, add new ones) - A link to the Article Class so that admin users can edit the stylsheet/template/class definition. 3) So in the left menu of the general admin page, we could hardcode a "Blog" link that links to the blog admin page defined in 2) (and only display it if the Blog app is present). The same goes for the Panels app. > Until now, after discussing with Jv, Thomas and Sergiu, the idea I > made > about the administration application is that it is a set of wiki > pages used > to administrate a wiki at global and space level (pretty much the > same kind > of application like Panels). But its implementation seems to change > the more > we discuss about it (which is a good thing of course) but now I am > really > confused. I don't see what's changing... Could you be more specific? The only thing I'd like NOT to see is (to continue with the Blog example) to have a blog admin page located in the general admin application. Now one question is whether we consider Import/Export, User/Group management, Preferences, Panels as 4 applications or not. I think for now we should consider them as 2: * the Admin app: Import/Export, User/Group management, Preferences * the Panels app WDYT? Thanks -Vincent > Can you help me understand WHAT exactly should I implement for now? > > Thanks, > Evelina > > -----Original Message----- > From: devs-bounces(a)xwiki.org [mailto:devs-bounces@xwiki.org] On > Behalf Of > Vincent Massol > Sent: Monday, May 19, 2008 1:06 PM > To: XWiki Developers > Subject: [xwiki-devs] New Admin Design direction > > Hi, > > Some comments I've discussed with JV about implementing > http://dev.xwiki.org/xwiki/bin/view/Design/ImproveWikiAdministration > > I believe we should design it in the following manner: > > * The Admin page is a generic empty shell > * An XWiki instance is made of applications (admin pages like users/ > groups/configs are part of the admin application too). Examples: Blog, > Calendar, Panels, etc > * Each application should be able to contribute admin pages to > configure/administrate itself. These pages should automatically appear > in the left menu on the new admin page. Note that this will require > interface extensions so right now we would hardcode them in the menu. > * What it means is that the admin page should link to the admin pages > located in the applications providing them. > > I know we're missing the interface extensions to make this work but > I'd like that our design for the new admin page works towards this > goal in mind. > > WDYT? > > Note: This email was prompted by Evelina asking if it was ok to attach > XARs to be imported in the XWiki.XWikiPeferences page. IMO it's not a > good thing to do. The XARs should be attached in the ImportExport > application pages (as it's done now). Now I have no idea how easy or > hard this is to implement since I haven't dived in the implementation. > > Thanks > -Vincent

16 years, 9 months

[xwiki-devs] FW: New Admin Design direction

by Evelina Slatineanu

Hi, Yes, I've read that document a hundred times but the implementation proposal changed about that much too :P So, yes, Vincent is right about the fact that we should follow the interface extension direction for the new applications that we are going to make but, so far, since we don't have the interface extensions I am a little bit puzzled about the whole thing. What I don't know how to do is: 1. In what way an application should contribute admin pages to the administration application? For this we should have at least some classes & objects generically defined for each application and the administration one to read these objects and to be able to know what to include (even hardcoded) in the administration menu, as Vincent says. And isn't this what interface extension application is suppose to do? Please correct me if I am wrong or I did not understand the request. For example, let's say we have the Blog application. For now we have global administration and space administration. We have the rights, the panels and the presentation preferences included in the space administration for Blog space (this is something fixed). Where should go the other things that the Blog administration application wants to include in the administration menu? The things that Vincent wants to be hardcoded for now. In the space administration page? In another administration page...? And how should I read these things? From what kind of objects or documents or whatever else may be used? Until now, after discussing with Jv, Thomas and Sergiu, the idea I made about the administration application is that it is a set of wiki pages used to administrate a wiki at global and space level (pretty much the same kind of application like Panels). But its implementation seems to change the more we discuss about it (which is a good thing of course) but now I am really confused. Can you help me understand WHAT exactly should I implement for now? Thanks, Evelina -----Original Message----- From: devs-bounces(a)xwiki.org [mailto:devs-bounces@xwiki.org] On Behalf Of Vincent Massol Sent: Monday, May 19, 2008 1:06 PM To: XWiki Developers Subject: [xwiki-devs] New Admin Design direction Hi, Some comments I've discussed with JV about implementing http://dev.xwiki.org/xwiki/bin/view/Design/ImproveWikiAdministration I believe we should design it in the following manner: * The Admin page is a generic empty shell * An XWiki instance is made of applications (admin pages like users/ groups/configs are part of the admin application too). Examples: Blog, Calendar, Panels, etc * Each application should be able to contribute admin pages to configure/administrate itself. These pages should automatically appear in the left menu on the new admin page. Note that this will require interface extensions so right now we would hardcode them in the menu. * What it means is that the admin page should link to the admin pages located in the applications providing them. I know we're missing the interface extensions to make this work but I'd like that our design for the new admin page works towards this goal in mind. WDYT? Note: This email was prompted by Evelina asking if it was ok to attach XARs to be imported in the XWiki.XWikiPeferences page. IMO it's not a good thing to do. The XARs should be attached in the ImportExport application pages (as it's done now). Now I have no idea how easy or hard this is to implement since I haven't dived in the implementation. Thanks -Vincent _______________________________________________ devs mailing list devs(a)xwiki.org http://lists.xwiki.org/mailman/listinfo/devs

16 years, 9 months

[xwiki-devs] Rendering one Xwiki page with 2 different templates / class sheets

by Kamna Jain

Hello Devs, Is it possible to render one page with two different class sheets. For example, in a 3 page navigation, -> We create an object of a class on the first page and add it to the second page. -> But, we do not display the Object properties on the second page, instead, we add some more properties to that object on that page ->on the third page we want to display the object properties. So, my question is can I just use the same page for the second and third page (described above). That one page has the object added to it but will display two different things based on the style sheet. I tried doing this, but it did not replace the class sheet applied the first time with the second one. -> From Page 1 to Page 2, I used $response.sendRedirect($newdoc.getURL("save", "template=${etemplate}&parent=${eparent}&title=$etitle")) where etemplate = Template 1 This adds #includeForm("XWiki.ClassSheet1") -> From Page 2 - Page2 (with a different template), I used, $response.sendRedirect($newdoc.getURL("propupdate", "template=${etemplate}&parent=${eparent}&title=$etitle")) where etemplate = template 2 This does not replace #includeForm("XWiki.ClassSheet1") , but just adds // to the wiki editor and the editor contents look like this: // #includeForm("XWiki.ClassSheet1") I was expecting it to just overwrite it with #includeForm("XWiki.ClassSheet2") Q) Is there any way to remove the template and add a new one....any other better way of achieving this. Thanks a lot for all help

16 years, 9 months

Re: [xwiki-devs] [xwiki-notifications] r9863 - xwiki-platform/core/trunk/xwiki-core

by Vincent Massol

Maybe some comments explaning why we have to exclude so many deps with a link pointing to the jira issue where we asked the project to fix their pom and a message saying that once it's solved we can remove them? Thanks -Vincent On May 19, 2008, at 5:56 PM, sdumitriu (SVN) wrote: > Author: sdumitriu > Date: 2008-05-19 17:56:53 +0200 (Mon, 19 May 2008) > New Revision: 9863 > > Modified: > xwiki-platform/core/trunk/xwiki-core/pom.xml > Log: > XWIKI-2377: Upgrate the apache-fop dependency > Done. We still need to update batik-rasterizer to 1.7 once it will > be published on the maven repo. > > [misc] Remove pdfbox dependency, which was used by the Lucene plugin > > > Modified: xwiki-platform/core/trunk/xwiki-core/pom.xml > =================================================================== > --- xwiki-platform/core/trunk/xwiki-core/pom.xml 2008-05-19 14:49:51 > UTC (rev 9862) > +++ xwiki-platform/core/trunk/xwiki-core/pom.xml 2008-05-19 15:56:53 > UTC (rev 9863) > @@ -405,41 +405,62 @@ >  > <dependency> > <groupId>org.apache.xmlgraphics</groupId> > - <artifactId>xmlgraphics-commons</artifactId> > - <version>1.1</version> > - <scope>runtime</scope> > - </dependency> > - <dependency> > - <groupId>org.apache.xmlgraphics</groupId> > <artifactId>fop</artifactId> > - <version>0.93</version> > + <version>0.95beta-1</version> > </dependency> > <dependency> > <groupId>batik</groupId> > <artifactId>batik-rasterizer</artifactId> > <version>1.6</version> > + <exclusions> > + <exclusion> > + <groupId>batik</groupId> > + <artifactId>batik-awt-util</artifactId> > + </exclusion> > + <exclusion> > + <groupId>batik</groupId> > + <artifactId>batik-bridge</artifactId> > + </exclusion> > + <exclusion> > + <groupId>batik</groupId> > + <artifactId>batik-css</artifactId> > + </exclusion> > + <exclusion> > + <groupId>batik</groupId> > + <artifactId>batik-dom</artifactId> > + </exclusion> > + <exclusion> > + <groupId>batik</groupId> > + <artifactId>batik-gvt</artifactId> > + </exclusion> > + <exclusion> > + <groupId>batik</groupId> > + <artifactId>batik-parser</artifactId> > + </exclusion> > + <exclusion> > + <groupId>batik</groupId> > + <artifactId>batik-script</artifactId> > + </exclusion> > + <exclusion> > + <groupId>batik</groupId> > + <artifactId>batik-svg-dom</artifactId> > + </exclusion> > + <exclusion> > + <groupId>batik</groupId> > + <artifactId>batik-transcoder</artifactId> > + </exclusion> > + <exclusion> > + <groupId>batik</groupId> > + <artifactId>batik-util</artifactId> > + </exclusion> > + <exclusion> > + <groupId>batik</groupId> > + <artifactId>batik-xml</artifactId> > + </exclusion> > + </exclusions> > </dependency> > - <dependency> > - <groupId>batik</groupId> > - <artifactId>batik-svggen</artifactId> > - <version>1.6</version> > - </dependency> > - <dependency> > - <groupId>batik</groupId> > - <artifactId>batik-dom</artifactId> > - <version>1.6</version> > - </dependency> > - <dependency> > - <groupId>batik</groupId> > - <artifactId>batik-ext</artifactId> > - <version>1.6</version> > - </dependency> > - <dependency> > - <groupId>pdfbox</groupId> > - <artifactId>pdfbox</artifactId> > - <version>0.7.1</version> > - </dependency> > > + >  >  > <dependency>

16 years, 9 months

[xwiki-devs] Using search apis

by Sachin Mittal

Hi, I am working on an application that relies heavily on custom search to get the data to client. I have looked at the xwiki api and it seems that seerch method needs programming rights. Now every user would not have programming rights. So could you please let me know how can I execute such search methods from within my velocity code. One way would be to use my custom search plugin to bypass the xwiki programming rights. I have also see the xwiki reference page for search queries and there are some where no result is displayed, and this is probably because when we access the page there is no access for guest user or logged in user to execute those queries. http://platform.xwiki.org/xwiki/bin/view/DevGuide/velocityHqlExamplesMacro So again can't the search apis move out of programming rights? Thanks Sachin ----- http://www.assembla.com/wiki/show/sachin_mittal about me: -- View this message in context: http://www.nabble.com/Using-search-apis-tp17315167p17315167.html Sent from the XWiki- Dev mailing list archive at Nabble.com.

16 years, 9 months

[xwiki-devs] Issue when running mvn install -Pjettyrun on platform web

by Ludovic Dubost

When I run jettyrun from platform web, I don't get the skins loaded. What I see in the run is that it points to the sources of platform web for it's web resources. With this patch: Index: pom.xml =================================================================== --- pom.xml (revision 9842) +++ pom.xml (working copy) @@ -170,6 +170,7 @@ <configuration> <contextPath>/xwiki</contextPath> <classesDirectory>${project.build.directory}/${project.build.finalName}/WEB-INF</classesDirectory> + <webAppSourceDirectory>${project.build.directory}/${project.build.finalName}/</webAppSourceDirectory> <scanIntervalSeconds>10</scanIntervalSeconds> <connectors> <connector implementation="org.mortbay.jetty.nio.SelectChannelConnector"> It points to the result of the build in target, where the skins have been unzipped. I would commit this, but I'm wondering why this was not reported already and if everybody has this problem ? Ludovic -- Ludovic Dubost Blog: http://blog.ludovic.org/ XWiki: http://www.xwiki.com Skype: ldubost GTalk: ldubost

16 years, 9 months

[xwiki-devs] Migration of xWiki enterprise.

by Marco Casavecchia Morganti

Hello all, I have to migrate from xWiki Enterprise 1.2.1 to something newer because of a known bug of my current release. My idea is to switch to the 1.4.. can anyone tell me if i must install the 1.3 before the switch to the 1.4? Is there a "migration checklist" somewhere? Thanks. -- By MCM.

16 years, 9 months

[xwiki-devs] New Admin Design direction

by Vincent Massol

Hi, Some comments I've discussed with JV about implementing http://dev.xwiki.org/xwiki/bin/view/Design/ImproveWikiAdministration I believe we should design it in the following manner: * The Admin page is a generic empty shell * An XWiki instance is made of applications (admin pages like users/ groups/configs are part of the admin application too). Examples: Blog, Calendar, Panels, etc * Each application should be able to contribute admin pages to configure/administrate itself. These pages should automatically appear in the left menu on the new admin page. Note that this will require interface extensions so right now we would hardcode them in the menu. * What it means is that the admin page should link to the admin pages located in the applications providing them. I know we're missing the interface extensions to make this work but I'd like that our design for the new admin page works towards this goal in mind. WDYT? Note: This email was prompted by Evelina asking if it was ok to attach XARs to be imported in the XWiki.XWikiPeferences page. IMO it's not a good thing to do. The XARs should be attached in the ImportExport application pages (as it's done now). Now I have no idea how easy or hard this is to implement since I haven't dived in the implementation. Thanks -Vincent

16 years, 9 months

[xwiki-devs] Compilation errors in a fresh trunk :(

by Asiri Rathnayake

Just checked out and ran a `mvn install` got the following ... <code> [INFO] Compiling 22 source files to /home/asiri/projects/xwiki/xwiki-dev/trunks/xwiki-platform-plugins/lucene/target/classes [INFO] ------------------------------------------------------------------------ [ERROR] BUILD FAILURE [INFO] ------------------------------------------------------------------------ [INFO] Compilation failure /home/asiri/projects/xwiki/xwiki-dev/trunks/xwiki-platform-plugins/lucene/src/main/java/com/xpn/xwiki/plugin/lucene/LucenePluginApi.java:[41,46] type com.xpn.xwiki.plugin.PluginApi does not take parameters /home/asiri/projects/xwiki/xwiki-dev/trunks/xwiki-platform-plugins/lucene/src/main/java/com/xpn/xwiki/plugin/lucene/LucenePlugin.java:[544,15] incompatible types found : com.xpn.xwiki.plugin.lucene.LucenePluginApi required: com.xpn.xwiki.api.Api /home/asiri/projects/xwiki/xwiki-dev/trunks/xwiki-platform-plugins/lucene/src/main/java/com/xpn/xwiki/plugin/lucene/LucenePluginApi.java:[68,12] cannot find symbol symbol : method hasAdminRights() location: class com.xpn.xwiki.plugin.lucene.LucenePluginApi /home/asiri/projects/xwiki/xwiki-dev/trunks/xwiki-platform-plugins/lucene/src/main/java/com/xpn/xwiki/plugin/lucene/LucenePluginApi.java:[69,53] cannot find symbol symbol : variable context location: class com.xpn.xwiki.plugin.lucene.LucenePluginApi /home/asiri/projects/xwiki/xwiki-dev/trunks/xwiki-platform-plugins/lucene/src/main/java/com/xpn/xwiki/plugin/lucene/LucenePluginApi.java:[69,19] cannot find symbol symbol : method getProtectedPlugin() location: class com.xpn.xwiki.plugin.lucene.LucenePluginApi /home/asiri/projects/xwiki/xwiki-dev/trunks/xwiki-platform-plugins/lucene/src/main/java/com/xpn/xwiki/plugin/lucene/LucenePluginApi.java:[85,19] cannot find symbol symbol : method getProtectedPlugin() location: class com.xpn.xwiki.plugin.lucene.LucenePluginApi /home/asiri/projects/xwiki/xwiki-dev/trunks/xwiki-platform-plugins/lucene/src/main/java/com/xpn/xwiki/plugin/lucene/LucenePluginApi.java:[106,27] cannot find symbol symbol : variable context location: class com.xpn.xwiki.plugin.lucene.LucenePluginApi /home/asiri/projects/xwiki/xwiki-dev/trunks/xwiki-platform-plugins/lucene/src/main/java/com/xpn/xwiki/plugin/lucene/LucenePluginApi.java:[105,19] cannot find symbol symbol : method getProtectedPlugin() location: class com.xpn.xwiki.plugin.lucene.LucenePluginApi /home/asiri/projects/xwiki/xwiki-dev/trunks/xwiki-platform-plugins/lucene/src/main/java/com/xpn/xwiki/plugin/lucene/LucenePluginApi.java:[167,31] cannot find symbol symbol : variable context location: class com.xpn.xwiki.plugin.lucene.LucenePluginApi /home/asiri/projects/xwiki/xwiki-dev/trunks/xwiki-platform-plugins/lucene/src/main/java/com/xpn/xwiki/plugin/lucene/LucenePluginApi.java:[166,16] cannot find symbol symbol : method getProtectedPlugin() location: class com.xpn.xwiki.plugin.lucene.LucenePluginApi /home/asiri/projects/xwiki/xwiki-dev/trunks/xwiki-platform-plugins/lucene/src/main/java/com/xpn/xwiki/plugin/lucene/LucenePluginApi.java:[183,15] cannot find symbol symbol : method getProtectedPlugin() location: class com.xpn.xwiki.plugin.lucene.LucenePluginApi /home/asiri/projects/xwiki/xwiki-dev/trunks/xwiki-platform-plugins/lucene/src/main/java/com/xpn/xwiki/plugin/lucene/LucenePluginApi.java:[191,15] cannot find symbol symbol : method getProtectedPlugin() location: class com.xpn.xwiki.plugin.lucene.LucenePluginApi /home/asiri/projects/xwiki/xwiki-dev/trunks/xwiki-platform-plugins/lucene/src/main/java/com/xpn/xwiki/plugin/lucene/LucenePluginApi.java:[199,15] cannot find symbol symbol : method getProtectedPlugin() location: class com.xpn.xwiki.plugin.lucene.LucenePluginApi /home/asiri/projects/xwiki/xwiki-dev/trunks/xwiki-platform-plugins/lucene/src/main/java/com/xpn/xwiki/plugin/lucene/LucenePluginApi.java:[216,27] cannot find symbol symbol : variable context location: class com.xpn.xwiki.plugin.lucene.LucenePluginApi /home/asiri/projects/xwiki/xwiki-dev/trunks/xwiki-platform-plugins/lucene/src/main/java/com/xpn/xwiki/plugin/lucene/LucenePluginApi.java:[215,19] cannot find symbol symbol : method getProtectedPlugin() location: class com.xpn.xwiki.plugin.lucene.LucenePluginApi /home/asiri/projects/xwiki/xwiki-dev/trunks/xwiki-platform-plugins/lucene/src/main/java/com/xpn/xwiki/plugin/lucene/LucenePluginApi.java:[263,16] cannot find symbol symbol : variable context location: class com.xpn.xwiki.plugin.lucene.LucenePluginApi /home/asiri/projects/xwiki/xwiki-dev/trunks/xwiki-platform-plugins/lucene/src/main/java/com/xpn/xwiki/plugin/lucene/LucenePluginApi.java:[262,19] cannot find symbol symbol : method getProtectedPlugin() location: class com.xpn.xwiki.plugin.lucene.LucenePluginApi /home/asiri/projects/xwiki/xwiki-dev/trunks/xwiki-platform-plugins/lucene/src/main/java/com/xpn/xwiki/plugin/lucene/LucenePluginApi.java:[286,16] cannot find symbol symbol : variable context location: class com.xpn.xwiki.plugin.lucene.LucenePluginApi /home/asiri/projects/xwiki/xwiki-dev/trunks/xwiki-platform-plugins/lucene/src/main/java/com/xpn/xwiki/plugin/lucene/LucenePluginApi.java:[285,19] cannot find symbol symbol : method getProtectedPlugin() location: class com.xpn.xwiki.plugin.lucene.LucenePluginApi /home/asiri/projects/xwiki/xwiki-dev/trunks/xwiki-platform-plugins/lucene/src/main/java/com/xpn/xwiki/plugin/lucene/LucenePluginApi.java:[345,31] cannot find symbol symbol : variable context location: class com.xpn.xwiki.plugin.lucene.LucenePluginApi /home/asiri/projects/xwiki/xwiki-dev/trunks/xwiki-platform-plugins/lucene/src/main/java/com/xpn/xwiki/plugin/lucene/LucenePluginApi.java:[344,16] cannot find symbol symbol : method getProtectedPlugin() location: class com.xpn.xwiki.plugin.lucene.LucenePluginApi /home/asiri/projects/xwiki/xwiki-dev/trunks/xwiki-platform-plugins/lucene/src/main/java/com/xpn/xwiki/plugin/lucene/LucenePluginApi.java:[407,31] cannot find symbol symbol : variable context location: class com.xpn.xwiki.plugin.lucene.LucenePluginApi /home/asiri/projects/xwiki/xwiki-dev/trunks/xwiki-platform-plugins/lucene/src/main/java/com/xpn/xwiki/plugin/lucene/LucenePluginApi.java:[406,16] cannot find symbol symbol : method getProtectedPlugin() location: class com.xpn.xwiki.plugin.lucene.LucenePluginApi [INFO] ------------------------------------------------------------------------ [INFO] For more information, run Maven with the -e switch [INFO] ------------------------------------------------------------------------ [INFO] Total time: 2 minutes 25 seconds [INFO] Finished at: Sun May 18 08:50:39 LKT 2008 [INFO] Final Memory: 45M/142M [INFO] ------------------------------------------------------------------------ </code>

16 years, 9 months

Jump to page:

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

2005

xwiki-devs