January 2013 - xwiki-devs@xwiki.org

[xwiki-devs] [Idea] XWiki Project Development Flavor
by Vincent Massol 04 Jul '13

04 Jul '13

Hi devs, I've noticed Apache BloodHound (https://issues.apache.org/bloodhound/) and this reminded of this idea I've had several times in the past: Creating a Project Development Flavor of XE. I mentioned it in some other email already but I wanted to see if this excites you as much as it does for me and maybe we could brainstorm in this thread about what it could be like . Some scattered thoughts: * First, from the point of view of the XWiki project I believe it could be a game changer if we did it right since it has the potential of being adopted by projects around the world and thus making them discover xwiki as a result. And since they're developers they would be able to take advantage of XWiki's development features and contribute back to the project through extensions for example. * Ideally it would be awesome that this project be started independently of the XWiki project I think and just use XWiki as the platform since it's a full fledged project with a different goal than the XWiki project itself. * We need to finish the Flavor idea by allowing the DM to list flavors. * Some ideas of content for this Development Project flavor: ** A home page dashboard about metrics of your project. These metrics would be retried from external sources. Examples: *** Statistics about commits using Git/GitHub *** Latest emails (taken from mailman or other mailing list software, possibly by subscribing the project to a mailing list so that it gets the emails) *** Latest issues (taken from JIRA for example) *** Screenshot example: http://incubator.myxwiki.org/xwiki/bin/view/Improvements/XWikiOrgProposal2#… ** A Release application to help perform releases ** A forum application, for example the Mail Archive Application done by Jeremie which would need to be improved to add ability to post from it ** A Release notes application ** The Blog application ** Ability to generate a whole PDF for the project's documentation for a given version ** A modern and nice skin (either Lyrebird or the new Skin proposal: http://incubator.myxwiki.org/xwiki/bin/view/Improvements/Skin4x) ** A layout configured for the flavor ** Future: a simple issue tracker (or integrate one) for those who want an all-in-one solution. However keep the external issue tracker possibility for those already having an issue tracker ** Some predefined templates for creating well known project pages: source repository, build, hall in fame, project documentation home page, etc ** The IRC Bot application ** Bundle the JIRA macro ** Bundle the FAQ application ** A Roadmap application * Of course we should use this flavor on xwiki.org itself. And we could move some of the modules we currently have in platform and that would make more sense there (jira macro, IRC Bot application, FAQ application, etc). WDYT? Add your ideas to this email thread or, better, on http://dev.xwiki.org/xwiki/bin/view/Design/DevelopmentFlavor Thanks -Vincent

8 16

[xwiki-devs] Redirect to a space
by Bruno Amaro Almeida 04 Jun '13

04 Jun '13

Hi How can i redirect the users after login to a space ? I`m looking at login.vm but i have no clue to do this Thanks

4 6

[xwiki-devs] [ANN] Test Reporting Application
by Sorin Burjan 02 Apr '13

02 Apr '13

Hello everybody, I have created a Test Reporting Application in order to make the Manual Testing Plan more easily to follow and execute. The rationale behind this is: * Hard to update a monolith page with all the manual tests performed * When someone who is testing is updating the page, no other user can update the page * It allows existing manual cases to be marked as automated (if we have an automated tests for them) * Easier to follow, track over what has been tested and what not Since I'd like to propose this to be used in the XWiki community for our Manual Test cases, I have put a live version on Incubator along with some test cases so I can get your suggestions before putting it in actual production/usage. I'm sure you will have some cool suggestions on how to improve it even further. So give it a try. I have also added a suggestions page linked form the application homepage. Note that the application was designed to be generic, so everybody can use it in their own software project. Contrib repo: https://github.com/xwiki-contrib/application-testreporting Incubator Live version: http://incubator.myxwiki.org/xwiki/bin/view/QA/WebHome Suggestions page: http://incubator.myxwiki.org/xwiki/bin/view/QA/Suggestions Looking forward to get your feedback ! Regards, Sorin B.

5 6

[xwiki-devs] [VOTE] Name for Entity classes in the new model
by Vincent Massol 05 Mar '13

05 Mar '13

Hi devs, As you may have seen, I've been working on the new model in a branch. We need to decide on the naming of the Entity classes (wiki, space, document, object, object definition, etc). We have several possibilities I know of for naming them: 1) Wiki, Space, Document, Object, ObjectDefinition 2) WikiEntity, SpaceEntity, DocumentEntity, ObjectDefinitionEntity 3) Wiki, Space, Document, XObject, XObjectDefinition (or simply ObjectDefinition) 4) XWiki, XSpace, XDocument, XObject, XObjectDefinition 5) Some other name for objects. Some concerns: * Using Object as in 1) is a bit of a pain since there's java.lang.Object which forces to use the FQN name when coding in Java. Which is why I've put proposals 2) and 3) * In proposal 3) there's a bit of an inconsistency with the X in XObject which is not present in the other entity names, hence proposal 4 and 2) * In proposal 1) there can be some other clashes. For example Document can clash with the DOM Document object My personal vote goes to 2), even though it makes the entity names a bit longer. Cast your votes! Thanks -Vincent

8 11

[xwiki-devs] What do we do with template field in document ?
by Thomas Mortagne 21 Feb '13

21 Feb '13

Hi devs, We have a "template" field in XWikiDocument and in what we export/import in the XAR but it's not part of the database mapping (there is defaultTemplate but no template). See http://jira.xwiki.org/browse/XWIKI-8650. Since it's not saved in the database it's totally useless to have it in the XAR but we do have it in several pages of XE (some Blog pages). So my question is what the hell is this field and what should be do with it ? I can see two possibilities: 1) stop exporting it in the XAR and deprecated related method in XWikiDocument 2) put it back in the database mapping (I guess it used to be there or I don't see how we could have some pages with it on github) WDYT ? Since I have no idea what this field is supposed to do I don't have a strong opinion but since it's totally useless right now and nobody seems to complain I would go for 1). -- Thomas Mortagne

2 4

[xwiki-devs] New repository for PDF Viewer Macro on contrib
by Ludovic Dubost 19 Feb '13

19 Feb '13

Hi, I've created a new git repository on xwiki-contrib for a PDF Viewer module based on Mozilla's pdf.js that I have been working on. https://github.com/xwiki-contrib/macro-pdfviewer The code and extension should be published today Ludovic -- Ludovic Dubost Founder and CEO Blog: http://blog.ludovic.org/ XWiki: http://www.xwiki.com Skype: ldubost GTalk: ldubost

3 6

[xwiki-devs] Future of mailsender plugin
by Ludovic Dubost 13 Feb '13

13 Feb '13

Hi, I wanted to discuss about the future of the mailsender plugin ? I've been working on a small tool to be able to send a Calendar Invitation by email from a Meeting Notes AppWithinMinutes application and I found some limitation in the mailsender plugin, namely you cannot add multipart alternative email parts in addition to the text and html parts already supported by the plugin. I was able to hack the mailsender plugin to add a vcalendar part but it does not really sound right to do that since we should support any part of any content type, but this is a bigger refactoring. I was wondering what the future is for the mailsender plugin. Do we plan to make it a component and keep the same functionality ? Is there a plan for an alternative component ? And what would be the approach to add a vcalendar part in emails sent by the current mailsender ? This would be needed to support the feature of sending invitation emails which would be very powerfull. Ludovic -- Ludovic Dubost Founder and CEO Blog: http://blog.ludovic.org/ XWiki: http://www.xwiki.com Skype: ldubost GTalk: ldubost

6 27

[xwiki-devs] [VOTE] Make UTF-8 mandatory for a valid installation
by Sergiu Dumitriu 12 Feb '13

12 Feb '13

Hi devs, We've moved more and more toward an UTF-8-only application, and XWiki has only been tested with this configuration for several years. I propose that we require UTF-8 for a valid, supported installation. This means: - JVM encoding (-Dfile.encoding=UTF8) - Container default URL encoding (Tomcat has ISO-8859-1 by default) - Database encoding (MySql is still configured with latin1 on some distros) There's one big site to update on our side: xwiki.org. Here's my +1. This is a move toward a future web, since more and more standards require (or at least assume as a default) UTF-8. After thinking a bit more, it would make sense to require a valid Unicode encoding, including UTF-16, which is preferable in countries that don't use a latin alphabet. However, XWiki doesn't currently work under 16-bit encodings at all. -- Sergiu Dumitriu http://purl.org/net/sergiu

8 12

[xwiki-devs] Free Web-based diagraming tool
by Roman Muntyanu 11 Feb '13

11 Feb '13

Hi Devs! Thought you might be interested http://www.diagram.ly/ Roman Muntyanu | rmuntyan(a)softserveinc.com<mailto:[email protected]> | Project Manager | SoftServe<http://www.softserveinc.com/> Inc. | +380-32-240-9090 x3738

2 1

[xwiki-devs] [Brainstorming] Handling "young" APIs for backward compatibility
by Vincent Massol 11 Feb '13

11 Feb '13

Hi devs, We have recently voted a rule where we said that we will do the following: * Always deprecate APIs * Always move them to Legacy modules * And when there's a technical issue to moving stuff to the Legacy module, only then, send a VOTE to remove an API (see http://markmail.org/message/tino4ngttflc5i3s) This means that from now on (starting on 26th of April 2012) we're not allowed to put excludes in CLIRR. However I've seen that we have added some CLIRR excludes after the vote was passed. I believe that the main issue we have is for "young" APIs that are not considered stable. Proposal 1: Internal package ========= * Young APIs must be located in the "internal" package till they become stable. I propose "internal" to reuse an existing package that we filter when testing for CLIRR. "internal" means that users should not use this API because it's considered unstable and can change at any time. * When a Young API is considered stable enough and we want to open it to public consumption then we move it from "internal" to its target package (that's easy to with IDEs). From that point forward any changes to them goes through the standard mechanism of deprecation/legacy. * If we want to add a new method to an existing public API then this should not be considered a "young" API. It's just an addition to an existing API and thus goes directly to the deprecation/legacy cycle. * We need to be careful to isolate "young" APIs from public API so that users don't inadvertently use "young" unstable APIs by mistake. If not possible then directly go through the deprecation/legacy cycle. The advantage of this proposal is that it doesn't change our current practices and is very easy to verify through CLIRR. Proposal 2: Experimental package ========= Another possibility I can think of is to introduce a new "experimental" package instead of reusing the "internal" one. It has the advantage of being able to follow "young" APIs and ensure they don't stay in that state indefinitely, while still allowing the user who uses it to notice it's experimental. Proposal 3: Experimental Annotation ========= Another idea is to just use an @Experimental javadoc tag for experimental code. It has the advantage of using the target package but it has drawbacks: * It's impossible for users to notice that they're using Experimental APIs since when they import a class they won't see anything that'll tell them they're using a "young" API * It's almost impossible to tell CLIRR to exclude those APIs from its checks. The only way to do this is to modify the source code of the CLIRR plugin AFAIK. Thus we would need to exclude those manually using CLIRR excludes and thus before we release we would need to go over the full list of CLIRR excludes to ensure the excludes listed are only for "young" APIs marked "experimental". Note that I mentioned javadoc tag and not annotation because I believe we need to add information about when the Experimental API was first introduced so that we eventually move it as a proper API by removing the Experimental tag. Maybe we would need a rule such as: keep that tag for less or equal to 3 full minor releases (i.e. 6 months). WDYT? Any other idea? Thanks -Vincent

8 25