xwiki-devs

xwiki-devs@xwiki.org

9400 discussions

[xwiki-devs] Overwrite Method of Component in Velocity

by Matthias Wegner

Hi All, I want to create a component where i can overwrite a method of the component from velocity or groovy script inside a wiki page. Its also fine if i can "read" a groovy script to the component so i can use the defined logic. Maybe i have to use a own programmed macro for that. Is that possible? Do you use something similar somewhere? Regards, Matthias -- View this message in context: http://xwiki.475771.n2.nabble.com/Overwrite-Method-of-Component-in-Velocity… Sent from the XWiki- Dev mailing list archive at Nabble.com.

9 years, 10 months

[xwiki-devs] Fw: [ANNOUNCE] Apache Solr 5.0.0 and Reference Guide for Solr 5.0 released

by vincent＠massol.net

FYI. Could be interesting for us to upgrade. Don’t know if it’s backward compatible with 4.x or not though. Thanks -Vincent On 21 Feb 2015 at 01:05:53, Anshum Gupta (anshum(a)apache.org) wrote: 20 February 2015, Apache Solr™ 5.0.0 and Reference Guide for Solr 5.0 available The Lucene PMC is pleased to announce the release of Apache Solr 5.0.0 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 5.0 is available for immediate download at: http://lucene.apache.org/solr/mirrors-solr-latest-redir.html See the CHANGES.txt file included with the release for a full list of details. Solr 5.0 Release Highlights: * Usability improvements that include improved bin scripts and new and restructured examples. * Scripts to support installing and running Solr as a service on Linux. * Distributed IDF is now supported and can be enabled via the config. Currently, there are four supported implementations for the same: * LocalStatsCache: Local document stats. * ExactStatsCache: One time use aggregation * ExactSharedStatsCache: Stats shared across requests * LRUStatsCache: Stats shared in an LRU cache across requests * Solr will no longer ship a war file and instead be a downloadable application. * SolrJ now has first class support for Collections API. * Implicit registration of replication,get and admin handlers. * Config API that supports paramsets for easily configuring solr parameters and configuring fields. This API also supports managing of pre-existing request handlers and editing common solrconfig.xml via overlay. * API for managing blobs allows uploading request handler jars and registering them via config API. * BALANCESHARDUNIQUE Collection API that allows for even distribution of custom replica properties. * There's now an option to not shuffle the nodeSet provided during collection creation. * Option to configure bandwidth usage by Replication handler to prevent it from using up all the bandwidth. * Splitting of clusterstate to per-collection enables scalability improvement in SolrCloud. This is also the default format for new Collections that would be created going forward. * timeAllowed is now used to prematurely terminate requests during query expansion and SolrClient request retry. * pivot.facet results can now include nested stats.field results constrained by those pivots. * stats.field can be used to generate stats over the results of arbitrary numeric functions. It also allows for requesting for statistics for pivot facets using tags. * A new DateRangeField has been added for indexing date ranges, especially multi-valued ones. * Spatial fields that used to require units=degrees now take distanceUnits=degrees/kilometers miles instead. * MoreLikeThis query parser allows requesting for documents similar to an existing document and also works in SolrCloud mode. * Logging improvements: * Transaction log replay status is now logged * Optional logging of slow requests. Solr 5.0 also includes many other new features as well as numerous optimizations and bugfixes of the corresponding Apache Lucene release. Detailed change log: http://lucene.apache.org/solr/5_0_0/changes/Changes.html Also available is the Solr Reference Guide for Solr 5.0. This 535 page PDF serves as the definitive user's manual for Solr 5.0. It can be downloaded from the Apache mirror network: https://s.apache.org/Solr-Ref-Guide-PDF Please report any feedback to the mailing lists (http://lucene.apache.org/solr/discussion.html) 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. -- Anshum Gupta http://about.me/anshumgupta

9 years, 10 months

[xwiki-devs] Questions about fixing getRenderedContent() bug

by Vincent Massol

Hi, Im trying to fix http://jira.xwiki.org/jira/browse/XWIKI-4274 Basically if you do $xwiki.getDocument("someDoc").getRenderedContent() it'll get executed in the context of the current doc which I believe is wrong especially since other signatures of getRenderedContent() execute in the target document's context. I have fixed this locally but found that admin.vm for example is assuming that getRenderedContent() will get executed in the context of the calling doc (i.e. XWiki.Import when doing an import for example). FYI the chain flow is admin.vm -- getRenderedContent() --> XWiki.AdminSheet --> XWiki.AdminImportSheet --> importinline.vm, which requires the current doc to be XWiki.Import (to get/put attachments from/to it). I can fix this easily using a new getRenderedContent signature I've introduced. However I'm wondering if we have other places that incorrectly use getRenderedContent() and assume it won't be rendered in the context of the target document. Is this change too dangerous to make? If not know, we'll need to it quickly (2.1M1?) since it's an important bug IMO. WDYT? Thanks -Vincent

