Hi,
I've noticed that the xwiki jira is using the default resolved step. In most
of the jira I have managed I have removed this step as it's seldom or never
used and leads to issues being resolved but never closed... BTW I've noticed
that our JIRA has 56 issues resolved but not closed... :-) I'm pretty sure
they should be closed.
Here's my proposal: remove the resolved state. I can do it.
If an issue is closed but still has problems then the reporter can reopen
it.
Here's my +1
Thanks
-Vincent
___________________________________________________________________________
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
Here are some additional tips to qualify my post below:
* In you want to know whether you should create a jira issue or not ask
yourself the question: "is my change going to affect any user or any plugin
developer"? If the answer is yes then you must create a jira issue
* You shouldn't create a bug issue for a new feature that you or someone
else has implemented in the current version under development. Whatever fix
you do must be against the existing JIRA issue for that bug/feature.
The idea here is that the changelog must be as meaningful as possible.
Thanks
-Vincent
> -----Original Message-----
> From: Vincent Massol [mailto:vincent@massol.net]
> Sent: mardi 14 novembre 2006 09:03
> To: 'xwiki-dev(a)objectweb.org'
> Subject: [Proposal] Issue Driven Development (IDD)
>
> 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
___________________________________________________________________________
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
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
___________________________________________________________________________
Yahoo! Mail r�invente le mail ! D�couvrez le nouveau Yahoo! Mail et son interface r�volutionnaire.
http://fr.mail.yahoo.com
> -----Original Message-----
> From: Vincent Massol [mailto:vincent@massol.net]
> Sent: lundi 13 novembre 2006 16:46
> To: 'xwiki-dev(a)objectweb.org'
> Subject: RE: Contributors.txt and @author in license headers
>
>
>
> > -----Original Message-----
> > From: Vincent Massol [mailto:vincent@massol.net]
> > Sent: lundi 13 novembre 2006 16:43
> > To: 'xwiki-dev(a)objectweb.org'
> > Subject: Contributors.txt and @author in license headers
> >
> > Hi,
> >
> > Our license headers say: " * Copyright 2006, XpertNet SARL, and
> > individual contributors as indicated by the contributors.txt."
> >
> > There are 3 problems with this that I can see:
> >
> > 1) It's not really English in that it's either missing a "file" at
> the
> > end or we should remove the "the" before "contributors" ;-)
> > 2) I cannot find the contributors.txt file!
> > 3) I don't think we should explicitely mention the file name as we'll
> > always risk having to rename all headers if we decide to put this
> file
> > somewhere else/name it differently.
> > 4) In several of our license headers there are @authors. For example:
> >
> > /*
> > * Copyright 2006, XpertNet SARL, and individual contributors as
> > indicated
> > * by the contributors.txt.
> >
> > [snip]
> >
> > * You should have received a copy of the GNU Lesser General Public
> > * License along with this software; if not, write to the Free
> > * Software Foundation, Inc., 51 Franklin St, Fifth Floor, Boston, MA
> > * 02110-1301 USA, or see the FSF site: http://www.fsf.org.
> > *
> > * @author ravenees
> > * @author jeremi
> > */
> >
> > I thought the authors were supposed to be indicated in the
> > contributors.txt file! :-)
> >
> > Personally I don't like @author tags and especially not in license
> > headers (actually it's the first time I ever see them put there, they
> > are usually put in the class javadoc). The reason I don't like these
> > tags is because:
> > * they are always not up to date and there are usually mane more
> > authors than the ones listed
> > * we never know what the author has worked on in the file and to what
> > extent. For example someone could have simply added a missing dot in
> a
> > javdoc.
> > * this information is better defined in the SCM which contains the
> full
> > history and what everyone has exactly contributed to.
> >
> > So I'd be in favor of implementing the contributors.txt file and
> > removing all @authors tags from the license headers.
>
> FWIW in cargo, we store contributions in SVN and they're also available
> on the web site at http://cargo.codehaus.org/Credits. It's never
> completely up to date but it's a good first approach. This is the
> equivalent of the contributors.txt file.
Ah last point, Maven2's pom.xml has a tag to define both committers and
contributors too. So we could also use that instead of a contributors.txt
file. The advantage is that there's no place to define what the contributors
have contributed too which means it's not going to be obsolete. To see what
contributors have done, people could see fisheye, jira, svn. Actually
fisheye would be the best tool for that, especially as it integrates with
jira.
Thus WDYT about using the pom.xml file to indicate committers and
contributors?
Thanks
-Vincent
___________________________________________________________________________
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
Hi there,
I have some questions on the xwiki plugin API:
1) In XWikiDefaultPlugin it seems the classname field is never used. It's
actually never set AFAICS. I also don't understand the "if" in the following
method:
public void setName(String name) {
if (!name.equals(className))
this.name = name;
}
BTW this will probably fail at runtime as className is not set anywhere I
can see.
2) I can see in XWikiPluginManager.addPlugins() that it calls
addPlugin(classNames[i], classNames[i], context). Thus it seems "className"
and "name" will always be the same. Why the have both?
3) Why do plugins need to know their own class name? I mean I understand
plugin class names are required to instantiate them but why pass their
className in the XWikiDefaultPlugin constructor?
4) Why do we pass the context in the XWikiDefaultPlugin constructor as it's
not used at all (it's not assigned). Actually all plugin API methods all
accept a XWikiContext object... I believe the best would be to pass the
context in the constructor and remove the context in the plugin API method
signatures.
5) In XWikiPluginInterface what is virtualInit() compared to init(). The
name is not really self-explanatory and there's no javadoc... It seems it
gets called in one place only, in XWiki.updateDatabase(), but I don't
understand it's called there.
6) In XWikiPluginManager there are several methods like this one:
public void virtualInit(XWikiContext context) {
Vector plugins = getPlugins("virtualInit");
for (int i=0;i<plugins.size();i++) {
try {
((XWikiPluginInterface)plugins.get(i)).virtualInit(context);
} catch (Exception e)
{}
}
}
However as virtualInit() is defined in XWikiPluginInterface, it'll always be
present in any plugin. So why check and not instead loop over all plugins?
7) What is XWikiPluginInterace.flushCache() for?
8) I can see two methods in XWikiPluginInterface: begin and endRendering. My
first thought was that plugins could contribute to rendering a page but
that's not it as these methods are not returning any content. It seems they
are only hooks so that actions be can performed before and after the
rendering is done. Is that correct? I haven't been able to find any plugin
implementing these methods. Are there any examples?
9) Could you explain XWikiPluginInterface's commonTagsHandler(),
startRenderingHandler(),outsidePREHandler(),insidePREHandler() and
endRenderingHandler()? I think I have a general idea of what they're for but
I'd like more details. Actually I'd like to write the javadoc for them but I
need the info to put there.
10) Same question for downloadAttachment().
11) I see in all plugins that we implement the getPluginApi() like this:
public Api getPluginApi(XWikiPluginInterface plugin, XWikiContext
context) {
return new ZipExplorerPluginAPI((ZipExplorerPlugin) plugin,
context);
}
My question is why do we create a new object every time the API is called.
It doesn't sound efficient. As there's only one plugin instance created for
every plugin, why isn't the *API class instantiated in the plugin
constructor method?
12) I personally don't like too much the way that all plugins have to
implement all plugin methods even those that they do not use. I think it
would be better to define different extension points (as interfaces for
example) and have plugins implement the interfaces/extension points they
need only. This would have several advantages:
- it would clearly show what a given plugin is contributing
- we wouldn't have to create a XWikiDefaultPlugin class with empty methods.
A user implementing a plugin interface should see in his IDE the methods he
has to implement. With XWikiDefaultPlugin as all methods are already
implemented it's hard to know/understand.
- I also think we should have more extension points for plugins. Like the
ability to hook in the storage logic. For example if we want to implement a
SVN plugin that saves docs to SVN by committing them.
That's all for now :-)
Note: Once I get the answers to these questions I'll document the code.
Thanks
-Vincent
___________________________________________________________________________
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
Seems like Clover 2 is going to be cool and that we could use it!
See here for a sample report:
http://www.cenqua.com/clover/20/samples/index_test_results.html
And here for the feature list: http://www.cenqua.com/clover/20/index.html
Thanks
-Vincent
___________________________________________________________________________
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
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
___________________________________________________________________________
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
Hi,
Here's something I would be keen to implement: a XWiki/SVN bridge. Imagine
the following:
* You edit a page on the wiki and when you click on save, xwiki saves the
content to SVN in addition to saving it to the xwiki database
* On the user profile page, we add 2 new fields: svn username and svn
password. This is used when doing the save/commit.
* We put a "svn update" button in the available actions for each page. We
could also do that at the level of the space/wiki
* If SVN says there's a conflict then we tell the user, do a merge and put
the resulting merge inside the edit window and ask the user to sort it out.
The user has to click on save again to save it.
* We create a scheduling job (we are using the quartz scheduler, right?) to
update the space/wiki every few hours (say 2 hours) by loading the content
from svn for each page and saving it as the new content. Question: is this
going to work? Is it possible that some pages would need to be updated in
the correct order for it work, in which case the only solution would be a
bulk update?
Technical details:
* We use JavaSVN
* We use the low level API of JavaSVN (the one that doesn't use a
workspace).
WDYT?
Could someone point to me where is the xwiki code where we would need to
insert the SVN commit code so that I can have a look at it?
Thanks
-Vincent
___________________________________________________________________________
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
Hi Nam,
> -----Original Message-----
> From: Phung Hai Nam [mailto:namphunghai@users.forge.objectweb.org]
> Sent: mercredi 15 novembre 2006 12:10
> To: xwiki-commits(a)objectweb.org
> Subject: [xwiki-commits] r1569 - in
> xwiki/trunk/web/standard/src/main/webapp: templates tiny_mce_2/langs
> tiny_mce_2/themes/wikieditor tiny_mce_2/themes/wikieditor/css
> tiny_mce_2/themes/wikieditor/jscripts
>
> Author: namphunghai
> Date: 2006-11-15 12:10:21 +0100 (Wed, 15 Nov 2006) New Revision: 1569
>
> Modified:
>
> xwiki/trunk/web/standard/src/main/webapp/templates/listattachwysiwyg.vm
> xwiki/trunk/web/standard/src/main/webapp/tiny_mce_2/langs/en.js
>
> xwiki/trunk/web/standard/src/main/webapp/tiny_mce_2/themes/wikieditor/c
> ss/editor_popup.css
>
> xwiki/trunk/web/standard/src/main/webapp/tiny_mce_2/themes/wikieditor/j
> scripts/link.js
>
> xwiki/trunk/web/standard/src/main/webapp/tiny_mce_2/themes/wikieditor/l
> ink.htm
> Log:
> Fixed XWiki-413 and Xwiki-416 for Wysiwyg editor 2.
I see you've referenced the jira issues that's very cool! :-)
I think a best practice would also to include the issue description in the email as otherwise it's just too hard to have to go to jira and look up the issue to understand what it's about.
I'd suggest the following template:
-cut here ------------------
XWIKI-NN: Description of the issue
* blah blah
* blah blah
- cut here -----------------
WDYT?
[snip]
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,
In order to understand better the code I have reviewed the ZipExplorer
plugin. Here's my code review:
* There are 2 unused fields that should be removed: capacity and log
* The getFileName() method can be improved:
- first parameter variable must not be modified (the path one in this
case). There should always be a local variable created.
- I don't think XWiki URI manipulation should be done in this class at
all! I'd recommend creating a XWikiURI class in charge of performing all
actions on XWiki URI: creation, getting the different part, etc. In this
manner is XWiki decides to change the URI format, it'll only be done in one
place. This would also remove completely the need for getFileName() from
ZipExplorerPlugin.
* There are no javadocs... The minimum would be to have a class javadoc
explaining what the plugin is doing and putting an example of how to use it.
* readFromInputStream() is a generic method to read an input stream in
memory. Note that this method should be moved in some generic place as it
would be useful for other portion of the code and is completely generic.
Even better this method is already implemented in commons-io
[http://jakarta.apache.org/commons/io/api-release/org/apache/commons/io/File
Utils.html#readFileToByteArray(java.io.File)]. Also note that it's a
dangerous method as it's limited by the size of the memory and the size of
of a byte[] array in Java... If the zip is large it's going to fail... It
would be better to implement it with streaming instead, if possible.
* getFileTreeList(). By reading this method's name I don't understand what
it does. I also don't understand what is the difference with getFileList()
(I haven't analyzed the code).
* Exception handling is very very poor :-) For example:
} catch (XWikiException e) {
e.printStackTrace();
} catch (IOException e) {
e.printStackTrace();
}
* The unit tests seem to be lacking. In any case they're hard to read. I
haven't fully understood them yet... I believe they shouldn't test XWiki's
core but only the plugin.
Let me know what you think and I'll create some jira issues to fix it.
Thanks
-Vincent
___________________________________________________________________________
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
Hi there,
As a reminder, I'll start moving tests we have in trunk/src/tests in
core/src/test in a few hour's time. I'll move the unit tests first (the ones
with no environment dependency). I'll keep the Ant build working at all
times.
As usual let me know if this is going to cause an issue for you.
Thanks
-Vincent
___________________________________________________________________________
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
