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
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
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
Hi devs,
Recently we've done a big work of converting the old $msg into $services.localization or {{translation/}}.
Every time we've done that in a module we need to add a dependency in its pom on the appropriate localization module.
I haven't checked fully if we've done this or not but it's possible that some functional tests don't fail because they don't test everything so we need to review the POMs.
Thanks
-Vincent
Hi All,
I'm trying to do the following task without any success.
Getting a list of documents of a specific Blog Category (Let's say Category
"C"). After getting all documents of "C", then getting from each document
the "Summary" field.
Would it be possible to lead me on how to do this task in Velocity?
Any help will be strongly appreciated.
ps. I'm working on Google Map extension for supporting several positions; I
will push it as soon as I finish it.
Best wishes
Youcef
Hi devs,
While introducing the new security module, we have added a new right named
"creator", only applicable at document level, it is automatically applied
on documents for their creator. This right is not really checked for
itself, but it imply the delete right with a tie resolution policy of
allow, and a inheritance policy of not deniable. This give a document
creator the right to delete the document whatever other policies could say
about him.
Since having only delete right on a document does not seems really logical,
I am wondering if it would not be good to make the creator right also imply
the view, and the edit right. This would give to document creators
consistant minimal right on their documents, what ever the policy of the
wiki is.
WDYT ?
--
Denis Gervalle
SOFTEC sa - CEO
eGuilde sarl - CTO
As discussed a while ago, I'm finally made public the Mobile XWiki Client
code I've been working on.
I've transfered the repository as well as the mobile skin repository to
xwiki-contrib
https://github.com/xwiki-contrib/mobile-standardxwikiclienthttps://github.com/xwiki-contrib/skin-mobile-simple
The next step for the mobile client is a rework to be:
1/ More modular to allow for additional module and UI changes to allowed by
plugins.
2/ A rework of the network layer to be able to queue requests to XWiki and
manager errors and retries as well as login.
Ludovic
--
Ludovic Dubost
Founder and CEO
Blog: http://blog.ludovic.org/
XWiki: http://www.xwiki.com
Skype: ldubost GTalk: ldubost