Hi xwikiers,
Denis expressed to me some concerns about the type that should be
associated to Mail.MailConfig since it contains configuration data.
One important issue I see if that this page is primarily an admin
configuration UI which happen to also contains configuration data
(would have been much cleaner to store the data in a generated
document...) so I think the best for now is to keep the default type.
Since you are not supposed to go trough edit more to modify those
configuration data, the edit protection should not really affect users
in practice (no warning when using admin UI).
WDYT ?
--
Thomas Mortagne
Hey everyone,
I’m working on improving dokuwiki importer this GSoC and have designed a proposal defining goals according to the current issues and some proposed ideas, for this summer.
I’ll be glad if developers can share their views and let me know if you feel something more can be added to it or changed for better.
Thanks to Thomas Mortagne and Shubham Jain for mentoring me on this project.
You can find the proposal here http://design.xwiki.org/xwiki/bin/view/Improve%20dokuwiki%20Extension/ <http://design.xwiki.org/xwiki/bin/view/Improve%20dokuwiki%20Extension/>
Best,
Neha
Hello to our GSoC 2018 students,
The GSoC 2018 coding period has officially started.
I hope you have taken advantage of the bonding period to get up to speed
with the XWiki project, its code and documentation, and that you have a
pretty good idea of what you need to do to turn your project into a success.
As for tips and things that you need to do in the following (coding)
period, please make sure you read carefully the these 2 dedicated sections
[1][2] in the student guidelines [3], particularly:
* keeping your progress report page up to date [4]
* creating your design page as instructed [5]
* making your contribution to the XWiki project (pull request)
Working on your project is great, but it`s only half of the work that GSoC
involves. The other half is integrating into the community, letting people
know what your are working on, asking for help and learning to ask the
right questions, and generally communicating about yourself and your work.
In order to keep in touch, additionally to reading and being active on the
mailing list, you also need to be present on IRC as much as possible (at
least while you are working on your project) so that:
* people see you and can quickly get a hold of you
* you are exposed to everyday community activity that might spark your
interest
* get more occasions to ask questions
* get more occasions to help others with their problems should you know the
answer
* etc.
Hope you are finding XWiki to be an interesting project and that you are
enjoying your GSoC so far.
-The XWiki Development Team
----------
[1]
http://dev.xwiki.org/xwiki/bin/view/GoogleSummerOfCode/Guidelines#HSuggeste…
[2]
http://dev.xwiki.org/xwiki/bin/view/GoogleSummerOfCode/Guidelines#HConditio…
[3] http://dev.xwiki.org/xwiki/bin/view/GoogleSummerOfCode/Guidelines
[4]
http://dev.xwiki.org/xwiki/bin/view/GoogleSummerOfCode/DocumentingStudentPr…
[5] http://design.xwiki.org/
The XWiki development team is proud to announce the availability of XWiki
10.4-rc-1.
In this version we've improved the Navigation panel by allowing pages to be
excluded from the listing. We've added a new macro for Notifications that
allows it to be embedded in other pages. We've also improved the History's
Changes view by providing more navigation options between versions. We've
continued to tweak the edit protection, added in the previous version, for
some default extension pages (like Skin, Color Themes, Dashboard, Sandbox,
etc.).
You can download it here: http://www.xwiki.org/xwiki/bin/view/Main/Download
Make sure to review the release notes:
http://www.xwiki.org/xwiki/bin/view/ReleaseNotes/Data/XWiki/10.4RC1/
Thanks for your support
-The XWiki dev team
Hi devs,
I’ve recomputed the global Clover TPC by excluding all tests from the result and found the following results:
* 2012-07-02: 62.21%
* 2016-12-20: 65.29% => +3.08%
* 2017-11-09: 68.59% => +3.3%
* 2018-04-03: 68.34% => -0.25%
* 2018-05-11: 68.77% => +0.43%
So:
* From mid 2012 to end of 2016 (4.5 years) => +3.08%
* From 2016 to 2017 (11 months, almost 1 year) => +3.3%
** Big increase compared to before where it took 4.5 years to get a similar results
* From 2017 to 2018 (6 months) => +0.18%
** We’re doing quite bad in 2018 so far.
My next step is to find out the biggest offenders by sorting the packages having lost the most TPC while having the most covered elements (a package with one class that goes from 80% to 50% is less important than a package with 10 classes going from 80% to 70%).
Thanks
-Vincent
Hi devs, here’s a feedback we received, FYI.
Ideas?
Thanks
-Vincent
> Begin forwarded message:
>
> From: Vincent Massol
> Subject: Re: Get started with XWiki
> Date: 14 May 2018 at 09:10:06 CEST
> To: XXX
> Cc: XXX
>
> Hi Christian,
>
>> On 12 May 2018, at 14:25, Christian XXX wrote:
>>
>> It's not working.
>>
>> And as usual ith java, the log does not help. Maybe if I were an expert? But an app is supposed to be installed by just 'smart' users, not experts.
>
> If you choose the easy installation methods we propose then it’s easy and you have nothing to do.
>
> Which distribution did you choose and use?
>
>> And there is no help from the website.
>>
>> Oracle Linux 7.
>> Linux localhost.localdomain 4.1.12-124.14.5.el7uek.x86_64 #2 SMP Fri May 4 15:26:53 PDT 2018 x86_64 x86_64 x86_64 GNU/Linux
>> Java 10
>> Xwiki 10.3
>> tomcat.
>>
>> If it is not compatible whith this java. It should not install.
>
> It’s just not been tested with Java 10 yet. It’s not even fully working with Java 9.
>
> Note that it’s hard to check for the java version for all the distributions since XWiki is a webapp and the XWiki WAR can just be dropped in a servlet container and thus we don’t have a startup script and a place where we can put a check. All we could do is have a Servlet Listener that would emit a big stack trace (like the one you got) and that would say at the innermost level that XWiki requires Java <= 8. But even that wouldn’t be good since it would prevent testing in Java 9+. We want feedback from users about what works/what doesn’t work so improve support for Java 9 and 10.
>
>> If it is compatible with only one version of java, which one?
>
> You need to read the installation page ;)
>
> See http://www.xwiki.org/xwiki/bin/view/Documentation/AdminGuide/Installation/ and especially:
> http://www.xwiki.org/xwiki/bin/view/Documentation/AdminGuide/Installation/#…
>
>> Here is the error:
>>
>>
>> Error number 4001 in 4: Error while evaluating velocity template colorThemeInit.vm
>> Error number 4001 in 4: Error while evaluating velocity template colorThemeInit.vm
>> com.xpn.xwiki.XWikiException: Error number 4001 in 4: Error while evaluating velocity template colorThemeInit.vm
>
> [snip]
>
>> Caused by: java.lang.IllegalStateException: No standard field found for reverse order comparator!
>> at org.jboss.marshalling.river.Protocol.<clinit>(Protocol.java:276)
>> ... 249 mor
>
> [snip
>
>> Caused by: java.lang.IllegalStateException: No standard field found for reverse order comparator!
>> at org.jboss.marshalling.river.Protocol.<clinit>(Protocol.java:276)
>> ... 249 mor
>
> What this says is that JBoss Infinispan (which we use) is not compatible with Java 10. Apparently this is fixed in recent version of JBoss Marshalling: https://issues.jboss.org/browse/JBMAR-216. We probably just need to wait for JBoss Infinispan to release a new version that uses JBoss Marshalling 2.1.0.Final.
>
> What would be awesome would be for you to report the problem of using XWiki with Java 10 on https://jira.xwiki.org so that we can have an issue for it and work to make it work.
>
> Note that I’m replying to this message to help you out but it’s not the right place to post a question and get help normally. For that we have a user forum at https://forum.xwiki.org/.
>
> I’m sorry you had some issues. OTOH you’re looking for trouble by trying with Java 10. There are very few (if any!) java app that currently work with Java 9 and 10. You’d be much better off using Java 8. On the positive side, if you raise the issue on https://jira.xwiki.org, then you will transform your negative experience into a positive one, by contributing to the development of XWiki and helping out future users.
>
> Thanks
> -Vincent Massol
[snip]
Hi devs,
Our current Test coverage strategy is to fail the build when new code added results in a coverage lower than the threshold for the module, using jacoco.
This has 2 limitations causing our global TPC to go down from time to time (see https://markmail.org/message/hqumkdiz7jm76ya6 ).
Thus I’d like to propose the following addition to our strategy:
* We already have a jenkins pipeline to automatically compute the full TPC using Clover. See http://dev.xwiki.org/xwiki/bin/view/Community/Testing#HUsingClover2BJenkins
* Make it run more often (it’s currently executed once per month, see http://ci.xwiki.org/view/Tools/job/Clover/). Takes about 5-6 hours to execute. Thus we could run it once per week or even once per day during the night.
* Add some groovy logic in the pipeline to perform an analysis after the Clover report has been generated. Perform 2 checks by comparing the previous report with the one that just executed:
** Find new packages introduced that have a TPC < the average computed TPC
** Find packages and/or files having a TPC lower than the previous TPC
** Find removed packages that had a TPC higher than the average computed TPC
* Save a report in the directory for the Clover report at http://ci.xwiki.org/view/Tools/job/Clover/
* For all failures, send an email to notifications(a)xwiki.org with details and a link to the saved report
* Ideally, and if we can do it, call the github API to find the authors of commits for those packages and add them in the report. Examples of APIs we could use:
** https://api.github.com/repos/xwiki/xwiki-platform/commits?since=2018-05-07T… (there’s a path parameter that could be used to filter but I don’t think it’ll work
** https://github.com/xwiki/xwiki-platform/compare/master@%7B2018-05-07%7D...m… (the committers/authors need to be extracted from the HTML which is a bit fragile)
* Add a step in the Release process to ensure that the global TPC has not been lowered. This would be a way to ensure we pay attention to that and fix it when we lower it. We would need to tune this to find something that helps keep the TPC increasing while not putting too much pressure at the same time on the release date. It doesn’t have to be in the release process but we need some checkpoint to make sure we look at it and that all devs fix the tests when they lower the global TPC, or at the very least that an analysis is done in case where it’s hard to keep the TPC (for example, removing existing code that had a lot of tests will lower the TPC ;)).
WDYT?
As a dev, would you be willing to pay attention to not lower the global TPC and work to fix it when it happens?
Thanks
-Vincent