Hi guys,
Just got an idea about a talk I could give at a conference: Building a wiki, with XWiki Rendering and AngularJS.
The ideas are:
* Demonstrate XWiki Rendering through a use case which is to build a simple wiki
* Use a recent/modern framework like AngularJS to draw people to the talk ;)
* Talk about XWiki
* Get people to use xwiki rendering and grow the developer base for xwiki rendering
I think we're close to be able to implement this but it's missing one thing: ability to call XWiki Rendering from REST.
Thus I think it would be a good idea to move our REST framework into XWiki Commons and then in XWiki Rendering add a REST module to expose rendering operations through REST.
WDYT?
Thanks
-Vincent
Hi. I'm new to XWiki and haven't done much with Java and Maven, so
apologies for the dumb question...
I'm trying to build from the git repositories. I'm starting with
xwiki-commons and just naively typing "mvn" to see what happens. It
seems to get quite a long way through the build, but then dies with:
[WARNING] The POM for
edu.emory.mathcs.util:emory-util-classloader:jar:2.1 is missing, no
dependency information available
[ERROR] Failed to execute goal on project xwiki-commons-classloader-api:
Could not resolve dependencies for project
org.xwiki.commons:xwiki-commons-classloader-api:jar:4.5-SNAPSHOT:
Failure to find edu.emory.mathcs.util:emory-util-classloader:jar:2.1 in
http://repo1.maven.org/maven2 was cached in the local repository,
resolution will not be reattempted until the update interval of central
has elapsed or updates are forced -> [Help 1]
Interpreting the various .pom files, it looks like it expects to find
all necessary dependencies on maven.xwiki.org. Looking through the
hierarchy there, seems like there's org. and com. hierarchies, but
nothing under edu. at all.
Am I supposed to configure other repositories myself before this build
will work? Or is it just an oversight that edu.emory.mathcs.util isn't
already included on maven.xwiki.org?
Thanks for any help!
Hi all,
I am about to contribute an application I made to provide an UI for
multipage pdf export (
http://extensions.xwiki.org/xwiki/bin/view/Extension/Multipage+PDF+Export )
to help export pages in a space, displayed in a hierarchy like UI (using
the hierarchy macro), and, after long reflection, I decided to put this
application in its own repository (another option would have been to put
it in the multipagepdfexport repository already existing). The choice is
motivated mainly by the need to version it independently.
Repository name: multipagepdfexport-application-spaceexport
User name: lucaa
Thanks a lot,
Anca Luca
Hi devs,
I'd like to propose that we use the XWiki.org JIRA project more:
http://jira.xwiki.org/browse/XWIKIORG
The idea is to create issues in it whenever we see stuff to improve on xwiki.org.
I'm also proposing to do the following actions:
* Modify it in JIRA so that this project doesn't have any Affects and Fix for fields. The idea is to simple have a list of issues and no releases.
* Add some documentation on the contribution page on xwiki.org to explain that creating jira issues for stuff to improve on xwiki.org is a way to contribute too
* Send an email to the users list asking people to create jira issues for stuff to improve on xwiki.org
* Modify the xwiki.org feedback form on xwiki.org to ask users to create jira issues for stuff they'd like to see improved
* Move documentation located in JIRA Platform project (and possibly others) to the XWiki.org JIRA project
Are you ok about this?
Once this is all done I'll send another email to propose to start again the Doc Days (say one per month).
Thanks
-Vincent
fyi, we might want to upgrade for 3.4 for example.
-Vincent
Begin forwarded message:
> From: Simon Willnauer <simonw(a)apache.org>
> Subject: [ANNOUNCE] Apache Lucene 3.5.0 released
> Date: November 27, 2011 2:40:07 PM GMT+01:00
> To: announce(a)apache.org
> Reply-To: simonw(a)apache.org
>
> November 27 2011, Apache Luceneâ„¢ 3.5.0 available
>
> The Lucene PMC is pleased to announce the release of Apache Lucene 3.5.0.
>
> Apache Lucene is a high-performance, full-featured text search engine
> library written entirely in Java. It is a technology suitable for nearly
> any application that requires full-text search, especially cross-platform.
>
> This release contains numerous bug fixes, optimizations, and
> improvements, some of which are highlighted below. The release
> is available for immediate download at:
>
> http://www.apache.org/dyn/closer.cgi/lucene/java (see note below).
>
> See the CHANGES.txt file included with the release for a full list of
> details.
>
> Lucene 3.5.0 Release Highlights:
>
> * Added a very substantial (3-5X) RAM reduction required to hold the
> terms index on opening an IndexReader. (LUCENE-2205)
>
> * Added IndexSearcher.searchAfter which returns results after a
> specified ScoreDoc (e.g. last document on the previous page) to
> support deep paging use cases. (LUCENE-2215)
>
> * Added SearcherManager to manage sharing and reopening IndexSearchers
> across multiple search threads. Underlying IndexReader instances are
> safely closed if not referenced anymore. (LUCENE-3445, LUCENE-3558)
>
> * Added SearcherLifetimeManager which safely provides a consistent
> view of the index across multiple requests (e.g. paging/drilldown).
> (LUCENE-3558, LUCENE-3486)
>
> * Renamed IndexWriter.optimize to forceMerge to discourage use of
> this method since it is horribly costly and rarely justified
> anymore. (LUCENE-3439)
>
> * Added NGramPhraseQuery that speeds up phrase queries 30-50%
> when n-gram analysis is used. (LUCENE-3426)
>
> * Added a new reopen API (IndexReader.openIfChanged) that
> returns null instead of the old reader if there are no changes
> in the index. (LUCENE-3464)
>
> * Improvements to vector highlighting: support for more queries
> such as wildcards and boundary analysis for generated snippets
> (LUCENE-1824, LUCENE-1889)
>
> * IndexSearcher and IndexReader now perform additional checks to
> throw AlreadyClosedExceptions if searches are performed on a
> closed IndexReader. Performing searches on already closed reader
> can cause JVM crashes when invalid memory mapped files are
> referenced.
>
> * Several bugfixes, including a bug where closing an NRT reader
> after the writer was closed was incorrectly invoking the
> DeletionPolicy. See CHANGES.txt entries for full details.
>
> Note: The Apache Software Foundation uses an extensive mirroring network for
> distributing releases. It is possible that the mirror you are using may not
> have replicated the release yet. If that is the case, please try another
> mirror. This also goes for Maven access.
>
> Happy searching,
>
> Apache Lucene/Solr Developers
Hello devs,
FYI I've created a repository in contrib with the basis of an
experimental spatial module [1].
There is also a design document I've started working on a couple of
weeks ago on the dev wiki [2].
The basic idea in one line is to be able to store and query geometries
(points, shapes, etc.) as first class XWiki properties.
It's very early support (it actually works only on a custom branch of
the SOLR API module for now) and I will continue to work on it in the
near future. I'm posting this so that if there are other committers or
contributors interested in the topic we can start a discussion.
[1] https://github.com/xwiki-contrib/module-spatial
[2] http://dev.xwiki.org/xwiki/bin/view/Design/SpatialModule
Thanks,
Jerome.