xwiki-devs September 2012

xwiki-devs@xwiki.org

23 participants
62 discussions

[xwiki-devs] [Brainstorming] Handling "young" APIs for backward compatibility

by Vincent Massol

Hi devs, We have recently voted a rule where we said that we will do the following: * Always deprecate APIs * Always move them to Legacy modules * And when there's a technical issue to moving stuff to the Legacy module, only then, send a VOTE to remove an API (see http://markmail.org/message/tino4ngttflc5i3s). This means that from now on (starting on 26th of April 2012) we're not allowed to put excludes in CLIRR. However I've seen that we have added some CLIRR excludes after the vote was passed. I believe that the main issue we have is for "young" APIs that are not considered stable. Proposal 1: Internal package ========= * Young APIs must be located in the "internal" package till they become stable. I propose "internal" to reuse an existing package that we filter when testing for CLIRR. "internal" means that users should not use this API because it's considered unstable and can change at any time. * When a Young API is considered stable enough and we want to open it to public consumption then we move it from "internal" to its target package (that's easy to with IDEs). From that point forward any changes to them goes through the standard mechanism of deprecation/legacy. * If we want to add a new method to an existing public API then this should not be considered a "young" API. It's just an addition to an existing API and thus goes directly to the deprecation/legacy cycle. * We need to be careful to isolate "young" APIs from public API so that users don't inadvertently use "young" unstable APIs by mistake. If not possible then directly go through the deprecation/legacy cycle. The advantage of this proposal is that it doesn't change our current practices and is very easy to verify through CLIRR. Proposal 2: Experimental package ========= Another possibility I can think of is to introduce a new "experimental" package instead of reusing the "internal" one. It has the advantage of being able to follow "young" APIs and ensure they don't stay in that state indefinitely, while still allowing the user who uses it to notice it's experimental. Proposal 3: Experimental Annotation ========= Another idea is to just use an @Experimental javadoc tag for experimental code. It has the advantage of using the target package but it has drawbacks: * It's impossible for users to notice that they're using Experimental APIs since when they import a class they won't see anything that'll tell them they're using a "young" API * It's almost impossible to tell CLIRR to exclude those APIs from its checks. The only way to do this is to modify the source code of the CLIRR plugin AFAIK. Thus we would need to exclude those manually using CLIRR excludes and thus before we release we would need to go over the full list of CLIRR excludes to ensure the excludes listed are only for "young" APIs marked "experimental". Note that I mentioned javadoc tag and not annotation because I believe we need to add information about when the Experimental API was first introduced so that we eventually move it as a proper API by removing the Experimental tag. Maybe we would need a rule such as: keep that tag for less or equal to 3 full minor releases (i.e. 6 months). WDYT? Any other idea? Thanks -Vincent

11 years, 6 months

[xwiki-devs] [Contrib] xwiki-application-mailarchive

by Jeremie BOUSQUET

Dear community, I would like to request for a new contrib project to store the Mail Archive application I'm currently writing. Name: xwiki-application-mailarchive Description: A mailing-list archive application. - For now a GitHub project to store sources should be fine. My username on GitHub is "jbousque". - For Jira it might be useful to have a project once the application is released "officially", that is still not the case. Meanwhile the generic project is ok for me. - There is a specific page in Design space on xwiki.org : http://dev.xwiki.org/xwiki/bin/view/Design/MailArchiveApplication , but for now no extension has been added. I would like if possible to test my extension (automatic install with dependencies) before publishing it The Design page also gives some info about the current state and progress, and some screenshots. There is many remaining work, but it begins to look like something usable. The bad side is the lack of unit tests most of all ... A question : the groupId "org.xwiki.contrib" is to be used, do I have to use this exact groupId or can there be sublevels if needed ? If so I would use org.xwiki.contrib.mailarchive as groupId. Thanks, Jeremie

11 years, 7 months

[xwiki-devs] [Brainstorming] Colocated Functional Test (CFT)

by Vincent Massol

Hi devs, I've started an experiment to have colocated functional tests (CFT), which means having the functional tests located where the functional domain sources are located instead of in XE. For example for the linkchecker module we have the following directories: xwiki-platform-linkchecker/ |_ xwiki-platform-linkchecker-refresher (JAR) |_ xwiki-platform-linkchecker-ui (XAR) |_ xwiki-platform-linkchecker-tests (functional tests) The rationale for this was: * Have everything about a functional domain self-contained (source and all tests) * Making it easy to run only tests for a given functional domain * Move page objects to the functional domain too Here are some findings about this experiment: A - It takes about 30 seconds to generate the adhoc packaging and start XWiki. This would be done for each module having functional tests compared to only once if all tests were executed in XE B- The package mojo created to generate a full packaging is quite nice and I plan to reuse it in lots of other places in our build (distributions, database, places where we need XWiki configuration files) C- We will not be able to run platform builds in Maven multithreaded mode since it would mean that several XWiki instance could be started at the same time on the same port D- The colocated functional test module Solutions/ideas: * One idea to overcome A and C would to have the following setup: ** Keep functional test modules colocated but have them generate a test JAR ** Still allow running functional tests from the colocated module (this makes it easy to verify no regression was introduced when making changes to a given domain) ** Have functional tests in XE depend on the colocated functional test module JARs and configure Jenkins to run all functional tests from XE only * Another solution to overcome C is to auto-discover the port to use in our XWiki startup script (and save it in a file so that the stop script can use it). I think the first proposal is the best one and brings the best of the 2 worlds. WDYT? Thanks -Vincent

11 years, 9 months

[xwiki-devs] Thoughts on new model proposal

by Caleb James DeLisle

Hi, I took a look at the new model proposal and there are a few questions and suggested changes. https://github.com/xwiki/xwiki-platform/blob/feature-newmodel/xwiki-platfor… Should this be a String rather than a Java UUID type? https://github.com/xwiki/xwiki-platform/blob/feature-newmodel/xwiki-platfor… If we use getChildren() rather than getChildReferences(), we will be mangling the model with the database code which violates the MVC principle. Also we run the risk of encouraging users to walk the tree looking for the entity it wants rather than creating a reference to it and using that. Walking the tree would obviously incur enormous unnecessary database load. https://github.com/xwiki/xwiki-platform/blob/feature-newmodel/xwiki-platfor… Do we want to continue with the concept of the global variable representing the "current" document? I'm currently not brimming with alternative ideas but the heavy reliance on the XWikiContext has lead to a lot of inter-modular communication which makes oldcore difficult to maintain, perhaps we can prevent this in the new model. https://github.com/xwiki/xwiki-platform/blob/feature-newmodel/xwiki-platfor… I would rather this have a name which doesn't collide with a java.lang class. When I see Object in a .java file I would like it to always mean java.lang.Object. https://github.com/xwiki/xwiki-platform/blob/feature-newmodel/xwiki-platfor… I like XClass better for this purpose, it is essentially a class and creating a new name which nobody has ever heard of will just steepen the learning curve and make things hard on newcomers. https://github.com/xwiki/xwiki-platform/blob/feature-newmodel/xwiki-platfor… Why not give the user direct access to the property without the intervening wrapper? https://github.com/xwiki/xwiki-platform/blob/feature-newmodel/xwiki-platfor… I don't like this. A Persistable is saved in a store by a user. Who is the user and where are they saving it? What if I want to have multiple stores? Must there be a global variable representing the store which is implied by this function? The comment and minorEdit fields are also a bit dubious, perhaps in the future they will make no sense, perhaps they should really be attributes of the Document, also the "attributes" parameter reminds me of this: http://geek-and-poke.com/2012/06/how-to-create-a-stable-api.html Finally, giving the document awareness of where and how it is stored violates the MVC boundries. I think we should not worry about the API which stores the Persistable when we are creating the model, the store API should be separate so that it can evolve while the model stays stable. https://github.com/xwiki/xwiki-platform/blob/feature-newmodel/xwiki-platfor… A session is essentially a transaction? If so why not call it Transaction? Also why does it extend Persistable? How do you persist a session? https://github.com/xwiki/xwiki-platform/blob/feature-newmodel/xwiki-platfor… Why does addSpace() not take a Space parameter? it makes sense to me that you would do: parent = storeApi.get(wikiRef, "SomeSpace", user); child = new DefaultSpace(); child.addDocument("ADocument", new DefaultDocument("This is content.")); parent.addSpace("ChildSpace", child); storeApi.save(parent, user); I'm just brainstorming here but this seems like a reasonable approach.. I noticed the lack of a User data type, is that just something which is planned for the future or is it intentionally missing? Thanks, Caleb

11 years, 9 months

Re: [xwiki-devs] [VOTE] Move history when moving stuff from repositories of "xwiki" organization

by Denis Gervalle

Le 9 mars 2012 16:59, "Vincent Massol" <vincent(a)massol.net> a écrit : > > > On Mar 2, 2012, at 10:06 AM, Denis Gervalle wrote: > > > On Wed, Feb 29, 2012 at 08:19, Vincent Massol <vincent(a)massol.net> wrote: > > > >> Hi, > >> > >> On Feb 28, 2012, at 12:17 PM, Thomas Mortagne wrote: > >> > >>> Hi devs, > >>> > >>> Since I plan to move some stuff from platform to commons I would like > >>> to know what you think of the history in this case. > >>> > >>> Pros including history: > >>> * can access easily the whole history of a moved file. > >> > > > > This is really an important matter, especially for those joining the > > project. When you follow XWiki from "outside", and not in a continuous > > manner, the history is of great value to understand why stuffs are like > > they are, and what you may do, or not when moving forward. > > The history is not lost. If you do a join (all active repos) you still have it. I do not know what you means by joining all repos, but I would be surprise to see the IDE find its way between them. I even wonder how it could be possible. > > >> But sometimes > >>> changing packages etc make too much difference for git to see it's > >>> actually the same file so you loose it anyway. > >> > > > > If you simply change the package name, and nothing else, it is really > > unlikely to happen. > > > > > >>> > >>> Cons including history: > >>> * double the history which make tools like ohloh indicate wrong > >> informations > >> > > > > Sure, the stats will be broken, but what is the matter. This is not > > cheating, just a misfeature in Ohloh, since the commit are just identical, > > something they may notice. IMO, this is the matter of the statistical tools > > to improve that. > > Can you tell me how to implement this because right now my GitHub tool doesn't do that and I don't know how to do it? If I had to implement it, I will probably use some hashing method to be able to recognize similar commits, since there effectively no link between them. But my main remarks that the statistics are broken, not the way we use git. > > >>> * it's a lot easier to move without history > >> > > > > There should be some tools to improve that point or we may write one, once > > for all. So this is not a real cons either. > > It's really hard to copy history in Git. It's almost impossible to do it right. You have to remember the full history and it's just too hard. I would be really disappointed to have to conclude that. There is probably some edge cases, but most of the time there is clever work around. You have to talk to Sergiu :-) > > >>> WDYT ? > >>> > >>> Even if it was looking a bit weird to me at first I'm actually +1 to > >>> not move the history in this case. > >> > >> +1, FTR I'd be -0, close to -1 to move it. If/when the source repository > >> is removed for one reason or another, then we might want to import its > >> history somewhere. > >> > > > > Seems we are really opposite on this one, since I am close to -1 to not > > move it. > > Sorry but that's the current practice :) It's also the easiest one. Until we have Git, there were no better way. This does not means that we should not improve our practice. By the way, it was not my thread, if Thomas has asked, it means that the current practice was not so current. > > > Statistics is really less valuable IMO, it is a small interest compare to > > code history, that I have use a lot, especially when I have join the > > project and follow sparingly. > > I can say exactly the same thing as you said above. It's just a question of tools since the history is not lost. It's still there in our active repos. There is absolutely no link between these histories. It is not only a question of tools. Moreover, requiring querying all active repositories to have a proper history completely defeat the purpose of having separate repositories. I do not see the comparison with my remark above. Git has been made for versionning, not for statistics, it is not my fault. > > > So the general rule for me is: Copy history when the source repository is > >> removed/deleted/not used anymore. > > How many times have you done this? I believe 0 times since I don't think you'd be so much in favor if you had tried it. I suggest you try it a few times on your own projects first :) It's really hard to do it right and very time consuming. When I have copied the security component from contrib, I have done so. I hope that I am not alone. And, frankly, it was not so hard, compare to the advantage you have. > > > You never know what will happen to a repository in the future, so this > > rules is somewhat a hope on the future, no more. And remembering that we > > may loose history if we do some change in the old repository, is for me > > like hoping you will remember my birthday ;) > > I don't agree with this at all. Again we're not loosing history. If a repo is removed then its history is copied I agree about that. I would like to know how you do that after the facts? > > >>> Eduard was proposing to include in the first commit of the new > >>> repository the id of the last commit containing the files (basically > >>> the id of the parent of the commit deleting the files) in the old > >>> repository so that it's easier to find it. I'm +1 for this. > >> > > > > But you loose all the benefits of the IDE tools that brings history of a > > selection automatically and that are really useful. > > A huge majority of xwiki's history is already lost to IDEs (when we moved from SVN) even though the SVN history was moved. Even Git itself doesn't follow the history when you move stuff around. Said differently it's alwasy possible to find the history but the IDE and "standard" tool don't follow it. It does so far better since we move to Git and it is really a valuable tool. Do you means that because in a few case, the history may be broken, that we should not try to have it as complete as possible? > > > Moreover, if the history is rewritten due to a change in structure later, > > the hash may be broken. > > Not sure I understand this one. In Git, nothing is fully permanent, that is all I say. > > You should really measure the cost of what you propose Denis. It's really hard to do. Prove me that is more cost than the one newcommers has to enter the project. Maybe you do not value history so much because you have by your own experience of the project a good knowledge of what happen in the past. When I dig in some code, I always found history valuable to understand why that piece of code is not written the way I may have expected and why I should not got that way. If Thomas conclude it is too hard to be done, and not just some developer's lazyness, I would understand; but I do not agree that it should not be done just because it breaks statistics or we think it is too hard. This is why I suggest a tools that do it once for all. I would be really disappointed of Git if we had to conclude this. Thanks, Denis > > Thanks > -Vincent > > > So having a broken history is hardening the task of those who want to > > participate. A great value compare to the statistics IMO. > > > > -- > > Denis Gervalle > > SOFTEC sa - CEO > > eGuilde sarl - CTO > > _______________________________________________ > > devs mailing list > > devs(a)xwiki.org > > http://lists.xwiki.org/mailman/listinfo/devs > > _______________________________________________ > devs mailing list > devs(a)xwiki.org > http://lists.xwiki.org/mailman/listinfo/devs

