November 2006 - xwiki-devs@xwiki.org

xwiki build.416 Build Successful
by ludovic＠xwiki.org 15 Nov '06

15 Nov '06

View results here -> http://build.xpertnet.biz/cc/buildresults/xwiki?log=log20061115182635Lbuild…

1 0

xwiki build.415 Build Successful
by ludovic＠xwiki.org 15 Nov '06

15 Nov '06

View results here -> http://build.xpertnet.biz/cc/buildresults/xwiki?log=log20061115172126Lbuild…

1 0

xwiki build.414 Build Successful
by ludovic＠xwiki.org 15 Nov '06

15 Nov '06

View results here -> http://build.xpertnet.biz/cc/buildresults/xwiki?log=log20061115130612Lbuild…

1 0

[Proposal] Issue Driven Development (IDD)
by Vincent Massol 15 Nov '06

15 Nov '06

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

2 1

RE: Contributors.txt and @author in license headers
by Vincent Massol 15 Nov '06

15 Nov '06

> -----Original Message----- > From: Vincent Massol [mailto:[email protected]] > 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:[email protected]] > > 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

3 2

Questions on Plugin API
by Vincent Massol 15 Nov '06

15 Nov '06

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

3 2

xwiki build.413 Build Successful
by ludovic＠xwiki.org 15 Nov '06

15 Nov '06

View results here -> http://build.xpertnet.biz/cc/buildresults/xwiki?log=log20061115122111Lbuild…

1 0

Clover 2.0 preview
by Vincent Massol 15 Nov '06

15 Nov '06

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

2 1

[JIRA] Missing "fix for" fields...
by Vincent Massol 15 Nov '06

15 Nov '06

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

2 1

[Idea] SVN bridge
by Vincent Massol 15 Nov '06

15 Nov '06

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

3 3