Hello community, Hello Google Summer of Code students,
First of all, congratulations on your applications and your activity during
the selection period, and welcome in the XWiki development team.
Before guiding the accepted students to their next steps, we'd like to
thank again all those who showed interest in XWiki for this Summer of Code.
We had a lot of good applications this year, with professional approaches
and interesting ideas, and it was very difficult to choose only 3.
Unfortunately, some very good students, with great potential, were not
accepted. So, to those interested in getting involved anyway, without
Google's implication, I renew the invitation to put your ideas in practice
under the guidance of the community. Even though the money will be missing,
you can still take advantage of the other GSoC benefits: learning new
things, gaining experience, earning recognition, etc [1]. If you would like
to do that, please let us know by replying to this mail.
For the accepted students, here are some getting started hints:
= Community bonding period =
According to the program timeline [2], the next month (until - May 21st) is
to be used for community bonding.
The first thing to do, sometime this week, is to present yourself and your
project on the dev list, so that everyone knows who you are and
what to expect from you (a precondition is to be subscribed to the list,
which you *need to do ASAP* if you haven't already).
Also, you should continue getting acquainted with 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?"
Subscribe to the devs list (if you didn't do this already), and start
monitoring the 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. [7]
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] http://www.catb.org/~esr/writings/cathedral-bazaar/homesteading/
[2] http://www.google-melange.com/gsoc/events/google/gsoc2012
[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
[7] http://www.catb.org/~esr/writings/cathedral-bazaar/cathedral-bazaar/
[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,
When Query Manager as been introduced by Artem I suggested to add a
setWiki to make easier to execute request on another wiki. For me it
was supposed to be usable by anyone and I discovered recently that it
was allowed only when the user has programming right.
Since I really don't see the point I propose to remove this check.
* all the users without programming right can do is to list documents
names so it's not very dangerous
* api;XWiki#searchDocumentsNames(String wikiName, String
parameterizedWhereClause, int maxResults, int startOffset, List< ? >
parameterValues) does not have any check so what the query manager
prevent is doable anyway
WDYT ?
Here is my +1.
--
Thomas Mortagne
Hi devs,
In HTTP specifications a redirect is always absolute URL which is
probably why we use absolute URL with sendRedirect.
However sendRedirect does not produce direct HTTP response but allows
relative URL and delegate to the application server the job of
producing proper absolute URL.
IMO XWiki should always use relative URL everywhere it can so I
propose to change our practice to use relative URL instead of absolute
URL with HttpSevletResponse#sendRedirect when possible.
The only reasons I see to use external URLs are:
* interwiki URL in a domain based multiwiki
* html/pdf export for links pointing on not exported pages or non view actions
WDYT ?
Here is my +1. We very often fix bugs in the way to produce external
URL and it's still not OK (see
http://jira.xwiki.org/browse/XWIKI-7632) so lets reduce the scope for
this need as much as possible.
--
Thomas Mortagne
Hi devs,
Sergiu has extracted the AutoTag plugin from oldcore in its own module. That's cool.
However he's also marked it @deprecated while doing so. And he's stopped bundling it in XE.
This raises several question:
1) Do we consider that what the plugin does it not useful? Because if we consider it's useful we might not want to deprecate it without offering an alternative. It's not because a technology is deprecated that we should deprecate stuff using that technology. Deprecated means: don't use this, instead use that. BTW it should be our rule that when we add the @deprecated tag we also mention what to use instead.
2) If we consider it's not useful anymore. We have 2 choices:
2a) Move it in legacy modules
2b) Move it to retired/contrib
My opinion:
* It could be useful but I'm not sure the XWiki Dev team wants to support it. IMO it should not be deprecated since it can still be useful and there's no replacement for it.
* Since I don't think the XWiki Dev Team should support it, I'd move it to xwiki-contrib/retired and publish it on e.x.o. for users who want to still use it.
* Since this is breaking our new rule regarding deprecations/legacy it requires a VOTE to move it to contrib/retired. It also needs to be clearly mentioned in the Release Notes as a breakage and explain how user can add it back to their wikis.
Let me know what you think and I'll send a VOTE if you agree with what I said above.
Thanks
-Vincent
Hi,
I've now put the Event Renderer in its own syntax module, same as what we have for other syntaxes.
Thus we need to decide if we still want to bundle it in XE or not (it was bundled but only because it was in rendering-api before).
IMO there's no reason to bundle it at all since:
* it's not used anywhere
* I don't see any use case for it (we use it only for tests)
* We want to reduce the # of extensions we bundle by default
* It can be added by the user in his XE instance should he need it (I doubt it)
So here's my +1 to not bundle it and to add this potential backward compat breakage in the RN for 4.1M1
Thanks
-Vincent
The XWiki development team is proud to announce the availability of
XWiki Commons, XWiki Rendering, XWiki Platform, XWiki Enterprise and
XWiki Enterprise Manager 3.5.1.
This is the first bugfix release for the 3.5 series, and, since 3.5 is
the final major release in the 3.x cycle, a bugfix release for the whole
3.x cycle. The main focus has been on quality assurance, improving the
compatibility with various database systems, polishing the new sheet
mechanism, the new extension manager, the skin, the WYSIWYG, and other
parts of the XWiki platform.
See the full release notes at
http://www.xwiki.org/xwiki/bin/ReleaseNotes/ReleaseNotesXWikiEnterprise351
for more details.
--
Sergiu Dumitriu
http://purl.org/net/sergiu/
It's tomorrow, the 26th of April, don't forget!
Goal:
* Move as many deprecations to legacy modules
Who:
* All committers and all contributor who wish to help out
Metric:
* Our score will be the # of APIs moved.
Each dev need to report the # of APIs he's moved.
Let's make it a success and learn from it.
I'll publish a blog post with the result afterwards.
Thanks
-Vincent
Hi devs,
Following the numerous database related issues that have/are delayed/ing
the 3.5.1 release and the 4.0 release, and seing how it could be long and
annoying to put multi-database tests in place, and the hard work Sorin has
done in testing these issues again and again, I have taken a couple of hour
to write a decent bash script.
Here is an excerpt of the usage message of my script:
This script can do the following steps easily to help you testing xwiki
distribution:
- Download a distribution package, either release or snapshot (using
mysql/jetty distribution).
- Deploy that package, and configure it for a requested database.
- Create the needed database.
- Import a database dump, previously exported with this same tool.
- Launch the configured XWiki with Jetty.
- Backup the database after XWiki shutdown.
All operations could be done in a multiuser environment, using common
databases, without conflict.
You may start using it as easy as "xwiktest -v 3.5 -d oracle -w" to have a
XWiki release 3.5 downloaded and run with oracle and non-conflicting ports
and database.
Full options are listed at the end of this thread for the interested.
I really hope this script could help in testing more often any changes that
may have consequences between versions, or may cause incompatibilities with
some databases. It would be nice if a well connected VM (the one from Sorin
has all DBs well configured but is badly connected and downloading is
really slow :( ) could be available to all committers, avoiding each one to
have to setup each database locally.
If you find it useful, I will maintain this script as much as possible, and
improve it further. I have already some idea like:
- automatically import a given XAR
- check logs, terminate and report issue automatically (to integrate with
Jenkins?)
- allow starting multiple version one after each others, testing migration
in one run
...
This is already more than a simple script (~500 lines), and well documented.
However, I do not found a good place to put such script in GitHub. IMO,
this script is like release scripts, it will be maintained by the dev team,
and it could became essentiel to the project, and I have conform as much as
a bash script could to our coding practices. Therefore I do not think that
putting it in xwiki-contrib is right. Release scripts should not even be
there, and need a place in a xwiki repositories IMO.
These are scripts that are never released nor compile or what ever. We have
already something similar in xwiki repositories: xwiki-debug-eclipse
I do not think it is nice to multiply repositories in xwiki, but there is a
need for unreleased but maintained codes like these.
I proposed that we create a new repository in XWiki to contains such codes,
and to put/move in it:
- xwiki-debug-eclipse
- xwiki-release-tools (for release scripts)
- xwiki-testing-tools (for the above script)
We may call this repository:
- xwiki-tools
- xwiki-utils
- xwiki-dev-tools
...
WDYT ?
--
Denis Gervalle
SOFTEC sa - CEO
eGuilde sarl - CTO
As promised for the curious, the options of my testing script:
Usage: xwikitest [OPTIONS]
Options:
-b backup.sql Backup database to the given file (or folder for
oracle) after shutdown.
-B backup.sql Backup current database to the given file, same as -b
-z -k -n
-d database Choose a database
(mysql-myisam,mysql-innodb,psql,oracle,hsqldb). Current is mysql-innodb.
-e distribution Choose a distribution (enterprise or manager).
Current is manager.
-i dump.sql Import the given sql dump in the database before
startup.
-I dump.sql Import the given sql dump in the database without
running, same as -i -z -n
-h Display this usage message. At the end, it shows your
current arguments and alone the defaults.
-k Do not clean the database before startup.
-n Do not start XWiki.
-p port Port for Jetty listening. Current is 7581.
-r snapshot Use given snapshot (ie: 20120410.161114-97). Default
to use release.
-s dbsuffix Database suffix for test isolation. Current is DenisG.
-t port Port for Jetty termination. Current is 7501.
-v version Choose a XWiki version. Current is 4.1.
-w Download from maven.xwiki.org. Default is to search
current folder.
-z Do not redeploy and reconfigure (use with care).
Hi, all,
I am using jQuery for javascript, since it is conflicting with prototype, I
use the jQuery help extension:
http://extensions.xwiki.org/xwiki/bin/view/Extension/jQuery+Helpers, so far
everything works fine on Firefox, the problem is the IE7, I got jQuery is
undefined error from the UI library: $xwiki.jsx.use("jQuery.jQueryUI"), I
can see the javascript code in firebug with last par of the code:
.bind("blur",h)})})})(jQuery);
I noticed that there is a ";" in the end, but in IE7, I checked the code
from Microsoft Script Editor when I debug, it shows no ";", not sure if
that is the problem.
In IE7, I clicked the jQuery helper extension demo pages:
bin/view/jQuery/Demo1 page and bin/view/jQuery/Demo2 page, they both gave
me "jQuery is undefined" error. so this error happens to the extension as
well.
Could anybody help me with is issue?
Thanks very much.
Dave
Hi devs,
In preparation of our Deprecation Day and continuing our vote on the Deprecation strategy I'd like to propose several rules we need to clarify since we need them and I'd like to finish documenting our full deprecation strategy.
Rule 1: Where are Legacy modules located?
===================================
* Proposal:
- Each Git repository needing legacy modules provides a *-legacy module for holding legacy modules. For example:
-- For Commons, xwiki-commons-core/xwiki-commons-legacy/
-- For Platform, xwiki-platform-core/xwiki-platform-legacy/
-- For Rendering, xwiki-rendering-legacy/
* Explanation:
- It's better to locate them in a specific module (*-legacy) than inside their own module (for ex in xwiki-commons-core/xwiki-commons-component/xwiki-commons-component-legacy/) because legacy modules are something we don't want to see as much as possible since we're must not use them in our code, thus it's logical to park them all together somewhere.
* Notes:
- This is our current rule but it's never been explicitly defined
Rule 2: What do Legacy modules contain?
=================================
* Proposal:
- Each Legacy module should replace the non-legacy module it corresponds to. This means that the user must have only 1 JAR for a given module: either its legacy version or it's non-legacy version but should never have both.
* Explanation:
- We need consistency. Right now we have oldcore which acts like this but others don't and it's complex to explain to users that for some they have to swap them and for others they have to keep both side by side
- In the very close future, we'll use a lot of Aspects in modules others than legacy-oldcore, and thus we'll need to apply this strategy anyway.
* Notes:
- Currently, only oldcore acts like this.
- The consequence is that we'll have one legacy module per non legacy modules. Right now we sometimes have one legacy module for several non legacy modules which we'll need to fix
Here's my +1 to both.
Thanks
-Vincent