xwiki-devs July 2012

xwiki-devs@xwiki.org

33 participants
98 discussions

by Jonathan Solichin

Hello friends, Just wanted to say, I figured out the issue with my changes not loading. the macros.vm was getting cached. I put the following lines in xwiki.properties to stop it. velocity.properties = file.resource.loader.cache = false velocity.properties = velocimacro.library.autoreload = true I hope this is the best solution. Thanks JS

12 years, 5 months

[xwiki-devs] Fwd: [GSoc] XDroid Platform

by sasinda rukshan

---------- Forwarded message ---------- From: sasinda rukshan <sasindarukshan(a)gmail.com> Date: Mon, Jun 18, 2012 at 2:56 PM Subject: Re: [xwiki-devs] [GSoc] XDroid Platform To: XWiki Developers <devs(a)xwiki.org> Hi Thomas, Thanks for the explanations. The methods toXML , toEmbedXML are wrong.It was just an idea that came up without much thinking. I will use a separate model converter.(xwikitTosimpleModelConverter implements ModelConverter like thing). So the model objects don't know about it at all. By what you ment by "user" I think it is the client app developer is it? you did not mean end user. I never reveal the xml representations to end users. I came up with a simpler design. I will post diagram later tomorrow. To give a brief on it, XObject : has protected property List<XProperty> |__XPoperty :<< all objects that can be added as a property of an objects should extend this. Has an attribute list. cancels the | property list of XObject | |_____XString : |__Abstract XDocObject :<< all documents should have an object of this. This is the pages class. Has a object List<XObject> | |____XBlog :<< all documents which are blogs should have a object of this. This determines the class of the object. | but this data is not posted anywhere in <link rel="...../class"> . It is just kept for type checks. That is like | this page should include XBlogPost objects. |__XBlogPost : <<the BlogPostClass object. In my view I assume every page has an object of some class. And this object holds the objects which you can get under .../pages/BlogPg1/objects/ [ an added advantage: I think we can make a ViewEngine to generate android View components from the above model. Since the objects in the page carry rendering descriptions.We can make a general model like a browser to brows xwiki using generated the views. But the problem is some features in specific spaces like blog do not seem to be totally defined by the XWiki Object model behind them. Also this is just an idea (not suggesting I do for the GSoc).Making it a usable reality is a little challenge. ] So as you said if a document (I think it equivalent to a page) can have many class types my assumption fails. Why should a document be of multiple classes. I was thinking a page belongs to a class. And the page is an instance of that class. If page can have multiple classes my understanding should be wrong. Isn't it? Thanks Best Regards Sasinda. > >>>> >>>> > On Wed, May 30, 2012 at 1:11 PM, Thomas Mortagne > >>>> >>>> > <thomas.mortagne(a)xwiki.com>wrote: > >>>> >>>> > > >>>> >>>> >> On Wed, May 30, 2012 at 4:28 AM, sasinda rukshan > >>>> >>>> >> <sasindarukshan(a)gmail.com> wrote: > >>>> >>>> >> > Hi, > >>>> >>>> >> > I am studying ORM Lite these days. > >>>> >>>> >> > Please It would be comforting if you can confirm whether it > is > >>>> worth > >>>> >>>> >> > the > >>>> >>>> >> > overhead to use ORM Lite. > >>>> >>>> >> > > >>>> >>>> >> > >>>> >>>> >> > >>>> > http://logic-explained.blogspot.com/2011/12/using-ormlite-in-android-projec… > >>>> >>>> >> > http://ormlite.com/ > >>>> >>>> >> > ORM Lite features: > >>>> >>>> >> > Automatically Creates standard DAOs for an annotated entity. > >>>> >>>> >> > Coding will be lot easier. > >>>> >>>> >> > >>>> >>>> >> Remember it's a framework for a mobile platform so it has to > >>>> remain > >>>> >>>> >> light and have good performances. I can see that Android > version > >>>> of > >>>> >>>> >> ormlite is very small but I never used it so I don't know if > >>>> it's good > >>>> >>>> >> or not. At least it seems petty active which is a good point > so I > >>>> >>>> >> don't have anything against it. > >>>> >>>> >> > >>>> >>>> >> > > >>>> >>>> >> > Can you suggest how to name the entities. > >>>> >>>> >> > I am going to go with, > >>>> >>>> >> > <entity> org.xwiki.xdroid.data.User --> <table> C_USER > >>>> >>>> >> > >>>> >>>> >> Note that there is already a package name prefix and group id > >>>> defined > >>>> >>>> >> for the framework and it's org.xwiki.android as you can see on > >>>> >>>> >> https://github.com/xwiki-contrib/android-client. Why do you > >>>> want to > >>>> >>>> >> change it ? It's more consistent with > >>>> >>>> >> org.xwiki.commons/org.xwiki.rendering/org.xwiki.platform so I > >>>> would > >>>> >>>> >> prefer to keep it that way unless you can give arguments. The > >>>> goal is > >>>> >>>> >> not to redo something completely but complete and improve the > >>>> existing > >>>> >>>> >> framework. > >>>> >>>> >> > >>>> >>>> >> Also as far as I can see there is already several things > called > >>>> >>>> >> "xdroid" on Google play among which an application developer > >>>> >>>> >> (https://play.google.com/store/apps/developer?id=x-droid) > and an > >>>> >>>> >> application ( > >>>> >>>> >> > >>>> >>>> >> > >>>> > https://play.google.com/store/apps/details?id=com.gurudigitalsolutions.xdro… > >>>> >>>> >> ). > >>>> >>>> >> > >>>> >>>> >> > > >>>> >>>> >> > Thanks, > >>>> >>>> >> > Best Regards > >>>> >>>> >> > > >>>> >>>> >> > Sasinda. > >>>> >>>> >> > > >>>> >>>> >> > > >>>> >>>> >> > > >>>> >>>> >> > > >>>> >>>> >> > > >>>> >>>> >> > On Wed, May 30, 2012 at 7:42 AM, sasinda rukshan > >>>> >>>> >> > <sasindarukshan(a)gmail.com>wrote: > >>>> >>>> >> > > >>>> >>>> >> >> Hi, > >>>> >>>> >> >> > >>>> >>>> >> >> I am commiting my work to my fork > >>>> >>>> >> >> https://github.com/sasinda/android-client. > >>>> >>>> >> >> I ll request to pull it to xwiki-contrib later. > >>>> >>>> >> >> > >>>> >>>> >> >> I was running in a wrong path these days. Wanted to save > login > >>>> >>>> >> >> history > >>>> >>>> >> and > >>>> >>>> >> >> suggest login. I was going to do it using an xml file > (login > >>>> >>>> >> attempts.xml). > >>>> >>>> >> >> Now it seems database is better. > >>>> >>>> >> >> Any way before I go wrong again I will say what I am going > to > >>>> do. > >>>> >>>> >> >> I am going to enforce following conventions.These are not > yet > >>>> >>>> >> >> needed, > >>>> >>>> >> >> considered the small scale.But when the system grows it > would > >>>> be > >>>> >>>> >> >> nice to > >>>> >>>> >> >> have them to avoid confusions. > >>>> >>>> >> >> *Database prefixes for:* > >>>> >>>> >> >> *Platform tables (can begin with appropriate prefix)* > >>>> >>>> >> >> AD_ //application dictionary : don't know when it will be > >>>> needed ;-) > >>>> >>>> >> >> C_ //core functionality > >>>> >>>> >> >> *Client Applications.* > >>>> >>>> >> >> X<App name prefix> ex: XBLOG_ for Blog app// All client > >>>> add in > >>>> >>>> >> modules > >>>> >>>> >> >> must begin with table prefix X(for xwiki and ordering) + > App > >>>> name. > >>>> >>>> >> This is > >>>> >>>> >> >> for my blog. > >>>> >>>> >> >> > >>>> >>>> >> >> I will create > >>>> >>>> >> >> C_User for user data. > >>>> >>>> >> >> C_LoginAttempt for saving login attempts. > >>>> >>>> >> >> > >>>> >>>> >> >> From C_LoginAttempt I can filter uniqe login combinations > and > >>>> give > >>>> >>>> >> >> suggestions in the login UI component. Also save the > history. > >>>> >>>> >> >> > >>>> >>>> >> >> All saved data for blog app will be linked to a perticular > >>>> login : > >>>> >>>> >> >> User, > >>>> >>>> >> >> XWiki server. > >>>> >>>> >> >> But only a single user will be most probably using his > >>>> personal > >>>> >>>> >> >> device. > >>>> >>>> >> So > >>>> >>>> >> >> above will be relevant only when he has multiple wikis. > >>>> >>>> >> >> > >>>> >>>> >> >> Best Regards, > >>>> >>>> >> >> Sasinda Rukshan. > >>>> >>>> >> >> > >>>> >>>> >> >> > >>>> >>>> >> >> > >>>> >>>> >> >> > >>>> >>>> >> >> > >>>> >>>> >> >> On Sun, May 27, 2012 at 5:43 PM, Chamika Weerasinghe < > >>>> >>>> >> chamikaw(a)gmail.com>wrote: > >>>> >>>> >> >> > >>>> >>>> >> >>> On Fri, May 25, 2012 at 1:25 AM, Jerome Velociter < > >>>> >>>> >> jerome(a)winesquare.net > >>>> >>>> >> >>> >wrote: > >>>> >>>> >> >>> > >>>> >>>> >> >>> > On Thu, May 24, 2012 at 6:09 PM, Thomas Mortagne > >>>> >>>> >> >>> > <thomas.mortagne(a)xwiki.com> wrote: > >>>> >>>> >> >>> > > On Thu, May 24, 2012 at 5:52 PM, sasinda rukshan > >>>> >>>> >> >>> > > <sasindarukshan(a)gmail.com> wrote: > >>>> >>>> >> >>> > >> Hi all, > >>>> >>>> >> >>> > >> I am starting this thread for my XWiki Android > Platform > >>>> >>>> >> >>> > >> Project. > >>>> >>>> >> >>> > >> > >>>> >>>> >> >>> > >> Please check whether following are OK. > >>>> >>>> >> >>> > >> [1] INFO > >>>> >>>> >> >>> > >> I tried to start my new modules with the > >>>> >>>> >> >>> de.akquinet.android.archetypes: > >>>> >>>> >> >>> > >> android-quickstart:1.0.8. (added eclipse plugins > m2e, > >>>> >>>> >> >>> > >> m2e-android[a.k.a *Android > >>>> >>>> >> >>> > >> Configurator* ]). But this seems buggy in eclipse. > >>>> >>>> >> >>> > >> Any way the earlier project has not followed the > above > >>>> >>>> >> >>> > >> archtype > >>>> >>>> >> >>> either. > >>>> >>>> >> >>> > So > >>>> >>>> >> >>> > >> I am going to write pom.xml manually for my each > module. > >>>> >>>> >> >>> > >> > >>>> >>>> >> >>> > >> [2] ADVICE NEEDED > >>>> >>>> >> >>> > >> xwiki-rest-model module contains 2 submodules > >>>> >>>> >> >>> > >> |-- xwiki-rest-model-gson ( gson should be > corrected > >>>> to > >>>> >>>> >> >>> > >> json) > >>>> >>>> >> >>> > > > >>>> >>>> >> >>> > > No the g is not a mistake, it's a model to be used > with > >>>> the > >>>> >>>> >> >>> > > gson > >>>> >>>> >> >>> > > library (http://code.google.com/p/google-gson/). See > >>>> >>>> >> >>> > > > >>>> >>>> >> >>> > > >>>> >>>> >> >>> > >>>> >>>> >> > >>>> >>>> >> > >>>> > http://extensions.xwiki.org/xwiki/bin/view/Extension/Google+Android+Client#… > >>>> >>>> >> >>> > . > >>>> >>>> >> >>> > > > >>>> >>>> >> >>> > >> |-- xwiki-rest-model-simplexml > >>>> >>>> >> >>> > >> I think the xwiki-rest-model-gson is redundant. The > >>>> classes > >>>> >>>> >> >>> > >> in xwiki-rest-model-simplexml is added with simple > xml > >>>> >>>> >> annotations, > >>>> >>>> >> >>> > >> otherwise both modules have same classes. There is no > >>>> problem > >>>> >>>> >> >>> > >> with > >>>> >>>> >> >>> the > >>>> >>>> >> >>> > >> added annotations for using the same model objects > for > >>>> Json > >>>> >>>> >> >>> > >> REST > >>>> >>>> >> web > >>>> >>>> >> >>> > >> services. And I intend to add my JPA (ORMLite library > >>>> for > >>>> >>>> >> >>> persistence) > >>>> >>>> >> >>> > >> annotations on top of it. > >>>> >>>> >> >>> > >> Shall I re-factor them to a single module > >>>> xwiki-rest-model. > >>>> >>>> >> >>> > > > >>>> >>>> >> >>> > > No keep them separated, the idea is that both are > useful > >>>> tool > >>>> >>>> >> >>> > > to be > >>>> >>>> >> >>> > > used by someone else that might be moved to > >>>> xwiki-platform at > >>>> >>>> >> >>> > > some > >>>> >>>> >> >>> > > point along with the current xwiki-rest-model (to be > >>>> renamed to > >>>> >>>> >> >>> > > xwiki-rest-model-jaxb). > >>>> >>>> >> >>> > > > >>>> >>>> >> >>> > > Chamika initially started with gson and since XWiki > REST > >>>> JSON > >>>> >>>> >> >>> > > representation had some limitation he moved to XML > >>>> >>>> >> >>> > > representation. > >>>> >>>> >> >>> > > Maybe at some point Android will have native support > for > >>>> jaxb > >>>> >>>> >> >>> > > which > >>>> >>>> >> >>> > > would obviously be the easier for us (embedding jaxb > is > >>>> not an > >>>> >>>> >> option > >>>> >>>> >> >>> > > in mobile world where size it still pretty important > >>>> especially > >>>> >>>> >> >>> > > on > >>>> >>>> >> >>> > > phones). Maybe it's already the case on most recent > >>>> versions > >>>> >>>> >> >>> > > like > >>>> >>>> >> 4.0 > >>>> >>>> >> >>> > > I don't know. > >>>> >>>> >> >>> > > >>>> >>>> >> >>> > There's also Jackson that could be tried for JSON > >>>> >>>> >> >>> > deserialization, if > >>>> >>>> >> >>> > said limitations are actually GSON limitations. > >>>> >>>> >> >>> > > >>>> >>>> >> >>> GSON wasn't the limitation. > >>>> >>>> >> >>> It was XWiki RESTful API which doesn't support JSON in > some > >>>> cases. > >>>> >>>> >> >>> So > >>>> >>>> >> it's > >>>> >>>> >> >>> safe to go with xml. > >>>> >>>> >> >>> > >>>> >>>> >> >>> > > >>>> >>>> >> >>> > Having full JAXB support sound a bit overweight for > such an > >>>> >>>> >> >>> > "embedded > >>>> >>>> >> >>> > API", even if one day it is natively supported by > Android. > >>>> What's > >>>> >>>> >> >>> > important is to have an easy and fast deserialization, > IMO. > >>>> >>>> >> >>> > The only advantage I can see of going JAXB would be in > >>>> re-using > >>>> >>>> >> >>> > the > >>>> >>>> >> >>> > exact representations and body readers/writers from > XWiki > >>>> core. > >>>> >>>> >> >>> > But > >>>> >>>> >> >>> > you probably don't even want to do that since it would > mean > >>>> >>>> >> >>> > dragging > >>>> >>>> >> >>> > XWiki core with you :) > >>>> >>>> >> >>> > > >>>> >>>> >> >>> > Jerome > >>>> >>>> >> >>> > > >>>> >>>> >> >>> > > > >>>> >>>> >> >>> > >> > >>>> >>>> >> >>> > >> [3] INFO > >>>> >>>> >> >>> > >> I had to change some pom.xml s. As the current > project > >>>> at: > >>>> >>>> >> >>> > >> > https://github.com/xwiki-contrib/android-client.gitdoes not > >>>> >>>> >> build. > >>>> >>>> >> >>> > Error > >>>> >>>> >> >>> > >> with parent pom.xml coordinates. > >>>> >>>> >> >>> > > > >>>> >>>> >> >>> > > You probably did not setup you maven install properly > >>>> since > >>>> >>>> >> >>> > > what's > >>>> >>>> >> on > >>>> >>>> >> >>> > > > https://github.com/xwiki-contrib/android-client.gitbuild > >>>> >>>> >> perfectly > >>>> >>>> >> >>> as > >>>> >>>> >> >>> > > you can see on > >>>> >>>> >> http://ci.xwiki.org/view/All/job/xwiki-android-client/ > >>>> >>>> >> >>> > > which run a build every time something changes on the > git > >>>> >>>> >> repository.. > >>>> >>>> >> >>> > > You should look at > >>>> >>>> >> >>> > > > http://dev.xwiki.org/xwiki/bin/view/Community/Building. > >>>> >>>> >> >>> > > > >>>> >>>> >> >>> > >> > >>>> >>>> >> >>> > >> > >>>> >>>> >> >>> > >> Thank you > >>>> >>>> >> >>> > >> Best Regards. > >>>> >>>> >> >>> > >> Sasinda Rukshan > >>>> >>>> >> >>> > >> _______________________________________________ > >>>> >>>> >> >>> > >> devs mailing list > >>>> >>>> >> >>> > >> devs(a)xwiki.org > >>>> >>>> >> >>> > >> http://lists.xwiki.org/mailman/listinfo/devs > >>>> >>>> >> >>> > > > >>>> >>>> >> >>> > > > >>>> >>>> >> >>> > > > >>>> >>>> >> >>> > > -- > >>>> >>>> >> >>> > > Thomas Mortagne > >>>> >>>> >> >>> > > _______________________________________________ > >>>> >>>> >> >>> > > devs mailing list > >>>> >>>> >> >>> > > devs(a)xwiki.org > >>>> >>>> >> >>> > > http://lists.xwiki.org/mailman/listinfo/devs > >>>> >>>> >> >>> > > >>>> >>>> >> >>> > > >>>> >>>> >> >>> > > >>>> >>>> >> >>> > -- > >>>> >>>> >> >>> > Jérôme Velociter > >>>> >>>> >> >>> > Winesquare > >>>> >>>> >> >>> > http://www.winesquare.net/ > >>>> >>>> >> >>> > _______________________________________________ > >>>> >>>> >> >>> > devs mailing list > >>>> >>>> >> >>> > devs(a)xwiki.org > >>>> >>>> >> >>> > http://lists.xwiki.org/mailman/listinfo/devs > >>>> >>>> >> >>> > > >>>> >>>> >> >>> _______________________________________________ > >>>> >>>> >> >>> devs mailing list > >>>> >>>> >> >>> devs(a)xwiki.org > >>>> >>>> >> >>> http://lists.xwiki.org/mailman/listinfo/devs > >>>> >>>> >> >>> > >>>> >>>> >> >> > >>>> >>>> >> >> > >>>> >>>> >> > _______________________________________________ > >>>> >>>> >> > devs mailing list > >>>> >>>> >> > devs(a)xwiki.org > >>>> >>>> >> > http://lists.xwiki.org/mailman/listinfo/devs > >>>> >>>> >> > >>>> >>>> >> > >>>> >>>> >> > >>>> >>>> >> -- > >>>> >>>> >> Thomas Mortagne > >>>> >>>> >> _______________________________________________ > >>>> >>>> >> devs mailing list > >>>> >>>> >> devs(a)xwiki.org > >>>> >>>> >> http://lists.xwiki.org/mailman/listinfo/devs > >>>> >>>> >> > >>>> >>>> > _______________________________________________ > >>>> >>>> > devs mailing list > >>>> >>>> > devs(a)xwiki.org > >>>> >>>> > http://lists.xwiki.org/mailman/listinfo/devs > >>>> >>>> > >>>> >>>> > >>>> >>>> > >>>> >>>> -- > >>>> >>>> Thomas Mortagne > >>>> >>> > >>>> >>> > >>>> >> > >>>> >> > >>>> >> > >>>> >> -- > >>>> >> Thomas Mortagne > >>>> > > >>>> > > >>>> > > >>>> > -- > >>>> > Thomas Mortagne > >>>> > >>>> > >>>> > >>>> -- > >>>> Thomas Mortagne > >>>> > >>> > >>> > >> > > _______________________________________________ > > devs mailing list > > devs(a)xwiki.org > > http://lists.xwiki.org/mailman/listinfo/devs > > > > -- > Thomas Mortagne >