9 years, 10 months

[xwiki-devs] [Discussion] Making XObjects work across languages

by Guillaume Lerouge

Hi guys, I met an issue recently on a project. We'd like to build an XWiki-based website that will be available in several languages. We'd like to use structured data, which means using XObjects. Unfortunately at the moment XObjects are not internationalized: they're available only in one language, even if a page exists in 2+ languages. A common workaround is to either duplicate all fields in the object (say, "type_FR" and "type_EN") or have 1 object per language, with a field handling the language property. In either way, custom sheets need to be developed to make it possible to modify the various languages of the page. There is also an issue with the search: in which language should the object's content be indexed? One solution would be to make it possible to have international languages handled directly in XWiki (the same way than the default title / content fields are handled now), but I'm not sure how much work that would take. WDYT? Guillaume

9 years, 10 months

[xwiki-devs] Fwd: Documenting how to contribute XAR XWiki extensions.

by Mohamed Boussaa

Hi all, I moved the tutorial to a new space (Documentation) under http://extensions.xwiki.org/ http://extensions.xwiki.org/xwiki/bin/view/Documentation/ContributingXWikiX… I also put a link to the tutorial in the extensions main page under "contribute extension" (when you're logged in) as you can see below. http://extensions.xwiki.org/xwiki/bin/view/Main/ [image: Inline image 1] WDYT ? (Thanks to Caleb for all these suggestions.) On Fri, Feb 13, 2015 at 5:10 PM, Caleb James DeLisle <cjd(a)cjdns.fr> wrote: > Hi all, > > Today I worked with Mohamed to release an extension (TotemApplication) to > the extension manager > and he wrote an excellent tutorial for uploading a xar file so that is is > accessible from the > extension manager. > > http://www.xwiki.org/xwiki/bin/view/Drafts/ContributingExtensions > > I'd like to propose we move this to a more official location than /Drafts/ > since at this point > it's the only end-to-end tutorial on contributing XAR extensions. > > WDYT? > Caleb > > > -- > Satire is the escape hatch from the cycle of sorrow, hatred and violence. > #JeSuisCharlie >

9 years, 10 months

[xwiki-devs] [Proposal] Automation Achievement Page on xwiki.org

by vincent＠massol.net

Hi devs, We’re starting a new year and new development cycle (the 7.x one). It’s time to reflect back on what we did and what we wish to achieve and also what we wish to do better. I think it wouldn’t do any harm to the xwiki project that we continue automating stuff (more build/release process automation, more development automation, more documentation automation, more test writing automation, etc). Basically anything that makes us better at delivering the XWiki software. If you agree with this, I’d like to propose that we start filling a wiki page on xwiki.org dedicated to what we achieved. I’ve started such as page at http://dev.xwiki.org/xwiki/bin/view/Drafts/AutomationAchievements (the idea will be to move it somewhere in dev.xwiki.org if this proposal is accepted). At the moment I’ve put only a single item that I remember we did on the automation topic but the idea is that each one of us (us = the xwiki community at large) updates this page when he/she implements some new automation stuff. The goal of this page is several: * show appreciation to whoever helped improve XWiki’s automation * realize that we’re doing work on automation and see how much we achieve in a year. And thus be able to compare year to year and see how we fare. * provides emulation to all of us to do even more in this domain WDYT? Thanks -Vincent

9 years, 10 months

[xwiki-devs] So what is an extension flavor exactly ?

by Thomas Mortagne

Hi devs, There is many ways to make an extension a flavor and we need to chose one. Here are a few I have in mind: 1) Extension of type FLAVOR (compared to XAR and JAR types for example) 2) A Boolean indicating if an extension is a flavor 2) A tag "Flavor" (or some of the name to be decided later) 3) A unique category "Flavor" (or some of the name to be decided later) I don't like 1) because a flavor does have anything special and I don't see the point of reimplementing a new extension type handler just to make an extension a flavor. I'm really not a fan for 2) either since it would makes this part of the core of extension API which I really don't like since flavor are XWiki runtime specific while you can use the xwiki-commons part of Extension Manager for many use cases that don't have anything to do with XWiki right now. So I'm hesitating between 3) and 4). When I started thinking about it I was more into 3) since we already have tags in XWiki Repository but since I saw that in both Android and IOS each application is in a unique category I'm tempted to change my mind and give my +1 to 3). Plus exposing categories is a nice new feature anyway. -- Thomas Mortagne

9 years, 10 months

[xwiki-devs] [Vote] Add a cache directory concept and make the XWiki launch faster (was: Move the caches files to permdir and make the launch of XWiki faster)

by Guillaume "Louis-Marie" Delhumeau

