Hi everyone,
I've staged the RC3 release on http://www.xwiki.org/10rc3/
It would be nice if some of you could quickly try it out (we'd like
to release ASAP) and let us know if it's working as expected. Once we
get a few confirmations we'll officially release it. We'd like to do
this tonight so that we can leave some time for users to install RC3
before we declare it the 1.0 finale version on next wednesday.
You can check the release notes on
http://www.xwiki.org/xwiki/bin/view/Main/ReleaseNotesXWiki10RC3
Thanks a lot
-Vincent (on behalf of the XWiki dev team)
Hi,
I'd like to remove the DataSource reference in web.xml (for 1.1 Beta 1):
<resource-ref>
<description>DB Connection</description>
<res-ref-name>jdbc/XWikiDS</res-ref-name>
<res-type>javax.sql.DataSource</res-type>
<res-auth>Container</res-auth>
</resource-ref>
it's defined in there but our default hibernate config doesn't use
it, so it's not used by default... but forces users using an app
server to create a fake DS as is described for example in the install
notes for Websphere and jboss.
We also need to document how to configure xwiki to use the app server
DS.
For example see:
http://mail-archive.objectweb.org/xwiki-dev/2005-06/msg00124.html
But I think our default should be the simplest possible ie without DS.
WDYT?
Thanks
-Vincent
Hi,
I'd like to propose a quick RC3 release before our final 1.0 release.
The reason is that we've found 2 important issues:
- one where absolute URLs in some wiki page can make the page hang
- another one for virtual wikis where users registered on the main
wiki cannot go to their profile page when logged in a child wiki
I propose to release RC3 tomorrow and to keep the same date for 1.0,
ie 2nd of May.
Reason is that I think it's better to promote a RC release as the
main release rather than risk release a 1.0 that hasn't been tried in
the real world out there. We're almost there now and better be safe
than sorry...
As this is an urgent matter, I propose to keep the vote till today
EOD only. We need at least 3 +1 votes to go ahead.
Here's my +1
Thanks
-Vincent
Hi Gilles,
On Apr 27, 2007, at 10:41 AM, Gilles Serasset wrote:
> Hi Vincent, Hi all,
>
> mmm, sorry, I just tried to figfure out the problems from the doc.
> There is a problem already here:
>
> First, the getXXX method do not return the same kind of info:
>
> getServletPath() - decoded
> getPathInfo() - decoded
> getRequestURI() - remain encoded
> getContextPath() - remain encoded
> getPathTranslated() - remain decoded
>
> You are using getServletPath which returns a decoded string when
> getRequestURI gives you a encoded string. Hence, if a non ascii
> char is used in the ServletPath, the length of the servletPath will
> be shorter than its encoded conterpart.
Yes this is a limitation and I assumed (probably wrongly) that
servlet path wouldn't contain non ascii chars. If we have a better
solution I'm all for it...
> Second, you don't have to fix the encoding anymore as it is not
> (incorrectly) decoded by the container. However, you have to decode
> it correctly using the java.net.URLDecoder class (and passing it
> you wiki encoding).
I don't understand what you're saying here. All I can say is that the
existing code wasn't working at all and it now works in all cases
I've tried except when the user enters non ascii chars directly in
the URL. Creating pages/links using XWiki works fine.
We discussed this with Sergiu and we'd like to modify xwiki so that:
- we assume that all URLs we get are URL encodings of UTF8 chars always
- when we generate URLs we UTF8 encode them (and then URL encode them)
> Third, in the case where you call getPathInfo, you should put:
>
> path = fixDecodedURI(request, request.getPathInfo());
This is what you had before but it wasn't working... That's what I
fixed :)
> Sorry, I'm teaching all day, so can't tell you more now...
Thanks
-Vincent
> Regards, Gilles,
> On 25 avr. 07, at 16:01, Vincent Massol wrote:
>
>> Hi Gilles (and everyone interested),
>>
>> I have modified today the XWiki.getDocumentName() method. I've
>> seen that you had modified it in the past to add the call to
>> fixDecodedURI(). I think it's no longer required but I'd like to
>> have your opinion on that.
>>
>> Here's the modified version:
>>
>> public String getDocumentName(XWikiRequest request, XWikiContext
>> context)
>> {
>> [...]
>> else {
>> // TODO: Introduce a XWikiURL class in charge of
>> getting the information relevant
>> // to XWiki from a request URL (action, space,
>> document name, file, etc)
>>
>> // Important: We cannot use getPathInfo() as the
>> container encodes it and different
>> // containers encode it differently, depending on
>> their internal behavior and how
>> // they are configured. Thus to make this container-
>> proof we use the
>> // getRequestURI() which isn't modified by the
>> container and is thus only
>> // URL-encoded.
>>
>> // Note: Ideally we should modify the
>> getDocumentNameFromPath method but in order
>> // not to introduce any new bug right now we're
>> reconstructing a path info that we
>> // pass to it using the following algorithm:
>> // path info = requestURI - (contextPath +
>> servletPath)
>> String path;
>> if (!request.getRequestURI().startsWith(
>> request.getContextPath() + request.getServletPath()))
>> {
>> log.warn("Request URI [" + request.getRequestURI()
>> + "] should have matched "
>> + "context path [" + request.getContextPath()
>> + "] and servlet path ["
>> + request.getServletPath() + "]");
>> // Even though this branch shouldn't get executed
>> we never know what containers
>> // will return and thus in order to be safe we
>> fall back to the previous
>> // behavior which was to use getPathInfo() for
>> getting the path (with the
>> // potential issue with i18n encoding as stated
>> above).
>> path = request.getPathInfo();
>> } else {
>> path = request.getRequestURI().substring(
>> request.getContextPath().length() +
>> request.getServletPath().length());
>> }
>>
>> // TODO: I think it's safe to remove the fixDecodedURI
>> now that we're not using
>> // getPathInfo() and thus the container doesn't encode
>> anything but I don't want
>> // to break anything at this late stage (we're
>> releasing 1.0 RC2). Remove it when
>> // we start working on 1.1.
>> docname =
>> getDocumentNameFromPath(fixDecodedURI(request,
>> path), context);
>> }
>> }
>> return docname;
>> }
>>
>> Thanks a lot
>> -Vincent
>
> --
> Gilles Sérasset
> GETALP-LIG BP 53 - F-38041 Grenoble Cedex 9
> Phone: +33 4 76 51 43 80 Fax: +33 4 76 44 66 75
>
>
Hi Vandan,
On Apr 27, 2007, at 8:18 AM, Vandan Parikh wrote:
> Hello everyone,
> I'm glad to be part of the XWiki GSoC group.
Glad to have you on board.
> However, I also had some other commitments and issues for the past
> few weeks.
> I'm planning to get acquainted with the code in the next week,
> however I may also have to deal with a laptop transition.
Make sure you read the docs on the Community space of xwiki.org.
There are plenty of useful information there.
> What environment do most people develop with? (Windows XP + Cygwin
> + Eclipse?)
For me: Mac OSX, IntelliJ IDEA
Ludovic: Windows XP, IntelliJ IDEA
Sergiu: Linux, IntelliJ IDEA
...
Note: We do have a free IntelliJ IDEA license for all development
done on XWiki (you're not allowed to use it on any other dev than
xwiki though). Let me know if you're interested and I'll send it to
you. Same applies for other GSoC students of course.
> On 4/24/07, Vincent Massol < vincent(a)massol.net> wrote:
> Hi Everyone,
>
> As we already said we're all excited to work with you as part of the
> GSoC. However, in order for this to work, we all need to make some
> efforts. The biggest effort that we need to make is good
> communication (this is what is required when working on any open
> source project). We have extended an invitation to you in the email
> below with very clear guidelines and next steps to perform.
>
> Out of the 7 GSoC students, only 3 have answered so far: Tharindu,
> Evelina and Radu. I think answering to our email is really the least
> everyone could do... Let's hope it was simply an oversight or that
> you were on holidays... :-)
>
> Indeed your success will be very much based on how you interact with
> the XWiki open source project and on your availability to discuss,
> reply to mails, work collaboratively, in pure open source fashion.
> Thus, let's start to communicate:
> - introduce yourself
> - tell us what your plans are, when you'll be able to start working
> on what feature
> - start asking questions
> - tell us what you don't understand in the process, in the dev tools,
> in the build, etc
> - suggest ideas
> - help with the xwiki.org documentation
> - etc
>
> One task that we need all of you to perform is (as described below)
> to familiarize yourself with the XWiki development process and team.
> For doing this we suggested that each of you take a few JIRA issues
> and start implementing them (after reading the docs on the community
> space of xwiki.org). So far, we have Evelina, Tharindu and Radu who
> have picked some issues. Remember that this is an official step, part
> of the GSoC programme and that is goes from the 12th of April till
> the 28th of May. Of course if some of you cannot do it right now for
> any reason (like you're on holiday, you're too busy, etc) then of
> course you should communicate it (remember: communication is
> everything!). How could we know otherwise?
>
> What we would like is that you submit patches for a few JIRA issues.
> We'll review these patches, comment on them, till they are the level
> of quality adequate so that they can be committed. This is very
> important because you'll probably make mistakes along the way and
> this is where you'll learn. If you don't do this, chance is that it's
> going to be real hard thereafter to apply any of your work. You
> should really familiarize with XWiki before starting head-on with
> your projects. It'll be easier afterwards if you understand how XWiki
> development works first.
>
> One other useful task that you'll need to perform for sending patches
> is learning how to build XWiki. Try to build XWiki from sources, try
> to debug it from your IDE. These are useful skills you'll need for
> later on.
>
> Last, we would welcome feedback on what we've proposed here and
> below. This is a learning process for us too. We're very interested
> in any feedback, how to make this GSoc 2007 even better, and we need
> your input too.
>
> Let's start communicating on the XWiki mailing lists! :)
>
> Thanks
> -Vincent on behalf of the XWiki SOC mentor team
>
> On Apr 13, 2007, at 11:08 PM, Vincent Massol wrote:
>
> > Hello XWiki Summer-of-Coders 2007,
> >
> > First of all, thank you for showing your interest in Open Source
> > development, and for choosing XWiki as the project which will get
> > you acquainted with this kind of development.
> >
> > [For all xwiki community members who don't know what the summer of
> > code is, check XWiki's SOC page on http://www.xwiki.org/xwiki/bin/
> > view/GoogleSummerOfCode/]
> >
> > The goal of the Summer of Code program is to introduce young
> > students like you in the fantastic world of Open Source. If you
> > only view this as a better paid summer job, then you can't be any
> > more wrong. Our mission, as your mentors, is to ease your
> > understanding of how things work, to help you learn new things you
> > won't be thought in school, to integrate you in a large and very
> > friendly community, and to help you understand how a very large
> > project is managed, planned, developed.
> >
> > Open Source is not only about the code. It is more about the
> > Community that participates in the development of the code. We, the
> > mentors, will do our best to introduce you in this community and
> > make you enjoy being part of it, so that when the summer ends, and
> > all your obligations as soc-ers cease to exist, you will want to
> > continue being part of our community. The most successful example
> > is that of Sergiu, who was a SoC student like you last year, and
> > now is a mentor for two of the accepted projects.
> >
> > Your job is a bit more difficult. You have to catch up with
> > hundreds of thousands of lines of code, learn about so many new
> > technologies, get used to a whole new way of working on a project,
> > get used to the many rules regarding project development that make
> > it survive the competition and become famous, AND write a not-so-
> > simple new component for XWiki. We know this is a difficult task to
> > achieve in less than 4 months, especially on your own, so we are
> > willing to offer any help we can provide.
> >
> > So, let's get started.
> >
> > 1. We need to know what your main email address is (the one you
> > check more often), so that we can reach you faster when needed.
> >
> > 2. We need to establish some rules regarding how you will interact
> > with the mentors and the community, and how you will develop your
> > code.
> >
> > First and foremost, working on XWiki needs to be fun and a good
> > learning process! However the XWiki project is already following
> > some development rules that we're asking SoC students to follow
> > too. This is for the good of the XWiki project but more importantly
> > it's a good way to learn how an open source community works and if
> > these practices are followed then it'll be much easier to integrate
> > the SoC student work into XWiki's official releases.
> >
> > So here are some practices we'd like SoC students to follow (please
> > comment on the list if you'd like to change some of them or propose
> > other things):
> >
> > * SoC students should be considered like any XWiki contributor
> > which means they should respect the same rules and which means they
> > are not committers on XWiki core. Note that a SoC student can
> > become a Committer in the same manner a contributor can become one.
> > * SoC students will be given commit access to the sandbox only,
> > where they'll create their project (one top level directory for
> > each project). For projects which need to modify some existing
> > code, JIRA issues will need to be created and patches attached.
> > It's important that patches be of good quality and small in order
> > to be applied quickly. Once sandbox projects reach a good level of
> > maturity (meaning they work and the code is of code quality,
> > documented, etc) then we'd like to migrate them to the main release
> > tree.
> > * SoC students should obey all Community rules. For example this
> > means:
> > o using the XWiki coding conventions
> > o using the defined communication channels: IRC and mailing
> list
> > * SoC students have time allocated to familiarize with XWiki
> > development process. As such we'd like each SoC student to pick one
> > or several existing issues in JIRA and send a patch that fixes it/
> > them before that period ends (from 12th of April to 28th of May)
> > This is a critical integration step to ensure all SoC students
> > understand how XWiki works and it's a chance to start asking
> > questions and get to know each other.
> > * SoC student should post a quick introduction on the xwiki dev
> > mailing list to explain who they are and what they're going to work
> > on.
> > * SoC student should always go to the list when communicating about
> > their project. They should use the XWiki IRC channel if they need
> > to talk to their mentors. The goal is that everyone in the XWiki
> > community help them, answer their questions, but also know what
> > they are doing. This will make patch applications and integration
> > of their work back into XWiki trunk easier later on. This is very
> > important and a criteria of success for the student. This is about
> > learning how open source works. Note that students can also CC
> > their mentor's email address if they want, but the mails have to go
> > to the XWiki dev list.
> > * SoC students should not block on anything for a long period of
> > time. They should ask plenty of questions on the list (but they
> > should also be autonomous!)
> >
> > These practices are also listed on http://www.xwiki.org/xwiki/bin/
> > view/GoogleSummerOfCode/
> >
> > 3. Here's what you need to do to get you started:
> >
> > a) You need to register on http://forge.objectweb.org/account/
> > register.php
> > ObjectWeb (or the OW2 Consortium, as it is known now) is an Open
> > Source software community, and XWiki is one of the many projects
> > belonging to this large "family". Mainly, it offers the same
> > facilities Sourceforge offers. This is where the source code is
> > hosted, and where the official mailing lists are hosted.
> > You have to remember the username and password, because later you
> > will use them for commiting code.
> >
> > b) You should subscribe to some of the mailing lists on http://
> > forge.objectweb.org/mail/?group_id=170 . We recommend that you
> > subscribe at least to xwiki-dev and xwiki-users.
> >
> > c) You need to register on http://jira.xwiki.org/jira/secure/Signup!
> > default.jspa
> > This is where the code management takes place. It is a repository
> > of known bugs, issues, planned new features or improvements. It
> > also offers some statistics and roadmaps regarding the project
> > evolution. Getting accustomed to using JIRA is a requirement.
> >
> > d) Download the XWiki source code. Follow the instructions on
> > http://www.xwiki.org/xwiki/bin/view/Community/SourceRepository
> > For the moment, you can only checkout the code using anonymous
> access.
> >
> > e) It will be very hard to understand the code by reverse
> > engineering. We know that the documentation is not our strong point
> > (on the contrary), but reading the guides on http://www.xwiki.org/
> > xwiki/bin/view/Main/Documentation will help a lot.
> >
> > f) Try to follow the discussions on JIRA and on the mailing lists.
> >
> >
> > We do know that you still have classes and exams, and we definitely
> > don't want you to disregard school, so take things easy, and don't
> > panic if something seems too difficult. Don't be shy, Open Source
> > communities are about communications and help.
> >
> > Good luck,
> >
> > -The XWiki SOC mentor team (Sergiu, Jeremi, Ludovic, Jean-Vincent,
> > Vincent)
> >
>
>
Hello XWiki Summer-of-Coders 2007,
First of all, thank you for showing your interest in Open Source
development, and for choosing XWiki as the project which will get you
acquainted with this kind of development.
[For all xwiki community members who don't know what the summer of
code is, check XWiki's SOC page on http://www.xwiki.org/xwiki/bin/
view/GoogleSummerOfCode/]
The goal of the Summer of Code program is to introduce young students
like you in the fantastic world of Open Source. If you only view this
as a better paid summer job, then you can't be any more wrong. Our
mission, as your mentors, is to ease your understanding of how things
work, to help you learn new things you won't be thought in school, to
integrate you in a large and very friendly community, and to help you
understand how a very large project is managed, planned, developed.
Open Source is not only about the code. It is more about the
Community that participates in the development of the code. We, the
mentors, will do our best to introduce you in this community and make
you enjoy being part of it, so that when the summer ends, and all
your obligations as soc-ers cease to exist, you will want to continue
being part of our community. The most successful example is that of
Sergiu, who was a SoC student like you last year, and now is a mentor
for two of the accepted projects.
Your job is a bit more difficult. You have to catch up with hundreds
of thousands of lines of code, learn about so many new technologies,
get used to a whole new way of working on a project, get used to the
many rules regarding project development that make it survive the
competition and become famous, AND write a not-so-simple new
component for XWiki. We know this is a difficult task to achieve in
less than 4 months, especially on your own, so we are willing to
offer any help we can provide.
So, let's get started.
1. We need to know what your main email address is (the one you check
more often), so that we can reach you faster when needed.
2. We need to establish some rules regarding how you will interact
with the mentors and the community, and how you will develop your code.
First and foremost, working on XWiki needs to be fun and a good
learning process! However the XWiki project is already following some
development rules that we're asking SoC students to follow too. This
is for the good of the XWiki project but more importantly it's a good
way to learn how an open source community works and if these
practices are followed then it'll be much easier to integrate the SoC
student work into XWiki's official releases.
So here are some practices we'd like SoC students to follow (please
comment on the list if you'd like to change some of them or propose
other things):
* SoC students should be considered like any XWiki contributor which
means they should respect the same rules and which means they are not
committers on XWiki core. Note that a SoC student can become a
Committer in the same manner a contributor can become one.
* SoC students will be given commit access to the sandbox only, where
they'll create their project (one top level directory for each
project). For projects which need to modify some existing code, JIRA
issues will need to be created and patches attached. It's important
that patches be of good quality and small in order to be applied
quickly. Once sandbox projects reach a good level of maturity
(meaning they work and the code is of code quality, documented, etc)
then we'd like to migrate them to the main release tree.
* SoC students should obey all Community rules. For example this means:
o using the XWiki coding conventions
o using the defined communication channels: IRC and mailing list
* SoC students have time allocated to familiarize with XWiki
development process. As such we'd like each SoC student to pick one
or several existing issues in JIRA and send a patch that fixes it/
them before that period ends (from 12th of April to 28th of May) This
is a critical integration step to ensure all SoC students understand
how XWiki works and it's a chance to start asking questions and get
to know each other.
* SoC student should post a quick introduction on the xwiki dev
mailing list to explain who they are and what they're going to work on.
* SoC student should always go to the list when communicating about
their project. They should use the XWiki IRC channel if they need to
talk to their mentors. The goal is that everyone in the XWiki
community help them, answer their questions, but also know what they
are doing. This will make patch applications and integration of their
work back into XWiki trunk easier later on. This is very important
and a criteria of success for the student. This is about learning how
open source works. Note that students can also CC their mentor's
email address if they want, but the mails have to go to the XWiki dev
list.
* SoC students should not block on anything for a long period of
time. They should ask plenty of questions on the list (but they
should also be autonomous!)
These practices are also listed on http://www.xwiki.org/xwiki/bin/
view/GoogleSummerOfCode/
3. Here's what you need to do to get you started:
a) You need to register on http://forge.objectweb.org/account/
register.php
ObjectWeb (or the OW2 Consortium, as it is known now) is an Open
Source software community, and XWiki is one of the many projects
belonging to this large "family". Mainly, it offers the same
facilities Sourceforge offers. This is where the source code is
hosted, and where the official mailing lists are hosted.
You have to remember the username and password, because later you
will use them for commiting code.
b) You should subscribe to some of the mailing lists on http://
forge.objectweb.org/mail/?group_id=170 . We recommend that you
subscribe at least to xwiki-dev and xwiki-users.
c) You need to register on http://jira.xwiki.org/jira/secure/Signup!
default.jspa
This is where the code management takes place. It is a repository of
known bugs, issues, planned new features or improvements. It also
offers some statistics and roadmaps regarding the project evolution.
Getting accustomed to using JIRA is a requirement.
d) Download the XWiki source code. Follow the instructions on http://
www.xwiki.org/xwiki/bin/view/Community/SourceRepository
For the moment, you can only checkout the code using anonymous access.
e) It will be very hard to understand the code by reverse
engineering. We know that the documentation is not our strong point
(on the contrary), but reading the guides on http://www.xwiki.org/
xwiki/bin/view/Main/Documentation will help a lot.
f) Try to follow the discussions on JIRA and on the mailing lists.
We do know that you still have classes and exams, and we definitely
don't want you to disregard school, so take things easy, and don't
panic if something seems too difficult. Don't be shy, Open Source
communities are about communications and help.
Good luck,
-The XWiki SOC mentor team (Sergiu, Jeremi, Ludovic, Jean-Vincent,
Vincent)
The XWiki development team team is pleased to announce the
availability of the 1.0 RC 2 release.
Go grab it on http://www.xwiki.org/xwiki/bin/view/Main/Download
This release is planned to the last before the final 1.0 release
(unless we find some important bugs in which case there'll be a RC3
release). The 1.0 release is still planned for end of April.
New in this release:
* Several important bugs fixed:
o PDF generation fails if a header text is repeated due to TOC
numbering in headings
o Filter conflict: external links can be rendered two times
o Generated heading id-s are not unique
o Save & Continue button switches you from the Global Rights
tab to the Preferences tab
o Levels and Users properties are saved with an extra empty value
o Fail to import a XAR exported with history
o Calling $xwiki.refreshLinks() do not seem to generate
backlinks for all pages
o XML content inside {code} macro is rendered in the WYSIWYG
editor
o Bug when deleting attachment with accent with XWiki in UTF-8
encoding
o Empty groups on XWiki.XWikiAllGroup, XWiki.XWikiAdminGroup
and XWiki.XWikiGroupTemplate
o Empty rights in Global Rights and in some spaces
o Missing PDF templates for new PDF export configuration feature
o Edition of a user do not show empty fields any more
o Only if in the style macro has icon parameter then apply
stylemacro class for the default value of class parameter.(to show
icon image)
o Do not display the register link if the current user do not
have the register right
o Global access levels are displayed in the local rights editor
o The editor (wiki and wysiwyg) textarea in new skin don't
fill 100% the editor panel
o Cannot create pages with non ASCII characters in the XWiki
standalone distribution
* Document that importing documents will replace the existing
versions and specially explain how to import XWiki user documents
* Improve documentation for the Attachment and Skins pages of the
User Guide
IMPORTANT: XWiki 1.0 RC 2 fixes an important security issue in past
releases where passwords were stored in clear in the database.
Passwords are now hashed. If you are upgrading from a previous
version, any new user or any password update will automatically get
the password hashed. However existing users who do not change their
passwords will still have their passwords in clear in the database.
Thus, we are providing a tool to automatically hash all passwords
from an existing database.
See the full release notes on http://www.xwiki.org/xwiki/bin/view/
Main/ReleaseNotesXWiki10RC2
Enjoy
-The XWiki development team
Hi everyone,
I've staged the RC2 release on http://www.xwiki.org/10rc2/
It would be nice if some of you could quickly try it out (we'd like
to release ASAP) and let us know if it's working as expected. Once we
get a few confirmations we'll officially release it.
You can check the release notes on
http://www.xwiki.org/xwiki/bin/view/Main/ReleaseNotesXWiki10RC2
Thanks a lot
-Vincent (on behalf of the XWiki dev team)
Hi Gunter,
On Apr 25, 2007, at 3:51 PM, Gunter Leeb wrote:
> Hi Vincent,
>
> I have just tried it, but with the same or similar exception. I have
> replaced the xwiki.jar and restartet. I would like to send you a log
> file, also to confirm that it is really picking up all your changes.
> Would you please send me a log4j.properties configured so you can see
> all the aspects that you need.
>
> Also, maybe it is relevant, but the pages got migrated from an old
> 0.9.940 (?) installation.
Thanks for trying it. Let's try to debug this... I think we can
follow 2 leads:
1) In your patched version of RC1, can you try creating a new page
with accents and then delete/rename it?
2) I'd like to reproduce your problem. Could you give me more
information about your setup (i18n setup, database and container) and
possibly it would be nice if you could send me a XAR export of your
wiki (not the whole thing, maybe only a few pages) so that I can try
it here. Could you also let me know exactly the steps you're performing?
Thanks
-Vincent
PS: I'm ccing the dev list so that others can join us in debuggin this.
>
> Regards,
>
> Gunter
>
>>>> Vincent Massol <vincent(a)massol.net> 25.04.2007 14:30 >>>
> Hi Gunter,
>
> I'm doing the release of XWiki 1.0 RC2 this afternoon and your bug
> was one that I wanted to check out before releasing RC2. I don't know
>
> if you've seen but I have commented on http://jira.xwiki.org/jira/
> browse/XWIKI-1139.
>
> Do you think you could give it a quick try with the new JAR I've
> uploaded for you?
>
> Thanks a lot
>
> -Vincent Massol
> XWiki release manager
Hi Gilles (and everyone interested),
I have modified today the XWiki.getDocumentName() method. I've seen
that you had modified it in the past to add the call to fixDecodedURI
(). I think it's no longer required but I'd like to have your opinion
on that.
Here's the modified version:
public String getDocumentName(XWikiRequest request, XWikiContext
context)
{
[...]
else {
// TODO: Introduce a XWikiURL class in charge of getting
the information relevant
// to XWiki from a request URL (action, space, document
name, file, etc)
// Important: We cannot use getPathInfo() as the
container encodes it and different
// containers encode it differently, depending on their
internal behavior and how
// they are configured. Thus to make this container-
proof we use the
// getRequestURI() which isn't modified by the container
and is thus only
// URL-encoded.
// Note: Ideally we should modify the
getDocumentNameFromPath method but in order
// not to introduce any new bug right now we're
reconstructing a path info that we
// pass to it using the following algorithm:
// path info = requestURI - (contextPath + servletPath)
String path;
if (!request.getRequestURI().startsWith(
request.getContextPath() + request.getServletPath()))
{
log.warn("Request URI [" + request.getRequestURI() +
"] should have matched "
+ "context path [" + request.getContextPath() +
"] and servlet path ["
+ request.getServletPath() + "]");
// Even though this branch shouldn't get executed we
never know what containers
// will return and thus in order to be safe we fall
back to the previous
// behavior which was to use getPathInfo() for
getting the path (with the
// potential issue with i18n encoding as stated above).
path = request.getPathInfo();
} else {
path = request.getRequestURI().substring(
request.getContextPath().length() +
request.getServletPath().length());
}
// TODO: I think it's safe to remove the fixDecodedURI
now that we're not using
// getPathInfo() and thus the container doesn't encode
anything but I don't want
// to break anything at this late stage (we're releasing
1.0 RC2). Remove it when
// we start working on 1.1.
docname =
getDocumentNameFromPath(fixDecodedURI(request,
path), context);
}
}
return docname;
}
Thanks a lot
-Vincent
Hello Developers
i am working on a REST remote control for xwiki, based on an idea from
Sergiu Dumitriu.
The idea is to leave xwiki authorisation where it is (it works fine, as
far as i can see), and have synchronized user and group data, as well as
space acces rights.
The drawbacks of this approach have been pointed out by Sergiu: updates
and deletions (group membership, group right per space etc.) everything
but easy to maintain.
Nevertheless, it appears to be doable, and until the decision is made,
which SSO xwiki will use in 1.1 / 2.0, i will continue this way.
Two questions regarding acces rights:
1:
When i have 2 groups aTeam and bTeam, and two spaces aSpace and bSapce,
and each space has access rights entry that disallow viewing aSpace for
everyone but admins and aTeam members (same for bTeam/bSpace):
Why do bTeam members still see the aSpace in the right hand panel?
bTeam members do *not* have access to the aSpace base page, created when
creating aSpace, but an unresolved velocity fragment appears after
trying to acces bSpace pages as aTeam member, vice versa.
Is it correct, that it says "Web Home" in the panel instead of the title
the spaces' default pages?
2:
When adding new members to a group there is a strange beahviour,
sometimes: instead of group member names after adding a user to the
group, there is "Web Home".
Why this?
And is this fixed in RC1:
http://mail-archive.objectweb.org/xwiki-users/2006-02/msg00103.html
or do i have to add a
$xwiki.flushCache()
in a page, that is called each time groups are updated?
I hope you can help wiht that topic, as a proper space access depending
on group membership is a crucial function if you intend to use a wiki
with a high number of users.
Yours
Thomas Krämer
Hi,
As we're getting closer to the 1.0 release we need to start thinking
about the 1.1 goals.
Things I'd like to propose for 1.1:
------------------------------------------
Note 1: I proposed a few weeks ago that we should a main release
every 3-4 months, with beta releases every 2-3 weeks. I didn't get
much answer and I concluded that it was ok for most of you. So we
need to consider that time frame in mind for deciding the overall
goal of the 1.1 release. Let's not be too ambitious...
Note 2: The points below are listed by order of importance to me
1) There are still 108 bugs in JIRA. As a consequence I think one
main goal of 1.1 is going to be the consolidation of 1.0.
2) Focus on making the default wiki a wiki that is a good as the
wikis out there. This includes improvements to the look & feel/skin
and to its usability. I don't think we need more features, we just
need each feature to be better implemented: more polished, more
intuitive, more documented, nicer looking.
3) Start introducing XWiki 2.0 architecture elements in it. Even
though XWiki 2.0 will probably be done in a separate branch I think
we should start backporting stuff that'll be done in that branch to
1.1 when possible.
4) Switch to a Maven2 build
WDYT and what would you want to see in the 1.1 release?
Thanks
-Vincent
Hi,
MadOtis on IRC told me that users he had created with a staged RC1
version cannot see the Main/WebHome page even though they have the
correct rights set up. Only new users created with the new RC1 can.
I haven't reviewed the last changes we did in the released RC1 but we
need to verify if this is a problem with users created in past betas
and if so add some instructions in the release notes for migrating
old users so that they work.
Sergiu, maybe you know what the issue is?
Thanks
-Vincent
Hi committers,
I see that we're now quite good at putting jira references in our
first commits. That's good! However sometimes when we make a mistake,
or forget something to commit, we don't put again the reference to
the JIRA issue in the subsequent commits.
It would be better if we were always putting the reference to JIRA.
For example, I fixed something related to XWIKI-49 this morning and I
used the following format:
"
XWIKI-49: PDF generation failed with vietnamese characters encoded in
UTF-8
* Replaced SNAPSHOT by a timestamped version so that the build can be
reproduced and so that we can perform a release of RC2 tomorrow.
* Moved out the JTidy <dependency> as it was now wrongly in the
"custom xwiki repository" section.
* Removed JTidy from our custom XWiki repository
"
Why do we need this?
Because it then makes it very easy later on to find what happened
related to a JIRA issue. We had this need for example when we were
trying to find out the difference between 2 branches (you may
remember, I spent a whole day on that a month ago). Thanks to the
Subversion plugin in JIRA we can see what happens related to an
issue. For example:
http://jira.xwiki.org/jira/browse/XWIKI-49?
page=com.atlassian.jira.plugin.ext.subversion:subversion-commits-
tabpanel
However that only works if we have put a reference to the jira issue
in the commit log.
Thanks
-Vincent
Hi Sergiu,
Just to let you know it's dangerous to depend on a snapshot version
as it means anytime they update their snapshot we'll get the update
so our build can start to fail at any time. Also, we cannot release
XWiki if we have snapshot versions (at least that's the maven
strategy and maven will even prevent you from doing a release) so
we'll need to fix before we release 1.1 B1.
I see Hibernate has used some timestamped versions, maybe we could do
the same or use their versions:
http://repo1.maven.org/maven2/org/hibernate/jtidy/
Thanks
-Vincent
On Apr 24, 2007, at 4:25 AM, Sergiu Dumitriu wrote:
> Author: sdumitriu
> Date: 2007-04-24 04:25:11 +0200 (Tue, 24 Apr 2007)
> New Revision: 2972
>
> Modified:
> xwiki/trunk/pom.xml
> Log:
> Adding the JTidy maven repository to the list of known repos.
>
>
>
> Modified: xwiki/trunk/pom.xml
> ===================================================================
> --- xwiki/trunk/pom.xml 2007-04-24 01:57:38 UTC (rev 2971)
> +++ xwiki/trunk/pom.xml 2007-04-24 02:25:11 UTC (rev 2972)
> @@ -55,6 +55,14 @@
> <enabled>true</enabled>
> </releases>
> </repository>
> + <repository>
> + <id>jtidy</id>
> + <name>JTidy Maven2 Remote Repository</name>
> + <url>http://jtidy.sourceforge.net/snapshots/</url>
> + <releases>
> + <enabled>true</enabled>
> + </releases>
> + </repository>
> </repositories>
> </project>
>
> \ No newline at end of file
Ludovic,
Do we already have an issue associated with this?
Thanks
-Vincent
On Apr 24, 2007, at 3:39 AM, Ludovic Dubost wrote:
> Author: ludovic
> Date: 2007-04-24 03:38:37 +0200 (Tue, 24 Apr 2007)
> New Revision: 2970
>
> Modified:
> xwiki/branches/XWIKI_1_0/core/src/main/java/com/xpn/xwiki/user/
> impl/xwiki/MyPersistentLoginManager.java
> Log:
> Fixed regression on cleanup impacting rememberme cookie
>
>
> Modified: xwiki/branches/XWIKI_1_0/core/src/main/java/com/xpn/xwiki/
> user/impl/xwiki/MyPersistentLoginManager.java
> ===================================================================
> --- xwiki/branches/XWIKI_1_0/core/src/main/java/com/xpn/xwiki/user/
> impl/xwiki/MyPersistentLoginManager.java 2007-04-24 01:36:29 UTC
> (rev 2969)
> +++ xwiki/branches/XWIKI_1_0/core/src/main/java/com/xpn/xwiki/user/
> impl/xwiki/MyPersistentLoginManager.java 2007-04-24 01:38:37 UTC
> (rev 2970)
> @@ -38,7 +38,7 @@
> * Class responsible for remembering the login information between
> requests. It uses (encrypted)
> * cookies for this. The encryption key is stored in xwiki.cfg,
> xwiki.authentication.encryptionKey
> * parameter.
> - *
> + *
> * The cookies used are:
> * <dl>>
> * <dt>username</dt>
> @@ -54,7 +54,7 @@
> * xwiki.authentication.useip . The secret parameter is specified in
> * xwiki.authentication.validationKey</dd>
> * </dl>
> - *
> + *
> * @version $Id: $
> */
> public class MyPersistentLoginManager extends
> DefaultPersistentLoginManager
> @@ -97,7 +97,7 @@
>
> /**
> * Setter for the {@link #cookieDomains} parameter.
> - *
> + *
> * @param cdlist The new value for {@link #cookieDomains}.
> * @see #cookieDomains
> */
> @@ -108,7 +108,7 @@
>
> /**
> * Setter for the {@link #cookiePath} parameter.
> - *
> + *
> * @param cp The new value for {@link #cookiePath}.
> * @see #cookiePath
> */
> @@ -119,7 +119,7 @@
>
> /**
> * Setup a cookie: expiration date, path, domain + send it to
> the response.
> - *
> + *
> * @param cookie The cookie to setup.
> * @param sessionCookie Whether the cookie is only for this
> session, or for a longer period.
> * @param cookieDomain The domain for which the cookie is set.
> @@ -140,7 +140,7 @@
>
> /**
> * Remember a specific login using cookies.
> - *
> + *
> * @param request The servlet request.
> * @param response The servlet response.
> * @param username The username that's being remembered.
> @@ -177,7 +177,7 @@
> setupCookie(passwdCookie, sessionCookie, cookieDomain,
> response);
>
> // Remember me
> - Cookie rememberCookie = new Cookie(COOKIE_REMEMBERME,
> sessionCookie + "");
> + Cookie rememberCookie = new Cookie(COOKIE_REMEMBERME, !
> sessionCookie + "");
> setupCookie(rememberCookie, sessionCookie, cookieDomain,
> response);
>
> if (protection.equals(PROTECTION_ALL) || protection.equals
> (PROTECTION_VALIDATION)) {
> @@ -202,7 +202,7 @@
> /**
> * Sets the maximum age for cookies. The maximum age is
> configured in xwiki.cfg using the
> * xwiki.authentication.cookielife parameter (number of days).
> The default age is 14 days.
> - *
> + *
> * @param cookie The cookie for which the expiration date is
> configured.
> */
> private void setMaxAge(Cookie cookie)
> @@ -218,7 +218,7 @@
>
> /**
> * Adds a cookie to the response.
> - *
> + *
> * @param response The servlet response.
> * @param cookie The cookie to be sent.
> */
> @@ -235,7 +235,7 @@
> * Compute the actual domain the cookie is supposed to be set
> for. Search through the list of
> * generalized domains for a partial match. If no match is
> found, then no specific domain is
> * used, which means that the cookie will be valid only for
> the requested domain.
> - *
> + *
> * @param request The servlet request.
> * @return The configured domain generalization that matches
> the request, or null if no match is
> * found.
> @@ -261,10 +261,10 @@
> /**
> * Get validation hash for the specified parameters. The hash
> includes a secret password, and
> * optionally binds the cookie to the requester's IP.
> - *
> + *
> * The hash secret is configured using the
> xwiki.authentication.validationKey parameter. The IP
> * binding is enabled using the xwiki.authentication.useip
> parameter.
> - *
> + *
> * @param username The remembered username.
> * @param password The remembered password.
> * @param clientIP The client IP of the request.
> @@ -319,7 +319,7 @@
> /**
> * Encrypt a string. The encryption is password-based. The
> password can be configured using the
> * xwiki.authentication.encryptionKey parameter.
> - *
> + *
> * @param clearText The text to be encrypted.
> * @return clearText, encrypted.
> * @todo Optimize this code by creating the Cipher only once.
> @@ -351,7 +351,7 @@
>
> /**
> * Forget a login by removing the authentication cookies.
> - *
> + *
> * @param request The servlet request.
> * @param response The servlet response.
> */
> @@ -369,7 +369,7 @@
> * Given an array of cookies and a name, this method tries to
> find and return the cookie from
> * the array that has the given name. If there is no cookie
> matching the name in the array, null
> * is returned.
> - *
> + *
> * @param cookies The list of cookies sent by the client.
> * @param cookieName The name of the cookie to be retrieved.
> * @return The requested cookie, or null if no cookie with the
> given name was found.
> @@ -389,7 +389,7 @@
>
> /**
> * Remove a cookie.
> - *
> + *
> * @param request The servlet request.
> * @param response The servlet response.
> * @param cookieName The name of the cookie that must be removed.
> @@ -411,7 +411,7 @@
>
> /**
> * Check if a text is supposed to be an affirmative value
> ("true", "yes" or "1").
> - *
> + *
> * @param text The text to check.
> * @return true if the text is one of "true", "yes" or "1",
> false otherwise.
> */
>
>
>
> --
> You receive this message as a subscriber of the xwiki-
> commits(a)objectweb.org mailing list.
> To unsubscribe: mailto:xwiki-commits-unsubscribe@objectweb.org
> For general help: mailto:sympa@objectweb.org?subject=help
> ObjectWeb mailing lists service home page: http://www.objectweb.org/
> wws
Hi,
We have lots of jira tasks scheduled for 1.1 but I don't think that's
right. According to our new strategy we're only scheduling issues
that we know we want to do in a given release. I think we've used 1.1
in the past as a way to say "later". But we have "future" for this
now. So I'd like to move all the tasks in 1.1 into "Future" if that's
ok with you.
Let me know.
Note: We also need to continue moving the issues that have no "fix
for" set (unscheduled issues). There are 76 of these.
Thanks
-Vincent
Hi everyone,
As release manager of the 1.0 version I'd like everyone's input on
any important pending issues that you may know and that would need to
be in the 1.0 release. As you've seen we've released RC1 yesterday.
We'd now like to release the 1.0 version in one or two weeks
depending on issues that need to be fixed.
I've already listed one issue in JIRA for 1.0:
* XWIKI-1107: XML content inside {code} macro is rendered in the
WYSIWYG editor
http://jira.xwiki.org/jira/browse/XWIKI-1107
Any other?
Thanks
-Vincent
Hi,
For XWiki 1.1 I'd like to separate XWiki's configuration files from
the generated WAR.
What I mean by configuration files: xwiki.cfg, hibernate.cfg.xml,
xwiki.hbm, feeds.hbm and possibly some others.
Rationale:
1) It would be nice to release different already made configurations
for XWiki: for HSQLDB, for MySQL, for Oracle, with a minimal list of
plugins configured, with all plugins enabled, with virtual wiki set
up, etc. It's going to be way better to release a single WAR that is
the same for all configs and a set of config files separately. This
also makes it much easier in the build process.
2) It's currently a little bit of a pain for users when they upgrade
their xwiki installation to a newer version. They have to remember to
save their config files, to unpack the XWiki WAR, modify the
configuration files, etc. What if an upgrade was a simple as dropping
the new WAR file in the webapps/ directory of your servlet container? :)
Thus I'd like to propose the following strategy:
* XWiki looks for where the config files are stored using the
following algorithm:
1) first it checks if a system property has been defined (say for
example "xwiki.configuration.directory")
1) if not, it checks if a location has been specified in the
web.xml file (as an init parameter)
2) if not found, it checks if the files can be found at the root
of the classpath (e.g. "/xwiki.cfg")
* The standalone distribution contains an already configured
directory structure which uses the system property strategy for
finding the configuration directory.
<further future - but not too far as it's the best solution I think>
We should propose a configuration wizard application which is in
charge of generating xwiki configuration files. I propose the
following distribution channels:
- as a webapp wizard configured on xwiki.org. Users use forms to
select what they want (which plugin, virtual wiki or not, etc). It
generate the files that can be downloaded by the users. Actually this
can even be implemented as a XWiki Application... ;-) Eating our dog
food they said...
- as a webapp wizard released inside the default WAR and that is
activated automatically if no configuration is found, i.e. the first
time XWiki is started. This is really by far the best I believe.
</further future>
WDYT?
Thanks
-Vincent
With RC1 lucene seems to work again, so i have costumized the existing search
form from jkraemer
(http://www.jkraemer.net/static/maven/xwiki/plugins/lucene-plugin/install.ht…)
But keep attention: it's just a quick&dirty example to display the results
in a table ;-)
As im not very familiar with velocity, the code is quite ugly! (for example
i didn't find a while loop to output the number of stars for score-quality,
so i did it with if, if, if..)
it still has some bugs:
* if you search for a regular expression (e.g. win*), then the query for the
next page will be win</strong>
* non wiki-documents and non-attachments will be hidden from the results, so
it could happen that you see an empty page with a link to the next results
(that's because searchresults.hitcount returns all results, also the hidden
ones..)
* many more..
* icons are hard-coded.. (/skins/lgs/*.png)
You can get the icons for free from famfamfam:
http://www.famfamfam.com/lab/icons/silk/
---------------------------
Searchform.vm:
1 Search
#set($query = $request.getParameter("text"))
#if(!$query)
#set($query = "")
#end
#warning("This is the new lucene search engine.\\
If you experience any problems, try to use the default xwiki
[Search>WebSearch?text=$query]..")
#set($itemsPerPage = "30")
#set($doRebuild = $request.getParameter("rebuild"))
#if($doRebuild=="yes")
#set($lucene = $xwiki.getPlugin("lucene"))
#if($lucene)
#set($documentCount = $lucene.rebuildIndex($xwiki,$context))
#if(${documentCount}>=0)
Started index rebuild with $documentCount documents. Will take some time
depending on the number of pages/attachments.
#else
Index rebuild failed.
#end
#end
#else
#if($xwiki.hasAdminRights())
[rebuild Index>${doc.web}.${doc.name}?rebuild=yes]
#end
#end
{pre}
<form action="$doc.name" method="post">
<input type="text" name="text" value="$query" />
<input type="submit" value="Search"/>
</form>
{/pre}
#if($query != "")
#set($lucene = $xwiki.getPlugin("lucene"))
#if($lucene)
#set($wikinames = "xwiki")
#set($languages = "default,en,de")
#set($firstIndex = $request.getParameter("firstIndex"))
#if(!$firstIndex)
#set($firstIndex = "1")
#end
#set($searchresults = $lucene.getSearchResults($query, $wikinames,
$languages, $xwiki))
#set($results = $searchresults.getResults($firstIndex,$itemsPerPage))
#if($results.size()>0)
#set($lastIndex=$searchresults.getEndIndex($firstIndex, $itemsPerPage))
#if($searchresults.hitcount==1)
##{pre} $msg.get("oneresult"):{/pre}
#else
##{pre}$msg.get("results") $firstIndex - $lastIndex $msg.get("of")
${searchresults.hitcount}:{/pre}
#if($searchresults.hasPrevious($firstIndex))
[previous
page>${doc.web}.${doc.name}?text=$query&firstIndex=$searchresults.getPreviousIndex($firstIndex,$itemsPerPage)]
#end
#if($searchresults.hasNext($firstIndex,$itemsPerPage))
[next
page>${doc.web}.${doc.name}?text=$query&firstIndex=$searchresults.getNextIndex($firstIndex,$itemsPerPage)]
#end
#end
<table width="100%" class="grid" cellSpacing=0 cellpadding="5" border="1">
<tr>
<th>Result</th>
<th width="100">Date</th>
<th width="150">Last Author</th>
<th width="100">Score</th>
</tr>
#foreach($result in $results)
#if($result.type=='wikipage')
<tr>
#if($xwiki.isVirtual())
<td align=left>[${result.wiki}:${result.web}.${result.name}]</td>
#else
<td align=left>[${result.web}.${result.name}]</td>
#end
<td>$xwiki.formatDate($result.date, "d. MMM yyyy")</td>
<td>$xwiki.getUserName($result.author)</td>
<td>
#set($resval=$result.score*100)
#if($resval>10)
/xwiki/skins/lgs/16-star-hot.png
#end
#if($resval>25)
/xwiki/skins/lgs/16-star-hot.png
#end
#if($resval>50)
/xwiki/skins/lgs/16-star-hot.png
#end
#if($resval>70)
/xwiki/skins/lgs/16-star-hot.png
#end
#if($resval>90)
/xwiki/skins/lgs/16-star-hot.png
#end
${resval}%
</td>
</tr>
#elseif($result.type=='attachment')
<tr>
<td align=left> ${result.url} /xwiki/skins/lgs/disk.png
${result.filename} \\
Attachment of [${result.web}.${result.name}]</td>
<td>$xwiki.formatDate($result.date, "d. MMM yyyy")</td>
<td>$xwiki.getUserName($result.author)</td>
<td>
#set($resval=$result.score*100)
#if($resval>10)
/xwiki/skins/lgs/16-star-hot.png
#end
#if($resval>25)
/xwiki/skins/lgs/16-star-hot.png
#end
#if($resval>50)
/xwiki/skins/lgs/16-star-hot.png
#end
#if($resval>70)
/xwiki/skins/lgs/16-star-hot.png
#end
#if($resval>90)
/xwiki/skins/lgs/16-star-hot.png
#end
${resval}%
</td>
</tr>
#end
</tr>
#end
#else
$msg.get("noresults")
#end
</table>
\\
#else
lucene plugin not found
#end
#end
--
View this message in context: http://www.nabble.com/Costumized-Lucene-Search-Page-tf3605463.html#a10073014
Sent from the XWiki- Dev mailing list archive at Nabble.com.
Hi all,
In user/impl/xwiki/XWikiAuthServiceImpl.java i read:
protected String findUser(String susername2, XWikiContext context)
throws XWikiException {
String susername = susername2.replaceAll(" ", "");
susername = susername.replaceAll(" ", "");
[...]
Why are we calling replaceAll method called twice ? It seems useless,
what have I missed ?
Thanks,
Pablo