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

[xwiki-devs] [Proposal] Choosing the default component implementation

by Sergiu Dumitriu

Hi devs, Currently, requesting a component instance without a hint will look for the implementation that uses the "default" hint, which makes it difficult to change the implementation in an XWiki instance. Sure, it is easy as long as all the implementations use the "default" hint, but choosing the default between alternative implementations that should all still be usable by themselves is not possible. Also, "default" is not really a good hint, since it describes the state of the implementation, not the technology, the aspect that makes it different from the others. It would be better to name each implementation with a proper hint. I propose to define a mapping that can specify which hint is the default for a component. In a text file, META-INF/component-defaults.txt, we'll keep componentinterface=defaulthint mappings. For example: com.xpn.xwiki.store.XWikiStoreInterface=hibernate com.xpn.xwiki.store.migration.DataMigrationManager=hibernate And then, when we lookup the current storage implementation, we don't need to check what is the configured hint in xwiki.cfg (or xwiki.properties), we can just request the default implementation. If there's no mapping for a component, we'll continue to use the "default" hint. I'm not sure where exactly to keep such files. We bundle a components.txt file in each jar containing component implementations. We could do the same for the components we consider the platform defaults, and allow overrides in the WEB-INF/classes/META-INF/component-defaults.txt file. Still, this means that whenever platform defaults change, we need to keep another special section in the release notes, to let users know about these changes, so that they can manually revert to the old default if they need to. In the future we could change existing components to give proper hints instead of "default", where such a change is applicable. Another idea is to not use "default" at all, and instead go for a generic "xwiki", "xe", "xwiki-platform" or something like that whenever there's just one implementation for a component and we can't find another hint to describe it. WDYT? -- Sergiu Dumitriu http://purl.org/net/sergiu/

13 years, 5 months

5
19
0 0

[xwiki-devs] monitoring the cache: how to get the eviction rate?

by Paul Libbrecht

Hello developers, I have been doing a nifty little cache monitor on www.curriki.org which is still running xwiki 1.5.4. It can show the entries and capacity of the two xwiki caches, pageExistCache and the document cache which sound pretty central. Not surprisingly, they're both full on our production server. name entries capacity pageExistCache 10000 10000 cache 3000 3000 The caches are using OSCache (through "OSCacheCache"). I've been trying to get a real statistical count but there I kind of failed thus far. I can use the StatisticListenerImpl which gives fairly high numbers: > StatisticListenerImpl: Hit = 9583563 / 1320251374, stale hit = 0 / 538, miss = 8541 / 17175236, flush = 27348, entries (added, removed, updates) = 25457741, 0, 7678101 these numbers are integers, and might actually be too small for the 2billions limit of an int, they are static (so count "all the OSCache instances"). What I would like to get is the "eviction rate" but I do not know how to compute it. That is, I wish to read the number of cache-entries which are thrown away because the cache is full and others come in. Once I can have it, I can start tuning (cache size, less greedy algorithms, ...) and measure the effect of such tuning. We have plenty of RAM space to accommodate the cache but we should use this well. The big annoyance with this process is that it can only run on our production server. So thus far I did not dare register a CacheListener in groovy fearing it would suddenly be slow. Has anyone used a different strategy or tool? I'm happy to post my little monitor script. thanks in advance. paul

13 years, 5 months

2
4
0 0

[xwiki-devs] Extension "Resolve Maven Pom" clarification on an issue

by jerem

Hello, I'm using the Extension module and the resolve maven pom to parse some poms installed in a local repository. As I have some failures, I realized I was hitting this bug : http://jira.xwiki.org/browse/XWIKI-7641 My question is on understanding this text from the issue : Where is stored the AETHER cache repository on a wiki instance ? Thanks, Jeremie -- View this message in context: http://xwiki.475771.n2.nabble.com/Extension-Resolve-Maven-Pom-clarification… Sent from the XWiki- Dev mailing list archive at Nabble.com.

13 years, 5 months

3
4
0 0

[xwiki-devs] How to add a sub-menu button for image menu in wysiwyg editor inline form

by du du

Hi, all, I am trying to add an addComments sub-menu item to image button from the menu bar of WYSIWYG editor, what it does is to add comments for an image inserted in the editor because I need to explain what each image is about after I put it in the editor, I checked the class:XWiki.WysiwygEditorConfigClass and the wysiwyg.js, I added a sub-menu in the WysiwygEditorConfigClass for image menu, but after that, I got lost, this sub-menu button is supposed to connect to a plugin to trigger java to run I believe since it is a plugin and each sub-menu like imageInsertAttached, imageInsertURL is a plugin, but I could not find the code where it calls a plugin, so how is the sub-menu button hooked to the plugin? when a user clicks on the submenu button in the editor (inline form) page, which javascript function gets called? Thanks very much in advance!! Dave