12 years, 5 months

[xwiki-devs] Fwd: [ANNOUNCE] Apache Solr 4.0-alpha released.

by Vincent Massol

So that we know what we'll get in the future… -Vincent Begin forwarded message: > From: Robert Muir <rmuir(a)apache.org> > Subject: [ANNOUNCE] Apache Solr 4.0-alpha released. > Date: July 3, 2012 3:11:19 PM GMT+02:00 > To: dev(a)lucene.apache.org, solr-user(a)lucene.apache.org, Lucene mailing list <general(a)lucene.apache.org>, announce <announce(a)apache.org> > > 3 July 2012, Apache Solr™ 4.0-alpha available > The Lucene PMC is pleased to announce the release of Apache Solr 4.0-alpha. > > Solr is the popular, blazing fast, open source NoSQL search platform from > the Apache Lucene project. Its major features include powerful full-text > search, hit highlighting, faceted search, dynamic clustering, database > integration, rich document (e.g., Word, PDF) handling, and geospatial search. > Solr is highly scalable, providing fault tolerant distributed search > and indexing, > and powers the search and navigation features of many of the world's > largest internet sites. > > Solr 4.0-alpha is available for immediate download at: > http://lucene.apache.org/solr/mirrors-solr-latest-redir.html?ver=4.0a > > See the CHANGES.txt file included with the release for a full list of > details. > > Solr 4.0-alpha Release Highlights: > > The largest set of features goes by the development code-name “Solr > Cloud” and involves bringing easy scalability to Solr. See > http://wiki.apache.org/solr/SolrCloud for more details. > * Distributed indexing designed from the ground up for near real-time > (NRT) and NoSQL features such as realtime-get, optimistic locking, and > durable updates. > * High availability with no single points of failure. > * Apache Zookeeper integration for distributed coordination and > cluster metadata and configuration storage. > * Immunity to split-brain issues due to Zookeeper's Paxos distributed > consensus protocols. > * Updates sent to any node in the cluster and are automatically > forwarded to the correct shard and replicated to multiple nodes for > redundancy. > * Queries sent to any node automatically perform a full distributed > search across the cluster with load balancing and fail-over. > > Solr 4.0-alpha includes more NoSQL features for those using Solr as a > primary data store: > * Update durability – A transaction log ensures that even uncommitted > documents are never lost. > * Real-time Get – The ability to quickly retrieve the latest version > of a document, without the need to commit or open a new searcher > * Versioning and Optimistic Locking – combined with real-time get, > this allows read-update-write functionality that ensures no > conflicting changes were made concurrently by other clients. > * Atomic updates - the ability to add, remove, change, and increment > fields of an existing document without having to send in the complete > document again. > > There are many other features coming in Solr 4, such as > * Pivot Faceting – Multi-level or hierarchical faceting where the top > constraints for one field are found for each top constraint of a > different field. > * Pseudo-fields – The ability to alias fields, or to add metadata > along with returned documents, such as function query values and > results of spatial distance calculations. > * A spell checker implementation that can work directly from the main > index instead of creating a sidecar index. > * Pseudo-Join functionality – The ability to select a set of > documents based on their relationship to a second set of documents. > * Function query enhancements including conditional function queries > and relevancy functions. > * New update processors to facilitate modifying documents prior to indexing. > * A brand new web admin interface, including support for SolrCloud. > > This is an alpha release for early adopters. The guarantee for this > alpha release is that the index > format will be the 4.0 index format, supported through the 5.x series > of Lucene/Solr, unless there > is a critical bug (e.g. that would cause index corruption) that would > prevent this. > > Please report any feedback to the mailing lists > (http://lucene.apache.org/solr/discussion.html) > > Happy searching, > > Lucene/Solr developers

