After playing for while trying to create new virtual wikis in a 1.2
XWiki installation I can only conclude that something weird is happening
here.
As far as I remember, once you create a new database for a new virtual
wiki, its schema is "automatically" updated. It seems that this doesn't
happen here.
Please, when must the schema be updated? The controller xwiki user has
full rights on the new virtual wiki database.
Thanks!
--
Ricardo RodrÃguez
Your EPEC Network ICT Team
Hi everyone,
Just to let you know that I've finally implemented the separation of
the skins from the web module that was planned a long time ago.
See http://jira.xwiki.org/jira/browse/XWIKI-2031 for details
If you svn up you'll find a new xwiki-platform-skins/ directory.
Also, the distribution now only includes the Albatross skin by default
(see http://jira.xwiki.org/jira/browse/XWIKI-2032 for details)
I've also created one JIRA project for each skin so from now on please
remember to use the Albatross jira project if you have issues
regarding the albatross skin. If you find open issues in the platform
that are for the Albatross skin don't hesitate to move them over too.
Last, I've released the skin in version 1.0 as is so the current
versions in trunk are now 1.1-SNAPSHOT for all.
I'm currently finishing uploading them on ObjectWeb and modifying
xwiki.org.
Thanks
-Vincent
Hi all
I'm just an Linux/Apace/MySQL/PostgreSQL guy (and no developer). I have no
experience with Tomcat or whatsoever. Maybe I could indeed deploy the
xwiki-installation but I'm not sure about that, so I'm asking for a
step-by-step Howto (something like you can see on http://www.howtoforge.com
).
Web(!)Server: Linux Debian 4 (console only)
DB: MySQL
Apache 2.2.x (mod_proxy must be used as mod_jk is obsolet as I saw it)
Please with a Domain example.
I would donate $50. Maybe there are other ppl who are interested in that and
would donate too??
Anybody willing to lower the xwiki installation-barrier (no offend
xwiki-guys :))?
Cheers
Hi,
I am a newbie to Xwiki, just a day's worth of knowledge!
I was looking for information on the reasons for choosing HSQL DB as the
backend!
Any response will be appreciated!
Thanks
Hi all,
using the "Copy a document" page with:
- source document=XWiki.provaCopia
- target document mySpace.provaCopia
I get this result:
- Copying document XWiki.provaCopia () from xwiki to xwiki:
$xwiki.xWiki.copyDocument($sourcedoc, $targetdoc, $sourcewiki, $targetwiki,
$language, false, $context.context)
and the copy is not done.
Can you help me??
Good day, community.
I think, some parts of JIRA comments (see below, especially after '***') must
be discussed in mail list.
---------- Forwarded Message -----------
From: "rssh" <rssh(a)gradsoft.com.ua>
To: "Thomas Mortagne (JIRA)" <jira(a)xwiki.org>
Sent: Sun, 13 Jan 2008 18:45:56 +0300
Subject: Re: [Issue] Commented: (XWIKI-2006) allows to configurate name of
database schema [patch[
> your code does not follow the xwiki coding rules to be applied
> (mainly javadoc and some code style). See
http://dev.xwiki.org/xwiki/bin/view/Community/CodeStyle
>
Hmm, on first intention coding rules are standard. Ok, I will look and
produse third patch.
***
> Some more personal comments:
> - I think you should separate theses two different features in two
> jira and patches - I don't see the need for staticParam(String key)
> and staticGetMainDatabaseSchemaName()
Ok -- what is another way to read something from configuration file in
static context ?
Is name of configuration file is not encapsulated inside XWiki ?
- I think only HibernateStore
> should knows about main database name and prefix database name,
> especially the way you implement it at wiki name -> database name
> conversion.
This means remove all you add to XWiki and call
> context.getWiki().Param("xwiki.db") directly in
> getSchemaFromWikiName for example. - I think "xwiki.db" is not the
during initialization of wiki (where exists calls of hibernate store)
context.getWiki() return null, so this is impossible.
> best name for that parameter as it's only used in virtual mode and
> it's the main wiki database name I would prefer something like
> "xwiki.virtual.db.main". If this parameter means also the database
> name in non virtual mode I doubt it works as context's database is
> not taken into account in non virtual mode.
>
I would vote against usage of 'xwiki.virtual.db.main' in non-virtual mode,
because find this confusing.
(But you free to change names during/after import of the path)
> About your implementation of main wiki name, I would prefer to
Sorry, I can't understand you. I does not touch implementation of main wiki
name.
> modify what XWikiContext.getMainWiki returns which is here for
> that. We could remove derby and hsqldb specifics conversions that
A afraid, that if I understand what you try to say, this will be completely
other story. Much bigger and harder (and I afraid in some cases impossible).
Why -- because in XWiki getDatabase()/setDatabase() calls used in meaning
get/set database and get/set application name. Now, when database name and
wiki name become differ, to do this would be necessary review each call of
get/set Database() in XWiki and XWikiContext, understand - what was means
(application name or database name) and change. This would be more complex
structure (where we will have logical database names) and (from my point of
view) this complexity will not give any benefits.
> would be useless if it can be setted in xwiki.cfg. This means review
> the code to remove the remaining "xwiki" use as main wiki in place
> of calling context.getMainXWiki().
>
Sorry, but you talk about some other path. I just does not touch this
part of xwiki, in my path all about 'logical names' is remaining as in
previous version.
> > allows to configurate name of database schema [patch[
> > -----------------------------------------------------
> >
> > Key: XWIKI-2006
> > URL: http://jira.xwiki.org/jira/browse/XWIKI-2006
> > Project: XWiki Platform
> > Issue Type: New Feature
> > Affects Versions: Future
> > Environment: any
> > Reporter: Ruslan Shevchenko
> > Priority: Minor
> > Attachments: configurated_db_schema_02.patch
> >
> >
> > attached path allows to configure
> > 1. name of database schema of main wiki.
> > 2. prefixes for database schemas for virtual wikis.
> > (tested by hand with normal and virtual wiki configurations)
>
> --
> This message is automatically generated by JIRA.
> -
> If you think it was sent incorrectly contact one of the
> administrators: http://jira.xwiki.org/jira/secure/Administrators.jspa
> -
> For more information on JIRA, see: http://www.atlassian.com/software/jira
--
Ruslan Shevchenko
GradSoft. http://www.gradsoft.ua
------- End of Forwarded Message -------
--
Ruslan Shevchenko
GradSoft. http://www.gradsoft.ua
Hi everyone,
Some time back XWiki SAS, the company who started XWiki had a free
online farm on xwiki.com. This farm was closed for new projects a few
months ago after XWiki SAS realized it didn't have the manpower (or
finance) to support it in a professional way. XWiki SAS still has a
professional farm offering but it's not a free farm (see http://www.xwiki.com/xwiki/bin/view/Services/#HHosting)
.
I'd like to discuss with you the idea of offering a free farm managed
by the xwiki community and under the xwiki.org umbrella. In essence it
means there would be 2 farms available:
* a paying one which is on xwiki.com, for professional needs
* a free one on xwiki.org for universities, individuals or anyone not
requiring guaranteed support/availability at all times
Here's how it would work:
* No support guarantee. All support done on the xwiki.org user mailing
list.
* No stability guarantee. We would always install the latest Platform/
XE/XEM version on it and it would serve as a stability test for the
xwiki development team. Obviously the community will always try to
make it as stable as possible but that's not guaranteed.
* There will be several members of the community who'll have admin
access on the farm.
* We will reduce admin tasks by offering a simple UI on the farm
itself (restart, see memory stats, see blocking requests, ban a wiki,
etc)
* It will be open to anyone. However the target users will be
technical people who can support themselves to some extent. We won't
control that but it'll be mentioned on the registration page.
XWiki SAS would pay for the machine, hosting and the initial
installation.
I have 2 questions for you:
1) As a user of it, would you be interested by such a farm? Do you
think it's interesting for the xwiki project to have such a free farm?
2) As a community member, would you be willing to help administer it/
support it? For this farm to work we need to find several members of
the xwiki community willing to help administer it. Here are the tasks
I can think of:
- work on the welcome page content for the farm
- work on the FAQ for the farm (like "what do I do if I've lost my
password", etc)
- help answer user questions on the list (this can and should be be
done by everyone)
Thanks
-Vincent, with 2 hats: community developer and CTO of XWiki SAS
The XWiki development team is pleased to announce the release of XWiki
Enterprise Manager 1.0 Release Candidate 1.
Go grab it at http://www.xwiki.org/xwiki/bin/view/Main/Download
This is the first release candidate leading to XWiki Enterprise Manager 1.0.
The main new features is Wiki Manager GlobalSearch that implement a
multiwiki version of search(), searchDocuments() and
searchDocumentsNames(). It's also the first XEM released based on
final 1.2 version of XE.
For more information see the Release notes at:
http://www.xwiki.org/xwiki/bin/view/Main/ReleaseNotesXEM10RC1.
Thanks -The XWiki dev team.
Hi,
As you know I've started exploring using Doxia for XWiki's rendering.
I started writing a Doxia Sink (for generating XWiki wiki syntax
source code) and a Doxia XWiki Parser.
I'm implementing this in the Doxia project itself (in the sandbox for
now till it's ready).
You can see what I have committed so far here:
http://svn.apache.org/repos/asf/maven/sandbox/trunk/doxia/doxia-module-xwik…
You can also see the jira issue I've created to modify Doxia to fit
our needs here:
http://tinyurl.com/2wpeqg
Status:
* First xwiki sink version written
* First xwiki parsing version written (not fully functional yet, not
all syntax supported yet)
* Next: Copy the link parser I have writte in xwiki's source code to
Doxia's xwiki module
* Next: Modify Doxia to implement http://tinyurl.com/2wpeqg
* I've also started writing a wrapper around both Doxia/Wikimodel that
I'd like to commit in xwiki (in a xwiki-rendering module for example)
so that XWiki is independent from any rendering framework. To be
honest I don't know if this is going to work fully but it seems the
right thing to do for now. If someone is interested in writing the
wikimodel implementation of it or help me work on it, let me know and
I'll commit it.
As you can see there are quite a few modifications that are required
to be done in Doxia before we can have a functional XWiki Parser/Sink.
Thanks
-Vincent