13 years, 5 months

2
1
0 0

[xwiki-devs] [Brainstorming] Pretty printing XML when exporting XAR?

by Vincent Massol

Hi devs, We need to take a decision. There are 2 places where we have XMLs: A) In our SCM when we store our documents and when we call mvn xar:format B) When we export XARs Right now we pretty print in A) (very recent, I've done this a few days ago) but not in B) which is not optimal since users absolutely need to call xar:format to be able to diff their output with what is in our SCM. * Solution 1: we don't pretty print in A and B * Solution 2: we pretty print in A and B What would you prefer? Thanks -Vincent

13 years, 5 months

6
5
0 0

[xwiki-devs] [GSOC] [REMINDER] Today is the student application deadline

by Eduard Moraru

Hello interested GSoC students, I`d like to remind you that, according to the GSoC timeline [1], today at 19:00 GMT/UTC is the final day when you can apply as a GSoC student. After that, students can no longer apply or modify their application's details. Please make sure that you don`t miss this deadline and that your application is in final state to be reviewed by our mentors. Also, if you have worked on any existing Jira issue, please make sure to include that in the application so that we know about it and make sure you publish (pull request or attached patch file) your work so we can review it. Otherwise, if you have posted a link (github repository) with any past coding that you have done that you would like us to see, please make sure to include it in the application together with any references that can certify that the code is yours. Code samples that were uploaded very recently (like 1 week ago) will not be considered. Thanks, Eduard ---------- [1] http://www.google-melange.com/gsoc/events/google/gsoc2012

13 years, 5 months

1
0
0 0

[xwiki-devs] GSOC-2012 LDAP Server Implementation

by Sai Teja Jammalamadaka

Hello. My name is Sai Teja Jammalamadaka. I'm a Student of Computer Science and Engineering (B.Tech.) at Vishnu Institute of Technology, Bhimavaram, India. I am interested to participate in GSOC this year. I've taken a look at the ideas page, and I see that you are wanting to develop a LDAP server using XWiki. To be frank, I have never worked on an open source project before. I have worked on Java based web projects which I've submitted for Competitions like Oracle's ThinkQuest International Competition and IBM's The Great Mind Challenge. I created a small side scrolling java game using the JGame Java Library. So I do have a good exposure to the Java Language. But I've never channeled my time into working with a public open source project, as of yet. What I've understood from discussing on IRC is that the project is to implement an XWiki LDAP as a backend for user registration and groups for XWiki. I think that it will provide me with a good challenge and at the same time allow me to learn more about java, since I am a java programmer at heart. One of my strong points is that I can analyse pieces of java code with ease, so I feel that I will be able to get a good understanding of XWiki during the community bonding period in May before the actual coding starts. I would like your advice and feedback. I mean is there scope for you to select a project related to the LDAP compared to other projects? And since I've never worked before on open source projects, will that affect my chance of getting accepted? What else can I do to overcome that drawback? Eagerly Awaiting Your Reply, Sai Teja Jammalamadaka, Student of Computer Science and Engineering, Vishnu Institute of Technology, Bhimavaram, 534204 Andhra Pradesh INDIA Link to CV: https://docs.google.com/open?id=0B3KNacfHUN6OamJwWGFuQ0FULWlmLUxab25yejhaQQ Website: www.saiteja.in (undergoing maintenance) Email: audiodevelop(a)gmail.com IRC Nick: audiodevelop

13 years, 5 months

4
8
0 0

[xwiki-devs] GSOC 2012

by savitha sundaramurthy

Dear Team XWiki I'm Savitha doing my MS in Computer science at Arizona State University. I'm really excited to contribute to open source community through XWiki GSOC 2012. I'm interested in the project *SOLR search component*. I have worked in lot of Java Projects and have a good standing in it. I've downloaded and built the Xwiki source code as per the instructions. Right now I'm going through the documentation of SOLR and trying to play around with XWiki Enterprise . Looking forward to this opportunity. -- Thanks, Savitha

13 years, 5 months

4
17
0 0

[xwiki-devs] XWiki chat authentication

by Fabio Mancinelli

Hi everybody, I've added the support for XWIki authentication to the chat prototype. Now, XMPP connections are authenticated using the XWiki authentication service. To make the integration seamless, BOSH connections are authenticated using XWiki cookies. So if you connect from an XWiki page where you are already logged in, you will be automatically authenticated. Otherwise you must provide actual XWiki usernames and passwords (e.g., if you login from Pidgin) Everything works quite well, though I think that some code review is needed because accessing the AuthService from outside a real HTTP request is quite tricky and I don't know if what I did has potential issues. There are 2 places where I can perform authentication: 1) In the XWikiUserAuthorization class. This code is called by the Vysper server when it needs to authenticate a request. Here we are outside the HTTP/Servlet realm because calls to the verifyCredentials method could come also from the TCP/IP endpoint (the one used by Pidgin, for example). What I did here is to create fake HTTP/Servlet request/response to build an XWiki context and access to the AuthService. I've adapted the code from XWikiContextInitializationFilter and it looks like this: https://github.com/xwiki-contrib/xwiki-platform-chat/blob/master/xwiki-plat… (called from here: https://github.com/xwiki-contrib/xwiki-platform-chat/blob/master/xwiki-plat…) 2) In the XWikiBoshHandler class. Here I have basically overridden Vysper's Bosh process method that processes XMPP Stanzas. I intercept AUTH stanzas and I try to authenticate the request from where these stanzas come from using cookies. Here we are in the HTTP/Servlet realm and I use the Execution object to retrieve the XWiki context which is available because I associated a XWikiContextInitializationFilter to the Bosh servlet. The code is here: https://github.com/xwiki-contrib/xwiki-platform-chat/blob/master/xwiki-plat… (pretty standard) Comments are welcome. Thanks, -Fabio

