I'm having some difficulty at the moment with github, but can someone check my changes and perhaps check them in?
I basically had to take the AnchorFilter out so it would leave the anchors as is, and then replace all the links in the main doc that were moved, to the new link reference.
Thanks
Dan Jones
________________________________
This communication (including all attachments) is intended solely for
the use of the person(s) to whom it is addressed and should be treated
as a confidential AAA communication. If you are not the intended
recipient, any use, distribution, printing, or copying of this email is
strictly prohibited. If you received this email in error, please
immediately delete it from your system and notify the originator. Your
cooperation is appreciated.
Hi Federico,
This looks really strange. The failure happen during the update of the
database schema by Hibernate, to conform with the updated hibernate mapping
of XWiki 4.x. The errors says that a new foreign key constrains should be
added for column agl_id of table feeds_aggregatorurlgroups to the primary
key of table feeds_aggregatorurl, but that this last table does not have
any primary key which is really weird. Are you sure you have properly
imported the database ?
You may try to alter the table feeds_aggregatorurl to declare its primary
key as agg_id, but I am afraid you we fail on other similar issue for other
table as well, since this kind of error is really unexpected.
Regards,
On Wed, Aug 7, 2013 at 3:17 PM, Federico Moglia <
federico.moglia(a)workingteams.com> wrote:
> Thanks Sergio! I attach the complete log of catalina.out of the moment
> when I try to access to the new version by the browser. The first exception
> that I see is:
> 2013-08-07 09:47:56,657 [http://localhost:9001/xwiki/bin/view/Main/]
> ERROR .x.x.s.XWikiHibernateBaseStore - Failed updating schema while
> executing query [alter table feeds_aggregatorurlgroups add constraint
> FK7B845B068E772CC foreign key (agl_id) references feeds_aggregatorurl]
> org.postgresql.util.PSQLException: ERROR: there is no primary key for
> referenced table "feeds_aggregatorurl"
>
> There are more exceptions related with SQL after of this. Could you
> explain me why is happening? How I can resolve it?
>
> Thank you again!
>
>
> On Wed, Aug 7, 2013 at 10:12 AM, Federico Moglia <
> federico.moglia(a)workingteams.com> wrote:
>
>> Thanks Sergio! I attach the complete log of catalina.out of the moment
>> when I try to access to the new version by the browser. The first exception
>> that I see is:
>> 2013-08-07 09:47:56,657 [http://localhost:9001/xwiki/bin/view/Main/]
>> ERROR .x.x.s.XWikiHibernateBaseStore - Failed updating schema while
>> executing query [alter table feeds_aggregatorurlgroups add constraint
>> FK7B845B068E772CC foreign key (agl_id) references feeds_aggregatorurl]
>> org.postgresql.util.PSQLException: ERROR: there is no primary key for
>> referenced table "feeds_aggregatorurl"
>>
>> There are more exceptions related with SQL after of this. Could you
>> explain me why is happening? How I can resolve it?
>>
>> Thank you again!
>>
>>
>> On Tue, Aug 6, 2013 at 11:55 AM, Sergiu Dumitriu <sergiu(a)xwiki.com>wrote:
>>
>>> Hi Federico,
>>>
>>> The root of the problem seems to be a corrupted database.
>>>
>>> Changing rights fails to commit the changes to the database.
>>>
>>> Trying to upgrade fails to execute some migrations, mandatory database
>>> changes needed for the new version. You should look at the logs that
>>> occur while starting the new version, it will say what migration failed
>>> to execute and why.
>>>
>>> On 08/06/2013 09:23 AM, Federico Moglia wrote:
>>> > Hi!
>>> > I'm Federico and I'm working with XWiki Enterprise 3.1. I have some
>>> > problems in the app, for example, when I tried to assign rights to any
>>> > user. Attach screen of error and a txt file with the stack trace of
>>> > exception.
>>> >
>>> > For try to solve this, I've imported the xwiki database to the version
>>> > 4.1.1. The restore in PostgreSQL didn't give any errors. But when I
>>> > tried to access, the application shows me this exception in the
>>> browser:
>>> > Exception while switching to database xwiki Wrapped Exception: Database
>>> > xwiki needs migration(s), it could not be safely used! (Attach file
>>> with
>>> > the full stack trace) I am using PostgreSQL 9.1. In the file xwiki.cfg,
>>> > I have configured the migration with the next
>>> > line: xwiki.store.migration=1. So, I don't understand why fails. Maybe
>>> > my database is corrupted and this is the cause of the problem. But I
>>> > don't know how I solve this.
>>> >
>>> > When I tried to import the xwiki in .xar format, the log in
>>> catalina.out
>>> > shows this:
>>> > 2013-07-26
>>> > 16:17:43,752
>>> http://localhost:9001/xwiki/bin/get/XWiki/XWikiPreferences?xpage=packageinf…
>>> > c.x.x.p.p.Package - Failed to parse document
>>> > [Disney/GlosarioTecnico.xml] from XML during import, thus it will not
>>> be
>>> > installed. The error was: Error number 2002 in 2: Error parsing xml
>>> > Wrapped Exception: Truncated ZIP file Nested exception: Truncated ZIP
>>> file
>>> >
>>> > The information that I've found in Internet was not very useful to
>>> > resolve the problem, for this reason, I decided to write you. I hope
>>> > that you can help me with this.
>>> >
>>> > Thanks!
>>>
>>>
>>> --
>>> Sergiu Dumitriu
>>> http://purl.org/net/sergiu
>>>
>>
>>
>
> _______________________________________________
> notifications mailing list
> notifications(a)xwiki.org
> http://lists.xwiki.org/mailman/listinfo/notifications
>
>
--
Denis Gervalle
SOFTEC sa - CEO
eGuilde sarl - CTO
For the Workspace integration in XE, I need to modify the default XARs. It
makes me able to provide template XARs for the creation of subwikis, which
will be different from the XAR of the main wiki (for example: we don't need
the WorkspaceManager UI in every subwikis).
What I propose to do:
1/ Create a subproject *xwiki-enterprise-workspace-ui*, which defines what
a workspace should be.
1bis/ Create a *xwiki-enterprise-workspace-ui-all* too, in *
xwiki-enterprise-distribution*
2/ Create a subproject *xwiki-enterprise-wiki-ui*, which defines what a
subwiki should be.
2bis/ Create a *xwiki-enterprise-wiki-ui-all* too, in *
xwiki-enterprise-distribution*
3/ Add *xwiki-enterprise-wiki-ui* as a dependency of *xwiki-enterprise-ui*.
This will be a temporary solution, because we will have flavours in the
future.
WDYT?
Louis-Marie
Hi devs,
I think it would be great to have some indication of how many active instances of XWiki are out there in the wild. The idea is not so much to know the figure but to see how this figures evolves and thus to see if we're doing things right. It will also give us information about how quickly or slowly our user base upgrades from version to version.
Here's my proposal:
* When installing XWiki on a clean DB (ie first time install) generate a unique id and store it in the DB (similar to the version we're storing in the DB but using some UUID). Thus when an install is upgraded the same id is preserved.
* When the Extension Manager is used and thus connects to extensions.xwiki.org (default extension repository), this unique ID is sent too.
* In addition the version of XE is sent too
* On extensions.xwiki.org side, we only log the unique ID/XE version **without** logging the IP or any other information thus ensuring that the ID remains completely anonymous
* We display a counter on xwiki.org about the # of active instances of XE with a graph about XE versions used
WDYT?
Thanks
-Vincent
Hi developers. I'm sorry to post such a long post, but the workspace
integration
in XE is a big deal, with a lot of things to discuss. That is why I
describe
the current state, what we want to have in the long term and what we can do
for 5.2.
1 - Current state
------------------
1.1 - What "Workspaces" is
---------------------------
Currently, "Workspaces" is a set of features developped on top of XWiki
Entreprise. It was developped for a research project and released as an
extension. We now have a special release for it, but "Workspaces" is still
not
integrated deeply into the core. From the core perspective, it is still
like an
"add-on".
That is why we have 2 modules: xwiki-platform-wiki-manager and
xwiki-platform-workspace.
1.2 - What a subwiki is
------------------------
A subwiki is just an other wiki, that can use either global or local users
(as
you decide). You can invite people to your subwiki through the "Invitation"
application, which is bundled by default. But the "Invitation" application
is
now hidden, so we need to add a new entry point for it.
1.3 - What a workspace is
---------------------------
A workspace is a "space" where people can collaborate for a project.
The actual implementation says that:
- a workspace is a subwiki
- a workspace does not have local users
- there is an option that make possible for people to "join" the workspace
(if
he is not already in), with the optionnal validation of an admin. These
options are called "membership type".
- a workspace can be created by everyone, by default.
+ there is an UI in the workspace administration to invite user to the
workspace.
1.4 - WorkspaceManager has to be installed
-------------------------------------------
When you download a new XEM and create a fresh instance of "Workspaces",
you
will have a message on the main page that invite you to "Install
WorkspaceManager".
This installation of WorkspaceManager creates a new subwiki called
"workspacetemplate". In this template, 2 XARS are imported:
- workspace-template.xar, which is a nothing but a renamed
xwiki-entreprise-ui-all.xar, most of the time.
- workspace-template-features.xar, that add some UI for the workspace
features
(changing the top menu, etc).
The installation also changes some settings in the template subwiki and
then,
4 pages are removed: XWiki.AdminRegistrationSheet,
XWiki.RegistrationConfig,
XWiki.RegistrationHelp, XWiki.AdminUsersSheet. This is because a workspace
is
not supposed to have local users.
This new workspace is a template, hidden to the users, and it will be used
when
you create a new workspace, unless the user manually decide to use an other
template.
If "WorkspaceManager" is not installed, you won't have the ability to
create
workspaces.
This installation process is dirty in my point of view. Why should the user
install something else after having installed XEM?
1.5 - What "WikiManager" is.
----------------------------
The module xwiki-platform-wiki-manager is the module that provides an API
and a
UI to manage multi-wikis. Is is a dependency for xwiki-platform-workspace.
But this module is quite old. It was first developed as a "plugin" and not
as a
component, even if it can be used through a bridge.
2 - Long term objectives
---------------------------
2.1 - What we have discussed
---------------------------
After some discussion in the mailing list, we have decided the following:
- the ability of create subwikis will be integrated by default on XE.
- we will stop making a distinction between workspaces and subwikis. There
will
be only the notion of "subwiki", with several options to cover all the use
cases.
- we will have a single UI to create a new subwiki, integrated in the top
menu,
like the space and the page creation.
Now, this is what I propose to do after a discussion with Vincent:
2.2 - Create a new 'wiki' module
---------------------------------
Currently we have xwiki-platform-wiki-manager and xwiki-platform-workspace.
But
it no longer make sense to have 2 distinct modules since we will have only
one
concept. But instead of integrating the workspace features into the
wiki-manager
module, we will create a new one.
Why? Because xwiki-platform-wiki-manager is not a compoment and this new
module
will be a clean component with a clean API and a clean script service.
Vincent
already has created a new 'wiki' module for his URL module so it make sense
to
go in this direction.
This new module will not be too long to implement since we can keep a lot
of
code from the 2 existing modules, but it will be written in a manner that
the
"farm" and the "workspace" use-cases are handled.
2.3 - The creation of a subwiki will not be possible until a subwiki
template
is created
-----------------------------------------------------------------------------
The user may not want to use subwikis, so we should not force him to do it.
Moreover, instead of having a "WorkspaceManager Install" process, we can
add a
new entry in the Administration that create the "workspacetemplate" and
actually
enable the "subwikis" features. It will not be seen a post-install
installation.
When creating the "workspacetemplate" (which will be called
"subwikitemplate"),
I will not remove XWiki.AdminRegistrationSheet, XWiki.RegistrationConfig,
XWiki.RegistrationHelp and XWiki.AdminUsersSheet. I will make some code to
"disable" them if the "local users" option is disabled. For example, the
RegisterSheet will redirect to the main wiki Registration.
2.4 - Merge WorkspaceManager UI and WikiManager UI
--------------------------------------------------
There will be only one UI in the future that shows all the subwikis and
offering
features of the 2 current UIs.
2.5 - Improve Invitation application
-------------------------------------
Right now, we both have the "workspaces users" section in the
administration and
the Invitation application. It seems that Invitation application is a
better
application than the "workspace users" section because it can do more
things.
But the UI should be improved.
Moreover, if a user wants to "join" a subwiki, the "join" link should be
located
near the "register" one. It would look more "integrated" than the current
thing.
At the end, it should replace the invitation feature of the current
"workspaces
users" section of the administration.
3. What I have already done
---------------------------
I have made a new wizard, based on the Caty proposal and the current
workspace
creation UI.
Screenshots:
- Step1:
http://tof.canardpc.com/view/582b629c-80c7-4e82-acda-ea99a20741a8.jpg
- Step2:
http://tof.canardpc.com/view/32737e88-9f78-4249-8063-caa42f92665c.jpg
I have also started to change the XARs organization of enterprise, see it
there:
http://markmail.org/message/e4agvo2gevst6gox
4 - What I propose to do for 5.2
---------------------------------
Regarding the objectives, it seems obvious that we won't have the time to
do all
the work for 5.2. So we have to decide what we do.
I propose to make it iteratively, but we have to take into account that the
"Workspace Integration" has been voted for 5.2.
So, we should:
- bundle the "Workspaces" application by default, not bundle the
"Wiki Manager UI". So the user can only create workspaces, which is the
main
use case. If the user want to create a subwiki like in the "farm"
use-case, he
will have to manually install WikiManager UI from the Extension Manager,
which
is not very hard!
- start dropping the "workspace" terminology. The Workspaces application
will be
integrated, but all the texts will mention "subwikis" instead of
"workspaces".
So the user will not be used to the "workspace" term since we want to
drop it
in the near future.
I don't know yet if it is better to create new translation keys or to
reuse
current ones (like workspacemanager.doc.createwiki.wikiname).
- we keep the current main page, we do not put the Workspaces main page by
default.
- we integrate the new subwiki creation wizard that I have made, but in the
end
it does not do more than the current workspace creation UI. We do not
implement the "users isolation" option.
- Add a link to WorkspaceManager.Install in the administration instead of
having
it in the main page.
- I create the menu Home/Wiki/Space/Page based on the option D of the
Caty's
proposal.
http://incubator.myxwiki.org/xwiki/bin/view/Improvements/CreateWikiImprovem…
The menu will be:
* Add
* Subwiki (if WorkspaceManager has been installed)
* Space
* Page
* Home
* Administer wiki (if you have the right)
* Subwiki directories
---
* Watch home (if you are in the main wiki)
* Document index (if you are in the main wiki)
* Subwiki (if you are not in the main wiki):
* Watch subwiki
* Administer subwiki
* Document index
* Delete subwiki
* Space:
* No change there
* Page:
* No change there
Then, for the next releases (5.3?), we start to make the work that I have
described in the long term objectives section.
Conclusion
----------
WDYT? ;)
Hello there,
I'd like to try to limit/customize the shown facets in the refinement
panel for the Solr search. This would allow for a custom search page
with different facet fields than the standard search (e.g. the facet
"page" or "date" might not be useful in every case) or the addition of
custom facet fields, for example "tags".
Instead of modifying the global defaults in solrconfig.xml, I'd want to
name the desired facet fields in the concrete solr query. Like
documented for example in
http://wiki.apache.org/solr/SimpleFacetParameters#Examples, if I want
both fields "cat" and "inStock", I need to add both fieldnames to the
query for the parameter "facet.field". On the Solr side, the set(String,
String[]) method
(http://lucene.apache.org/solr/4_2_1/solr-solrj/org/apache/solr/common/param…)
could be used for this. However, the current SolrQueryExecutor
implementation does not support this "multiple arguments" case, so for
example a $query.bindValue('facet.field', ["cat", "inStock"])) doesn't work.
To solve this problem, I suggest that SolrQueryExecutor.execute() checks
each value of the named parameters for a list and optionally calls
set(String, String[]) instead of set(String, String). I'd gladly supply
a patch for this issue. Is there any interest in this?
Sincerely,
Martin Kresse
--
Martin Kresse
Anwendungsentwicklung
EsPresto AG
Breite Str. 30-31
10178 Berlin/Germany
Tel: +49.(0)30.90 226.750
Fax: +49.(0)30.90 226.760
m.kresse(a)espresto.com
HRB 77554 B - Berlin-Charlottenburg
Vorstand: Maya Biersack, Peter Biersack
Vorsitzender des Aufsichtsrats: Dipl.-Wirtsch.-Ing. Winfried Weber
Zertifiziert nach ISO 9001:2008
Hi everyone,
I hope everybody is having a happy BFD - however if you are through with that, maybe someone can look into some issue with the translations.
Sometimes the translations and their deprecation keys seems not to match.
For example the key: 'annotations.config.title'
is deprecated, and as deprecation key on l10n I see: 'platform.extension.updater.reloadHint'
http://l10n.xwiki.org/xwiki/bin/view/Platform/PlatformXWikiCoreResources_90…
Looking at what 'platform.extension.updater.reloadHint' acutally means this is maybe a mismatch:
http://l10n.xwiki.org/xwiki/bin/inline/Platform/PlatformXWikiCoreResources_…
Also in some cases I suspect that a translation has been moved from a deprecated key to a new translation:
http://l10n.xwiki.org/xwiki/bin/view/Platform/PlatformXWikiCoreResources_-1…
It looks like there is a one-less error or the like when calculation the deprecation keys.
Is there any chance to fix that? Or am I simply mistaken?
Best Regards,
Clemens
Hi devs,
I need to have an Event that I can subscribe to that tells me when the DB is ready. This is for the activeinstalls module. I'd like to start some Quartz job when the DB is ready (I'm getting the unique id from the DB).
Thus I'd like to introduce a new DatabaseReadyEvent that's sent in XWiki.initXWiki() at the end of the method:
…
String syntaxes = Param("xwiki.rendering.syntaxes", "xwiki/1.0");
this.configuredSyntaxes = Arrays.asList(StringUtils.split(syntaxes, " ,"));
ObservationManager observationManager = Utils.getComponent((Type) ObservationManager.class);
observationManager.addListener(this);
--> send the event here
…
Note that in the future we'll refactor DB initialization so that it's performed when XWiki starts rather than on the first request and we'll probably introduce a notion of init sequence and thus it'll probably be possible to just subscribe to Application Started Event with the proper sequence id. Or we'll introduce a ApplicationInitializer component role with the ability to say before or after which role it should execute (or use a priority).
However this is complex to achieve right now and I feel a DatabaseReadyEvent would fill the need in the meantime.
WDYT?
Thanks
-Vincent