Hi devs,
I'd like to release 3.4M1 tomorrow morning (EET) but there are still
failing tests on CI:
* xwiki-enterprise-test-extension : ExtensionsAdminPage was not
synchronized with the latest changes to the Extension Manager UI. It
expects an "Extensions" administration section, which was (I guess)
replaced in the mean time with three different administration
sections. Sergiu or Thomas should take care of this, otherwise I'll
exclude the test.
* xwiki-enterprise-test-ui : Sergiu, please update
TemplateProviderInlinePage and CreatePageTest due to XWIKI-7358 (Add
support for simple space templates).
* xwiki-enterprise-test-wysiwyg : A test is failing because when you
go to an unexisting page (/bin/view/Space/UnexistingPage) the link to
create that page doesn't lead to edit mode but to a strange "create"
mode, which has only a button to create the page. Sergiu, I think this
is related to XWIKI-7358. Can you take care of it?
* there is one App Within Minutes test failing on CI which I can't
reproduce locally. I'm taking care of this.
Thanks,
Marius
Hi Folks,
I would really appreciate even if somebody can provides the pointers about
below queries.
Thanks and Regards
Mohit Gupta
---------- Forwarded message ----------
From: mohit gupta <motgupta(a)gmail.com>
Date: Thu, Jan 5, 2012 at 4:01 PM
Subject: Configuring the webhome page of main space?
To: XWiki Users <users(a)xwiki.org>
Hi All,
I want to configure the default home page i.e webhome page of main space. I
am looking for these kind of customizations:-
1) Replacing *Welcome to your wiki *with Welome to *ApplicationName
Wiki.*Though i can see the ways to customize the panel bars,browser
title bar text but not the text.
2) Right now, on web home page under main space i can see see all the
details(like what activity admin or any other users did . For example
modification in existing page or creation of new page) on page just after
login (i.e webhome page on main space). i want to hide these unnecessary
details from specific group users? Is it possible to customize. i am not
even able to find the vm file for this page so that i can do some tweaking
in code?
Hi Marius,
I think the display module should be independent of the Velocity module.
I see that the VelocityManager is used in DocumentContentDisplayer but I don't think that's nice. It's used to isolate the velocity context in case velocity is used. I think we can improve this for the following reasons:
1) We don't always need to render content using velocity
2) Code using the displayer shouldn't need to depend on velocity if it doesn't need to
I think a better solution would be to have some generic component interface for isolating content (we might already have this) and then have the displayer call "registered" components without knowing them.
This would mean that the code isolating the velocity namespace would be located in the velocity module itself for ex (or in a sub module) which makes more sense IMO.
WDYT?
Thanks
-Vincent
Hi,
As there are now more projects using the Curriki Distribution, in the
Curriki mailing list we have voted for the following changes for the
Curriki Project:
* Rename the main project xwiki-learning-cms
* Call the core: xwiki-learning-cms-core:
http://svn.xwiki.org/svnroot/xwiki/xwiki-learning-cms/xwiki-learning-cms-co…
* Call the curriki specific code : curriki:
http://svn.xwiki.org/svnroot/xwiki/xwiki-learning-cms/curriki
* Call the planete sankoré specific code : sankore:
http://svn.xwiki.org/svnroot/xwiki/xwiki-learning-cms/sankore
The curriki 1.8 branches would go into the curriki area, except for the
latest branch which would be duplicated in xwiki-kearning-cms-core as the
1.0 branch
The 2.x branches would go into xwiki-learning-cms-core
We would then publish the sankore core to the repository.
As you can see these plans are based on SVN. A separate discussion is
undergoing to see if we can easily move to GitHub.
In this case we would ask for one or more repositories in the xwiki-contrib
area. It's not clear to me in this case if we should use only one or 3
different repositories. I tend to think it should be 3.
Finally we would rename curriki.xwiki.org into lcms.xwiki.org.
We're asking the goahead from the XWiki commiters to make these changes.
Here's my +1
Ludovic
--
Ludovic Dubost
Founder and CEO
Blog: http://blog.ludovic.org/
XWiki: http://www.xwiki.com
Skype: ldubost GTalk: ldubost
Hi dev,
I've just noticed that we have a MacroContentParser.getCurrentSyntax() API.
However there's a more general need of being able to get the current syntax even without using a MacroContentParser (I have this need now in some code).
Thus I'm proposing to deprecate (remove?) the MacroContentParser.getCurrentSyntax() method and add a new MacroTransformationContext.getCurrentSyntax()
WDYT?
Thanks
-Vincent
Hi devs,
I'd like to propose releasing XWiki Syntax 2.1 as official (it's currently experimental) for XWiki Rendering 3.4.
Rationale
========
* It has useful expanded support for links and images compared to 2.0
* It's been "experimental" for a long time and people are already using it
* It would be nice to release it in the 3.x cycle since it was started in that cycle
* That would allow us to start XWiki Syntax 2.2 for the 4.x cycle (see outstanding items at http://tinyurl.com/6pdt5oa )
Migration aspects
==============
* I don't think we need to mandate moving to 2.1 for users. They can keep using 2.0 if they want
* We should make it the default wiki syntax starting in XE 3.4, leaving 2.0 available by default
* I believe there's no conversion issue between 2.0 and 2.1 so it shouldn't be an issue for users wanting to switch.
* We could provide a migration script on extensions.xwiki.org for users wanting to convert all their 2.0 pages into 2.1 pages
Here's my +1
Thanks
-Vincent
Hi Devs,
In order to change the way we compute document ID to reduce
the likelihood of a collision, I need to improve and secure our current
data migration system. I have started this works late during 3.2, but it
since this is an important refactoring, and after discussion on IRC, it
have been decide to wait for 3.4 to commit it, so we have a full cycle to
have it carefully test. So I would like your approval now to commit this
work.
The advantages of these changes are:
- Ensure that the hibernate store could not be access without having it
migrated in the appropriate version for the running platform
- Ensure that the hibernate store is left untouched if the migration have
not been allowed
- Easy addition of migrations, since migrator are now components
- Schema and datamigration are done only once and together
- One more step in the isolation of the store from XWiki
- Secure enough to allow converting document IDs
The impact on API and users are:
- deprecate xwiki.store.hibernate.updateschema which is enable by default
- xwiki.store.migration.databases=all by default (in place of xwiki) since
this is the general UC
- XWikiMigrationInterface and XWikiMigratorInterface are removed and new
component roles DataMigrationManager and DataMigration should be used
instead
These improvements consist in:
- Replace Migrators by DataMigration components
- Replace the MigrationManager by a DataMigrationManager component
- Put a "hibernate" hint on hibernate stores (in place of default) to
allow the hibernate migrator to access a correctly typed store
- inject and call the HibernateDataMigrationManager from the stores (and
not from XWiki)
- Convert data migration like action done during schema update (yes we
have some sql updates during schema update) into a LegacyDataMigration
producing data version 1 from data version 0
- Join together schema update and data migration on a unique place (schema
update were currently done in several places in XWiki and the store)
- XWIKI-1859: Do not start migrations on a clean installation of XWiki
- XWIKI-2075: Move all databases upgrades and schema updates to XWiki's
initialization instead of doing it lazily (partial fix, since it is still
hard to have the store initialized has needed)
- data migration is moved to the first access to a store (which is still
during first request, but the matter is no more here)
- XWIKI-2066: Migrator fails to upgrade sub wiki databases, now properly
fixed (previous fix was a hack that do not)
- no more excessive synchronization required for schema update, but
there is still some mandatory document added lazily
- clear reporting of access error when migration does not succeed
For more, read http://markmail.org/thread/l3dzx7pj32n5qlqd
Here is my +1
--
Denis Gervalle
SOFTEC sa - CEO
eGuilde sarl - CTO
Hi (Sergiu),
I see you've committed Caty's pull requests. Thanks for that it's very nice! :)
One little detail: the name of the color theme that was bundled in XE 3.3
Right now it's "XE33Default". I think this is not correct since the colortheme application is not supposed to be linked to XE. We're actually moving it to platform.
So I'd rather call it something like "XWiki33Default" with a title of "XWiki 3.3 Default" instead.
WDYT?
Thanks
-Vincent
Hi All,
I created one page named as Release4 and when i try to search Release4 does
not show any results for this page but if i create another page with name
ReleaseFour and now search ReleaseFour , it shows the results. *Is it an
issue or i am missing some thing here?*
Hi All,
i have created a space on xwiki with the name MySpace. Now i want to create
one sub space under MySpace with name Releases. When i go MySpace and do
add space and give the name of my new sub space i.e Releases . It does
not add that space under MySpace but it adds as seperate space together.
Is it possible to create sub-space ?