I see there has been some discussion on the list, as far as I understand there is no decision about it in general.
However I would like to drop support for pre-nested pages for the mocca calendar on the master branch right now.
The pre-nested spaces structure is:
- Calendars are plain pages
- Events are pages that have their calendar as parent page, but are usually placed as siblings in the same space
(necessarily w/o nested pages)
It is more natural to have calendars as nestable, non-terminal pages, and the corresponding events nested inside these calendar pages.
Bugs that would be easy to solve after dropping support:
http://jira.xwiki.org/browse/MOCCACAL-91 "Cannot create two events with the same title in the same calendar "
This has been fixed in 2.5.1 for pre-nested pages, but that fix does not work for nested pages.
Admittedly it could also be fixed with an if (nested space) do x else y
I have to admit that I am reluctant to implement the if-else fork and fully test it (If I do not test both nested and pre-nested spaces it will be broken with high probability)
In some places there are already horrible if-else clauses to support both colibri and flamingo, which I put there and the experience makes me unwilling to try this again with nested spaces.
http://jira.xwiki.org/browse/MOCCACAL-93 "Preinstalled "Other Events" Calendar should not be a terminal page"
This actually can not be fixed in a pre-nested spaces compatible way (I think)
Proposal:
a) there is already a "stable-2.5" branch.
all fixes and improvements for pre-nested spaces will/should go on this branch
b) master will switch its xwiki platform dependency from 5.4 to 7.4.2
(not 7.2 for me, because 7.4.2 is what I am willing to test against ... any takers to test with 7.2 ?)
c) for now, the old "parent-child" relationship will still be used to determine which events belong to which calendar
so no migration from pre-nested spaces is really necessary - at least I think so. Of course this should be tested.
(It would be nice to have such migration, of course. I am not sure how to write this, however.)
Any opinions? Should I send an official [vote] request?
Clemens
Hi devs,
I think it's time to separate the Pre Nested Spaces and Nested Spaces
versions of the Forum Applications. I would like to create a branch 1.9.7
to move the Pre Nested Spaces version which would be used only for bug
fixes.
Reasons to use Nested Spaces on Forum Application:
* to have Access Rights inheritance for forums and topics
* to have a proper hierarchy Forums/MyForum/MyTopic instead of
Forums_MyForum/MyTopic
* to be able to configure other needed applications at Topic space level
(e.g.: Ratings - store topics' votes objects in dedicated pages in the same
space)
This means that the new version of the application will need XWiki 7.2+ (or
even 7.4.2 if the Mail Sender Plugin will be replaced with the stable
version of the Mail Sender API).
Considering that Nested Spaces bring some value to the application's users,
I'm voting +1.
Thanks,
Alex
Hi guys,
I saw that at devoxx fr and it seems a great way of working with Jenkins.
So I’ve done some POC over the week end, following:
* https://jenkins.io/doc/
* https://github.com/jenkinsci/pipeline-plugin/blob/master/TUTORIAL.md
Here are the features we could use:
* Commit a Jenkinsfile in the SCM (in each branch we use) —> Solves a big part of the issue of saving the jenkins setup + version it (we know who’s modified what and when and it’s in sync with the branches).
* Jenkins can automatically create jobs when a Jenkinsfile is noticed. So for example on my local machine I’ve configured a special job for the xwiki-contrib org on github and whenever a project there adds a Jenkinsfile, a job is created (and executed) on jenkins
* It’s very visual and very powerful. You program the jenkinsfile in groovy and you have a great DSL to control fully all the steps to execute.
* It’s possible to create some reusable libraries so that we don’t duplicate Jenkinsfile content across modules. I still need to finish my research on how to do that. There’s a readFile() API but I need to check how to package them so that they’re not on the FS.
For ex this is what I got locally:
* https://www.evernote.com/l/AHdeHR61ufBJxrWGIz6FOLtxvwdFf6LXBic
* With this simple jenkinsfile:
————
#!groovy
node (){
stage "Checkout"
env.PATH = "${tool 'Maven 3'}/bin:${env.PATH}"
checkout scm
stage "Build"
def pom = readMavenPom()
def projectName = pom.name
def projectVersion = pom.version
echo "Building ${projectName} - ${projectVersion}"
sh 'mvn clean package'
stage "Collect Results"
step([$class: 'ArtifactArchiver', artifacts: '**/target/*.jar', fingerprint: true])
try {
step([$class: 'JUnitResultArchiver', testResults: '**/target/surefire-reports/TEST-*.xml'])
} catch (all) {
}
}
————
Some examples:
* https://github.com/jenkinsci/pipeline-examples
* https://gist.github.com/chinshr/aa87da01ec28335e3ffd
* https://github.com/cloudbees/zendesk-java-client/blob/master/Jenkinsfile
Thanks
-Vincent
Hi all,
we are going to perform some operations on l10n.xwiki.org to migrate
it to a new virtualization platform.
These operations will last around 4h (depending on how fast the
data-transfer will be)
We are going to start at 16h30 (Paris time) and if everything goes
fine the wiki should be back at the end of the day.
During the operations the wiki will stay up and accessible but it will
be set in read-only mode.
We apologize for the inconvenience.
Thanks,
Fabio Mancinelli
Infrastructure Manager
XWiki SAS
Hello community, Hello Google Summer of Code students and applicants,
First of all, we would like to thank all of this year's GSoC student
applicants for their interest in XWiki. Even if this year we have been
assigned and selected only 1 slot for the program, we would still help and
encourage any student interested to do a project without Google's
implication and enjoy all the benefits of the program, except for the
Google sponsored money of course. If you would like to do that, please let
us know by replying to this mail. You are always welcomed to our community.
Having said that, we would like to acknowledge and welcome Fitz as this
year's Google Summer of Code student inside the XWiki development team!
We know you have already started looking into the details of your project
(which is gear!). Here are some general getting started hints for the next
steps of the program:
= Community bonding period =
According to the program timeline [2], the next month (until - May 22nd) is
to be used for community bonding.
You have already introduced yourself to the community, but keep
communicating and exploring.
Also, you should continue getting acquainted with the project, the code,
the practices and the developers. Please make sure you all read and
understand the following - very useful - documents:
- [3] http://purl.org/xwiki/community/
- [4] http://purl.org/xwiki/dev/
- [5] http://platform.xwiki.org/xwiki/bin/view/Features/
= Mentorship =
We prefer open mentorship. While your assigned mentor is the one officially
in charge with your guidance, almost all interaction should be done 'in the
open' as much as possible, on the IRC channel or on the mailing list. You
should choose the communication medium according to the importance of the
matters to be discussed: naturally, the less important issues are to be
discussed on IRC, while the design decisions, important progress
announcements and testing/feedback requests go on the list. This way, the
community is informed on the evolution of your project, and other
developers can come up any time with useful ideas and suggestions.
Moreover, if your mentor is "hit by a bus" (the bus factor [6]), another
developer can take his place with little effort.
= Communication =
Sitting alone in your room, working secretly on your project is definitely
a bad approach. However, please keep in mind that too much communication
can also be harmful, as it distracts the others from their own work. You
need to be able to communicate just right:
- provide meaningful information about your progress,
- ask the community's opinion on non-trivial design or implementation
decisions
- avoid wasting a lot of time on a problem, when a more experienced
developer (or a student that fought the same problem) could quickly provide
you an answer; however, do try to find the answer yourself at first.
Wrong: "Where do I start? What do I do now? And how do I do that? Is this
good? It doesn't work, help me!"
Right: "Since a couple of hours ago I get a strange exception when building
my project, and googling for a solution doesn't seem to help. Looking at
the error, I think that there's a wrong setting for the assembly plugin,
but nothing I tried works. Can someone please take a look?"
Start monitoring the devs mailing list discussions. It is also recommended
to subscribe to the users list, but not mandatory. The notifications list
is a little too high volume and technical for the moment, but it is a great
knowledge source.
= Development process =
The project's lifecycle is NOT design -> implementation -> testing ->
documentation.
We invite you to adopt a test driven development [8][9][10] approach and to
experience agile development [11]. After the first coding week, you must
have some code that works. It won't do much, of course, but it will be the
seed of your project. Every functionality will be validated by tests. The
code must be properly tested and commented at the time of the writing
(don't think you'll do that afterwards, because in most cases you won't).
Since our code is now hosted on GitHub [12], you should register an account
there and fork some xwiki repositories, so that you can try to build XWiki
from sources, and be able to contribute bugfixes. We'll add you to the
xwiki-contrib organization [13], and we'll create dedicated repositories
for each project. We encourage you to do __at least__ weekly commits
(ideally, if you are well organized, you should be able to commit code that
works daily, so try to aim at daily commits). This way, the code can be
properly reviewed, and any problems can be detected before they grow into
something too difficult to fix. One big code blob committed at the end, no
matter how good it may seem, is a failure at several levels.
A simple way of having something functional in the first week is to prepare
the maven build for your modules, which will give you the first unit test
for the first class.
= Next steps, in a nutshell =
- Get more familiar with the code and development process and try to master
Maven, JUnit, Selenium, component driven development, ...
- Continue fixing a few small issues, chosen so that they are __related to
your project__. You can ask on IRC for help selecting good issues, or you
can pick from the (non-comprehensive) list of easy issues [14]
-- This will help you get more familiar with the code your project needs to
interact with.
- Refine and organize the ideas concerning your project (you can use the
Drafts space [15]), and write several use case scenarios.
- Start writing the first piece of code for your project.
At the end of the community bonding period, you should have a clear vision
of the project, well documented on the xwiki.org wiki, you should have the
build infrastructure ready, and you should be pretty familiar with the
existing code you will need to interact with. And, of course, you should be
familiar with the community and the way we communicate.
Good luck, and may we all have a great Summer of Code!
-The XWiki Development Team
----------
[1] https://developers.google.com/open-source/gsoc/timeline
[3] http://purl.org/xwiki/community/
[4] http://purl.org/xwiki/dev/
[5] http://platform.xwiki.org/xwiki/bin/view/Features/
[6] http://en.wikipedia.org/wiki/Bus_factor
[8] http://en.wikipedia.org/wiki/Test-driven_development
[9] http://www.amazon.com/dp/0321146530/
[10] http://www.amazon.com/dp/0201485672/
[11] http://www.amazon.com/dp/0596527675/
[12] https://github.com/xwiki/
[13] https://github.com/xwiki-contrib/
[14]
http://jira.xwiki.org/jira/secure/IssueNavigator.jspa?mode=hide&requestId=1…
[15] http://dev.xwiki.org/xwiki/bin/view/Drafts/
Hi devs,
As I was working on the Forum Application, which depends on Ratings
Application, I noticed that the rating configuration doesn't work as
expected on the Nested Spaces versions of XWiki.
For example, having A.WebPreferences with a XWiki.RatingsConfigClass
object, the configuration does not apply to A.B.WebHome, because the
configuration is set at space level, without inheritance to the below
levels.
As a solution for this I propose to create a new Api
(getConfigurationDocument()) in the Ratings module which will check,
starting the current document, and get the first ancestor that holds the
XWiki.RatingsConfigClass object and use that as configuration document,
keeping the fallback to the XWiki.RatingsConfig document.
An issue has been created at http://jira.xwiki.org/browse/XWIKI-13274 and a
first pull request at https://github.com/xwiki/xwiki-platform/pull/472, but
without having been discussed here before.
WDYT?
Hello Dear devs,
I am Fitz Lee, a CS Master's student from the University of Chinese Academy
of Sciences. I'm very interested in this project, XWiki authenticator
Android. I have submitted the final application for Gsoc2016
(https://drive.google.com/file/d/0ByNx4jI3PEaNaGRxMkt0cUU3SjA/view?usp=shari…
).
In order to furtherly understand the authenticator project, I have developed
this android demo (https://github.com/fitzlee/SampleSyncAdapter), which is
based on SampleSyncAdapter Google Android Sample. By deeply Analyzing the
SampleSyncAdapter source, I have implemented the material design(>=4.4) ui,
the synchronization of contacts and the access of other apps . But some
functions in google server(https://samplesyncadapter2.appspot.com/sync)
can't work well so that the client-to-server Synchronization function can't
be tested and verified, and it needs to cooperate with server. In my github
repository(https://github.com/fitzlee/SampleSyncAdapter), I also show my
analysis about the authenticator, synchronization, contactmanager, sign-in,
sign-up and the whole process of the app. And now I am trying to develop the
XWiki android authenticator project.
Please consider my application, and I am eager to join this project and make
a contribution. It's my first time to join the open source organization for
enhancing my teamwork and technical skills. Please give me a chance, and I
will try my best. If there is anything I can do for this project , I will be
very happy.
Here, i also have some questions which confuse me during my development:
1. contact synchronization
(1)Situation:
Now I have implemented the server-to-app synchronization with the modified
SampleSyncAdapter (https://github.com/fitzlee/SampleSyncAdapter), and this
demo can download contacts from server to local sqlite3 database. Also I can
edit and modify the local contact and from logcat I have seen the dirty
contacts being sent to the server. But the synchronization of server can't
work so that I can't test this function.
(2)Problem:
Moreover, by analyzing the XWiki android authenticator in the repository
(https://github.com/xwiki-contrib/android-authenticator). I have seen that
some function has not been implemented, like getDirtyContacts and
getRawContact in ContactManager. And the process of synchronisation in
SynAdapter_onPerformSync also confuse me, like "ensureXWikiGroupExists>>
XWikiConnector.getUsers>> ContactManager.updateContacts>>
ContactManager.updateStatusMessages". I think it should be this process,
like "ContactManager.getDirtyContacts>> NetworkUtilities.syncContacts>>
ContactManager.updateContacts". Therefore, I don't know whether there is
something wrong with me. Could you give me some advice?
2. A test xwiki server and test user which may help me a lot to develop this
project for testing.
I have analysed the sampleSynAdapter and implemented some function, for
example material design(>=4.4), version support(2.3 with v7 library) and the
synchronisation from server to the android local sqlite3
database(contacts2.db) using ContactManager.But when client sends some dirty
contact data to server, the synchronisation of server in google appengine
can't work well so that I can't test my app's synchronisation. And the
SampleSyncAdapter server also can't provide me more apis,like signing up and
other necessary function.I have tried to upload a python server to google
appengine,but failed because of the incompatibility between the source code
by python version 2.5 and the cloud platform by 2.7 version.
Question: Please if possible, could i have a test user and some server apis
in xwiki server, or maybe i should write a test server by myself?
3. requirement
I think this project mainly has the following requirements.
(1) sign in
it is easy,just like my analysis of android SampleSyncAdapter, including the
server connection with XWikiconnector and the account added by
AccountManager
(2) sign up
may also need some other api, like getting a list of xwiki user, adding
friends which can be synchronized in the local phone contacts. Also other
activitie may be possibly added, therefor the authenticator app will be very
complex.
(3) synchronization of contacts
(4) edit the contact
(5) access by other apps
Question: Are there more other requirements in this app, like adding
friends(general person) and creating new xwiki account(administrator)?
maybe it will cause more demands and be more complex.
4. support version and ui
(1) ui design
* material design >=4.4 with the support library support-v7
(2) support version
* The ui design can support the lowest 2.3 version and the android
sampleSynAdapter can also support 2.3 version. So I think our authenticator
app can support the lowest 2.3 version if needed.
Question: Maybe there are somethings I have not noticed, so this conclusion
is wrong, please give me some advice? Is that OK?
5. account permission
In AccountGeneral.java there are two permissions , like
AUTHTOKEN_TYPE_READ_ONLY, AUTHTOKEN_TYPE_FULL_ACCESS. Could you tell me
what the permissions main? other xwiki instance access limits ? Account
manager? And where should I use them?
I am looking forward to hearing from you. Thank you very much.
Best Regards
Fitz Lee | UCAS Master
Email&Skype: fitz.lee(a)outlook.com
Github&Homepage: https://github.com/fitzlee
University of Chinese Academy of Sciences(UCAS)
Shijingshan District, Beijing, China
--
View this message in context: http://xwiki.475771.n2.nabble.com/Questions-Gsoc2016-XWiki-Android-authenti…
Sent from the XWiki- Dev mailing list archive at Nabble.com.