13 years, 5 months

1
0
0 0

[xwiki-devs] XWiki chat

by Fabio Mancinelli

Hi everybody, one of the research projects we are involved in is about realtime collaboration. One of the aspects we wanted to investigate was the integration of a chat system within XWiki. I've been working on this lately and I've built a prototype that uses an embedded XMPP server for handling all the communication. I still have to cleanup a bit the code before committing it, but I took a video of how things work. You can find it here: http://youtu.be/0Gwtpu3iVwo (it's FullHD, so make sure to change the video quality and to switch to fullscreen) There are several things we need to address (authentication is one of them), but I think we could have a functional extension pretty soon. It's 1:30am right now, so I will give you more details in a next mail :) Enjoy. Thanks, Fabio

13 years, 5 months

7
16
0 0

[xwiki-devs] [ANN] XWiki Enterprise and XWiki Enterprise Manager 4.0 Milestone 2 Released

by Thomas Mortagne

The XWiki development team is proud to announce the availability of XWiki Commons, XWiki Rendering, XWiki Platform, XWiki Enterprise and XWiki Enterprise Manager 4.0 Milestone 2. This version mainly introduces: * various ways of customizing users directory and profiles * comments and annotation merge * LDAP administration UI See the full release notes at http://www.xwiki.org/xwiki/bin/view/ReleaseNotes/ReleaseNotesXWikiEnterpris… for more details. Thanks -The XWiki dev team

13 years, 5 months

1
0
0 0

[xwiki-devs] [PROPOSAL] Change component role from Class to Type

by Thomas Mortagne

