On Jan 23, 2007, at 4:53 PM, Sergiu Dumitriu wrote:
> I think we should revert this in the B3 branch, since it is
> experimental code. For the trunk, it's your call. I'll fix it as
> soon as I can.
ok. I think we should revert it both for the trunk and for the B3
branch. The reason is that some people are using the trunk (like
curriki for example) and this is breaking them.
Sergiu, could you please revert this change on both the trunk and the
B3 branch (and update the jira issue accordingly)?
Thanks
-Vincent
>
> On 1/23/07, Vincent Massol <vincent(a)massol.net> wrote:
> Hi Sergiu,
>
> Ludovic has noticed several important issues with beta 3. Apparently
> this is cause by a modification you made, see http://
> svn.forge.objectweb.org/cgi-bin/viewcvs.cgi/xwiki/xwiki/trunk/core/
> src/main/java/com/xpn/xwiki/XWiki.java?r2=1946&r1=1944&rev=1946
>
> Apparently there are some data loss happening, some strange stuff
> with history, some panels do not work anymore (the Add Object panel
> doesn't work for example).
>
> Ludovic is suggesting we rollback this change.
>
> WDYT?
>
> Thanks
> -Vincent
>
> PS: I'm holding of the release till this is resolved.
>
>
>
>
> ______________________________________________________________________
> _____
> Yahoo! Mail réinvente le mail ! Découvrez le nouveau Yahoo! Mail et
> son interface révolutionnaire.
> http://fr.mail.yahoo.com
>
>
Hi,
I've noticed that the java files for the Lucene plugin have a header
like this:
/*
*
* ===================================================================
*
* Copyright (c) 2005 Jens Krämer, All rights reserved.
*
* This program is free software; you can redistribute it and/or
* modify it under the terms of the GNU General Public License
* as published by the Free Software Foundation; either version 2
* of the License, or (at your option) any later version.
*
* This program is distributed in the hope that it will be useful,
* but WITHOUT ANY WARRANTY; without even the implied warranty of
* MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
* GNU General Public License for more details, published at
* http://www.gnu.org/copyleft/gpl.html or in gpl.txt in the
* root folder of this distribution.
*
* Created on 01.02.2005
*
I don't think we should include code that is 1/ copyrighted to
someone else and 2/ GPL
We should ask Jens Kramer to donate the code to the XWiki project
under the XWiki copyright and under a LGPL license.
Who can do this?
Thanks
-Vincent
___________________________________________________________________________
Yahoo! Mail réinvente le mail ! Découvrez le nouveau Yahoo! Mail et son interface révolutionnaire.
http://fr.mail.yahoo.com
Hi all,
We are looking for wiki solution. Your XWiki looks impressive but we have one question.
We need authentication from LDAP and also handling the groups and user privileges from LDAP. We saw on JIRA [#XWIKI-330] issue (new feature) about that. Is someone taking any progress regarding this or do you know when this kind of feature is going to be in you software?
Regards Sasa.
Hi Ludovic,
Sorry I'm late on this (was on holiday). See below
On Mar 9, 2007, at 6:44 PM, Ludovic Dubost wrote:
>
> Hi,
>
> I'm in the process of finishing an XWiki Google Web Toolkit API
> (server-side and client-side).
> I'd like to commit that one in the core including the Java code
> that is
> compiled to Javascript. There is common code for both.
> Curriki will also rely on this API.
> It is not necessary that the build system compiles the code to
> Javascript for the moment, however it is needed to compile the
> server code.
>
> Currently I suggest commiting the code in:
>
> web/standard/src/main/java/api
> or
> web/standard/src/main/java/com.xpn.xwiki.gwt.api
>
I suggest committing this in a new module in xwiki/xwiki/trunk/web/gwt
One reason is that it's not going to work for m2 where you have
currently committed it (in standard/). We won't be able to use the
gwt maven2 plugin there.
Also it's cleaner to separate it from the rest. This is the general
direction for the build: separate different "features" into different
build modules for a better modularity.
Here's how I see it working with m2:
* The gwt m2 plugin generates the javascript from the java files in
the generate-sources build phase
* We use the WAR plugin in gwt/ to wrap both the server java classes
and the generated js into one WAR
* We then use the WAR overlay feature of the WAR plugin in standard/
to add the gwt WAR.
Please let me all know if you're ok with this and I'll do the move.
> I also have a Google Web Toolkit client for the FeedPlugin. It's a
> very
> cool RSS Aggregator interface.
> It's only client side code. I'm not sure if it should be commit in
> the core.
I don't think it should be in the core but for now I'd rather we have
it in a separate module in web/rssreader. Again the idea is to use
the m2 plugin to generate a WAR overlay for the standard WAR.
In the future we need to think how to externalize this in the same
way as we're externalizing plugins in xwiki-plugins. We can probably
consider it as a XWiki Application in the same manner as we have
Blog, Calendar, etc applications. We need a xwiki-applications
directory for these (different from the current xwiki-applications
which is for applications like Curriki sitting on top of XWiki). Then
when we build the default wiki we'll include several of these
applications in it and we'll also release them as XARs.
Again let me know about the creation of the rssreader module and I'll
do it.
> If it is it would be in
>
> web/standard/src/main/java/rssreader
> or
> web/standard/src/main/java/com.xpn.xwiki.gwt.reader
>
> Can we vote for these 2 things:
>
> - commit the API
> - commit the RSS Reader
See above.
Thanks
-Vincent
Hi,
One user spammed our jira yesterday (user name: "marie"). I've
removed the spam comments she left and removed the user from JIRA.
-Vincent
___________________________________________________________________________
Yahoo! Mail r�invente le mail ! D�couvrez le nouveau Yahoo! Mail et son interface r�volutionnaire.
http://fr.mail.yahoo.com
Hi Sergiu,
Ludovic has noticed several important issues with beta 3. Apparently
this is cause by a modification you made, see http://
svn.forge.objectweb.org/cgi-bin/viewcvs.cgi/xwiki/xwiki/trunk/core/
src/main/java/com/xpn/xwiki/XWiki.java?r2=1946&r1=1944&rev=1946
Apparently there are some data loss happening, some strange stuff
with history, some panels do not work anymore (the Add Object panel
doesn't work for example).
Ludovic is suggesting we rollback this change.
WDYT?
Thanks
-Vincent
PS: I'm holding of the release till this is resolved.
___________________________________________________________________________
Yahoo! Mail r�invente le mail ! D�couvrez le nouveau Yahoo! Mail et son interface r�volutionnaire.
http://fr.mail.yahoo.com
On Nov 15, 2006, at 1:05 PM, Ludovic Dubost wrote:
>
> Great.. this is what we need.. Can we have this on xwiki.org ?
Done: http://www.xwiki.org/xwiki/bin/view/Community/DevelopmentProcess
-Vincent
>
> Ludovic
>
> Vincent Massol a écrit :
> > Hi XWiki committers,
> >
> > I'd like to suggest one good practice when developing with JIRA:
> whenever
> > someone commits something to SVN he/she has to put the reference
> to the JIRA
> > issue # in the commit message. Of course this shouldn't be done
> for any
> > trivial things like adding a small javadoc, renaming a single
> variable,
> > cosmetic changes, svn ignore, etc.
> >
> > The strategy goes like this:
> >
> > * When you plan to work on something, create a jira issue and
> assign it to
> > yourself
> > * Implement it
> > * Commit it with the jira issue #
> > * Close the jira issue
> >
> > Another acceptable variation is:
> >
> > * Implement something
> > * When you want to commit it you realize you don't have any jira
> issue to
> > put in the commit message so don't commit
> > * Create the jira issue
> > * Commit
> >
> > The rationale behind this:
> >
> > * One consistent way to manage our work (this is different from
> now where
> > sometimes it's in jira and sometimes it's not). It also means
> there's no
> > unaccounted work, meaning I can go to jira and query it and I'll
> see what
> > everyone has been working on.
> > * Automated release notes/change logs. When we release a version
> we can
> > simply do a jira extract and it'll give the full change log of what
> > happened. This is really important for our users to see what has
> been done
> > when in XWiki.
> > * Tracability. When you use the jira issue # in your commit, the
> jira
> > subversion plugin can show the modified files directly from jira.
> This is
> > quite useful later on, when someone is looking at a jira issue
> and wants to
> > see what was modified. In addition fisheye is also integrated
> with jira and
> > when you browse the source repository you can see the jira issue
> associated
> > with files.
> >
> > I'm proposing that we adopt this practice in XWiki.
> >
> > WDYT?
> >
> > Thanks
> > -Vincent
> >
> > PS: Some time back I blogged about 6 jira issue smells. This was
> one of
> > them. Here's the link: http://tinyurl.com/yzv4bf
>
Hi,
The com.xpn.xwiki.store.XWikiRCSFileStore file doesn't seem to exist
anymore. I can see it's referenced in comment in xwiki.cfg files and
in a StoreObjectRCSFileTest class. Can I remove them?
I'm also curious to know why we have removed it?
Thanks
-Vincent
PS: I wish we had fisheye working, I could have done a quick search
to get the full knowledge about this... Unfortunately OW's SVN
implementation is very old and they're not allowing us to query it
from fisheye as it seems it's making the svn server fail!!
___________________________________________________________________________
D�couvrez une nouvelle fa�on d'obtenir des r�ponses � toutes vos questions !
Profitez des connaissances, des opinions et des exp�riences des internautes sur Yahoo! Questions/R�ponses
http://fr.answers.yahoo.com
On Nov 15, 2006, at 12:48 PM, Ludovic Dubost wrote:
>
> It's not sure that we will find exactly in which version they have
> been
> fixed.
> If we are working on the head, is the policy to mark it fix for the
> upcoming release ?
The policy is to fill the "fix for" either:
* When you're planning to fix an issue for a given release. If it
happens that it's not fixed for that release then the fix for must be
updated at the time of the release
* When you're closing an issue
In any case there should never be any issue closed without a "fix
for" filled.
> in this case what happens if the upcoming release
> never comes out or does not have the version number that we thought
I'm not sure what you mean. Imagine that we define a version named
1.1 planned for a given date. Now imagine that we decide not to
release this version and instead to name it 1.0.9. Then in JIRA we'll
rename 1.1 in 1.0.9 and all issues will then have a fix for for 1.0.9.
I'm probably not understanding something here :-)
Thanks
-Vincent
> Maybe we need to define our versioning policy
>
> Ludovic
>
> Vincent Massol a écrit :
> > Hi developers,
> >
> > I've noticed that there are 43 issues which are resolved or
> closed and which
> > do not have a "fix for" value. This means that these issues are
> not going to
> > be associated with a XWiki version which also means that they are
> > unaccounted for and that users cannot know in which version they
> have been
> > fixed.
> >
> > I think it would be good if everyone had a look and added a "fix
> for" value
> > for the issues they have fixed.
> >
> > WDYT?
> >
> > Note: With the default jira workflow it's not possible to edit an
> issue that
> > has been closed so you'll have to reopen it and close it again.
> If you want
> > I can also modify the workflow to allow editing an issue that's
> been closed.
> > Let me know.
> >
> > Thanks
> > -Vincent
>