xwiki-devs April 2013

xwiki-devs@xwiki.org

33 participants
77 discussions

[xwiki-devs] [Proposal] Roadmap for XWiki 5.0

by Vincent Massol

Hi devs, With XWiki 4.x cycle coming to an end soon, it's time to prepare the roadmap for XWiki 5.0. This is a proposal that comes from some internal meetings done with XWiki committers who are working for XWiki SAS. If you're interesting in participating to this release, don't hesitate to add yourself to the list so that everyone can have some visibility of what's going to be worked on during this timeframe! If you think some work defined below doesn't go in the interest of the project also feel free to raise issues. Features: * Continue SOLR implementation - Edy * EM upgrade of subwikis + flavor concept (add Flavor type in EM/Repository) + leftover from 4.x for EM/DW - Thomas + Marius for DW UI part for flavors * AWM work from 4.x to finish (see http://www.xwiki.org/xwiki/bin/view/Roadmaps/WebHome) - Marius * scalable import/export - Thomas * Home page improvements (XE) and usability improvements in general - JV * Horizontal Menu management (add, remove pages) - JV * virtual=1 by default - Edy (Edy will need to make a proposal for that since it's an important decision ;)) * l10n speed improvements - Ludovic Important JIRAs sorted by priority (most important first): * AWM Add the ability to publish an application as an extension XWIKI-7377 - Marius * AWM Add the ability to export an application XWIKI-7376 - Marius * Unable to edit a page using the WYGIWYG editor after adding a dashboard macro to it XWIKI-8495 - Need volunteer * Improve AWM for it to deal with error messages made by Client when filling the AWM form in using special chars XWIKI-8763 - Marius * Import of Office file breaks Activity Stream and Recently Modified Panel XRENDERING-261 - Need volunteer * Cannot change document title from "inline" mode XWIKI-7905 - Not sure if we want it, to be checked with Marius * When the workspace owner is changed, the new owner is not added as a member nor in the admin group XWIKI-8397 - Edy * Unable to upload a new attachment using the "All pages" tab in the WYSIWYG editor XWIKI-8465 - Marius * Workspace owner and initial members not set as members (nor in admin group) when the workspace identifier contains an underscore XWIKI-8394 - Edy Investigations: * XEM Homepage / Portal - Caty * Knowledge base Flavor - Caty/Ludovic * New Activity Stream Investigation Part 1 - JV (he's agree to become our AS champion :)) * General Flavours Investigation - Caty + input from tech Regarding dates I'm proposing the following: * 5.0M1: 4 March 2013 * 5.0M2: 25 March 2013 * 5.0RC1: 8 April 2013 * 5.0Final: 15 April 2013 Thanks -Vincent

11 years, 4 months

[xwiki-devs] Fwd: [QA] Feedback for 5.0 RC1

by Manuel Smeria

Hello, XWiki 5.0 RC1 is scheduled to be released today. After the release, besides the list of issues fixed for it and the new wiki mode in distribution wizard<http://www.xwiki.org/xwiki/bin/view/ReleaseNotes/ReleaseNotesXWiki50RC1#HNe…> , do you need something else tested ? Thank you, Manuel

11 years, 4 months

[xwiki-devs] [Discussion] Why drop the $msg script binding in the future?

by Eduard Moraru

Are we sure we want to drop the $msg binding in the future [1]? Compared to other services, $services.localization would be used heavily inside scripts and we would basically have 2 options: 1. use $services.localization.render('key') (you fall asleep writing this every time) 2. always declare a variable in your script like #set ($keys = $services.localization) and then do $keys.render('key') AFAIK, we have already considered in the past that a similarly used service like $services.model is already becoming a bit annoying having to write the oh-so-very-long "$services.model.createDocumentReference(wiki, space,name)"; do we want to get the same effect with the new localization module? I understand and agree that the new localization module is more powerful and flexible than the XWikiMessageTool, but I feel that those new features are not required in day to day use and unnecessarily crowd/pollute the regularly used API. This transition should IMO be smoother and with less impact than what is currently being proposed. If the new localization module can provide all the features of the XWikiMessageTool, then I propose that we simply reuse the $msg binding as it is and, in the background, transform XWikiMessageTool into a facade (as I see we have already pretty much done to preserve backwards compatibility), but agree that we *keep* $msg as the simplified translations binding, to be used in day to day operations and, for more complex tasks, the dev needs to use $services.localization instead. Basically, I`m proposing to apply the KIS(s) principle. :) WDYT? Thanks, Eduard ---------- [1] http://markmail.org/message/atrshzt3mlscfedc

11 years, 4 months

[xwiki-devs] [Idea] Integrating Apache Shiro for authentication/authorization?

by Vincent Massol

Hi, Just an idea, maybe it could be interesting for us to provide an integration with Apache Shiro: http://shiro.apache.org/ The framework looks nice and maybe we could offload work to it. Thanks -Vincent

11 years, 4 months

[xwiki-devs] [ GSOC 2013 ] - Live Notifications inside XWiki - request for expert advice

by Akila Darshana Panditha

Hello all , I am a 4th (final) year undergraduate from Department of Computer Science and Engineering, University of Moratuwa, Sri Lanka. After going through accepted list of organizations and their project ideas for GSOC 2013, your organization’s proposal called “Live Notifications inside XWiki” found pretty interesting for me. I am fluent with Java EE technologies and HTML5/JavaScript application development. I also have nearly 1 year industrial experience on Java based enterprise application development and HTML5/JavaScript dynamic front-end developments. After going through description of the project idea I am thinking about few possible approaches to solve this problem they are *1. **Using HTTP Ajax streaming mechanism* Main drawbacks will be connection overloading and comparatively high resource usage in server side *2. **Using polling mechanism initiated by front-end JavaScript* Main drawbacks will be delay of updating frontend and request handling overheads in backend *3. * *Integration with compatible messaging mechanism like XMPP* This approach can lead to major modifications in backend to support third-party components. I have used all these approaches within various projects but need expert advice from XWiki community to choose best approach for this particular project. I have started to getting familiar with XWiki in users perspective as well as a developer. Currently I am in the process of setting up development and testing environment for the project. I ll put up a more formal proposal on due course. At this moment your comments and guidance to approach this problem is highly appreciated. Looking forward to contribute to XWiki as a developer and become a part of the community. Thanks in Advance. -- Akila Darshana Panditha SMIEEE Undergraduate (BSc Engineering) Department of Computer Science and Engineering University of Moratuwa Sri Lanka. about.me/akiladarshana Telephone - *+94714407683* (Mobile) , *+94112641772* (Residence) Blog - akiladarshana.wordpress.com

11 years, 4 months

[xwiki-devs] Apply for GSOC 2013 under the XWiki

by Visitha Baddegama

Hi All, I'm Visitha Baddegama, a final year undergraduate from the Department ofComputer Science and Engineering, University of Moratuwa, Sri Lanka. This time I'm planning to contribute XWiki Project under Google Summer of Code 2013. I am fluent in Java, C# languages,and Web technologies. And I was a student of GSOC 2012 under the DocBook project [1] and sucessfully completed it [2]. By working on that project I got deep knowledge in technologies like XSLT, XML, JavaScript, HTML, Ant, Make, JQuery and CSS. And because of I have developed lot of Android and Phonegap apps, I am familiar with HTML5, CSS, JavaScript and JQuery mobile too. At the end of last November, I joined to OwnCloud [3] (An Open source personnel cloud) community and already I have developed few important features to OwnCloud's messaging app, calendar app and files app. I went through the GSOC 2013 idea page [4] of XWiki and found several very interesting projects. Among all of them, I am looking forward to work with "Improve the Messaging Feature" project. As our department group project, we have already developed very similar features to OwnCloud messaging app too. There we improved to display unread inbox message count on the top of message app icon and improved it to display messages as conversations in smart phone. And we tried to integrate it with FB/Google chat application. Therefore I have huge eager to apply to this project and have a good confidence that I can successfully complete this project and give my whole strength to this project. I will send you a proposal including how I am going to develop this project. I think we can add few additional features to messaging app other than expected functionality too. Please guide me to next steps of this project. And I warmly welcome any advices and guidance from you to improve my knowledge in this project. I successfully integrated XWiki to my machine using this [5] and now I am gathering more knowledge in XWiki and its features. Looking forward to be a part of XWiki community. Thanks in Advance..!! [1]. http://docbook.org/ [2]. http://www.google-melange.com/gsoc/org/google/gsoc2012/docbook [3]. https://owncloud.org/ [4]. http://dev.xwiki.org/xwiki/bin/view/GoogleSummerOfCode/<https://en.opensuse.org/openSUSE:GSOC_ideas> [5]. http://enterprise.xwiki.org/xwiki/bin/view/Main/Download -- Visitha Warna Baddegama Undergraduate Department of Computer Science and Engineering University of Moratuwa Sri Lanka

11 years, 4 months

[xwiki-devs] Google Summer Of Code 2013

by lavinia bobonete

Hi, My name is Lavinia Bobonete and I am now pursuing a Master degree in Computer Science, at Politehnica University of Bucharest. I have a couple of years experience with Java (both SE and EE) and JavaScript (JavaScript MVC especially), so I think that there shouldn't be any programming barriers. I've looked over your proposed projects and there is more than one project that catches my attention: Wiki Collections, Live Notifications, Messaging Feature and Extension Repository. These all correspond to my area of interest. But I have a question: is there any project with a higher priority in the development of XWiki? And secondly: how can I start getting involved? I'm looking forward to hearing from you and being a valuable part of the community, Lavinia Bobonete

11 years, 4 months

[xwiki-devs] [Reminder] BFD #16

by Vincent Massol

We're only 23 bugs away from succeeding in catching up on 2 years! We can make it during this BFD! See http://jira.xwiki.org/secure/Dashboard.jspa?selectPageId=10352 Dashboard for BFD#16: http://jira.xwiki.org/secure/Dashboard.jspa?selectPageId=11507 Let's do it! Thanks -Vincent

11 years, 4 months

[xwiki-devs] [Proposal] Flavor's vision + Next steps

by Vincent Massol

Hi devs, Caty, Thomas, Marius and myself have had a brainstorming session today about Flavors. Here's the proposal that came out of it: * Remove notion of XE/XEM distributions. The distribution is just "XWiki" * XWiki becomes an empty shell (as it is already when you download the WAR), even when you download the standalone distribution * Generate distributions in xwiki-platform, maybe in xwiki-distributions with installers inside and some functional tests (but most func tests will be with flavors) * Remove xwiki-enterprise and xwiki-manager and introduce xwiki-flavors/ in xwiki-platform * Introduce notion of Categories for extensions (similar to the category concepts in wiki macros) * Flavors will be extensions categorized as "flavors" (using the Categories system) * In the future we'll also need a new Maven <paclaging> type to represent a grouping of extensions with no specific content * Display Flavors in DW first steps and ask user to choose which one they want to specialize their wiki * First 2 flavors we need: Workspaces and Knowledge Base (closest to the current XE but without Blog). We need to define precisely the first version of these 2 flavors We also agreed that the main work to be done before we can really have flavors is to implement Categories for extensions. We'll need to decide when we start working on this in our roadmap but probably not before 5.2 anyway since 1) it'll be Marius and Thomas who would work on this and 2) Thomas has to work on performance import/export and Marius needs to work on AWM, probably both in 5.1 (roadmap not defined yet). WDYT? Thanks -Vincent