12 years, 5 months

[xwiki-devs] Fwd: [ANNOUNCE] Apache Lucene 4.0-alpha released.

by Vincent Massol

So that we know what we'll get in the future… -Vincent Begin forwarded message: > From: Robert Muir <rmuir(a)apache.org> > Subject: [ANNOUNCE] Apache Lucene 4.0-alpha released. > Date: July 3, 2012 3:09:13 PM GMT+02:00 > To: dev(a)lucene.apache.org, Lucene mailing list <general(a)lucene.apache.org>, java-user <java-user(a)lucene.apache.org>, announce <announce(a)apache.org> > > 3 July 2012, Apache Lucene‚ 4.0-alpha available > The Lucene PMC is pleased to announce the release of Apache Lucene 4.0-alpha > > 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://lucene.apache.org/core/mirrors-core-latest-redir.html?ver=4.0a > > See the CHANGES.txt file included with the release for a full list of > details. > > Lucene 4.0-alpha Release Highlights: > > * The index formats for terms, postings lists, stored fields, term > vectors, etc > are pluggable via the Codec api. You can select from the provided > implementations or customize the index format with your own Codec > to meet your needs. > > * Similarity has been decoupled from the vector space model (TF/IDF). > Additional models > such as BM25, Divergence from Randomness, Language Models, and > Information-based models > are provided (see > http://www.lucidimagination.com/blog/2011/09/12/flexible-ranking-in-lucene-4). > > * Added support for per-document values (DocValues). DocValues can be > used for custom > scoring factors (accessible via Similarity), for pre-sorted Sort > values, and more. > > * When indexing via multiple threads, each IndexWriter thread now > flushes its own segment > to disk concurrently, resulting in substantial performance improvements > (see http://blog.mikemccandless.com/2011/05/265-indexing-speedup-with-lucenes.ht…). > > * Per-document normalization factors ("norms") are no longer limited > to a single byte. > Similarity implementations can use any DocValues type to store norms. > > * Added index statistics such as the number of tokens for a term or > field, number of postings > for a field, and number of documents with a posting for a field: > these support additional > scoring models (see > http://blog.mikemccandless.com/2012/03/new-index-statistics-in-lucene-40.ht…). > > * Implemented a new default term dictionary/index (BlockTree) that > indexes shared prefixes > instead of every n'th term. This is not only more time- and space- > efficient, but can > also sometimes avoid going to disk at all for terms that do not > exist. Alternative term > dictionary implementions are provided and pluggable via the Codec api. > > * Indexed terms are no longer UTF-16 char sequences, instead terms > can be any binary > value encoded as byte arrays. By default, text terms are now encoded as UTF-8 > bytes. Sort order of terms is now defined by their binary value, > which is identical > to UTF-8 sort order. > > * Substantially faster performance when using a Filter during searching. > > * File-system based directories can rate-limit the IO (MB/sec) of merge > threads, to reduce IO contention between merging and searching threads. > > * Added a number of alternative Codecs and components for different > use-cases: "Appending" > works with append-only filesystems (such as Hadoop DFS), "Memory" > writes the entire > terms+postings as an FST read into RAM (see > http://blog.mikemccandless.com/2011/06/primary-key-lookups-are-28x-faster-w…), > "Pulsing" inlines the postings for low-frequency terms into the > term dictionary (see > http://blog.mikemccandless.com/2010/06/lucenes-pulsingcodec-on-primary-key.…), > "SimpleText" writes all files in plain-text for easy > debugging/transparency (see > http://blog.mikemccandless.com/2010/10/lucenes-simpletext-codec.html), > among others. > > * Term offsets can be optionally encoded into the postings lists and > can be retrieved > per-position. > > * A new AutomatonQuery returns all documents containing any term > matching a provided > finite-state automaton (see > http://www.slideshare.net/otisg/finite-state-queries-in-lucene). > > * FuzzyQuery is 100-200 times faster than in past releases (see > http://blog.mikemccandless.com/2011/03/lucenes-fuzzyquery-is-100-times-fast…). > > * A new spell checker, DirectSpellChecker, finds possible corrections > directly against the > main search index without requiring a separate index. > > * Various in-memory data structures such as the term dictionary and > FieldCache are represented > more efficiently with less object overhead (see > http://blog.mikemccandless.com/2010/07/lucenes-ram-usage-for-searching.html). > > * All search logic is now required to work per segment, IndexReader > was therefore refactored to > differentiate between atomic and composite readers > (see http://blog.thetaphi.de/2012/02/is-your-indexreader-atomic-major.html). > > * Lucene 4.0 provides a modular API, consolidating components such as > Analyzers and Queries > that were previously scattered across Lucene core, contrib, and > Solr. These modules also > include additional functionality such as UIMA analyzer integration > and a completely reworked > spatial search implementation. > > Please read CHANGES.txt and MIGRATE.txt for a full list of new > features and notes on upgrading. > Particularly, the new apis are not compatible with previous version of > Lucene, however, file > format backwards compatibility is provided for indexes from the 3.0 series. > > This is an alpha release for early adopters. The guarantee for this > alpha release is that the index > format will be the 4.0 index format, supported through the 5.x series > of Apache Lucene, unless there > is a critical bug (e.g. that would cause index corruption) that would > prevent this. > > Please report any feedback to the mailing lists > (http://lucene.apache.org/core/discussion.html) > > Happy searching, > > Apache Lucene/Solr Developers

12 years, 5 months

[xwiki-devs] Clover TPC values for Commons/Rendering/Platform/Enterprise

by Vincent Massol

Hi devs, I've finally spent the time to measure our TPC (Test Percentage Coverage) using Clover. The reports are very interesting and show where we need to spend our efforts in testing (be them automated or manual). Here are the raw top level results: =========================== All results: http://maven.xwiki.org/site/clover/20120701/ * Only Commons (this means unit tests and integration tests in the commons repository only): 62.4% * Only Rendering: 75.5% * Only Platform: 36.8% * Commons+Rendering (ie Rendering tests exercise also Commons code): 72.1% * Commons+Rendering+Platform: 47.4% * Commons+Rendering+Platform+Enterprise: So our code is roughly tested at X% (note that 100% TPC doesn't mean the code is working, it means each line of code has been tested in some way but it doesn't mean all combinations have been tested!). A good value is between 70-80%. We're actually better than I thought (I had 50% or lower in mind) :) However there are huge disparity with code having 90+% and code having 0% coverage (402 classes have 0% coverage!). Quick high level analysis: ==================== * Commons is missing quite a lot of unit tests * Wikimodel in Rendering is dragging the TPC down, I think we were above 80% before we included WikiModel) * Platform has a very low level of unit tests which means it's easy to break stuff in platform and it's hard to verify that what we add in platform works well in general (means going through longer stabilization phases than needed) * Our functional tests are quite effective (even though they take a very very long time to execute) since they make the TPC go from 47% to 63% for Commons+Rendering+Platform. The bad TPC for Platform is probably improved by the functional tests. Next steps ========= * IMO all developers need to look in details at the results and familiarize themselves with the Clover reports * Each dev should look at stuff he has coded and ensure that they have a good level of unit tests * All new code should get at the very minimum between 70-80% unit test coverage. For example the new diff module in commons only has only 43.4% coverage which is far from enough * Spend time to automate the generation of these reports. We need a dedicated agent for this since it "contaminates" the local repository with clovered jars. The overall generation time is around 4-5 hours. * Dig more around the reports to identify functional areas of XWiki missing automated tests. These areas must be covered by manual testing at each release. * Decide if we want a more rigorous strategy for new code, and how to get alerts for modules missing coverage. WDYT? Let's share your analysis in this thread so that we can brainstorm about what to do with these reports Thanks -Vincent

