Hi list,
In order to ease XWiki installation for those who don't want to deal
with tomcat/mysql, Ludovic asked me to work on a standalone installation
of XWiki based on jetty and hsqldb.
I think I get to a point where I have something useful, so I wanted to
describe what I have done, and if Ludo agrees to create an account for
me, I will be able to commit some files in the next few days ;-)
So, I have added a 'standalone' target into the build.xml file (see
below). This target expands a jetty.5.1.5 archive, removes the sample
applications, inserts the xwiki release (exploded war) into the webapps
directory, copies some configuration files in order to make xwiki use an
in-process hsqldb database. hsqldb database files are also copied into
the package. The database data have been taken from the mysql export
(xwiki-db-0.9.2.sql).
At the root of this package, 4 scripts are eventually copied in order to
help user to start/stop the application server (start_xwiki.bat|sh,
stop_xwiki.bat|sh).
The produced package is usable 'as-is' simply by copying the files
somewhere on your disk. And yes, it works on a USB key also. It weights
a total of 37 MB.
With this target, I have also written a basic Nullsoft Installer script,
in order to help Windows users in installing the package. Basically this
installer installs all the files produced by the standalone target in a
user specified directory, then create 3 shortcuts in the Windows start
menu: start, stop (Ã la tomcat) and uninstall. Before doing this the
installer checks if a jre 1.4 or newer is installed (I'm not sure that
1.4 is required for xwiki, this can be changed easily), if not the user
is redirected to the download section of the Java web site. This
installer weight a total of 30 MB.
On the todo list of this installer :
- add the possibility to specify a port number for the jetty server ;
- install a bundled jre if needed (have to check the sun license in
order to be sure this is possible)
- add a final window explaining what to do after the installation (use
the start/stop shortcuts, start a browser...)
On the todo list of this standalone installation :
- add an installer for Mac OS X platforms
- add an installer for Linux platforms (autopackage ?), may be not so
useful, since Linux users are more acquainted to tomcat/mysql
installation ...
Any question, comment, idea would be greatly appreciated.
Seb.
here is the standalone target code :
<!-- Standalone package properties -->
<property name="standalone.base.dir" value="${basedir}/standalone"/>
<property name="standalone.jetty.archive.dir" value="jetty-5.1.5"/>
<property name="standalone.jetty.archive"
value="${standalone.base.dir}/${standalone.jetty.archive.dir}.zip"/>
<property name="standalone.package.name" value="xwikionjetty"/>
<property name="standalone.release.dir"
value="${release.dir}/${standalone.package.name}"/>
<fileset id="standalone.db.bootstrap"
dir="${standalone.base.dir}/db" includes="xwiki_db.*"/>
<fileset id="standalone.config" dir="${standalone.base.dir}/config"
includes="xwiki.cfg, hibernate.cfg.hsql.xml"/>
<fileset id="standalone.scripts"
dir="${standalone.base.dir}/scripts" includes="*"/>
<target name="standalone" depends="release">
<!-- unzip jetty archive into standalone release dir -->
<!-- exclude some jetty provided jar files in order to avoid clashes -->
<!-- these jars are provided by xwiki -->
<unzip src="${standalone.jetty.archive}" dest="${release.dir}">
<patternset>
<exclude name="**/ext/xercesImpl.jar"/>
<exclude name="**/ext/xml-apis.jar"/>
<exclude name="**/ext/xmlParserAPIs-2.5.jar"/>
</patternset>
</unzip>
<move todir="${standalone.release.dir}">
<fileset dir="${release.dir}/${standalone.jetty.archive.dir}"/>
</move>
<!-- remove example webapps -->
<delete file="${standalone.release.dir}/webapps/javadoc.war"/>
<delete dir="${standalone.release.dir}/webapps/template"/>
<!-- explode xwiki war file into jetty/webapps -->
<mkdir dir="${standalone.release.dir}/webapps/xwiki"/>
<unwar src="${release.warfile}"
dest="${standalone.release.dir}/webapps/xwiki"/>
<!-- replace configuration files with standalone version -->
<copy todir="${standalone.release.dir}/webapps/xwiki/WEB-INF"
overwrite="true">
<fileset refid="standalone.config"/>
</copy>
<!-- install db bootstrap -->
<mkdir dir="${standalone.release.dir}/db"/>
<copy todir="${standalone.release.dir}/db">
<fileset refid="standalone.db.bootstrap" />
</copy>
<!-- install start/stop scripts -->
<copy todir="${standalone.release.dir}">
<fileset refid="standalone.scripts"/>
</copy>
</target>
The sounds awsome.
I really would like a standalone package that runs off a USB key.
I teach tech classes at a local college and have started using XWiki for presentations and documentation. Sometimes the colleges internet connection is not so reliable so I have fretted about not having my presentations available during class. To overcome this I have been bringing a laptop configured as a linux server with xwiki installed hosting all my presentations and notes.
As you can see XWiki on a USB key would be absolutlely useful
Great work!
Dennis
Dennis
> Hi list,
>
> In order to ease XWiki installation for those who don't want to deal
> with tomcat/mysql, Ludovic asked me to work on a standalone installation
> of XWiki based on jetty and hsqldb.
>
> I think I get to a point where I have something useful, so I wanted to
> describe what I have done, and if Ludo agrees to create an account for
> me, I will be able to commit some files in the next few days ;-)
>
> So, I have added a 'standalone' target into the build.xml file (see
> below). This target expands a jetty.5.1.5 archive, removes the sample
> applications, inserts the xwiki release (exploded war) into the webapps
> directory, copies some configuration files in order to make xwiki use an
> in-process hsqldb database. hsqldb database files are also copied into
> the package. The database data have been taken from the mysql export
> (xwiki-db-0.9.2.sql).
>
> At the root of this package, 4 scripts are eventually copied in order to
> help user to start/stop the application server (start_xwiki.bat|sh,
> stop_xwiki.bat|sh).
>
> The produced package is usable 'as-is' simply by copying the files
> somewhere on your disk. And yes, it works on a USB key also. It weights
> a total of 37 MB.
>
> With this target, I have also written a basic Nullsoft Installer script,
> in order to help Windows users in installing the package. Basically this
> installer installs all the files produced by the standalone target in a
> user specified directory, then create 3 shortcuts in the Windows start
> menu: start, stop (Ã la tomcat) and uninstall. Before doing this the
> installer checks if a jre 1.4 or newer is installed (I'm not sure that
> 1.4 is required for xwiki, this can be changed easily), if not the user
> is redirected to the download section of the Java web site. This
> installer weight a total of 30 MB.
>
> On the todo list of this installer :
>
> - add the possibility to specify a port number for the jetty server ;
> - install a bundled jre if needed (have to check the sun license in
> order to be sure this is possible)
> - add a final window explaining what to do after the installation (use
> the start/stop shortcuts, start a browser...)
>
> On the todo list of this standalone installation :
>
> - add an installer for Mac OS X platforms
> - add an installer for Linux platforms (autopackage ?), may be not so
> useful, since Linux users are more acquainted to tomcat/mysql
> installation ...
>
> Any question, comment, idea would be greatly appreciated.
>
> Seb.
>
> here is the standalone target code :
>
> <!-- Standalone package properties -->
> <property name="standalone.base.dir" value="${basedir}/standalone"/>
> <property name="standalone.jetty.archive.dir" value="jetty-5.1.5"/>
> <property name="standalone.jetty.archive"
> value="${standalone.base.dir}/${standalone.jetty.archive.dir}.zip"/>
> <property name="standalone.package.name" value="xwikionjetty"/>
> <property name="standalone.release.dir"
> value="${release.dir}/${standalone.package.name}"/>
>
> <fileset id="standalone.db.bootstrap"
> dir="${standalone.base.dir}/db" includes="xwiki_db.*"/>
> <fileset id="standalone.config" dir="${standalone.base.dir}/config"
> includes="xwiki.cfg, hibernate.cfg.hsql.xml"/>
> <fileset id="standalone.scripts"
> dir="${standalone.base.dir}/scripts" includes="*"/>
>
> <target name="standalone" depends="release">
> <!-- unzip jetty archive into standalone release dir -->
> <!-- exclude some jetty provided jar files in order to avoid clashes -->
> <!-- these jars are provided by xwiki -->
>
> <unzip src="${standalone.jetty.archive}" dest="${release.dir}">
> <patternset>
> <exclude name="**/ext/xercesImpl.jar"/>
> <exclude name="**/ext/xml-apis.jar"/>
> <exclude name="**/ext/xmlParserAPIs-2.5.jar"/>
> </patternset>
> </unzip>
> <move todir="${standalone.release.dir}">
> <fileset dir="${release.dir}/${standalone.jetty.archive.dir}"/>
> </move>
>
> <!-- remove example webapps -->
> <delete file="${standalone.release.dir}/webapps/javadoc.war"/>
> <delete dir="${standalone.release.dir}/webapps/template"/>
>
> <!-- explode xwiki war file into jetty/webapps -->
> <mkdir dir="${standalone.release.dir}/webapps/xwiki"/>
> <unwar src="${release.warfile}"
> dest="${standalone.release.dir}/webapps/xwiki"/>
>
> <!-- replace configuration files with standalone version -->
> <copy todir="${standalone.release.dir}/webapps/xwiki/WEB-INF"
> overwrite="true">
> <fileset refid="standalone.config"/>
> </copy>
>
> <!-- install db bootstrap -->
> <mkdir dir="${standalone.release.dir}/db"/>
> <copy todir="${standalone.release.dir}/db">
> <fileset refid="standalone.db.bootstrap" />
> </copy>
>
> <!-- install start/stop scripts -->
> <copy todir="${standalone.release.dir}">
> <fileset refid="standalone.scripts"/>
> </copy>
> </target>
>
>
>
>
>
>
>
> --
> You receive this message as a subscriber of the xwiki-dev(a)objectweb.org mailing
> list.
> To unsubscribe: mailto:xwiki-dev-unsubscribe@objectweb.org
> For general help: mailto:sympa@objectweb.org?subject=help
> ObjectWeb mailing lists service home page: http://www.objectweb.org/wws
When XWiki renders a document, the interactions between the Groovy,
Velocity, and Wiki (Radeox?) syntax processing can lead to unexpected and
undesirable behavior. There have been posts on this list in the past where
this issue has been discussed. However, I'm not aware that any consensus has
emerged as to how to deal with these problems.
To summarize, here are a few of the issues that I'm aware of:
* Getting XWiki to render a bit of text without doing any syntax processing
on it can be difficult. For example, the {pre} ... {/pre} markup turns off
XWiki syntax processing, but not Groovy processing.
* The # symbol is used both to do numbered lists and is also used for Groovy
processing. If a user wants to create a numbered list and forgets to put a
space after the #, he can run into trouble. The following example will cause
a stack dump:
#bring coffee
#include doughnuts
* Code samples on a Wiki page sometimes don't render correctly, due to
conflicts with Velocity syntax processing. The following C/C++ code sample
results in a runtime stack dump:
{code}
#include <stdio.h>
...
{code}
* Groovy and Velocity both use $varname syntax. I think I've read some posts
in the past where this was an issue -- although I can't come up with any
examples at the moment.
* A usability issue: Most XWiki tags ({table}, {code}, etc.) come in pairs.
The closing tag has no slash. For example: {table} ... {table}. However,
the {pre} tag does have a closing slash: {pre} ... {/pre}. This
inconsistency is annoying and causes difficulties for new users.
* A significant usability issue for Windows users: Pathnames contain
backslashes (\). XWiki uses the backslash as an escape character. So
attempting to put a UNC path like \\myserver\myshare\mydoc.txt in an XWiki
document triggers an XWiki runtime exception. Boy, is that frustrating for
new XWiki users. The solution is to wrap the path in {pre} .. {/pre}, but
the error message gives the user no clue what the problem was, much less how
to correct it.
Here are some proposals for discussion:
1. {pre} ... {/pre} should turn off ALL syntax processing of its contents.
2. {code} ... {code} should turn off ALL syntax processing, except for
syntax coloring.
3. {pre} should allow {pre} as a closing tag.
4. Consider requiring users to explicitly enable Groovy/Velocity processing
for selected Wiki documents as needed. In the page editor, provide two
checkboxes: "Perform Groovy Processing" and "Perform Velocity Processing".
The user could separately enable either Groovy or Velocity processing, or
both. People who enable them would presumably be in a better position to
deal with the kinds of syntax conflicts that would occur.
5. Provide more user-friendly error messages when a Groovy or Velocity
processing exception occurs. Show the Wiki source line that caused the
problem.
I haven't opened a JIRA issue for this yet, because I'm not sure how best to
word it. But I think this is a high-priority issue that should be carefully
addressed before the 1.0 release. This may be an issue that warrants a page
on the xwiki.org developer site. I'll be glad to start one if the developers
desire it -- perhaps here:
http://www.xwiki.org/xwiki/bin/view/Dev/Discussions
Stephen
Thought you might enjoy this.
------- Forwarded message -------
From: "Karl Dubost" <karl(a)w3.org>
To: "'public-evangelist(a)w3.org' w3. org" <public-evangelist(a)w3.org>
Subject: HOWTO Spot a Wannabe Web Standards Advocate
Date: Thu, 10 Nov 2005 20:10:30 -0000
Evangelistas,
[[[
HOWTO Spot a Wannabe Web Standards Advocate
If there is a match, you have spotted a wannabe.
* Talks about the importance of the alt tag.
* Claims <b> and <i> are deprecated.
* And spells it %u201Cdepreciated%u201D.
* Uses <span style="font-style: italic;">, because <i> is
presentational.
* Wants software to use <em> and <strong> when the UI says
italic and bold.
* Marks up quoted text as <cite>.
* Complains about upper-case tags in HTML.
* Claims XHTML 1.0 is more semantic than HTML 4.01.
* Claims XHTML 1.0 is more structured than HTML 4.01.
* Claims XHTML 1.0 is less presentational than HTML 4.01.
* Claims browsers parse XHTML served as text/html faster than
they parse HTML.
* Refers to %u201Cthe benefits of XHTML%u201D without specifying
what the benefits are.
* Uses large XHTML 1.0 Transitional documents with table layouts
while claiming enhanced compatibility with handheld devices thanks to
XHTML.
* %u201CFuture proofs%u201D a site by migrating from HTML 4.01
Transitional to XHTML 1.0 Transitional and keeps serving it as text/
html with all the old JavaScript scripts in place.
* Uses the XML empty element notation on pages that are supposed
to be HTML pages.
* Complains about doctypeless application/xhtml+xml or SVG
documents and smugly points to validator.w3.org.
* Claims all tables are evil.
* Advocates pixel-based absolute CSS positioning as the
righteous replacement for evil tables.
* Changes //EN at the end of the public identifier in the
doctype to the language code of the language the page is written in.
* Omits the namespace declaration in XHTML or SVG and claims it
is OK, because it validates.
* Serves documents written using a home-grown XML vocabulary
along with an XSLT transformation to HTML to browsers instead of
serving HTML, because XML is more semantic.
]]]
-- HOWTO Spot a Wannabe Web Standards Advocate
http://hsivonen.iki.fi/wannabe/
Wed, 27 Jul 2005 17:06:31 GMT
--
Jim Stuttard
Hi,
As tempus fugit towards release 1.0 I have a bit of a basic architecture
problem with the current DB schema.
Why does XWiki's DB schema depend on a number of proxy primary keys - eg.
ID: bigint? XWikiListClasses has a primary key of id, and name;
XWikiClasses has only a numeric id and name doesn't seem to matter. Is
this just me missing some basic idea?
Doesn't this hide the cardinalities, semantic connections and
non-transitive dependencies captured by primary keys in a fully-normalised
relational schema?
Currently this information would have to be inferred from the existing
schema, taking some time to do. And so I can't tell whether the schema is
normalised or not.
An example might be a Document. If memory serves me, Documents are
frequently uniquely identified by the minimal primary key of {title,
author, publication date}. If you ask "What are the chances of 2 different
documents having the same author name, title and publication timestamp?"
then this satisfices most conditions. An XWikiDoc however has a large set
of required fields and a single key.
Neither MySql nor any other RDBMS I know of uses single-field primary
keys. They are only required in the binary relational model.
I have always thought that good OODB design demanded *explicit*
de-normalisation if needed?
Cheers
Jim
--
Jim Stuttard
Hi
I'd like to propose a patch for com.xpn.xwiki.doc.XWikiDocument in order to
add a function that can allow user to create attachments.
Regards
--
Xavier MOGHRABI - Consortium ObjectWeb
Email: xavier.moghrabi at objectweb.org
Phone: +33 4 76 61 52 35
I've noticed that the version number (correctly) gets bumped for
every new comment or image upload. However, I would like a means to
show a list of revisions for _just_ content changes, i.e. exlude the
revisions which were created for new comments and attachments. How
would I do this in some velocity code?
Thanks,
Matt
Greetings,
I am new to xwiki and was wondering how some of the multi-company features of xwiki work. From my readings it sounds like one must create a separate mysql db for each new company/tenant. If this is true would this not require a seperate database connection pools for each company?
Are Oracle or Postgresql supported? I know with these two databases one can create database namespaces (something mysql does not have). This would allow the same jdbc driver to reference mulitple namespaced schemes and thus use the same pool.
Anyway, any thoughts would be apprciated. I am looking to setup xwiki in a multi company setup and was looking for some insight.
Thanks,
Sam
---------------------------------
Yahoo! Music Unlimited - Access over 1 million songs. Try it free.
Here's an issue I feel should be addressed before the 1.0 release:
Create a wiki page with links like the following:
[Images: Good or Bad?]
[C++ Examples]
XWiki renders the first link like this:
<a class="wikicreatelink" href=""><span class="wikicreatelinktext">Images:
Good or Bad?</span><span class="wikicreatelinkqm">?</span></a>
It's completely broken. The second link is rendered like this:
<span class="wikilink"><a href="/xwiki/bin/view/Sandbox/C+++Examples">C++
Examples</a></span>
XWiki should be able to gracefully handle Wiki links with non alpha-numeric
characters.
Here are my thoughts on a solution to the problem:
1. When rendering a Wiki link, XWiki could strip out all non-alphanumeric
characters. Thus, a link like [Images: Good or Bad?] would render as <a
href="/.../ImagesGoodorBad">Images: Good or Bad?</a>. Benefits:
Straightforward to implement. Yields nice clean document names. Drawbacks:
Presents backwards compatibility problems; several different Wiki links
could map to the same document name.
2. XWiki could perform URL encoding on the Wiki links. Benefits: Better
backwards compatibility (I think). Drawbacks: Yucky document names.
Perhaps there are other solutions somewhere in between. My personal
preference is #1. Backwards compatibility could perhaps be addressed with a
configuration option switch.
I created a Jira issue for this: http://jira.xwiki.org/jira/browse/XWIKI-188
Thoughts?
Stephen
Here is a status on the development towards the next release, which
should be the one of the very last release before 1.0.
The following major feature have been added to the current SVN version
Thanks to the Summer of Code we have now
- a WYSIWYG Editor
- a Chart Wizard
- a new Query Language
Additionnally we have:
- a new title field and different rendering of document names in links
and in the header
- a backlinks feature (activated using xwiki.backlinks=1 in xwiki.cfg)
- a custom mapping feature allowing to store XWiki Objects in flat
tables for advanced developments
- new storage of XWiki classes definition in the xwikidoc table instead
of multiple tables
- the XWiki Preferences now use a custom mapping for better performance
- lot's of bug fixes, incl. access through proxies, issues with the
multilingual feature
- an import/export API (for backups and for XWiki applications) which is
needed for the Import/Export XWiki page
- improvements to the URL scheme which will allow to reduce the number
of elements in the xwiki URLs (currently some XWiki features still need
xwiki to run on the /xwiki/ path)
These are a lot of new features which needs to be well tested before
become fully usable. Most of the features can be deactivated or are
backwards compatible.
We would need some help from the XWiki community to test this new
version and report any issues in JIRA ( http://jira.xwiki.org ).
Except for the preferences storage and the xwiki classes definition
storage, it is possible to revert to an older version even if running
the new version. Now it is highly recommended to backup your database
and test with care on production data.
I'm planning to provide a test build for developers, but if you want to
test right away, you will need to build XWiki from the SVN code.
The plan for getting XWiki to 1.0 is:
- bug fixing
- bug fixing
- documentation
- very small missing features
- bug fixing
- documentation
- revamp of the XWiki interface according to the Usability report done
during the summer
- bug fixing
- documentation
Any help or comments is welcome.
For now it would be usefull to identify bugs that would absolutely need
to be fixed before releasing this version to replace 0.9.840. The
objective is to provide an improvement versus 0.9.840 and allow working
with the new features, not necessarily to provide a perfect version.
Thanks and happy testing
Ludovic
--
Ludovic Dubost
XPertNet: http://www.xpertnet.fr/
Blog: http://www.ludovic.org/blog/
XWiki: http://www.xwiki.com
Skype: ldubost AIM: nvludo Yahoo: ludovic