Hi devs, I recently modified component manager internals and changed the role used as key in the map from Class to Type so that it properly make a difference between Provider<Toto> and Provider<Titi> without the need to generate a special hint. For the one not aware of what Type is lets say it's what Class is extending. Among other things Type is also extended by ParameterizedType which is interesting here because it basically contain a Class with it's generic parameters (it also indicate if the type in included in another one but we don't care in our case ;)). To summarize: * Provider is a Class * Provider<String> is ParameterizedType and both are Type That said I would like to change the whole ComponentManager and related descriptors APIs to use Type as role instead of Class. = What it bring What it means is that it makes possible to cleanly represent a Provider in which the generic type is meaningful right in the ComponentDescriptor (right now the generic type is extract from the implementation class when the provider is registered which is pretty crappy) and simplify a lot the current implementation. But it also mean we could use this new "feature" for other components. For example right now we have things like: @Component public class DefaultStringDocumentReferenceResolver implements DocumentReferenceResolver<String> and @Component @Named("default/reference") public class DefaultReferenceDocumentReferenceResolver implements DocumentReferenceResolver<EntityReference> and injected by @Inject DocumentReferenceResolver<String> resolver; and @Inject @Named("default/reference") DocumentReferenceResolver<EntityReference> resolver; Having Type used as role means that we could have: @Inject DocumentReferenceResolver<String> resolver; and @Inject DocumentReferenceResolver<EntityReference> resolver; = What it breaks So what's the catch ? Basically it would break any code that currently programmatically register or unregister Provider since It would remove the current hack to discover the Provider parameter (assuming that the ComponentDescriptor now provide the complete role). But that's OK IMO given that Provider support is very recent and I doubt it's a common use case. We would obviously keep and deprecate all the existing APIs based on Class which are pretty easy to implement since Class extends Type. Even if removing them would not cause any issue when you build it's not binary compatible since it's not the same method signature. So WDYT ? Here is my +1 and since we are starting a new major version it sounds a good occasion so introduce such change. -- Thomas Mortagne

13 years, 5 months

7
17
0 0

[xwiki-devs] GSOC XWiki Android proposal WYSIWYG Editor

by sasinda rukshan

Dear* Thomas,* I think it will take the same time with android. No difference. I am also thinking that it is easy to propose but hard to make. I will lower the set of requirements to a doable set. I will almost complete the proposal by today night. Thanks for frequently checking out. Regards, Sasinda Rukshan,

13 years, 5 months

2
8
0 0

[xwiki-devs] [GSOC] A basic search implementation with SOLR

by savitha sundaramurthy

Hi Paul , Eduard and Sergiu, I went through Fabio Mancinelli's code and with the help of few inputs from there , I have implemented a basic search functionality using solr. It also fixes the issue http://jira.xwiki.org/browse/XWIKI-6226 . I have indexed the page in English, french and Spanish. I have implemented these main functionality: 1) Simple text search using solr. 2) Used *Extended Dismax Parser *to customize search relevancy using boost index. 3) Hit highlighting for English. Below is the link to the source code https://github.com/savis/xwiki-platform-search XWiki front end , HTML and Velocity code https://gist.github.com/2295648 I wanted to send a pull request but I was playing around when renaming my username and deleted the forked repository and I'm having difficulty forking it again. So I have created a new repository and shared the code above. I have taken few screen shots and have attached the document. I'm working on my application and it should be done today. Thanking You, Savitha

13 years, 5 months

2
1
0 0

[xwiki-devs] [Proposal] Supported Databases Strategy

by Vincent Massol

Hi devs, In the same spirit as what we have done for Browsers (see http://xwiki.markmail.org/thread/pn45a7qaefuplpye ) here's a proposal for Databases since we don't have a clear strategy ATM. I propose that by "supporting" we mean: - issues created for these DBs in jira are not closed as won't fix and we make a best effort to fix them - we include these DBs in our tests (be them automated or manual) - when we create new features or modify existing features we make a best effort to verify that they work on the supported list of DBs Proposal: * HSQLDB: only support the version bundled in the standalone zip * MySQL: We officially support the last major version, i.e. 5.0+ ATM * PostgreSQL: We officially support the last major version, i.e. 9.0+ ATM * Oracle: We officially support the last major version, i.e. 11g ATM * DB2: We don't officially support it. This means that we don't test against it, we don't ensure that new feature work on it but if someone raises an issue in jira and it's easy to fix (or if someone provides a patch) then we fix it. * Derby: Same as DB2 * Microsoft SQL Server: Same as DB2 * H2: Same as DB2 for the moment (it would change if we decide to replace HSQLDB by H2 one day) * Others: Same as DB2 I also propose that in the Release notes for each version of XWiki we mention the list of DBs we have tested against and that we "support". Here's my +1 Thanks -Vincent

13 years, 5 months

9
16
0 0

Re: [xwiki-devs] Poll/Survey Application - GSoC 2012

by Ecaterina Moraru (Valica)

Hi Rauf, First of all the discussions related to GSOC projects is best if they are public: other people could be interested in the subject, multiple mentors/community could respond to your questions. On Sat, Mar 31, 2012 at 11:57, Rauf Butt <raufbutt(a)gmail.com> wrote: > Dear Caty, > > Thanks for your response. After initial study of XWiki, below are my > findings > > 1. The database schema of XWiki is based on SQL and can be used with any > Sql based database but by default is MySql. > 2. There is an application to create polls at > http://extensions.xwiki.org/xwiki/bin/view/Extension/Polls+Application but > in this project, we need to create a widget. May be to embed the existing > poll application into a widget? > Regarding the exact details of this project idea, Ludovic would be best person to answer the questions. IMO could be the first objective to integrate the existing Polls application as a widget/gadget that could be integrated inside our Dashboard. See http://extensions.xwiki.org/xwiki/bin/view/Extension/Dashboard+Macro in order to find out more about how to use gadgets inside XWiki. The only difference between the Dashboard and the Polls application is that the Dashboard is already bundled with XWiki Enterprise, while the Polls Application is just a community extension. So the first step in reusing that code would be to analyze how much work would be to integrate the Polls code into the official bundled code, if it's the right solution, how much work is needed to combine Polls with AppWithinMinutes / Dashboard. 3. To create Survey, we would be using the available application: > http://extensions.xwiki.org/xwiki/bin/view/Extension/App+Within+Minutes+App…. > The demos show how to create applications with this extension. > > The idea behind AppWithinMinutes is to empower users to easily create applications. I think Ludovic wants to give users the ability to easily create Polls/Surveys, spread them (maybe by having them as gadget inside the Main.Dashboard) and analyze them at the end of the poll. > The project requirements include to modify the presentation (GUI) for this > survey and to display the survey results. > > Please correct me if there is some misunderstanding. > Should be correct. Thanks, Caty > > Kind Regards, > Rauf > > > > On 23 March 2012 11:35, Ecaterina Moraru (Valica) <h> wrote: > >> Hi Rauf, >> >> You should play with >> >> http://extensions.xwiki.org/xwiki/bin/view/Extension/App+Within+Minutes+App… >> >> also install from extensions >> http://extensions.xwiki.org/xwiki/bin/view/Extension/Polls+Application >> >> For the development documentation see >> http://dev.xwiki.org/xwiki/bin/view/Main/WebHome >> http://platform.xwiki.org/xwiki/bin/view/DevGuide/WebHome >> >> Thanks, >> Caty >> >> On Wed, Mar 21, 2012 at 03:11, Rauf Butt <raufbutt(a)gmail.com> wrote: >> >> > Dear Team XWiki, >> > >> > >> > I am very excited to contribute in open source community through the >> > platform of GSoC 2012. Last year, I contributed "Debugger Visualizers" >> to >> > MonoDevelop which had successfully become a part of Mono Develop. >> > >> > >> > >> > I have seen project ideas for GSoC 2012 at >> > http://dev.xwiki.org/xwiki/bin/view/GoogleSummerOfCode/WebHome. I am >> > interested in "*Poll/Survey Application*". The reason for my interest is >> > that I have good working experience of HTML, Javascript, Java and >> related >> > technologies. I also checked out XWiki to start understanding it. >> > >> > >> > >> > My understanding of the requirements is as follows: >> > >> > >> > >> > 1. Create a Poll widget to include within a web page. >> > >> > 2. Show Poll results within the Poll widget. >> > >> > 3. Use AppWithinMinutes XWiki to create surveys. >> > >> > 4. Develop the look and feel of such surveys (GUI). >> > >> > 5. At the end of survey, show the results of survey. >> > >> > >> > >> > Have you got a template for the survey GUI or we need to brain storm on >> > this? >> > >> > What database/file storage would be used to store Poll/Survey results? >> > >> > >> > Your kind feedback would help me in better recognising the core project >> > requirements and develop a good proposal. >> > >> > >> > Regards, >> > >> > >> > >> > Rauf >> > >> > Regent's College London >> > _______________________________________________ >> > devs mailing list >> > devs(a)xwiki.org >> > http://lists.xwiki.org/mailman/listinfo/devs >> > >> _______________________________________________ >> devs mailing list >> devs(a)xwiki.org >> http://lists.xwiki.org/mailman/listinfo/devs >> > >

13 years, 5 months

3
2
0 0

[xwiki-devs] Ideas for GSoC 2012

by Gianluca Sabena

Dear all, Some ideas for GSoC 2012: - Native Ace code editor support I think the future is to code online in the browser, I would like to see Ace Editor http://ace.ajax.org/ integrated in Xwiki as a native editor (not only for some objects), as an alternative to the wysiwyg, text and htmlarea editors for pages. The editor must support html, javascript, velocity and java syntax. The use case is: be able to write velocity ad groovy code in pages with a gui editor. - Node.js extension for real time editor I think in order to enhance collaboration we need a real time editor. I would like to see node.js integrated in Xwiki. In order to keep the architecture simpler I guess we could think to a "editing session". Use case: - three users wont to modify a page - they open a node.js session with the page content - work there - save the page back - we could use restful api to allow node.js to communicate with xwiki - Spreadsheet support I guess xwiki leaks spreadsheet support. This could be great for budgeting and control, in order to reduce attached excel files and move to a real collaboration over data. The Sheetserve community edition could be a source of inspiration http://extentech.com/estore/product_detail.jsp?showdetails=true&product_id=… (PS: Why don't move to Google groups for a better and simpler mailing- list management?) Thank you, Gianluca Sabena - - - - - - - - - - - - - - - - - - - www.intertesto.com - - - - - - - - - - - - - - - - - - - gianluca.sabena(a)intertesto.com skype: gianluca.sabena

13 years, 5 months

3
3
0 0

Re: [xwiki-devs] GSoC 2012

by sasinda rukshan

Hi all, I am Sasinda Rukshan from University of Moratuwa Sri Lanka. I created a proposal for the Google Android XWiki Connector. link : http://dl.dropbox.com/u/30342197/x%20wiki.pdf (failed to attach it to the mail and send as the mail bounced back alerting the file is too big. : 603KB) Thank you. Sasinda Rukshan. On Sun, Apr 1, 2012 at 2:55 PM, sasinda rukshan <sasindarukshan(a)gmail.com>wrote: > Hi, > > I am Sasinda Rukshan from University of Moratuwa Sri Lanka. > I have attached here with a proposal for the Google Android XWiki > Connector. > > Thank You. > > Sasinda Rukshan. >

13 years, 5 months

2
5
0 0

[xwiki-devs] Using MacroTransformationContext outside of Macro execution

by Grüner Heinrich

Hi, I want to parse XWiki Syntax in a independent thread (not via xwiki default transformation workflow). how is it possible to intantiate a valid MacroTransformationContext? This Context is needed to call the contentParser. I tried this: MacroTransformationContext mc=new MacroTransformationContext(new TransformationContext()); mc.setSyntax(Syntax.XWIKI_2_0); contentParser.parse(ts.getContent(),mc,true,true); but it threw the following Exception: org.xwiki.rendering.macro.MacroExecutionException: Failed to parse content [ == Werner == * test ] at org.xwiki.rendering.internal.macro.DefaultMacroContentParser.parseXDOM(DefaultMacroContentParser.java:122) at org.xwiki.rendering.internal.macro.DefaultMacroContentParser.parse(DefaultMacroContentParser.java:77) at org.centauron.xwiki.XWikiConnector.getCodeSnipsFromPage(XWikiConnector.java:117) at org.centauron.xwiki.XWikiConnector.getCodeSnipsFromPage(XWikiConnector.java:105) ... Any suggestions? Thanks, Stefan.

13 years, 5 months

2
1
0 0

[xwiki-devs] [VOTE] Changing our deprecation strategy

by Vincent Massol

Hi devs, I'd like to change our deprecation strategy. Here's what we are currently supposed to use (we voted it a long time ago): http://dev.xwiki.org/xwiki/bin/view/Community/DevelopmentPractices#HDepreca… " In addition our rule is to keep @deprecated methods/classes for 2 final releases after the version where they were first added has been released as final. For example if a method is deprecated in, say XE 1.3M2 then the method will be removed in 1.6M1 or after. Of course any major new release can deprecate anything. For example a XWiki 2.0 release is allowed to break backward compatibility (obviously we need to be careful to offer a migration path for users of previous major versions). " Issues: * This seems a bit harsh to me for some of our users/devs in the community. * We're not following which proves to me it's not a good rule * It doesn't say anything about Scripting APIs which require a greater stability in order not to break all wiki pages Definition of a Scripting API: * a Script Service (that's the new way of providing script apis) * a class in the "api" package in xwiki-platform-oldcore (this is the old way of providing script apis) Thus I'd like to propose this new rule: * Deprecated methods can only be removed in the next Release Cycle. For example something deprecated in version N.x can be removed in version N+1.y where x and y can be anything. This is logical since N+1 means a new major release and it's common to understand that major releases have no guarantee of API compatibility (See http://en.wikipedia.org/wiki/Software_versioning for example). * For scripting APIs we can remove deprecated API only after 4 Release Cycles. For example since we're in 4.x this means we can remove deprecated APIs from 0.x releases. And when we start 5.x we will be able to remove deprecated scripting apis deprecated in 1.x. Here's my +1 Thanks -Vincent

13 years, 5 months

5
23
0 0

[xwiki-devs] [ANN] Legacy modules are now only built when the "ci" profile is active

by Vincent Massol

Hi devs, I've made the following change today: * Legacy modules are not built nor packaged anymore by default when you build commons, platform and enterprise. * They are still built and packaged when the ci profile is activated and thus Jenkins still generates and run tests with legacy modules active (as before) This allows: * To speed up the developer builds (on my machine I win 2 minutes by not building commons and platform legacy modules) * Developers run without legacy modules by default which mean they can discover when we have wiki pages still using deprecated apis that have been moved to legacy Next step (that will require a vote) will be to provide a package without legacy modules for end users (details to be discussed too). Thanks -Vincent

13 years, 5 months

3
3
0 0

[xwiki-devs] [VOTE] Temporary make sure a BaseObject cannot target a class coming from another wiki

by Thomas Mortagne

Hi devs, we have an important inconsistency that we ignored since a long time and that is producing http://jira.xwiki.org/browse/XWIKI-7628. The main issue is that the storage save document containing object linked explicitly to another wiki without complaining which mean that user continue using API wrongly without really knowing it's wrong. And now we have lots of code badly using object class related API and contently creating object with absolute class references. Until now it was OK even if a mess and it's still not visible. But that's mostly luck... until we start copying documents from one wiki to another starting with 4.0 branch. What changed is that the unique identifier of the object in the database is "properly" generated by using it's reference and since a class reference in a BaseObject contain a wiki it's now taken into account. The old id generator used to use the deprecated BaseCollection#getClassName which is forced absolute for retro-compatibility reason even if it was actually possible before to put absolutely anything as class reference. So right now we have two issues: * store save invalid document without complaining * many code is wrongly using BaseObject and XWikiDocument API regarding class references mostly because you don't really see it right away when you don't use it properly. Even ObjectAddAction is wrong, a lot of code that was using setClassName has been badly converted to fix deprecated method code by resolving what was passed to setClassName into an absolute reference which is very wrong and not the behavior of setClassName. Here is what we propose with Denis: * 4.x (or until class coming from another wiki is supported but I doubt this is going to happen anytime soon with this storage): ** throw an exception in the storage when saving a document containing objects coming from another wiki ** to temporary limit breakage while we fix wrong code and help us find this wrong code, modify BaseCollection#setXClassReference to force it to remove the wiki from the passed reference and log a warning about a bad usage * 5.0: remove the bandage from BaseCollection#setXClassReference WDYT ? Here is my +1 -- Thomas Mortagne

13 years, 5 months

5
15
0 0

[xwiki-devs] Questions about Blog Example

by du du

Hi, all I am studying the BlogClass, BlogPostClass, I checked the Blog.BlogCode, there are alot of velocity scripts, I can see the search documents from db, but could not find any code related to insert document records into database, so how is the document created from blog saved into database? please point me to the script code in the Blog.BlogCode. Thanks Dave

13 years, 5 months

2
5
0 0

[xwiki-devs] [VOTE] Merge experimental xwiki-platform-security on master

by Denis Gervalle

Hi all, As you have probably notice, I have recently committed an feature-security-authorization branch on platform. I am working on this for a while now and it was the first step to share the outcome of this large refactoring of the initial work done early last year by Andreas. Since the code was not quality compliant with platform but the general structure Andreas has build seems to me well appropriate, I have progressively refactor its code to better fit our real needs. Here is what I have been done: 1) Split in to module api and bridge to allow breaking the currently unavoidable dependency on oldcore. Now only bridge depends on oldcore, and the api does not depends on bridge. As mush as possible has been written in the api (still some code to migrate), and some temporary internal bridge are used to access oldcore stuffs since augmenting the existing document-bridge does not seems appropriate IMO. 2) The initial enumeration of rights as been replaced by a Right class, which could be seen has a pseudo enum, but could be augmented with new rights. To register a new Right, you have to provide a RightDescription to the AuthorizationManager. The description will define the default state, the tie resolution policy, the inheritance policy, the list of entity types for which the right is applicable, the implied rights and if the right could be allowed in read-only mode. So new defined Right will benefit the whole logic of the AuthorizationManager and currently existing one could be declaratively defined. 3) Large renaming to better distinguish stuffs, clarify comments and prepare for future. I have voluntarily not taken existing names to clearly split the old and the new api. In brief, the new right service is now named AuthorizationManager. Internally, it manipulates SecurityReference (as well as UserSecurityReference and GroupSecurityReference, to represent entities, user and group), SecurityRule (representing a right object) and SecurityAccess (representing an access level in the old nomenclature), which are store in a SecurityCache using SecurityRuleEntry (a set of rules) and SecurityAccessEntry (the access of a given user). The AuthorizationManager delegate cache management to a SecurityCacheLoader which loads rules using a SecurityRuleLoader ; and delegate itself the computing of the access for a given user and a set of rules to an AuthorizationSettler. This last one could be overridden to provide specific decision that could not be done in declarative mode. 4) Refactoring was necessary to improve consistency and reduce complexity, and simplify as much as possible; while extending the limitations to allow more rights to be registered. This work has been a little bit opposed to the optimization done by Andreas, in particular on memory usage. But optimization is often the enemy of clean code. 5) Improvement were necessary to better mimic the existing implementation in some peculiar but necessary rules to stay compatible with current working wiki. I tend to reduce as much as possible what is not done declaratively, but there are still some special cases, like delete for creators, deny for other user on explicit allow and admin for wiki owner that are settle by the authorization settler. My implementation should be almost compatible with the old one, except for groups that are currently not checked from the entity wiki, but only from the user wiki. This needs some more refactoring for which I feel inconfortable with, some I'd like to share first. 6) The AuthorizationManager interface has been simplified, providing 2 methods for either checking or verifying an access right (the checking methods throws while the verifying one return a boolean), and one to register a new right. The existing RightService could be bridged on the new implementation using the XWikiCachingRightService class in xwiki.cfg and the new API could be used side-by-side with the old implementation as well. What should still really need to be improved is the unit testing, currently some tests are still awful and incomplete. I already refactor some of them, to provide a better coverage of essential part of the code: the security cache and the default authorization settler. Obviously, any help is welcomed. Since I already have an existing wiki using this implementation successfully and using it for creating new rights for extensions, I would like to merge this new implementation as experimental in platform to have it available for anyone who need it or want to test it, and for you to use in your new experimental development as well. Providing it in platform will encourage it to be finalized and replace the existing implementation. Here is my +1 for the merge on 4.x, WDYT ? -- Denis Gervalle SOFTEC sa - CEO eGuilde sarl - CTO