12 years, 5 months

[xwiki-devs] [Idea] Bundle jQuery ?

by Jerome Velociter

Hi devs, Now that all the scripts on the Internets are implemented as jQuery plugins, should we bite the bullet and make it easier for extensions developers to integrate such scripts ? Note it would not necessarily mean we use it ourselves in web/XE. If we don't do something about it, there is the risk that many extensions bring their own jQuery to the party, which will translate in slower page loads and more importantly a less enjoyable extension developer experience. An alternative idea would be an "official" jQuery extension (with a JSX) that other extensions can depend upon, should they need jQuery. What do you think ? Jerome

12 years, 5 months

Re: [xwiki-devs] [GSoC] Responsive Skin

by Jonathan Solichin

Hello friends, > The root application >> wikis >> spaces in a wiki >> Pages in a space. > If you reveal that in the menu users get the intuitive feeling that they > can create a wiki also. And in a wiki they can have spaces and etc... > Well the first time I used XWiki my intuition was to use the drop down at > space to get a list of spaces.I thought the document index would list the > spaces available. Ah ok, I think I understand what you mean. Clarify if I am wrong: on the bread crumb, you think that it would be a good idea if it listed the adjacent areas in the drop down. eg. if you hover over the pages, it will reveal all the pages in the same space as the current document. As a status update. I've done most of the mobile of the skin. Go ahead and try it in your respective browser: http://jssolichin.com/xwiki. I have presently tested it on android and Windows Phone along with browser resize on Chrome. Trying to get my hands on some iphone/blackberry. Let me know any glaring issues on those browsers in the mean time. What do you guys think about my implementation/solution to the sidebar? I handled the swiping a bit differently than the Coffin example. The issue with coffin is that it seems that it is not cross compatible. The swipe gesture does not work on WP7 nor on a browser. If you load coffin in a browser with a small viewport, you lose the ability to scroll completely and have no way to access the rest of the pages or the menu (unless i'm doing it wrong). The way I solved this issue is by making the sidebar in a negative position. In the mobile browser I tested, it seems to disregard this, so you can still swipe to see the sidebar. But since you can not do this is a desktop browser, i implemented the links to access it (sort of reminiscent of WP's right arrow for apps access). Another benefit is that it allows the browser to natively direct user to a specific div using #. So if I sent someone a link to http://jssolichin.com/xwiki#attachments, it should load the webpage in that area (also why I used scrolling instead of tabs). What do you guys think? One thing that I am wondering though is, sometimes a few lines of extra code is needed to make sure all the feature work properly upon resize. Should I worry about this? Like if a viewer resizes the browser from a desktop to a mobile size, should I add extra lines to make sure he can view it correctly? A lot of this has to do with the resizing capability of the sidebar (which can't be accomplished with css). Next step: implement all the drop down and test compatibility on mobile (as I can get a hold of them) and firefox/safari/ie. Also, begin porting over to xwiki/simplifying/standardizing. Thanks friends! JS

12 years, 5 months

[xwiki-devs] WYSIWYG goes to cache instead of opening the editor?

by echocoder

When editing an Xwiki page and choosing the WYSIWYG option instead of showing the editor it takes the user to a blank HTML cache page in /xwiki/resources/js/xwiki/xwe/*.cache.html. Do any of you know the cause of this and/or how to fix such? -- View this message in context: http://xwiki.475771.n2.nabble.com/WYSIWYG-goes-to-cache-instead-of-opening-… Sent from the XWiki- Dev mailing list archive at Nabble.com.

12 years, 5 months

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

2005

xwiki-devs July 2012