11 years, 9 months

[xwiki-devs] [Contrib] xwiki-enterprise-vagrant

by Sorin Burjan

Hi devs, As part of the Hackathon 2012, I started working no a maven module to create VM' provisioned with XWiki.The module is somehow in its early stages, It needs polishing. In order to make the code public for others to see it and help polish it, I would like to have a xwiki-contrib project for this. project name: xwiki-enterprise-vagrant username: sorinello Regards, Sorin B.

11 years, 10 months

[xwiki-devs] [VOTE] REST API Changes not passing CLIRR. Ignore errors

by Ludovic Dubost

As part of rest improvements to display pretty names of users and other improvements, I'm getting CLIRR errors because of API changes of the model and of public class: 1/ Model CLIRR error because the version field has been moved to PageSummary from Page. Page extends PageSummary. I need the version field also in representations sending back only PageSummaries. Unfortunately CLIRR does not realize that the version field is still there when moved to the super class. I believe it's safe to ignore this error. Howerver I've put ignore all errors on the Page class as I don't have a way to ignore this specific error 2/ CLIRR errors because of parameter additions to objects that are used (I think) only internally by the REST server API. Here are the errors: [ERROR] org.xwiki.rest.DomainObjectFactory: In method 'public org.xwiki.rest.model.jaxb.Attachment createAttachment(org.xwiki.rest.model.jaxb.ObjectFactory, java.net.URI, com.xpn.xwiki.api.Attachment, java.lang.String, java.lang.String)' the number of arguments has changed [ERROR] org.xwiki.rest.DomainObjectFactory: In method 'public org.xwiki.rest.model.jaxb.Attachment createAttachmentAtVersion(org.xwiki.rest.model.jaxb.ObjectFactory, java.net.URI, com.xpn.xwiki.api.Attachment, java.lang.String, java.lang.String)' the number of arguments has changed [ERROR] org.xwiki.rest.DomainObjectFactory: In method 'public org.xwiki.rest.model.jaxb.Comment createComment(org.xwiki.rest.model.jaxb.ObjectFactory, java.net.URI, com.xpn.xwiki.api.Document, com.xpn.xwiki.api.Object)' the number of arguments has changed [ERROR] org.xwiki.rest.DomainObjectFactory: In method 'public org.xwiki.rest.model.jaxb.HistorySummary createHistorySummary(org.xwiki.rest.model.jaxb.ObjectFactory, java.net.URI, java.lang.String, java.lang.String, java.lang.String, java.lang.String, org.suigeneris.jrcs.rcs.Version, java.lang.String, java.util.Date)' the number of arguments has changed [ERROR] org.xwiki.rest.DomainObjectFactory: In method 'public org.xwiki.rest.model.jaxb.Object createObject(org.xwiki.rest.model.jaxb.ObjectFactory, java.net.URI, com.xpn.xwiki.XWikiContext, com.xpn.xwiki.api.Document, com.xpn.xwiki.objects.BaseObject, boolean)' the number of arguments has changed [ERROR] org.xwiki.rest.DomainObjectFactory: In method 'public org.xwiki.rest.model.jaxb.ObjectSummary createObjectSummary(org.xwiki.rest.model.jaxb.ObjectFactory, java.net.URI, com.xpn.xwiki.XWikiContext, com.xpn.xwiki.api.Document, com.xpn.xwiki.objects.BaseObject, boolean)' the number of arguments has changed [ERROR] org.xwiki.rest.DomainObjectFactory: In method 'public org.xwiki.rest.model.jaxb.Page createPage(org.xwiki.rest.model.jaxb.ObjectFactory, java.net.URI, java.net.URI, com.xpn.xwiki.api.Document, boolean, com.xpn.xwiki.api.XWiki)' the number of arguments has changed [ERROR] org.xwiki.rest.DomainObjectFactory: In method 'public org.xwiki.rest.model.jaxb.PageSummary createPageSummary(org.xwiki.rest.model.jaxb.ObjectFactory, java.net.URI, com.xpn.xwiki.api.Document, com.xpn.xwiki.api.XWiki)' the number of arguments has changed [ERROR] org.xwiki.rest.resources.BaseAttachmentsResource: In method 'public org.xwiki.rest.model.jaxb.Attachments getAttachments(java.lang.String, java.lang.String, java.lang.String, java.lang.String, java.lang.String, java.lang.String, java.lang.Integer, java.lang.Integer)' the number of arguments has changed [ERROR] org.xwiki.rest.resources.BaseAttachmentsResource: In method 'protected org.xwiki.rest.model.jaxb.Attachments getAttachmentsForDocument(com.xpn.xwiki.api.Document, int, int)' the number of arguments has changed [ERROR] org.xwiki.rest.resources.BaseSearchResult: In method 'protected java.util.List search(java.util.List, java.lang.String, java.lang.String, java.lang.String, boolean, int)' the number of arguments has changed [ERROR] org.xwiki.rest.resources.BaseSearchResult: In method 'protected java.util.List searchObjects(java.lang.String, java.lang.String, java.lang.String, boolean, int)' the number of arguments has changed [ERROR] org.xwiki.rest.resources.BaseSearchResult: In method 'protected java.util.List searchPages(java.util.List, java.lang.String, java.lang.String, java.lang.String, boolean, int)' the number of arguments has changed [ERROR] org.xwiki.rest.resources.BaseSearchResult: In method 'protected java.util.List searchSpaces(java.lang.String, java.lang.String, boolean, int)' the number of arguments has changed [ERROR] org.xwiki.rest.resources.ModificationsResource: In method 'public org.xwiki.rest.model.jaxb.History getModifications(java.lang.String, java.lang.Integer, java.lang.Integer, java.lang.String, java.lang.Long)' the number of arguments has changed [ERROR] org.xwiki.rest.resources.attachments.AttachmentsAtPageVersionResource: In method 'public org.xwiki.rest.model.jaxb.Attachments getAttachmentsAtPageVersion(java.lang.String, java.lang.String, java.lang.String, java.lang.String, java.lang.Integer, java.lang.Integer)' the number of arguments has changed [ERROR] org.xwiki.rest.resources.attachments.AttachmentsResource: In method 'public org.xwiki.rest.model.jaxb.Attachments getAttachments(java.lang.String, java.lang.String, java.lang.String, java.lang.Integer, java.lang.Integer)' the number of arguments has changed [ERROR] org.xwiki.rest.resources.comments.CommentResource: In method 'public org.xwiki.rest.model.jaxb.Comment getComment(java.lang.String, java.lang.String, java.lang.String, java.lang.Integer, java.lang.Integer, java.lang.Integer)' the number of arguments has changed [ERROR] org.xwiki.rest.resources.comments.CommentVersionResource: In method 'public org.xwiki.rest.model.jaxb.Comment getCommentVersion(java.lang.String, java.lang.String, java.lang.String, java.lang.String, java.lang.Integer, java.lang.Integer, java.lang.Integer)' the number of arguments has changed [ERROR] org.xwiki.rest.resources.comments.CommentsResource: In method 'public org.xwiki.rest.model.jaxb.Comments getComments(java.lang.String, java.lang.String, java.lang.String, java.lang.Integer, java.lang.Integer)' the number of arguments has changed [ERROR] org.xwiki.rest.resources.comments.CommentsVersionResource: In method 'public org.xwiki.rest.model.jaxb.Comments getCommentsVersion(java.lang.String, java.lang.String, java.lang.String, java.lang.String, java.lang.Integer, java.lang.Integer)' the number of arguments has changed [ERROR] org.xwiki.rest.resources.objects.AllObjectsForClassNameResource: In method 'public org.xwiki.rest.model.jaxb.Objects getObjects(java.lang.String, java.lang.String, java.lang.Integer, java.lang.Integer)' the number of arguments has changed [ERROR] org.xwiki.rest.resources.objects.ObjectAtPageVersionResource: In method 'public org.xwiki.rest.model.jaxb.Object getObject(java.lang.String, java.lang.String, java.lang.String, java.lang.String, java.lang.String, java.lang.Integer)' the number of arguments has changed [ERROR] org.xwiki.rest.resources.objects.ObjectPropertiesAtPageVersionResource: In method 'public org.xwiki.rest.model.jaxb.Properties getObjectProperties(java.lang.String, java.lang.String, java.lang.String, java.lang.String, java.lang.String, java.lang.Integer)' the number of arguments has changed [ERROR] org.xwiki.rest.resources.objects.ObjectPropertiesResource: In method 'public org.xwiki.rest.model.jaxb.Properties getObjectProperties(java.lang.String, java.lang.String, java.lang.String, java.lang.String, java.lang.Integer)' the number of arguments has changed [ERROR] org.xwiki.rest.resources.objects.ObjectPropertyAtPageVersionResource: In method 'public org.xwiki.rest.model.jaxb.Property getObjectProperty(java.lang.String, java.lang.String, java.lang.String, java.lang.String, java.lang.String, java.lang.Integer, java.lang.String)' the number of arguments has changed [ERROR] org.xwiki.rest.resources.objects.ObjectPropertyResource: In method 'public org.xwiki.rest.model.jaxb.Property getObjectProperty(java.lang.String, java.lang.String, java.lang.String, java.lang.String, java.lang.Integer, java.lang.String)' the number of arguments has changed [ERROR] org.xwiki.rest.resources.objects.ObjectResource: In method 'public org.xwiki.rest.model.jaxb.Object getObject(java.lang.String, java.lang.String, java.lang.String, java.lang.String, java.lang.Integer)' the number of arguments has changed [ERROR] org.xwiki.rest.resources.objects.ObjectsAtPageVersionResource: In method 'public org.xwiki.rest.model.jaxb.Objects getObjects(java.lang.String, java.lang.String, java.lang.String, java.lang.String, java.lang.Integer, java.lang.Integer)' the number of arguments has changed [ERROR] org.xwiki.rest.resources.objects.ObjectsForClassNameResource: In method 'public org.xwiki.rest.model.jaxb.Objects getObjects(java.lang.String, java.lang.String, java.lang.String, java.lang.String, java.lang.Integer, java.lang.Integer)' the number of arguments has changed [ERROR] org.xwiki.rest.resources.objects.ObjectsResource: In method 'public org.xwiki.rest.model.jaxb.Objects getObjects(java.lang.String, java.lang.String, java.lang.String, java.lang.Integer, java.lang.Integer)' the number of arguments has changed [ERROR] org.xwiki.rest.resources.pages.PageChildrenResource: In method 'public org.xwiki.rest.model.jaxb.Pages getPageChildren(java.lang.String, java.lang.String, java.lang.String, java.lang.Integer, java.lang.Integer)' the number of arguments has changed [ERROR] org.xwiki.rest.resources.pages.PageHistoryResource: In method 'public org.xwiki.rest.model.jaxb.History getPageHistory(java.lang.String, java.lang.String, java.lang.String, java.lang.Integer, java.lang.Integer, java.lang.String)' the number of arguments has changed [ERROR] org.xwiki.rest.resources.pages.PageResource: In method 'public org.xwiki.rest.model.jaxb.Page getPage(java.lang.String, java.lang.String, java.lang.String)' the number of arguments has changed [ERROR] org.xwiki.rest.resources.pages.PageTranslationHistoryResource: In method 'public org.xwiki.rest.model.jaxb.History getPageTranslationHistory(java.lang.String, java.lang.String, java.lang.String, java.lang.String, java.lang.Integer, java.lang.Integer, java.lang.String)' the number of arguments has changed [ERROR] org.xwiki.rest.resources.pages.PageTranslationResource: In method 'public org.xwiki.rest.model.jaxb.Page getPageTranslation(java.lang.String, java.lang.String, java.lang.String, java.lang.String)' the number of arguments has changed [ERROR] org.xwiki.rest.resources.pages.PageTranslationVersionResource: In method 'public org.xwiki.rest.model.jaxb.Page getPageTranslationVersion(java.lang.String, java.lang.String, java.lang.String, java.lang.String, java.lang.String)' the number of arguments has changed [ERROR] org.xwiki.rest.resources.pages.PageVersionResource: In method 'public org.xwiki.rest.model.jaxb.Page getPageVersion(java.lang.String, java.lang.String, java.lang.String, java.lang.String)' the number of arguments has changed [ERROR] org.xwiki.rest.resources.pages.PagesResource: In method 'public org.xwiki.rest.model.jaxb.Pages getPages(java.lang.String, java.lang.String, java.lang.Integer, java.lang.Integer, java.lang.String)' the number of arguments has changed [ERROR] org.xwiki.rest.resources.spaces.SpaceAttachmentsResource: In method 'public org.xwiki.rest.model.jaxb.Attachments getAttachments(java.lang.String, java.lang.String, java.lang.String, java.lang.String, java.lang.String, java.lang.String, java.lang.Integer, java.lang.Integer)' the number of arguments has changed [ERROR] org.xwiki.rest.resources.spaces.SpaceSearchResource: In method 'public org.xwiki.rest.model.jaxb.SearchResults search(java.lang.String, java.lang.String, java.lang.String, java.util.List, java.lang.Integer)' the number of arguments has changed [ERROR] org.xwiki.rest.resources.tags.PagesForTagsResource: In method 'public org.xwiki.rest.model.jaxb.Pages getTags(java.lang.String, java.lang.String, java.lang.Integer, java.lang.Integer)' the number of arguments has changed [ERROR] org.xwiki.rest.resources.wikis.WikiAttachmentsResource: In method 'public org.xwiki.rest.model.jaxb.Attachments getAttachments(java.lang.String, java.lang.String, java.lang.String, java.lang.String, java.lang.String, java.lang.String, java.lang.Integer, java.lang.Integer)' the number of arguments has changed [ERROR] org.xwiki.rest.resources.wikis.WikiSearchResource: In method 'public org.xwiki.rest.model.jaxb.SearchResults search(java.lang.String, java.lang.String, java.util.List, java.lang.Integer)' the number of arguments has changed Ludovic -- Ludovic Dubost Founder and CEO Blog: http://blog.ludovic.org/ XWiki: http://www.xwiki.com Skype: ldubost GTalk: ldubost