11 years, 5 months

[xwiki-devs] Fwd: MEDIA ALERT: The Apache Struts Project Announces Apache Struts™ 1 End-Of-Life

by Sergiu Dumitriu

We really should stop using Struts 1. -------- Original Message -------- Subject: MEDIA ALERT: The Apache Struts Project Announces Apache Struts™ 1 End-Of-Life Date: Tue, 9 Apr 2013 14:01:20 +0100 (BST) From: Sally Khudairi <sk(a)apache.org> Reply-To: Sally Khudairi <sk(a)apache.org> To: announce(a)apache.org <announce(a)apache.org> >> this announcement is also available online at http://s.apache.org/7zi Apache Struts 2 recommended as an elegant Open Source, extensible successor framework for creating enterprise-ready Java Web applications Forest Hill, MD –9 April 2013– WHO: The Apache Software Foundation's Apache Struts Project, creators of leading Open Source solutions for creating Java web applications. WHAT: The Struts™ 1.x Web framework has reached its end-of-life (EOL) and is no longer officially supported. Created in 2000 to provide an improved development experience over pure Java Server Pages (JSP) utilization, Apache Struts 1 soon became the de-facto standard for Java-based Web application development. Numerous companies world-wide adopted Struts 1 as a strategic platform, even after JSF (Java Server Faces) was introduced as a standardized Java EE framework for Web application development. Its popularity was so prevalent in the early 2000s, most job offerings in the space of Java-based Web technology required Struts 1 as a must-have skill. Today, many important Websites and Web-based user interfaces continue to rely on Struts 1 technology. In addition, many popular Web frameworks, such as Spring MVC and WebWork, were significantly inspired by Struts 1. WHEN: The Apache Struts Project Management Committee is not aware of any urgent issues posing the immediate need to eliminate Struts 1 usage. However, the project's EOL status signifies that security and bug fixes will no longer be provided effective immediately. The Apache Struts project recommends new projects to be developed using Struts 2 as opposed to Struts 1. While any action-based Java web framework is a potential candidate to re-use Struts 1 architectural experience or migrate existing Struts-1-based applications, users are highly advised to investigate Struts 2 as a successor framework. WHY: Struts 2 is modern, highly decoupled, feature rich, well maintained, and successfully running in many mission-critical projects globally. It shares the same basic principles with Struts 1, and offers a highly improved architecture, API, and solution portfolio. WHERE: The last release of Apache Struts 1 is version 1.3.10 from December 2008. All software downloads, notices, and updates are available at the Apache Struts project homepage at http://struts.apache.org/. NEXT STEPS: The Struts community continues its focus on pushing the Apache Struts 2 framework forward, with as many as 23 releases to date. Availability and Oversight Apache Struts software is released under the Apache License v2.0, and is overseen by a self-selected team of active contributors to the project. A Project Management Committee (PMC) guides the Project's day-to-day operations, including community development and product releases. Apache Struts source code, documentation, mailing lists, and related resources are available at http://struts.apache.org/. About The Apache Software Foundation (ASF) Established in 1999, the all-volunteer Foundation oversees nearly one hundred fifty leading Open Source projects, including Apache HTTP Server — the world's most popular Web server software. Through the ASF's meritocratic process known as "The Apache Way", more than 400 individual Members and 3,500 Committers successfully collaborate to develop freely available enterprise-grade software, benefiting millions of users worldwide: thousands of software solutions are distributed under the Apache License; and the community actively participates in ASF mailing lists, mentoring initiatives, and ApacheCon, the Foundation's official user conference, trainings, and expo. The ASF is a US 501(3)(c) not-for-profit charity, funded by individual donations and corporate sponsors including AMD, Basis Technology, Citrix, Cloudera, Facebook, Go Daddy, Google, HP, Hortonworks, Huawei, IBM, InMotion Hosting, Matt Mullenweg, Microsoft, PSW Group, SpringSource/VMware, WANdisco, and Yahoo!. For more information, visit http://www.apache.org/ or follow @TheASF on Twitter. "Apache", "Struts", "Apache Struts", and "ApacheCon" are registered trademarks or trademarks of the Apache Software Foundation in the United States and/or other countries. All other brands and trademarks are the property of their respective owners. # # # Contact: Sally Khudairi Vice President The Apache Software Foundation press(a)apache.org +1 617 921 8656 >> You are receiving this message because you are subscribed to the Apache Announcements List to unsubscribe, send an email from the subscribed address to <announce-unsubscribe(a)apache.org>. For more information, visit http://apache.org/foundation/mailinglists.html#foundation-announce

11 years, 5 months

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

2005

xwiki-devs April 2013