13 years, 5 months

6
18
0 0

[xwiki-devs] [discussion] Polishing the merge between Annotations and Comments

by Sorin Burjan

Hello everybody, I have started testing and playing a little bit with our new features, the "merge between Annotations and Comments". I am very happy about this new feature, since this offers more flexibility and power. However, this is the initial commit and it still requires polishing in order to be ultra cool. Here are some of my suggestions after I tried to impersonate a "non technical end-user": 1) After adding an Annotation, user wants to add a reply by hovering over the yellow icon and clicking on the "Reply" button. This will move the caret at the bottom of the page, in the Comments Tab. It is a little bit confusing for the end users, which would expect an input text area to appear in the Annotation box, instead of being moved to the bottom of the page. 2) User wants to see the full thread of an annotation. He/she will hover over the yellow icon, and only the first/initial annotation will be visible. If there is at least one reply to that annotation, the user will see a link with "See thread". Clicking on the link, user will be sent in the Comments tab at the bottom of the page. An idea is to be able to see the whole thread related to that annotation in the same place, without having to be moved to the bottom of the page. Now a problem might be if the thread is really large. 3) User wants to delete the whole thread (maybe he/she wants to delete the annotation + all the threads). Clicking on the x button, only the first/actual displayed annotation will be deleted, leaving the rest of the thread/replies on the page at the bottom. IMO this would create confusion among end users and leave mess in the page objects, because users will not understand the context of the remaining comments. This behavior actually comes from Comments feature, which is keeping the replies even if the level 1 comment is deleted. 4) Clicking on the "See Thread" link, will move the user to the bottom of the page, and will highlight with yellow color the Author and Content of the first annotation only. IMO this is not very suggestive, the highlight could be useful only as a delimitation of the "starting" point of the thread, but by highlighting the content too is confusing for end users. This behavior comes from the Permalink behavior of Comments feature. 5) If we say that Annotations are merged with Comments, we can decide if we still keep them visually separated. When adding a new Annotation, in the Comments tab, you can see a small yellow icon denoting that this is an annotation. If user replies to that annotation, the second/nested annotation will be treated as a regular comment. This means only level 1 annotations are marked with the yellow sign, replies or ordinary comments aren't. This seems a little inconsistent IMO. This is not a vote, but if we decide on polishing one of these things, I will create the corresponding JIRA issues. WDYT ? Regards, Sorin B.

13 years, 5 months

3
2
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