February 2015 - xwiki-devs@xwiki.org

[xwiki-devs] So what is an extension flavor exactly ?
by Thomas Mortagne 17 Feb '15

17 Feb '15

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

5 8

[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 17 Feb '15

17 Feb '15

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

6 13

Re: [xwiki-devs] [xwiki-notifications] [xwiki/xwiki-platform] 645089: XWIKI-11794: 13 smartclient JS files not found whe...
by vincent＠massol.net 17 Feb '15

17 Feb '15

On 16 Feb 2015 at 10:14:08, GitHub ([email protected](mailto:[email protected])) 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

2 3

[xwiki-devs] [ANN] CKEditor Integration in XWiki
by Marius Dumitru Florea 16 Feb '15

16 Feb '15

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/

1 0

[xwiki-devs] [Vote] Move the caches files to permdir and make the launch of XWiki faster
by Guillaume "Louis-Marie" Delhumeau 16 Feb '15

16 Feb '15

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

6 13

[xwiki-devs] [GSOC] XWiki is applying for GSoC 2015. Proposals and mentors needed!
by Eduard Moraru 16 Feb '15

16 Feb '15

Hello fellow XWiki community members, This year XWiki is planning to participate once more at Google's Summer of Code [1]. The organization registration period has already started (9th of February) and the deadline is the 20th of February: 19:00 UTC [2] (a bit more than a week from now). 1. We need to provide by then a list of proposals and assign mentors for the students that are going to implement them. I would like to ask everybody that wants to participate as a mentor from the XWiki organization to review the proposals [3] list (currently empty) and add as many interesting proposals as possible. The proposals can be either new, or they can be revived from previous years. Just navigate to the previous years [4], find the proposal you like and know about, go to its proposal page (click it) and press the "Clone to this year" link. Now you can assign yourself as lead for that project, update it's description if needed and wait for the student applications to start pouring [image: emoticon_smile] 2. We also need to submit the actual application [5] of the XWiki organization to participate to the GSoC 2015 project so I would also like to ask you to review it so that we have a better chance of being selected into the program. 3. If you feel that you would like to help on improving XWiki's GSoC guides and application forms, please find the tips for students [6] on XWiki's GSoC page, the student application form [7] and the lessons learned [8] from previous years participations. Thanks for your help, Eduard ---------- [1] http://www.google-melange.com/gsoc/homepage/google/gsoc2015 [2] http://www.google-melange.com/gsoc/events/google/gsoc2015 [3] http://dev.xwiki.org/xwiki/bin/view/GoogleSummerOfCode/#HProposedProjects28… [4] http://dev.xwiki.org/xwiki/bin/view/GoogleSummerOfCode/WebHome#HPreviousGSo… [5] http://dev.xwiki.org/xwiki/bin/view/GoogleSummerOfCode/OrganizationApplicat… [6] http://dev.xwiki.org/xwiki/bin/view/GoogleSummerOfCode/Guidelines [7] http://dev.xwiki.org/xwiki/bin/view/GoogleSummerOfCode/student+application+… [8] http://dev.xwiki.org/xwiki/bin/view/GoogleSummerOfCode/LessonsLearned

2 3

[xwiki-devs] Documenting how to contribute XAR XWiki extensions.
by Caleb James DeLisle 16 Feb '15

16 Feb '15

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

4 5

[xwiki-devs] Mail sender API doesn't work with template?
by Pascal BASTIEN 16 Feb '15

16 Feb '15

Hello, On Xwiki 6.4, it seem that new mail sender API doesn't work. I didn't manage to use exemple 3 and 4 from doc: http://extensions.xwiki.org/xwiki/bin/view/Extension/Mail+Sender+API#HExamp… I use Admin account and use this code: http://www.xwiki.org/xwiki/bin/view/ReleaseNotes/ReleaseNotesXWiki641#HIssu… I attached a Xwiki/Mail objetct to MailTemplatePage but no mail are sent and /bin/admin/XWiki/XWikiPreferences?editor=globaladmin&section=emailStatus page are empty. Example 1 and 2 are working (I fixed a typo). Pascal B.

2 4

[xwiki-devs] [myxwiki] XWiki Enterprise 6.4.1 Upgrade
by Thomas Mortagne 13 Feb '15

13 Feb '15

Hi everyone, myxwiki.org has been upgraded to XE 6.4.1. If you own a wiki hosted there you should have a look at the release notes for this version at: http://www.xwiki.org/xwiki/bin/view/ReleaseNotes/ You should automatically get an upgrade wizard for your wiki when you login as admin. For more details see the upgrade guide available at : http://platform.xwiki.org/xwiki/bin/view/AdminGuide/Upgrade#HUpgradingwikid… To be notified of the myxwiki.org server upgrade you can follow myxwiki on twitter: http://twitter.com/myxwiki Thanks, -XWiki Community

1 0

[xwiki-devs] How to check if a document is publicly readable?
by Paul Libbrecht 13 Feb '15

13 Feb '15

Hello dear fellow XWikiers, what can I do to check if a document is publicly readable? thanks in advance. Paul

3 4