Hi devs,
I’d like to propose that we move to Java 8 as the minimal Java version supported for XWiki 8.0+.
The rationale is:
* Java 7 is end of life since April 2015.
* It brings [Default Methods|https://docs.oracle.com/javase/tutorial/java/IandI/defaultmethods.h…] which would make retro compatibility a lot easier for us (it's very hard to add new features to existing API right now).
* Required for:
** Infinispan 8
** JGroups 4
** Jetty 9.3+ seems to require Java 8 (or maybe it's just optimized for it, http://download.eclipse.org/jetty/ is not crystal clear about what "Java 8+" means exactly)
Nice to have
* Lambda Expressions
* Repeating Annotations which would probably allow us to use several times \@Named instead of \@Component(hints=\{"hint1", "hint2"\}) for example
* New date/time APIs (pretty much what is in Joda Time). We should refactor our $datetool velocity tool to make the java.time api available from velocity
* more…
See http://jira.xwiki.org/browse/XCOMMONS-878
Here’s my +1 and my +1 to start requiring Java 8 for 8.0M2.
Thanks
-Vincent
Hi devs,
Following the “XWiki Core” VOTE (http://markmail.org/message/rqgqzbepzms3p6h2), I’m now proposing to move the following extensions out of xwiki-platform and into xwiki-contrib:
I’ll also start moving some extensions from platform, starting with:
- xwiki-platform-blog
- xwiki-platform-faq
- xwiki-platform-jira
- xwiki-platform-release
- xwiki-platform-selenium
Please vote.
Here’s my +1
Thanks
-Vincent
By default, user profile application creates profile page under
/xwiki/bin/view/XWiki
Instead, i want the profile pages be created in xwiki/bin/view/UserSpace
How can i do that
Hi,
I’d like to request a github repo in xwiki-contrib for a Demo flavor extension.
The idea is that:
- since we want to demonstrate the power of xwiki on playground.xwiki.org
- and since the xwiki github org will focus on providing generic runtime only (made only with core extensions), it would be interesting for users testing xwiki to have a demo flavor that users can pick from on the DW screen (in addition to the default flavor). In the future we expect the community to create a lot more flavors but that’s for later, won’t happen overnight.
So I’m proposing to create a demo flavor that includes a maximum number of high-quality extensions that we have in xwiki-contrib:
To start with:
- Blog
- File Manager
- Meeting Manager
- Forum
- Task Manager
- Idea
- FAQ
- Diagram
In addition, in term of layout I’m proposing:
* Navigation panel on the left
* App bar on the right
* A demo text on the home page and beneath the activity stream (one under another so that clicking edit makes it easy to update the page)
WDYT?
Thanks
-Vincent
Hi devs,
Point 1: We still have some leftovers of the xwiki/1.0 syntax in platform. To give 2 examples:
* XWikiDocument.getUniqueWikiLinkedPages()
* XWikiDocument.getSections()
In both cases the code is like:
public List<DocumentSection> getSections() throws XWikiException
{
if (is10Syntax()) {
return getSections10();
} else {
… new rendering algorithm…
Point 2: We still have a lot of pages (hundreds) written in xwiki/1.0 syntax on xwiki.org (old release notes, old FAQ entries, the curriki wiki, etc)
Some details (http://www.xwiki.org/xwiki/bin/view/Admin/Syntaxes):
* platform: 49 pages (5%)
* xwiki: 530 pages (13%)
* curriki: 398 pages (37%)
* dev: 126 (3%)
* xclams: 29 (6%)
* etc
total of pages for the wikis supported by the xwiki dev team: 770 pages.
Possible actions
================
A - Migrate xwiki.org content. Hard and tedious to do since there are lots of pages.
B - Discard content written in xwiki/1.0 syntax on xwiki.org (and migrate the few pages that are in 1.0 but still needed, like the site Survey page)
C - Continue to support the xwiki/1.0 syntax located in xwiki-contrib to ensure it doesn’t break so that we can install it on xwiki.org when we migrate to 8.x in the future.
D - Continue moving xwiki/1.0 code from platform into the contrib module for xwiki/1.0. This means doing some refactoring and introducing some component. I think it would be interesting to deprecate XWikiDocument.getUniqueWikiLinkedPages() and XWikiDocument.getSections() (and move them to legacy) and instead introduce some new components somewhere TBD. Generally speaking I’m in favor to not manipulate the XDOM inside of the XWikiDocument class (just let it return the XDOM but consider it a black box) and instead do any XDOM manipulation elsewhere (refactoring module or other modules).
E - Break the xwiki/1.0 syntax by removing the code in platform, i.e. the is10Syntax() above for example. We would need to decide when it’s ok to do this. In 8.x? In 9.x? Later?
I see 2 main strategies that seem valid to me:
- Strategy 1: Do C and D. This would mean continuing to leave the old content of xwiki.org in xwiki/1.0 syntax and convert only the few pages that are still used today such as the site Survey page - but for example not translating old release notes.
- Strategy 2: Work as a task force (i.e. with everyone helping actively do the work) to migrate the content of xwiki.org (and possibly move away curriki and some older instance of xwiki). Consider that xwiki/1.0 syntax is not working anymore if you install XWiki 8.x (9.x? later?). That’s A and E.
Any other ideas? Thoughts?
WDYT?
Personally I’d be ok with both.
Thanks
-Vincent
Hi devs,
With the work done for 7.4.1 we’ve delayed the release of 8.0M1 a lot (by 2 weeks until now!).
Thus 8.0M2 only has 1 more work before we should release it (was planned for 15th of Feb) and we haven’t released 8.0M1 yet…
I’m thus proposing that we push the RC1 release by one week, and use the following updated dates:
* 8.0M1: 8 or 9th of Feb
* 8.0M2: 22nd of Feb
* 8.0RC1: 3rd of March
* 8.0final: 14th of March (same date as originally planned)
WDYT?
See also http://www.xwiki.org/xwiki/bin/view/Roadmaps/
Thanks
-Vincent
The XWiki development team is proud to announce the availability of XWiki
8.0 Milestone 1.
This is the first milestone release of the 8.x cycle. With this occasion we
deprecated and retired multiple projects like Colibri Skin, Color Themes,
old XWiki 1.0 syntax, etc. We also continued to polish our Nested Pages
feature introduced in 7.2, by adding improvements such as: asynchronous
copy and rename page actions, improved location picker for simple users and
the ability to omit "WebHome" in wiki links syntax.
You can download it here: http://www.xwiki.org/xwiki/bin/view/Main/Download
Make sure to review the release notes:
http://www.xwiki.org/xwiki/bin/view/ReleaseNotes/ReleaseNotesXWiki80M1
The following people have contributed code to this release (sorted
alphabetically):
Alexandru Cotiugă
Denis Gervalle
Ecaterina Moraru (Valica)
Eduard Moraru
Guillaume Delhumeau
Marius Dumitru Florea
Sergiu Dumitriu
Thomas Mortagne
Vincent Massol
Thanks for your support
-The XWiki dev team
The XWiki development team is proud to announce the availability of XWiki 7.4.1.
This is a bug fix release including some important improvements such
as: asynchronous copy and rename page actions, improved location
picker when copying and renaming, ability to omit "WebHome" in wiki
links and images syntaxes.
You can download it here: http://www.xwiki.org/xwiki/bin/view/Main/Download
Make sure to review the release notes:
http://www.xwiki.org/xwiki/bin/view/ReleaseNotes/ReleaseNotesXWiki741
The following people have contributed code to this release (sorted
alphabetically):
acotiuga
Denis Gervalle
Eduard Moraru
Guillaume Delhumeau
Marius Dumitru Florea
Thomas Mortagne
Vincent Massol
Thanks for your support
-The XWiki dev team
Hi,
The copy dialog is something we added recently in 7.2+ and displays the
page structure from the subwikis.
The problem is that if from subwikiA you want to copy to subwikiB and you
are browsing the tree, you will see unrendered titles for the homepage of
some applications.
1. So the current 'solution' was to change the visibility for
TranslationDocumentClass from WIKI to GLOBAL. Apparently this requires
PROGRAMMING rights.
2. Another bad solution would be not use translations keys for those
homepage titles, in order to display plain text. Or just accept the fact
that it is unrendered (which looks really bad).
3. other???
Thanks,
Caty
On Mon, Feb 8, 2016 at 12:03 PM, Iustin Insuratelu <
iustin.insuratelu(a)xwiki.com> wrote:
> Hello,
>
> Recently we've been discussing about a situation that creates some
> inconveniences.
>
> What happens in short:
> * Have multiple subwikis, each with different extensions
> * Try to copy one content page from one wiki to another
> * When you are using the Copy Dialog - you can see pages from other
> subwikis. In that list the translations are broken.
> * It's about the applications homepages that uses translations keys for
> their titles.
>
> You will get something similar to http://screencast.com/t/8aHY7dca
> There are problems with translations visibility between subwikis.
> Check:
> * ideas
> * filemanager
> * xpoll
> * notes
>
> You can get more details from:
> * http://jira.xwiki.org/browse/NOTES-3
> * http://jira.xwiki.org/browse/XDOODLE-32
> * http://jira.xwiki.org/browse/IDEAS-63
>
> The current solution (see
> https://github.com/xwiki-contrib/application-ideas/pull/16) creates a few
> glitches with installing that app on subwikis and programming rights.
>
> What we need is to define a rule that will be acceptable for the entire XE.
> What are your thoughts on this?
>
> Regards,
> *Iustin*
> _______________________________________________
> users mailing list
> users(a)xwiki.org
> http://lists.xwiki.org/mailman/listinfo/users
>