11 years, 10 months

Re: [xwiki-devs] dyssmetric cluster... what's up?

by Paul Libbrecht

Thank you Thomas, so it turned out an elementary configuration bit caused the test with titles to fail: the presence of a cache folder in WEB-INF containing various cache configs. Removing that made the test with titles and contents succeed. However, the test with collections still fails, and now I finally had it to fail on my sever as well: two tomcats, joined through a tcp channel, ... What I observe is that after a revision is cached in a server, a change of objects only on the other does not propagate. The event and history frame comes up, not the added object. Let me understand: jgroups just does the communication, and listeners include a cache listener which invalidate the entry when the document-event is fired. Is it correct? thanks in advance Paul

11 years, 11 months

[xwiki-devs] Call Fan Out computation algorithm

by Vincent Massol

Hi devs, I wanted to understand how Checkstyle computes the Class Fan out so I debugged it. Here are my findings: * Some classes are excluded by default: mIgnoredClassNames.add("boolean"); mIgnoredClassNames.add("byte"); mIgnoredClassNames.add("char"); mIgnoredClassNames.add("double"); mIgnoredClassNames.add("float"); mIgnoredClassNames.add("int"); mIgnoredClassNames.add("long"); mIgnoredClassNames.add("short"); mIgnoredClassNames.add("void"); mIgnoredClassNames.add("Boolean"); mIgnoredClassNames.add("Byte"); mIgnoredClassNames.add("Character"); mIgnoredClassNames.add("Double"); mIgnoredClassNames.add("Float"); mIgnoredClassNames.add("Integer"); mIgnoredClassNames.add("Long"); mIgnoredClassNames.add("Object"); mIgnoredClassNames.add("Short"); mIgnoredClassNames.add("String"); mIgnoredClassNames.add("StringBuffer"); mIgnoredClassNames.add("Void"); mIgnoredClassNames.add("ArrayIndexOutOfBoundsException"); mIgnoredClassNames.add("Exception"); mIgnoredClassNames.add("RuntimeException"); mIgnoredClassNames.add("IllegalArgumentException"); mIgnoredClassNames.add("IllegalStateException"); mIgnoredClassNames.add("IndexOutOfBoundsException"); mIgnoredClassNames.add("NullPointerException"); mIgnoredClassNames.add("Throwable"); mIgnoredClassNames.add("SecurityException"); mIgnoredClassNames.add("UnsupportedOperationException"); * All classes in java.lang.* are excluded too * Annotation classes are not counted * Classes in the same package are counted (they won't appear in import since it's in the same package so don't count imports to get class fan out) * Static method calls are not counted. So for example StringUtils from Commons Lang never counts for class Fan out * Enums are not counted (no new XXX() done. That's why static method calls are not counted too BTW) * Classes used in class extend or implement are not counted too. Hope it helps -Vincent