Thanks for your answers. I change the name of this thread since my proposal has changed: 1 - Add getCacheDirectory() in the class Environment: https://github.com/xwiki/xwiki-commons/blob/master/xwiki-commons-core/xwiki… It means breaking an interface. 2 - Add a cache directory setting in xwiki.properties, to change this directory if needed (for example: set a directory on a faster disk) 3 - For our distributions, set this cache directory in a folder inside our distributions (for example a "cache" directory aside the "data" directory). This setting can be changed by the user. 4 - Do not purge the LESS cache on startup. (see my previous mail for this) 5 - add a new module that pre-generate the LESS cache file to make the first XWiki launch faster (see my previous mail for this) +1 for all of this. Thanks, 2015-02-15 8:55 GMT+01:00 Marius Dumitru Florea < mariusdumitru.florea(a)xwiki.com>: > On Sun, Feb 15, 2015 at 2:09 AM, Eduard Moraru <enygma2002(a)gmail.com> > wrote: > > On Sat, Feb 14, 2015 at 10:44 AM, Thomas Mortagne < > thomas.mortagne(a)xwiki.com > >> wrote: > > > >> As I discussed with Guillaume before he send the proposal (but he felt > >> it was to much for his need) the best IMO is to add the concept cache > >> directory in Environment and conf file. It's not temp files and it's > >> not really permanent files either. > > > > > > +1 to that reasoning. > > +1 too, > > Thanks, > Marius > > > > > Thanks, > > Eduard > > > > > >> Basically I want to do that since a > >> while now mostly because I would like to be able to setup the Debian > >> package by default to put those files in /var/cache/xwiki/. > >> > >> > >> On Sat, Feb 14, 2015 at 7:13 AM, Marius Dumitru Florea > >> <mariusdumitru.florea(a)xwiki.com> wrote: > >> > On Feb 13, 2015 8:39 PM, "Denis Gervalle" <dgl(a)softec.lu> wrote: > >> >> > >> >> Hi Guillaume, > >> >> > >> > > >> >> 1) -1, this break the FHS which definitely separate caches from > >> permanent > >> >> data, and for a couple of good reason, you may want to put them on > >> >> different partition, using faster disk, or even in memory disk. So I > do > >> > not > >> >> find very clever to put all cache files into the permanent directory. > >> What > >> >> would be the purpose of a temporary directory if it was not for that > >> >> purpose. > >> > > >> > I agree with Denis. Caches are temporary files for me, but temporary > >> > doesn't mean they have to be deleted after each restart. > >> > > >> > Thanks, > >> > Marius > >> > > >> >> 2) +1, but with some way to force the purge, so annoying problem > still > >> get > >> >> a solution > >> >> 3) +1, it would be very helpful to have faster startup when testing. > I > >> >> would not put the file into the cache in the distribution, but in a > skin > >> >> folder or something, and it could simply copy the file in place of > >> >> generating it for the default skin. So this could work on any > >> > distribution, > >> >> and it could also solve your temporary folder issue. > >> >> > >> >> wdyt ? > >> >> > >> >> > >> >> On Thu, Feb 12, 2015 at 5:55 PM, Guillaume "Louis-Marie" Delhumeau < > >> >> gdelhumeau(a)xwiki.com> wrote: > >> >> > >> >> > Hi. > >> >> > > >> >> > Currently, XWiki is quite long to start, and this is mainly > because of > >> > the > >> >> > LESS compiler which generates the CSS file of the skin. > >> >> > > >> >> > Fortunately, we cache the results of the compilation in the LESS > >> cache, > >> >> > which is stored in the file-system (this is important). > >> >> > > >> >> > Some actions can be done to make the launch quicker: > >> >> > > >> >> > 1 - Not purge the cache at startup. > >> >> > The idea is to keep the cache of the previous launch of XWiki, so > LESS > >> >> > would have nothing to compile anymore. This does not solve the > first > >> > launch > >> >> > issue, but it is a great progress anyway. The disadvantage of this > is > >> > that > >> >> > restarting XWiki will not solve any issue related to a bad cached > file > >> > (ex: > >> >> > a buggy CSS file stored in the cache will still be there after a > >> > restart. > >> >> > The only way to fix this is to re-save the buggy LESS resource). > >> >> > > >> >> > Note that this behaviour can easily be changed by modifying a > config > >> > file: > >> >> > > >> >> > > >> > > >> > http://extensions.xwiki.org/xwiki/bin/view/Extension/LESS+Module#HCacheStra… > >> >> > > >> >> > 2 - During the build of XE, run an integration test that performs a > >> > simple > >> >> > view request to XWiki in order to make the LESS compiler builds the > >> CSS > >> >> > file and pushes it into the cache. After the integration test, we > just > >> > copy > >> >> > the generated LESS cache file into the Jetty/HSQLDB distribution, > and > >> so > >> >> > when you launch XWiki from this distribution, you use the > >> pre-generated > >> >> > cache. > >> >> > > >> >> > Of course it could only work for our Jetty distributions that users > >> test > >> >> > locally. It will not solve the issue on production servers. But it > is > >> >> > already good that a user have a good impression by starting XWiki > >> > quickly > >> >> > on her computer. > >> >> > > >> >> > I have made a proof of concept on a branch [1] and the thing is > >> working > >> >> > well. The first request to XWiki is really faster. > >> >> > > >> >> > The only blocking point I have now is that the current cache > directory > >> > is > >> >> > currently configured to be the temporary directory. Instead, I > need to > >> > use > >> >> > a directory from the distribution (where I can put my pre-generated > >> > cache > >> >> > files). I have solved this locally by setting an absolute path to > my > >> > "data" > >> >> > folder [2], but it is not clean. > >> >> > > >> >> > Thomas suggested me to configure all the caches to use the > "permdir" > >> >> > directory, which actually is the "data" directory in the case of > our > >> > jetty > >> >> > distributions, and so it does the job. > >> >> > > >> >> > So the vote is for the following proposal: > >> >> > 1 - move the cache files to permdir > >> >> > 2 - do not purge the LESS cache at startup (by default) > >> >> > 3 - add a new module that pre-generate the LESS cache file to make > the > >> >> > first XWiki launch faster > >> >> > > >> >> > Here is my +1. > >> >> > > >> >> > Thanks, > >> >> > > >> >> > [1] > >> >> > > >> https://github.com/xwiki/xwiki-enterprise/compare/feature-datalesscache > >> >> > [2] > >> >> > > >> >> > > >> > > >> > http://jira.xwiki.org/browse/XWIKI-10879?focusedCommentId=85369&page=com.at… > >> >> > > >> >> > > >> >> > -- > >> >> > Guillaume Delhumeau (gdelhumeau(a)xwiki.com) > >> >> > Research & Development Engineer at XWiki SAS > >> >> > Committer on the XWiki.org project > >> >> > _______________________________________________ > >> >> > devs mailing list > >> >> > devs(a)xwiki.org > >> >> > http://lists.xwiki.org/mailman/listinfo/devs > >> >> > > >> >> > >> >> > >> >> > >> >> -- > >> >> Denis Gervalle > >> >> SOFTEC sa - CEO > >> >> _______________________________________________ > >> >> 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 > _______________________________________________ > devs mailing list > devs(a)xwiki.org > http://lists.xwiki.org/mailman/listinfo/devs > -- Guillaume Delhumeau (gdelhumeau(a)xwiki.com) Research & Development Engineer at XWiki SAS Committer on the XWiki.org project