11 years, 11 months

[xwiki-devs] [Proposal] Bug Fixing Day #6 on October 4 + BFD every first Thursday of the Month

by Vincent Massol

Hi devs and contributors, It's been a long since we last organized a Bug Fixing Day. I've published all our last results about XWiki Days at http://dev.xwiki.org/xwiki/bin/view/Community/DevelopmentPractices#HXWikiDa… I've also created a dashboard for listing all issues fixed during all our past Bug Fixing Days at http://jira.xwiki.org/secure/Dashboard.jspa?selectPageId=11196 Our total score is 97 issues. We can do better! Well done to Sergiu who has the high score by far with 49 issues fixed. I'd like to propose the 6th BFD since we're deriving quite a lot on our bug count. For the past 365 days 824 bugs were created and we solved 734 which means we're behind by 90 bugs just for that rolling period… See http://jira.xwiki.org/secure/Dashboard.jspa?selectPageId=10000#Created-vs-R… This means we're loosing the battle every day since every day more bugs are created than solved (our total unclosed bug count is 793, see http://jira.xwiki.org/secure/Dashboard.jspa?selectPageId=10000#Issue-Statis… ). What we should be doing instead is have the green line just slightly above the red bar on http://jira.xwiki.org/secure/Dashboard.jspa?selectPageId=10000#Created-vs-R… This would mean we're catching up slowly on the bug count. I'd like to propose the date of the **4th of October **for our sixth BFD and more generally I'd like to propose having a BFD every month on the first Thursday of every month, with the goal of reducing drastically this roving bug count! WDYT? Thanks -Vincent

11 years, 11 months

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

2005

xwiki-devs September 2012