9 years, 10 months

Re: [xwiki-devs] [xwiki-notifications] [xwiki/xwiki-platform] 645089: XWIKI-11794: 13 smartclient JS files not found whe...

by vincent＠massol.net

On 16 Feb 2015 at 10:14:08, GitHub (noreply@github.com(mailto:noreply@github.com)) wrote: > Branch: refs/heads/stable-6.4.x > Home: https://github.com/xwiki/xwiki-platform > Commit: 645089e5e573d23868077c96c2edce4d4f2daaa7 > https://github.com/xwiki/xwiki-platform/commit/645089e5e573d23868077c96c2ed… > Author: Marius Dumitru Florea > Date: 2015-02-16 (Mon, 16 Feb 2015) > > Changed paths: > M xwiki-platform-core/xwiki-platform-dashboard/xwiki-platform-dashboard-macro/pom.xml > > Log Message: > ----------- > XWIKI-11794: 13 smartclient JS files not found when editing a dashboard inline > * Reduce a bit the expected test coverage ratio to fix the quality build. I find it silly that removing a few lines of code from a method that has unit tests can lower the ratio (there are less instructions tested but there are less instructions in total also). Not sure what you find silly because if some code is more tested than the rest of the code in the same module and if you remove that code (and thus the tests too), then it’s obvious that you will reduce the TPC (it’s a percentage). Maybe you have a wrong perception of what the TPC is? You seem to be wanting some fixed value (and not a percentage) but that doesn’t exist :) Thanks -Vincent

9 years, 10 months

[xwiki-devs] [ANN] CKEditor Integration in XWiki

by Marius Dumitru Florea

Hi guys, FYI I published an extension [1] that integrates the CKEditor [2] in XWiki. It can be installed through the Extension Manager and should work with any version greater than or equal to 6.2.5. I hope to add support for the missing features soon. Thanks, Marius [1] http://extensions.xwiki.org/xwiki/bin/view/Extension/CKEditor+Integration [2] http://ckeditor.com/

9 years, 11 months

Jump to page:

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

2005

xwiki-devs