27 Jul
2012
27 Jul
'12
10:12 a.m.
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
8 Aug
8 Aug
7:33 a.m.
Hi,
Could the dev team answer this one. It would be great to be able to
apply the pull request
for the REST API improvements along with the one Fabio just sent:
https://github.com/xwiki/xwiki-platform/pull/56
I've taken into account the comments sent out.
Ludovic
2012/7/27 Ludovic Dubost <ludovic(a)xwiki.com>om>:
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
--
Ludovic Dubost
Founder and CEO
Blog: http://blog.ludovic.org/
XWiki: http://www.xwiki.com
Skype: ldubost GTalk: ldubost
21 Aug
21 Aug
2:18 p.m.
On Fri, Jul 27, 2012 at 10:12 AM, Ludovic Dubost <ludovic(a)xwiki.com> wrote:
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
Yep, I think it's safe. We're adding stuff in a representation (page
summary) and keeping it also in the other, so API-wise it's ok.
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
The DomainObjectFactory is actually a utility class that is used to
build REST-model objects from XWiki-model objects.
It has been created just to prevent code duplication in resource
implementations.
Now I think it's unlikely that somebody uses it outside the REST
module (a quick grep confirmed this for platform).
The only use case for a developer of a module to use this class is if
she wants to return a REST-model object and build it using the utility
methods.
I think this is quite unlikely.
AFAIU all parameters additions are about "pretty names"
(https://github.com/ldubost/xwiki-platform/compare/master...bd49bcc84e1dec3d…)
If we want to be conservative we might do the following: we can add
the new methods and preserve the old ones making them call the new
ones with default parameters.
* false in methods like this
https://github.com/ldubost/xwiki-platform/compare/master...bd49bcc84e1dec3d…
* null, false in methods like this
https://github.com/ldubost/xwiki-platform/compare/master...bd49bcc84e1dec3d…
. This implies that in the new implementation the if statement should
also check for null values (like in this case:
https://github.com/ldubost/xwiki-platform/compare/master...bd49bcc84e1dec3d…)
We could also think about whether continuing to keep this class in the
public API. It could make sense but I think that nobody will ever use
it so we can start to @deprecate it and eventually move it in internal
packages.
-Fabio
3:20 p.m.
New subject: [xwiki-devs] [VOTE] REST API Changes not passing CLIRR. Ignore errors
On 08/21/2012 08:18 AM, Fabio Mancinelli wrote:
I'd rather not keep the old methods, but since this is a public class,
it needs to follow our deprecation strategy, so +1 for Fabio's suggestion.
--
Sergiu Dumitriu
http://purl.org/net/sergiu/
On Fri, Jul 27, 2012 at 10:12 AM, Ludovic Dubost
<ludovic(a)xwiki.com> wrote:
+1 as well.
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
Yep, I think it's safe. We're adding stuff in a representation (page
summary) and keeping it also in the other, so API-wise it's ok. 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
The DomainObjectFactory is actually a utility class that is used to
build REST-model objects from XWiki-model objects.
It has been created just to prevent code duplication in resource
implementations.
Now I think it's unlikely that somebody uses it outside the REST
module (a quick grep confirmed this for platform).
The only use case for a developer of a module to use this class is if
she wants to return a REST-model object and build it using the utility
methods.
I think this is quite unlikely.
AFAIU all parameters additions are about "pretty names"
(https://github.com/ldubost/xwiki-platform/compare/master...bd49bcc84e1dec3d…)
If we want to be conservative we might do the following: we can add
the new methods and preserve the old ones making them call the new
ones with default parameters.
* false in methods like this
https://github.com/ldubost/xwiki-platform/compare/master...bd49bcc84e1dec3d…
* null, false in methods like this
https://github.com/ldubost/xwiki-platform/compare/master...bd49bcc84e1dec3d…
. This implies that in the new implementation the if statement should
also check for null values (like in this case:
https://github.com/ldubost/xwiki-platform/compare/master...bd49bcc84e1dec3d…)
We could also think about whether continuing to keep this class in the
public API. It could make sense but I think that nobody will ever use
it so we can start to @deprecate it and eventually move it in internal
packages.
10:02 p.m.
So we should add methods to keep the old methods available and mark
all of them/the whole class deprecated ?
Ludovic
2012/8/21 Sergiu Dumitriu <sergiu(a)xwiki.com>om>:
On 08/21/2012 08:18 AM, Fabio Mancinelli wrote:
I'd rather not keep the old methods, but since this is a public class, it
needs to follow our deprecation strategy, so +1 for Fabio's suggestion.
--
Sergiu Dumitriu
http://purl.org/net/sergiu/
_______________________________________________
devs mailing list
devs(a)xwiki.org
http://lists.xwiki.org/mailman/listinfo/devs
--
Ludovic Dubost
Founder and CEO
Blog: http://blog.ludovic.org/
XWiki: http://www.xwiki.com
Skype: ldubost GTalk: ldubost
On Fri, Jul 27, 2012 at 10:12 AM, Ludovic Dubost <ludovic(a)xwiki.com>
wrote:
+1 as well.
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
Yep, I think it's safe. We're adding stuff in a representation (page
summary) and keeping it also in the other, so API-wise it's ok. 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
The DomainObjectFactory is actually a utility class that is used to
build REST-model objects from XWiki-model objects.
It has been created just to prevent code duplication in resource
implementations.
Now I think it's unlikely that somebody uses it outside the REST
module (a quick grep confirmed this for platform).
The only use case for a developer of a module to use this class is if
she wants to return a REST-model object and build it using the utility
methods.
I think this is quite unlikely.
AFAIU all parameters additions are about "pretty names"
(https://github.com/ldubost/xwiki-platform/compare/master...bd49bcc84e1dec3d…)
If we want to be conservative we might do the following: we can add
the new methods and preserve the old ones making them call the new
ones with default parameters.
* false in methods like this
https://github.com/ldubost/xwiki-platform/compare/master...bd49bcc84e1dec3d…
* null, false in methods like this
https://github.com/ldubost/xwiki-platform/compare/master...bd49bcc84e1dec3d…
. This implies that in the new implementation the if statement should
also check for null values (like in this case:
https://github.com/ldubost/xwiki-platform/compare/master...bd49bcc84e1dec3d…)
We could also think about whether continuing to keep this class in the
public API. It could make sense but I think that nobody will ever use
it so we can start to @deprecate it and eventually move it in internal
packages.
10:56 p.m.
New subject: [xwiki-devs] [VOTE] REST API Changes not passing CLIRR. Ignore errors
On 08/21/2012 04:02 PM, Ludovic Dubost wrote:
So we should add methods to keep the old methods
available and mark
all of them/the whole class deprecated ?
Yes.
Ludovic
2012/8/21 Sergiu Dumitriu <sergiu(a)xwiki.com>om>:
> On 08/21/2012 08:18 AM, Fabio Mancinelli wrote:
>>
>> On Fri, Jul 27, 2012 at 10:12 AM, Ludovic Dubost <ludovic(a)xwiki.com>
>> wrote:
>>>
>>> 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
>>>
>> Yep, I think it's safe. We're adding stuff in a representation (page
>> summary) and keeping it also in the other, so API-wise it's ok.
>
>
> +1 as well.
>
>
>>> 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
>>
>>
>> The DomainObjectFactory is actually a utility class that is used to
>> build REST-model objects from XWiki-model objects.
>> It has been created just to prevent code duplication in resource
>> implementations.
>>
>> Now I think it's unlikely that somebody uses it outside the REST
>> module (a quick grep confirmed this for platform).
>>
>> The only use case for a developer of a module to use this class is if
>> she wants to return a REST-model object and build it using the utility
>> methods.
>> I think this is quite unlikely.
>>
>> AFAIU all parameters additions are about "pretty names"
>>
>>
(https://github.com/ldubost/xwiki-platform/compare/master...bd49bcc84e1dec3d…)
>>
>> If we want to be conservative we might do the following: we can add
>> the new methods and preserve the old ones making them call the new
>> ones with default parameters.
>>
>> * false in methods like this
>>
>>
https://github.com/ldubost/xwiki-platform/compare/master...bd49bcc84e1dec3d…
>> * null, false in methods like this
>>
>>
https://github.com/ldubost/xwiki-platform/compare/master...bd49bcc84e1dec3d…
>> . This implies that in the new implementation the if statement should
>> also check for null values (like in this case:
>>
>>
https://github.com/ldubost/xwiki-platform/compare/master...bd49bcc84e1dec3d…)
>>
>> We could also think about whether continuing to keep this class in the
>> public API. It could make sense but I think that nobody will ever use
>> it so we can start to @deprecate it and eventually move it in internal
>> packages.
>
>
> I'd rather not keep the old methods, but since this is a public class, it
> needs to follow our deprecation strategy, so +1 for Fabio's suggestion.
>
\
--
Sergiu Dumitriu
http://purl.org/net/sergiu/
11:06 p.m.
On Aug 21, 2012, at 10:56 PM, Sergiu Dumitriu wrote:
On 08/21/2012 04:02 PM, Ludovic Dubost wrote:
Well since Fabio says that these classes should have been internal from the beginning and
it was a mistake and since Fabio thinks that it's unlikely that anybody would be using
them we could make an exception and skip the deprecation and move them to the internal
package.
WDYT?
Thanks
-Vincent
PS: I don't personally know much at all about the REST API so I'm basing my
comments purely on Fabio's analysis.
So we should add methods to keep the old methods
available and mark
all of them/the whole class deprecated ?
Yes. > Ludovic
>
> 2012/8/21 Sergiu Dumitriu <sergiu(a)xwiki.com>om>:
>> On 08/21/2012 08:18 AM, Fabio Mancinelli wrote:
>>>
>>> On Fri, Jul 27, 2012 at 10:12 AM, Ludovic Dubost <ludovic(a)xwiki.com>
>>> wrote:
>>>>
>>>> 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
>>>>
>>> Yep, I think it's safe. We're adding stuff in a representation (page
>>> summary) and keeping it also in the other, so API-wise it's ok.
>>
>>
>> +1 as well.
>>
>>
>>>> 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
>>>
>>>
>>> The DomainObjectFactory is actually a utility class that is used to
>>> build REST-model objects from XWiki-model objects.
>>> It has been created just to prevent code duplication in resource
>>> implementations.
>>>
>>> Now I think it's unlikely that somebody uses it outside the REST
>>> module (a quick grep confirmed this for platform).
>>>
>>> The only use case for a developer of a module to use this class is if
>>> she wants to return a REST-model object and build it using the utility
>>> methods.
>>> I think this is quite unlikely.
>>>
>>> AFAIU all parameters additions are about "pretty names"
>>>
>>>
(https://github.com/ldubost/xwiki-platform/compare/master...bd49bcc84e1dec3d…)
>>>
>>> If we want to be conservative we might do the following: we can add
>>> the new methods and preserve the old ones making them call the new
>>> ones with default parameters.
>>>
>>> * false in methods like this
>>>
>>>
https://github.com/ldubost/xwiki-platform/compare/master...bd49bcc84e1dec3d…
>>> * null, false in methods like this
>>>
>>>
https://github.com/ldubost/xwiki-platform/compare/master...bd49bcc84e1dec3d…
>>> . This implies that in the new implementation the if statement should
>>> also check for null values (like in this case:
>>>
>>>
https://github.com/ldubost/xwiki-platform/compare/master...bd49bcc84e1dec3d…)
>>>
>>> We could also think about whether continuing to keep this class in the
>>> public API. It could make sense but I think that nobody will ever use
>>> it so we can start to @deprecate it and eventually move it in internal
>>> packages.
>>
>>
>> I'd rather not keep the old methods, but since this is a public class, it
>> needs to follow our deprecation strategy, so +1 for Fabio's suggestion.
22 Aug
22 Aug
12:54 a.m.
I'm +1 for moving right away to internal.
Ludovic
2012/8/21 Vincent Massol <vincent(a)massol.net>et>:
On Aug 21, 2012, at 10:56 PM, Sergiu Dumitriu wrote:
--
Ludovic Dubost
Founder and CEO
Blog: http://blog.ludovic.org/
XWiki: http://www.xwiki.com
Skype: ldubost GTalk: ldubost
On 08/21/2012 04:02 PM, Ludovic Dubost wrote:
Well since Fabio says that these classes should have been internal from the beginning and
it was a mistake and since Fabio thinks that it's unlikely that anybody would be using
them we could make an exception and skip the deprecation and move them to the internal
package.
WDYT?
Thanks
-Vincent
PS: I don't personally know much at all about the REST API so I'm basing my
comments purely on Fabio's analysis.
So we should add methods to keep the old methods
available and mark
all of them/the whole class deprecated ?
Yes. > Ludovic
>
> 2012/8/21 Sergiu Dumitriu <sergiu(a)xwiki.com>om>:
>> On 08/21/2012 08:18 AM, Fabio Mancinelli wrote:
>>>
>>> On Fri, Jul 27, 2012 at 10:12 AM, Ludovic Dubost <ludovic(a)xwiki.com>
>>> wrote:
>>>>
>>>> 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
>>>>
>>> Yep, I think it's safe. We're adding stuff in a representation (page
>>> summary) and keeping it also in the other, so API-wise it's ok.
>>
>>
>> +1 as well.
>>
>>
>>>> 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
>>>
>>>
>>> The DomainObjectFactory is actually a utility class that is used to
>>> build REST-model objects from XWiki-model objects.
>>> It has been created just to prevent code duplication in resource
>>> implementations.
>>>
>>> Now I think it's unlikely that somebody uses it outside the REST
>>> module (a quick grep confirmed this for platform).
>>>
>>> The only use case for a developer of a module to use this class is if
>>> she wants to return a REST-model object and build it using the utility
>>> methods.
>>> I think this is quite unlikely.
>>>
>>> AFAIU all parameters additions are about "pretty names"
>>>
>>>
(https://github.com/ldubost/xwiki-platform/compare/master...bd49bcc84e1dec3d…)
>>>
>>> If we want to be conservative we might do the following: we can add
>>> the new methods and preserve the old ones making them call the new
>>> ones with default parameters.
>>>
>>> * false in methods like this
>>>
>>>
https://github.com/ldubost/xwiki-platform/compare/master...bd49bcc84e1dec3d…
>>> * null, false in methods like this
>>>
>>>
https://github.com/ldubost/xwiki-platform/compare/master...bd49bcc84e1dec3d…
>>> . This implies that in the new implementation the if statement should
>>> also check for null values (like in this case:
>>>
>>>
https://github.com/ldubost/xwiki-platform/compare/master...bd49bcc84e1dec3d…)
>>>
>>> We could also think about whether continuing to keep this class in the
>>> public API. It could make sense but I think that nobody will ever use
>>> it so we can start to @deprecate it and eventually move it in internal
>>> packages.
>>
>>
>> I'd rather not keep the old methods, but since this is a public class, it
>> needs to follow our deprecation strategy, so +1 for Fabio's suggestion.
_______________________________________________
devs mailing list
devs(a)xwiki.org
http://lists.xwiki.org/mailman/listinfo/devs
21 Aug
21 Aug
10:18 p.m.
On Aug 21, 2012, at 2:18 PM, Fabio Mancinelli wrote:
The question is whether this is supposed to be a SPI or not.
On Fri, Jul 27, 2012 at 10:12 AM, Ludovic Dubost
<ludovic(a)xwiki.com> wrote:
Note that CLIRR doesn't have false positives so if it complains it means there's a
breakage. The only decision to take is whether it's an "acceptable"
breakage, i.e. we voluntarily break assuming that nobody was using it and accept that a
few users might get broken.
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
Yep, I think it's safe. We're adding stuff in a representation (page
summary) and keeping it also in the other, so API-wise it's ok. 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
The DomainObjectFactory is actually a utility class that is used to
build REST-model objects from XWiki-model objects.
It has been created just to prevent code duplication in resource
implementations. Now I think it's unlikely that somebody uses it
outside the REST
module (a quick grep confirmed this for platform).
The only use case for a developer of a module to use this class is if
she wants to return a REST-model object and build it using the utility
methods.
I think this is quite unlikely.
AFAIU all parameters additions are about "pretty names"
(https://github.com/ldubost/xwiki-platform/compare/master...bd49bcc84e1dec3d…)
If we want to be conservative we might do the following: we can add
the new methods and preserve the old ones making them call the new
ones with default parameters.
* false in methods like this
https://github.com/ldubost/xwiki-platform/compare/master...bd49bcc84e1dec3d…
* null, false in methods like this
https://github.com/ldubost/xwiki-platform/compare/master...bd49bcc84e1dec3d…
. This implies that in the new implementation the if statement should
also check for null values (like in this case:
https://github.com/ldubost/xwiki-platform/compare/master...bd49bcc84e1dec3d…)
We could also think about whether continuing to keep this class in the
public API. It could make sense but I think that nobody will ever use
it so we can start to @deprecate it and eventually move it in internal
packages.
Based on what you say I'd say that these classes/methods were put public by mistake
and should all be moved to the internal package without going through deprecation.
Of course this means no other other XWiki modules should use them either since they're
internal.
Also this means that we don't provide any SPI either since SPI are user-public. Is
that what we want?
Thanks
-Vincent
10:49 p.m.
On Tue, Aug 21, 2012 at 10:18 PM, Vincent Massol <vincent(a)massol.net> wrote:
The question is whether this is supposed to be a SPI or not.
No. It's just an utility class where to put the code for building
model objects that is used in different places.
The idea is the same of
https://github.com/fmancinelli/xwiki-platform/blob/master/xwiki-platform-co…
Yep.
On Aug 21, 2012, at 2:18 PM, Fabio Mancinelli wrote:
Actually I was talking of the REST-API ... Re CLIRR, what is it
complaining for exactly? If I move a method in a superclass keeping
the same access level, it is still available in the subclasses for
clients calling it. So why complain?
On Fri, Jul 27, 2012 at 10:12 AM, Ludovic Dubost
<ludovic(a)xwiki.com> wrote:
Note that CLIRR doesn't have false positives so if it complains it means there's
a breakage. The only decision to take is whether it's an "acceptable"
breakage, i.e. we voluntarily break assuming that nobody was using it and accept that a
few users might get broken.
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
Yep, I think it's safe. We're adding stuff in a representation (page
summary) and keeping it also in the other, so API-wise it's ok. 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
The DomainObjectFactory is actually a utility class that is used to
build REST-model objects from XWiki-model objects.
It has been created just to prevent code duplication in resource
implementations. Now I think
it's unlikely that somebody uses it outside the REST
module (a quick grep confirmed this for platform).
The only use case for a developer of a module to use this class is if
she wants to return a REST-model object and build it using the utility
methods.
I think this is quite unlikely.
AFAIU all parameters additions are about "pretty names"
(https://github.com/ldubost/xwiki-platform/compare/master...bd49bcc84e1dec3d…)
If we want to be conservative we might do the following: we can add
the new methods and preserve the old ones making them call the new
ones with default parameters.
* false in methods like this
https://github.com/ldubost/xwiki-platform/compare/master...bd49bcc84e1dec3d…
* null, false in methods like this
https://github.com/ldubost/xwiki-platform/compare/master...bd49bcc84e1dec3d…
. This implies that in the new implementation the if statement should
also check for null values (like in this case:
https://github.com/ldubost/xwiki-platform/compare/master...bd49bcc84e1dec3d…)
We could also think about whether continuing to keep this class in the
public API. It could make sense but I think that nobody will ever use
it so we can start to @deprecate it and eventually move it in internal
packages.
Based on what you say I'd say that these classes/methods were put public by mistake
and should all be moved to the internal package without going through deprecation.
Of course this means no other other XWiki modules should use them either since
they're internal.
Also this means that we don't provide any SPI
either since SPI are user-public. Is that what we want?
Yep
Thanks,
Fabio
Thanks
-Vincent
_______________________________________________
devs mailing list
devs(a)xwiki.org
http://lists.xwiki.org/mailman/listinfo/devs
25 Aug
25 Aug
5:40 p.m.
On Tue, Aug 21, 2012 at 10:18 PM, Vincent Massol <vincent(a)massol.net> wrote:
On Aug 21, 2012, at 2:18 PM, Fabio Mancinelli wrote:
The question is whether this is supposed to be a SPI or not.
+1 for internal, if it's not supposed to be used outside of the module
that's the definition of internal
On Fri, Jul 27, 2012 at 10:12 AM, Ludovic Dubost
<ludovic(a)xwiki.com> wrote:
Note that CLIRR doesn't have false positives so if it complains it means there's
a breakage. The only decision to take is whether it's an "acceptable"
breakage, i.e. we voluntarily break assuming that nobody was using it and accept that a
few users might get broken.
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
Yep, I think it's safe. We're adding stuff in a representation (page
summary) and keeping it also in the other, so API-wise it's ok. 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
The DomainObjectFactory is actually a utility class that is used to
build REST-model objects from XWiki-model objects.
It has been created just to prevent code duplication in resource
implementations. Now I think it's unlikely that somebody uses
it outside the REST
module (a quick grep confirmed this for platform).
The only use case for a developer of a module to use this class is if
she wants to return a REST-model object and build it using the utility
methods.
I think this is quite unlikely.
AFAIU all parameters additions are about "pretty names"
(https://github.com/ldubost/xwiki-platform/compare/master...bd49bcc84e1dec3d…)
If we want to be conservative we might do the following: we can add
the new methods and preserve the old ones making them call the new
ones with default parameters.
* false in methods like this
https://github.com/ldubost/xwiki-platform/compare/master...bd49bcc84e1dec3d…
* null, false in methods like this
https://github.com/ldubost/xwiki-platform/compare/master...bd49bcc84e1dec3d…
. This implies that in the new implementation the if statement should
also check for null values (like in this case:
https://github.com/ldubost/xwiki-platform/compare/master...bd49bcc84e1dec3d…)
We could also think about whether continuing to keep this class in the
public API. It could make sense but I think that nobody will ever use
it so we can start to @deprecate it and eventually move it in internal
packages.
Based on what you say I'd say that these classes/methods were put public by mistake
and should all be moved to the internal package without going through deprecation.
Of course this means no other other XWiki modules should use them either since
they're internal.
Also this means that we don't provide any SPI either since SPI are user-public. Is
that what we want?
Thanks
-Vincent
_______________________________________________
devs mailing list
devs(a)xwiki.org
http://lists.xwiki.org/mailman/listinfo/devs
--
Thomas Mortagne
8 Oct
8 Oct
4:35 p.m.
Hi,
All votes told to move the code to internal packages.
This is something I can do, however I'm not sure exactly which code
should go into the internal package and which one should stay where it
is.
Right now here is the list of classes failing or not the CLIRR tests
Not failing:
org.xwiki.rest.ComponentsObjectFactory
org.xwiki.rest.Constants
org.xwiki.rest.RangeIterable
org.xwiki.rest.Relations
org.xwiki.rest.Utils
org.xwiki.rest.XWikiAuthentication
org.xwiki.rest.XWikiJaxRsApplication
org.xwiki.rest.XWikiResource
org.xwiki.rest.XWikiRestComponent
org.xwiki.rest.XWikiRestletJaxRsApplication
org.xwiki.rest.XWikiRestletServlet
org.xwiki.rest.XWikiSecretVerifier
org.xwiki.rest.XWikiSetupCleanupFilter
org.xwiki.rest.exceptions.QueryExceptionMapper
org.xwiki.rest.exceptions.XWikiExceptionMapper
org.xwiki.rest.representations.TextPlainReader
org.xwiki.rest.representations.comments.FormUrlEncodedCommentReader
org.xwiki.rest.representations.comments.TextPlainCommentReader
org.xwiki.rest.representations.objects.FormUrlEncodedObjectReader
org.xwiki.rest.representations.objects.FormUrlEncodedPropertyReader
org.xwiki.rest.representations.objects.TextPlainPropertyReader
org.xwiki.rest.representations.pages.FormUrlEncodedPageReader
org.xwiki.rest.representations.pages.TextPlainPageReader
org.xwiki.rest.representations.tags.FormUrlEncodedTagsReader
org.xwiki.rest.representations.tags.TextPlainTagsReader
org.xwiki.rest.resources.BrowserAuthenticationResource
org.xwiki.rest.resources.RootResource
org.xwiki.rest.resources.SyntaxesResource
org.xwiki.rest.resources.attachments.AttachmentAtPageVersionResource
org.xwiki.rest.resources.attachments.AttachmentHistoryResource
org.xwiki.rest.resources.attachments.AttachmentResource
org.xwiki.rest.resources.attachments.AttachmentVersionResource
org.xwiki.rest.resources.classes.ClassPropertiesResource
org.xwiki.rest.resources.classes.ClassPropertyResource
org.xwiki.rest.resources.classes.ClassResource
org.xwiki.rest.resources.classes.ClassesResource
org.xwiki.rest.resources.objects.BaseObjectsResource
org.xwiki.rest.resources.pages.ModifiablePageResource
org.xwiki.rest.resources.pages.PageTagsResource
org.xwiki.rest.resources.pages.PageTranslationsResource
org.xwiki.rest.resources.spaces.SpaceResource
org.xwiki.rest.resources.spaces.SpacesResource
org.xwiki.rest.resources.tags.TagsResource
org.xwiki.rest.resources.wikis.WikiPagesResource
org.xwiki.rest.resources.wikis.WikiSearchQueryResource
org.xwiki.rest.resources.wikis.WikisResource
Failing:
org.xwiki.rest.DomainObjectFactory
org.xwiki.rest.resources.BaseAttachmentsResource
org.xwiki.rest.resources.BaseSearchResult
org.xwiki.rest.resources.ModificationsResource
org.xwiki.rest.resources.attachments.AttachmentsAtPageVersionResource
org.xwiki.rest.resources.attachments.AttachmentsResource
org.xwiki.rest.resources.comments.CommentResource
org.xwiki.rest.resources.comments.CommentVersionResource
org.xwiki.rest.resources.comments.CommentsResource
org.xwiki.rest.resources.comments.CommentsVersionResource
org.xwiki.rest.resources.objects.AllObjectsForClassNameResource
org.xwiki.rest.resources.objects.ObjectAtPageVersionResource
org.xwiki.rest.resources.objects.ObjectPropertiesAtPageVersionResource
org.xwiki.rest.resources.objects.ObjectPropertiesResource
org.xwiki.rest.resources.objects.ObjectPropertyAtPageVersionResource
org.xwiki.rest.resources.objects.ObjectPropertyResource
org.xwiki.rest.resources.objects.ObjectResource
org.xwiki.rest.resources.objects.ObjectsAtPageVersionResource
org.xwiki.rest.resources.objects.ObjectsForClassNameResource
org.xwiki.rest.resources.objects.ObjectsResource
org.xwiki.rest.resources.pages.PageChildrenResource
org.xwiki.rest.resources.pages.PageHistoryResource
org.xwiki.rest.resources.pages.PageResource
org.xwiki.rest.resources.pages.PageTranslationHistoryResource
org.xwiki.rest.resources.pages.PageTranslationResource
org.xwiki.rest.resources.pages.PageTranslationVersionResource
org.xwiki.rest.resources.pages.PageVersionResource
org.xwiki.rest.resources.pages.PagesResource
org.xwiki.rest.resources.spaces.SpaceAttachmentsResource
org.xwiki.rest.resources.spaces.SpaceSearchResource
org.xwiki.rest.resources.tags.PagesForTagsResource
org.xwiki.rest.resources.wikis.WikiAttachmentsResource
org.xwiki.rest.resources.wikis.WikiSearchResource
So which one of these are not internal ?
Ludovic
2012/8/25 Thomas Mortagne <thomas.mortagne(a)xwiki.com>om>:
On Tue, Aug 21, 2012 at 10:18 PM, Vincent Massol
<vincent(a)massol.net> wrote:
--
Ludovic Dubost
Founder and CEO
Blog: http://blog.ludovic.org/
XWiki: http://www.xwiki.com
Skype: ldubost GTalk: ldubost
On Aug 21, 2012, at 2:18 PM, Fabio Mancinelli wrote:
The question is whether this is supposed to be a SPI or not.
+1 for internal, if it's not supposed to be used outside of the module
that's the definition of internal
On Fri, Jul 27, 2012 at 10:12 AM, Ludovic Dubost
<ludovic(a)xwiki.com> wrote:
Note that CLIRR doesn't have false positives so if it complains it means there's
a breakage. The only decision to take is whether it's an "acceptable"
breakage, i.e. we voluntarily break assuming that nobody was using it and accept that a
few users might get broken.
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
Yep, I think it's safe. We're adding stuff in a representation (page
summary) and keeping it also in the other, so API-wise it's ok. 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
The DomainObjectFactory is actually a utility class that is used to
build REST-model objects from XWiki-model objects.
It has been created just to prevent code duplication in resource
implementations. Now I think it's unlikely that somebody uses
it outside the REST
module (a quick grep confirmed this for platform).
The only use case for a developer of a module to use this class is if
she wants to return a REST-model object and build it using the utility
methods.
I think this is quite unlikely.
AFAIU all parameters additions are about "pretty names"
(https://github.com/ldubost/xwiki-platform/compare/master...bd49bcc84e1dec3d…)
If we want to be conservative we might do the following: we can add
the new methods and preserve the old ones making them call the new
ones with default parameters.
* false in methods like this
https://github.com/ldubost/xwiki-platform/compare/master...bd49bcc84e1dec3d…
* null, false in methods like this
https://github.com/ldubost/xwiki-platform/compare/master...bd49bcc84e1dec3d…
. This implies that in the new implementation the if statement should
also check for null values (like in this case:
https://github.com/ldubost/xwiki-platform/compare/master...bd49bcc84e1dec3d…)
We could also think about whether continuing to keep this class in the
public API. It could make sense but I think that nobody will ever use
it so we can start to @deprecate it and eventually move it in internal
packages.
Based on what you say I'd say that these classes/methods were put public by mistake
and should all be moved to the internal package without going through deprecation.
Of course this means no other other XWiki modules should use them either since
they're internal.
Also this means that we don't provide any SPI either since SPI are user-public. Is
that what we want?
Thanks
-Vincent
_______________________________________________
devs mailing list
devs(a)xwiki.org
http://lists.xwiki.org/mailman/listinfo/devs
--
Thomas Mortagne
_______________________________________________
devs mailing list
devs(a)xwiki.org
http://lists.xwiki.org/mailman/listinfo/devs
10 Oct
10 Oct
4:37 p.m.
Following a discussion with Vincent, I've created the
feature-restimprovements feature branch on the xwiki xwiki-platform github
and passed it to fabio who will:
- integrate his own patches for wiki creation and xar upload
- move internal code to internal
I've create a new pull request for this branch
https://github.com/xwiki/xwiki-platform/pull/71
The older pull request (https://github.com/xwiki/xwiki-platform/pull/56)
has been closed.
Ludovic
2012/10/8 Ludovic Dubost <ludovic(a)xwiki.com>
Hi,
All votes told to move the code to internal packages.
This is something I can do, however I'm not sure exactly which code
should go into the internal package and which one should stay where it
is.
Right now here is the list of classes failing or not the CLIRR tests
Not failing:
org.xwiki.rest.ComponentsObjectFactory
org.xwiki.rest.Constants
org.xwiki.rest.RangeIterable
org.xwiki.rest.Relations
org.xwiki.rest.Utils
org.xwiki.rest.XWikiAuthentication
org.xwiki.rest.XWikiJaxRsApplication
org.xwiki.rest.XWikiResource
org.xwiki.rest.XWikiRestComponent
org.xwiki.rest.XWikiRestletJaxRsApplication
org.xwiki.rest.XWikiRestletServlet
org.xwiki.rest.XWikiSecretVerifier
org.xwiki.rest.XWikiSetupCleanupFilter
org.xwiki.rest.exceptions.QueryExceptionMapper
org.xwiki.rest.exceptions.XWikiExceptionMapper
org.xwiki.rest.representations.TextPlainReader
org.xwiki.rest.representations.comments.FormUrlEncodedCommentReader
org.xwiki.rest.representations.comments.TextPlainCommentReader
org.xwiki.rest.representations.objects.FormUrlEncodedObjectReader
org.xwiki.rest.representations.objects.FormUrlEncodedPropertyReader
org.xwiki.rest.representations.objects.TextPlainPropertyReader
org.xwiki.rest.representations.pages.FormUrlEncodedPageReader
org.xwiki.rest.representations.pages.TextPlainPageReader
org.xwiki.rest.representations.tags.FormUrlEncodedTagsReader
org.xwiki.rest.representations.tags.TextPlainTagsReader
org.xwiki.rest.resources.BrowserAuthenticationResource
org.xwiki.rest.resources.RootResource
org.xwiki.rest.resources.SyntaxesResource
org.xwiki.rest.resources.attachments.AttachmentAtPageVersionResource
org.xwiki.rest.resources.attachments.AttachmentHistoryResource
org.xwiki.rest.resources.attachments.AttachmentResource
org.xwiki.rest.resources.attachments.AttachmentVersionResource
org.xwiki.rest.resources.classes.ClassPropertiesResource
org.xwiki.rest.resources.classes.ClassPropertyResource
org.xwiki.rest.resources.classes.ClassResource
org.xwiki.rest.resources.classes.ClassesResource
org.xwiki.rest.resources.objects.BaseObjectsResource
org.xwiki.rest.resources.pages.ModifiablePageResource
org.xwiki.rest.resources.pages.PageTagsResource
org.xwiki.rest.resources.pages.PageTranslationsResource
org.xwiki.rest.resources.spaces.SpaceResource
org.xwiki.rest.resources.spaces.SpacesResource
org.xwiki.rest.resources.tags.TagsResource
org.xwiki.rest.resources.wikis.WikiPagesResource
org.xwiki.rest.resources.wikis.WikiSearchQueryResource
org.xwiki.rest.resources.wikis.WikisResource
Failing:
org.xwiki.rest.DomainObjectFactory
org.xwiki.rest.resources.BaseAttachmentsResource
org.xwiki.rest.resources.BaseSearchResult
org.xwiki.rest.resources.ModificationsResource
org.xwiki.rest.resources.attachments.AttachmentsAtPageVersionResource
org.xwiki.rest.resources.attachments.AttachmentsResource
org.xwiki.rest.resources.comments.CommentResource
org.xwiki.rest.resources.comments.CommentVersionResource
org.xwiki.rest.resources.comments.CommentsResource
org.xwiki.rest.resources.comments.CommentsVersionResource
org.xwiki.rest.resources.objects.AllObjectsForClassNameResource
org.xwiki.rest.resources.objects.ObjectAtPageVersionResource
org.xwiki.rest.resources.objects.ObjectPropertiesAtPageVersionResource
org.xwiki.rest.resources.objects.ObjectPropertiesResource
org.xwiki.rest.resources.objects.ObjectPropertyAtPageVersionResource
org.xwiki.rest.resources.objects.ObjectPropertyResource
org.xwiki.rest.resources.objects.ObjectResource
org.xwiki.rest.resources.objects.ObjectsAtPageVersionResource
org.xwiki.rest.resources.objects.ObjectsForClassNameResource
org.xwiki.rest.resources.objects.ObjectsResource
org.xwiki.rest.resources.pages.PageChildrenResource
org.xwiki.rest.resources.pages.PageHistoryResource
org.xwiki.rest.resources.pages.PageResource
org.xwiki.rest.resources.pages.PageTranslationHistoryResource
org.xwiki.rest.resources.pages.PageTranslationResource
org.xwiki.rest.resources.pages.PageTranslationVersionResource
org.xwiki.rest.resources.pages.PageVersionResource
org.xwiki.rest.resources.pages.PagesResource
org.xwiki.rest.resources.spaces.SpaceAttachmentsResource
org.xwiki.rest.resources.spaces.SpaceSearchResource
org.xwiki.rest.resources.tags.PagesForTagsResource
org.xwiki.rest.resources.wikis.WikiAttachmentsResource
org.xwiki.rest.resources.wikis.WikiSearchResource
So which one of these are not internal ?
Ludovic
2012/8/25 Thomas Mortagne <thomas.mortagne(a)xwiki.com>om>:
--
Ludovic Dubost
Founder and CEO
Blog: http://blog.ludovic.org/
XWiki: http://www.xwiki.com
Skype: ldubost GTalk: ldubost
--
Ludovic Dubost
Founder and CEO
Blog: http://blog.ludovic.org/
XWiki: http://www.xwiki.com
Skype: ldubost GTalk: ldubost
On Tue, Aug 21, 2012 at 10:18 PM, Vincent Massol
<vincent(a)massol.net>
wrote:
>
> On Aug 21, 2012, at 2:18 PM, Fabio Mancinelli wrote:
>
>> On Fri, Jul 27, 2012 at 10:12 AM, Ludovic Dubost <ludovic(a)xwiki.com>
wrote:
>>> 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
>>>
>> Yep, I think it's safe. We're adding stuff in a representation (page
>> summary) and keeping it also in the other, so API-wise it's ok.
>
> Note that CLIRR doesn't have false positives so if it complains it
means
there's a breakage. The only decision to take is whether it's an
"acceptable" breakage, i.e. we voluntarily break assuming that nobody was
using it and accept that a few users might get broken.
>
>>> 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
>>
>> The DomainObjectFactory is actually a utility class that is used to
>> build REST-model objects from XWiki-model objects.
>> It has been created just to prevent code duplication in resource
>> implementations.
>
> The question is whether this is supposed to be a SPI or not.
>
>> Now I think it's unlikely that somebody uses it outside the REST
>> module (a quick grep confirmed this for platform).
>>
>> The only use case for a developer of a module to use this class is if
>> she wants to return a REST-model object and build it using the utility
>> methods.
>> I think this is quite unlikely.
>>
>> AFAIU all parameters additions are about "pretty names"
>> (
https://github.com/ldubost/xwiki-platform/compare/master...bd49bcc84e1dec3d…
)
>>
>> If we want to be conservative we might do the following: we can add
>> the new methods and preserve the old ones making them call the new
>> ones with default parameters.
>>
>> * false in methods like this
>>
https://github.com/ldubost/xwiki-platform/compare/master...bd49bcc84e1dec3d…
>> * null, false in methods like this
>>
https://github.com/ldubost/xwiki-platform/compare/master...bd49bcc84e1dec3d…
>> . This implies that in the new
implementation the if statement should
>> also check for null values (like in this case:
>>
https://github.com/ldubost/xwiki-platform/compare/master...bd49bcc84e1dec3d…
)
>>
>> We could also think about whether continuing to keep this class in the
>> public API. It could make sense but I think that nobody will ever use
>> it so we can start to @deprecate it and eventually move it in internal
>> packages.
>
> Based on what you say I'd say that these classes/methods were put
public
by mistake and should all be moved to the internal package without
going through deprecation.
+1 for internal, if it's not supposed to be used outside of the module
that's the definition of internal
>
> Of course this means no other other XWiki modules should use them
either since
they're internal.
>
> Also this means that we don't provide any SPI either since SPI are
user-public. Is that what we want?
Thanks
-Vincent
_______________________________________________
devs mailing list
devs(a)xwiki.org
http://lists.xwiki.org/mailman/listinfo/devs
--
Thomas Mortagne
_______________________________________________
devs mailing list
devs(a)xwiki.org
http://lists.xwiki.org/mailman/listinfo/devs
17 Oct
17 Oct
11:14 p.m.
Hi everybody
On Wed, Oct 10, 2012 at 4:37 PM, Ludovic Dubost <ludovic(a)xwiki.com> wrote:
Following a discussion with Vincent, I've created
the
feature-restimprovements feature branch on the xwiki xwiki-platform github
and passed it to fabio who will:
- integrate his own patches for wiki creation and xar upload
- move internal code to internal
I've create a new pull request for this branch
https://github.com/xwiki/xwiki-platform/pull/71
The older pull request (https://github.com/xwiki/xwiki-platform/pull/56)
has been closed.
I did quite a lot of work on this pull request with several changes,
mostly related to keep things consistent and some bugfixes.
It seems to me that the pull request is ready to be merged. The code
is not complex, but since query building and option handling make it
quite complicated it would be good if somebody could have a look at it
before I merge it.
I also wrote some integration tests to check that things are working
fine: https://github.com/xwiki/xwiki-enterprise/pull/33
Thanks,
Fabio
Ludovic
2012/10/8 Ludovic Dubost <ludovic(a)xwiki.com>
Hi,
All votes told to move the code to internal packages.
This is something I can do, however I'm not sure exactly which code
should go into the internal package and which one should stay where it
is.
Right now here is the list of classes failing or not the CLIRR tests
Not failing:
org.xwiki.rest.ComponentsObjectFactory
org.xwiki.rest.Constants
org.xwiki.rest.RangeIterable
org.xwiki.rest.Relations
org.xwiki.rest.Utils
org.xwiki.rest.XWikiAuthentication
org.xwiki.rest.XWikiJaxRsApplication
org.xwiki.rest.XWikiResource
org.xwiki.rest.XWikiRestComponent
org.xwiki.rest.XWikiRestletJaxRsApplication
org.xwiki.rest.XWikiRestletServlet
org.xwiki.rest.XWikiSecretVerifier
org.xwiki.rest.XWikiSetupCleanupFilter
org.xwiki.rest.exceptions.QueryExceptionMapper
org.xwiki.rest.exceptions.XWikiExceptionMapper
org.xwiki.rest.representations.TextPlainReader
org.xwiki.rest.representations.comments.FormUrlEncodedCommentReader
org.xwiki.rest.representations.comments.TextPlainCommentReader
org.xwiki.rest.representations.objects.FormUrlEncodedObjectReader
org.xwiki.rest.representations.objects.FormUrlEncodedPropertyReader
org.xwiki.rest.representations.objects.TextPlainPropertyReader
org.xwiki.rest.representations.pages.FormUrlEncodedPageReader
org.xwiki.rest.representations.pages.TextPlainPageReader
org.xwiki.rest.representations.tags.FormUrlEncodedTagsReader
org.xwiki.rest.representations.tags.TextPlainTagsReader
org.xwiki.rest.resources.BrowserAuthenticationResource
org.xwiki.rest.resources.RootResource
org.xwiki.rest.resources.SyntaxesResource
org.xwiki.rest.resources.attachments.AttachmentAtPageVersionResource
org.xwiki.rest.resources.attachments.AttachmentHistoryResource
org.xwiki.rest.resources.attachments.AttachmentResource
org.xwiki.rest.resources.attachments.AttachmentVersionResource
org.xwiki.rest.resources.classes.ClassPropertiesResource
org.xwiki.rest.resources.classes.ClassPropertyResource
org.xwiki.rest.resources.classes.ClassResource
org.xwiki.rest.resources.classes.ClassesResource
org.xwiki.rest.resources.objects.BaseObjectsResource
org.xwiki.rest.resources.pages.ModifiablePageResource
org.xwiki.rest.resources.pages.PageTagsResource
org.xwiki.rest.resources.pages.PageTranslationsResource
org.xwiki.rest.resources.spaces.SpaceResource
org.xwiki.rest.resources.spaces.SpacesResource
org.xwiki.rest.resources.tags.TagsResource
org.xwiki.rest.resources.wikis.WikiPagesResource
org.xwiki.rest.resources.wikis.WikiSearchQueryResource
org.xwiki.rest.resources.wikis.WikisResource
Failing:
org.xwiki.rest.DomainObjectFactory
org.xwiki.rest.resources.BaseAttachmentsResource
org.xwiki.rest.resources.BaseSearchResult
org.xwiki.rest.resources.ModificationsResource
org.xwiki.rest.resources.attachments.AttachmentsAtPageVersionResource
org.xwiki.rest.resources.attachments.AttachmentsResource
org.xwiki.rest.resources.comments.CommentResource
org.xwiki.rest.resources.comments.CommentVersionResource
org.xwiki.rest.resources.comments.CommentsResource
org.xwiki.rest.resources.comments.CommentsVersionResource
org.xwiki.rest.resources.objects.AllObjectsForClassNameResource
org.xwiki.rest.resources.objects.ObjectAtPageVersionResource
org.xwiki.rest.resources.objects.ObjectPropertiesAtPageVersionResource
org.xwiki.rest.resources.objects.ObjectPropertiesResource
org.xwiki.rest.resources.objects.ObjectPropertyAtPageVersionResource
org.xwiki.rest.resources.objects.ObjectPropertyResource
org.xwiki.rest.resources.objects.ObjectResource
org.xwiki.rest.resources.objects.ObjectsAtPageVersionResource
org.xwiki.rest.resources.objects.ObjectsForClassNameResource
org.xwiki.rest.resources.objects.ObjectsResource
org.xwiki.rest.resources.pages.PageChildrenResource
org.xwiki.rest.resources.pages.PageHistoryResource
org.xwiki.rest.resources.pages.PageResource
org.xwiki.rest.resources.pages.PageTranslationHistoryResource
org.xwiki.rest.resources.pages.PageTranslationResource
org.xwiki.rest.resources.pages.PageTranslationVersionResource
org.xwiki.rest.resources.pages.PageVersionResource
org.xwiki.rest.resources.pages.PagesResource
org.xwiki.rest.resources.spaces.SpaceAttachmentsResource
org.xwiki.rest.resources.spaces.SpaceSearchResource
org.xwiki.rest.resources.tags.PagesForTagsResource
org.xwiki.rest.resources.wikis.WikiAttachmentsResource
org.xwiki.rest.resources.wikis.WikiSearchResource
So which one of these are not internal ?
Ludovic
2012/8/25 Thomas Mortagne <thomas.mortagne(a)xwiki.com>om>:
--
Ludovic Dubost
Founder and CEO
Blog: http://blog.ludovic.org/
XWiki: http://www.xwiki.com
Skype: ldubost GTalk: ldubost
--
Ludovic Dubost
Founder and CEO
Blog: http://blog.ludovic.org/
XWiki: http://www.xwiki.com
Skype: ldubost GTalk: ldubost
_______________________________________________
devs mailing list
devs(a)xwiki.org
http://lists.xwiki.org/mailman/listinfo/devs On Tue, Aug 21, 2012 at 10:18 PM, Vincent Massol
<vincent(a)massol.net>
wrote:
>
> On Aug 21, 2012, at 2:18 PM, Fabio Mancinelli wrote:
>
>> On Fri, Jul 27, 2012 at 10:12 AM, Ludovic Dubost <ludovic(a)xwiki.com>
wrote:
>>> 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
>>>
>> Yep, I think it's safe. We're adding stuff in a representation (page
>> summary) and keeping it also in the other, so API-wise it's ok.
>
> Note that CLIRR doesn't have false positives so if it complains it
means
there's a breakage. The only decision to take is whether it's an
"acceptable" breakage, i.e. we voluntarily break assuming that nobody was
using it and accept that a few users might get broken.
>
>>> 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
>>
>> The DomainObjectFactory is actually a utility class that is used to
>> build REST-model objects from XWiki-model objects.
>> It has been created just to prevent code duplication in resource
>> implementations.
>
> The question is whether this is supposed to be a SPI or not.
>
>> Now I think it's unlikely that somebody uses it outside the REST
>> module (a quick grep confirmed this for platform).
>>
>> The only use case for a developer of a module to use this class is if
>> she wants to return a REST-model object and build it using the utility
>> methods.
>> I think this is quite unlikely.
>>
>> AFAIU all parameters additions are about "pretty names"
>> (
https://github.com/ldubost/xwiki-platform/compare/master...bd49bcc84e1dec3d…
)
>>
>> If we want to be conservative we might do the following: we can add
>> the new methods and preserve the old ones making them call the new
>> ones with default parameters.
>>
>> * false in methods like this
>>
https://github.com/ldubost/xwiki-platform/compare/master...bd49bcc84e1dec3d…
>> * null, false in methods like this
>>
https://github.com/ldubost/xwiki-platform/compare/master...bd49bcc84e1dec3d…
>> . This implies that in the new
implementation the if statement should
>> also check for null values (like in this case:
>>
https://github.com/ldubost/xwiki-platform/compare/master...bd49bcc84e1dec3d…
)
>>
>> We could also think about whether continuing to keep this class in the
>> public API. It could make sense but I think that nobody will ever use
>> it so we can start to @deprecate it and eventually move it in internal
>> packages.
>
> Based on what you say I'd say that these classes/methods were put
public
by mistake and should all be moved to the internal package without
going through deprecation.
+1 for internal, if it's not supposed to be used outside of the module
that's the definition of internal
>
> Of course this means no other other XWiki modules should use them
either since
they're internal.
>
> Also this means that we don't provide any SPI either since SPI are
user-public. Is that what we want?
Thanks
-Vincent
_______________________________________________
devs mailing list
devs(a)xwiki.org
http://lists.xwiki.org/mailman/listinfo/devs
--
Thomas Mortagne
_______________________________________________
devs mailing list
devs(a)xwiki.org
http://lists.xwiki.org/mailman/listinfo/devs
19 Oct
19 Oct
8:24 p.m.
Hi,
I finally merged the pull request.
As an additional step I've moved all the REST components to internal packages.
To do so I added a CLIRR skip to the POM that should be removed on the
next release.
I'll merge the XAR import and Wiki creation in the next release
because they need some additional work.
Thanks,
Fabio
On Wed, Oct 17, 2012 at 11:14 PM, Fabio Mancinelli
<fabio.mancinelli(a)xwiki.com> wrote:
Hi everybody
On Wed, Oct 10, 2012 at 4:37 PM, Ludovic Dubost <ludovic(a)xwiki.com> wrote:
Following a discussion with Vincent, I've
created the
feature-restimprovements feature branch on the xwiki xwiki-platform github
and passed it to fabio who will:
- integrate his own patches for wiki creation and xar upload
- move internal code to internal
I've create a new pull request for this branch
https://github.com/xwiki/xwiki-platform/pull/71
The older pull request (https://github.com/xwiki/xwiki-platform/pull/56)
has been closed.
I did quite a lot of work on this pull request with several changes,
mostly related to keep things consistent and some bugfixes.
It seems to me that the pull request is ready to be merged. The code
is not complex, but since query building and option handling make it
quite complicated it would be good if somebody could have a look at it
before I merge it.
I also wrote some integration tests to check that things are working
fine: https://github.com/xwiki/xwiki-enterprise/pull/33
Thanks,
Fabio
> Ludovic
>
> 2012/10/8 Ludovic Dubost <ludovic(a)xwiki.com>
>
>> Hi,
>>
>> All votes told to move the code to internal packages.
>>
>> This is something I can do, however I'm not sure exactly which code
>> should go into the internal package and which one should stay where it
>> is.
>>
>> Right now here is the list of classes failing or not the CLIRR tests
>>
>> Not failing:
>>
>> org.xwiki.rest.ComponentsObjectFactory
>> org.xwiki.rest.Constants
>> org.xwiki.rest.RangeIterable
>> org.xwiki.rest.Relations
>> org.xwiki.rest.Utils
>> org.xwiki.rest.XWikiAuthentication
>> org.xwiki.rest.XWikiJaxRsApplication
>> org.xwiki.rest.XWikiResource
>> org.xwiki.rest.XWikiRestComponent
>> org.xwiki.rest.XWikiRestletJaxRsApplication
>> org.xwiki.rest.XWikiRestletServlet
>> org.xwiki.rest.XWikiSecretVerifier
>> org.xwiki.rest.XWikiSetupCleanupFilter
>> org.xwiki.rest.exceptions.QueryExceptionMapper
>> org.xwiki.rest.exceptions.XWikiExceptionMapper
>> org.xwiki.rest.representations.TextPlainReader
>> org.xwiki.rest.representations.comments.FormUrlEncodedCommentReader
>> org.xwiki.rest.representations.comments.TextPlainCommentReader
>> org.xwiki.rest.representations.objects.FormUrlEncodedObjectReader
>> org.xwiki.rest.representations.objects.FormUrlEncodedPropertyReader
>> org.xwiki.rest.representations.objects.TextPlainPropertyReader
>> org.xwiki.rest.representations.pages.FormUrlEncodedPageReader
>> org.xwiki.rest.representations.pages.TextPlainPageReader
>> org.xwiki.rest.representations.tags.FormUrlEncodedTagsReader
>> org.xwiki.rest.representations.tags.TextPlainTagsReader
>> org.xwiki.rest.resources.BrowserAuthenticationResource
>> org.xwiki.rest.resources.RootResource
>> org.xwiki.rest.resources.SyntaxesResource
>> org.xwiki.rest.resources.attachments.AttachmentAtPageVersionResource
>> org.xwiki.rest.resources.attachments.AttachmentHistoryResource
>> org.xwiki.rest.resources.attachments.AttachmentResource
>> org.xwiki.rest.resources.attachments.AttachmentVersionResource
>> org.xwiki.rest.resources.classes.ClassPropertiesResource
>> org.xwiki.rest.resources.classes.ClassPropertyResource
>> org.xwiki.rest.resources.classes.ClassResource
>> org.xwiki.rest.resources.classes.ClassesResource
>> org.xwiki.rest.resources.objects.BaseObjectsResource
>> org.xwiki.rest.resources.pages.ModifiablePageResource
>> org.xwiki.rest.resources.pages.PageTagsResource
>> org.xwiki.rest.resources.pages.PageTranslationsResource
>> org.xwiki.rest.resources.spaces.SpaceResource
>> org.xwiki.rest.resources.spaces.SpacesResource
>> org.xwiki.rest.resources.tags.TagsResource
>> org.xwiki.rest.resources.wikis.WikiPagesResource
>> org.xwiki.rest.resources.wikis.WikiSearchQueryResource
>> org.xwiki.rest.resources.wikis.WikisResource
>>
>> Failing:
>>
>> org.xwiki.rest.DomainObjectFactory
>> org.xwiki.rest.resources.BaseAttachmentsResource
>> org.xwiki.rest.resources.BaseSearchResult
>> org.xwiki.rest.resources.ModificationsResource
>> org.xwiki.rest.resources.attachments.AttachmentsAtPageVersionResource
>> org.xwiki.rest.resources.attachments.AttachmentsResource
>> org.xwiki.rest.resources.comments.CommentResource
>> org.xwiki.rest.resources.comments.CommentVersionResource
>> org.xwiki.rest.resources.comments.CommentsResource
>> org.xwiki.rest.resources.comments.CommentsVersionResource
>> org.xwiki.rest.resources.objects.AllObjectsForClassNameResource
>> org.xwiki.rest.resources.objects.ObjectAtPageVersionResource
>> org.xwiki.rest.resources.objects.ObjectPropertiesAtPageVersionResource
>> org.xwiki.rest.resources.objects.ObjectPropertiesResource
>> org.xwiki.rest.resources.objects.ObjectPropertyAtPageVersionResource
>> org.xwiki.rest.resources.objects.ObjectPropertyResource
>> org.xwiki.rest.resources.objects.ObjectResource
>> org.xwiki.rest.resources.objects.ObjectsAtPageVersionResource
>> org.xwiki.rest.resources.objects.ObjectsForClassNameResource
>> org.xwiki.rest.resources.objects.ObjectsResource
>> org.xwiki.rest.resources.pages.PageChildrenResource
>> org.xwiki.rest.resources.pages.PageHistoryResource
>> org.xwiki.rest.resources.pages.PageResource
>> org.xwiki.rest.resources.pages.PageTranslationHistoryResource
>> org.xwiki.rest.resources.pages.PageTranslationResource
>> org.xwiki.rest.resources.pages.PageTranslationVersionResource
>> org.xwiki.rest.resources.pages.PageVersionResource
>> org.xwiki.rest.resources.pages.PagesResource
>> org.xwiki.rest.resources.spaces.SpaceAttachmentsResource
>> org.xwiki.rest.resources.spaces.SpaceSearchResource
>> org.xwiki.rest.resources.tags.PagesForTagsResource
>> org.xwiki.rest.resources.wikis.WikiAttachmentsResource
>> org.xwiki.rest.resources.wikis.WikiSearchResource
>>
>>
>> So which one of these are not internal ?
>>
>> Ludovic
>>
>> 2012/8/25 Thomas Mortagne <thomas.mortagne(a)xwiki.com>om>:
>> > On Tue, Aug 21, 2012 at 10:18 PM, Vincent Massol <vincent(a)massol.net>
>> wrote:
>> >>
>> >> On Aug 21, 2012, at 2:18 PM, Fabio Mancinelli wrote:
>> >>
>> >>> On Fri, Jul 27, 2012 at 10:12 AM, Ludovic Dubost
<ludovic(a)xwiki.com>
>> wrote:
>> >>>> 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
>> >>>>
>> >>> Yep, I think it's safe. We're adding stuff in a
representation (page
>> >>> summary) and keeping it also in the other, so API-wise it's ok.
>> >>
>> >> Note that CLIRR doesn't have false positives so if it complains it
>> means there's a breakage. The only decision to take is whether it's an
>> "acceptable" breakage, i.e. we voluntarily break assuming that nobody
was
>> using it and accept that a few users might get broken.
>> >>
>> >>>> 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
>> >>>
>> >>> The DomainObjectFactory is actually a utility class that is used to
>> >>> build REST-model objects from XWiki-model objects.
>> >>> It has been created just to prevent code duplication in resource
>> >>> implementations.
>> >>
>> >> The question is whether this is supposed to be a SPI or not.
>> >>
>> >>> Now I think it's unlikely that somebody uses it outside the
REST
>> >>> module (a quick grep confirmed this for platform).
>> >>>
>> >>> The only use case for a developer of a module to use this class is
if
>> >>> she wants to return a REST-model object and build it using the
utility
>> >>> methods.
>> >>> I think this is quite unlikely.
>> >>>
>> >>> AFAIU all parameters additions are about "pretty names"
>> >>> (
>>
https://github.com/ldubost/xwiki-platform/compare/master...bd49bcc84e1dec3d…
>> )
>> >>>
>> >>> If we want to be conservative we might do the following: we can add
>> >>> the new methods and preserve the old ones making them call the new
>> >>> ones with default parameters.
>> >>>
>> >>> * false in methods like this
>> >>>
>>
https://github.com/ldubost/xwiki-platform/compare/master...bd49bcc84e1dec3d…
>> >>> * null, false in methods like this
>> >>>
>>
https://github.com/ldubost/xwiki-platform/compare/master...bd49bcc84e1dec3d…
>> >>> . This implies that in the new implementation the if statement
should
>> >>> also check for null values (like in this case:
>> >>>
>>
https://github.com/ldubost/xwiki-platform/compare/master...bd49bcc84e1dec3d…
>> )
>> >>>
>> >>> We could also think about whether continuing to keep this class in
the
>> >>> public API. It could make sense but I think that nobody will ever
use
>> >>> it so we can start to @deprecate it and eventually move it in
internal
>> >>> packages.
>> >>
>> >> Based on what you say I'd say that these classes/methods were put
>> public by mistake and should all be moved to the internal package without
>> going through deprecation.
>> >
>> > +1 for internal, if it's not supposed to be used outside of the module
>> > that's the definition of internal
>> >
>> >>
>> >> Of course this means no other other XWiki modules should use them
>> either since they're internal.
>> >>
>> >> Also this means that we don't provide any SPI either since SPI are
>> user-public. Is that what we want?
>> >>
>> >> Thanks
>> >> -Vincent
>> >> _______________________________________________
>> >> devs mailing list
>> >> devs(a)xwiki.org
>> >> http://lists.xwiki.org/mailman/listinfo/devs
>> >
>> >
>> >
>> > --
>> > Thomas Mortagne
>> > _______________________________________________
>> > devs mailing list
>> > devs(a)xwiki.org
>> > http://lists.xwiki.org/mailman/listinfo/devs
>>
>>
>>
>> --
>> Ludovic Dubost
>> Founder and CEO
>> Blog: http://blog.ludovic.org/
>> XWiki: http://www.xwiki.com
>> Skype: ldubost GTalk: ldubost
>>
>
>
>
> --
> Ludovic Dubost
> Founder and CEO
> Blog: http://blog.ludovic.org/
> XWiki: http://www.xwiki.com
> Skype: ldubost GTalk: ldubost
> _______________________________________________
> devs mailing list
> devs(a)xwiki.org
> http://lists.xwiki.org/mailman/listinfo/devs
10:04 p.m.
Well done ! This will help the mobile app !
Envoyé de mon iPhone
Le 19 oct. 2012 à 20:24, Fabio Mancinelli <fabio.mancinelli(a)xwiki.com> a écrit :
Hi,
I finally merged the pull request.
As an additional step I've moved all the REST components to internal packages.
To do so I added a CLIRR skip to the POM that should be removed on the
next release.
I'll merge the XAR import and Wiki creation in the next release
because they need some additional work.
Thanks,
Fabio
On Wed, Oct 17, 2012 at 11:14 PM, Fabio Mancinelli
<fabio.mancinelli(a)xwiki.com> wrote:
Hi everybody
On Wed, Oct 10, 2012 at 4:37 PM, Ludovic Dubost <ludovic(a)xwiki.com> wrote:
_______________________________________________
devs mailing list
devs(a)xwiki.org
http://lists.xwiki.org/mailman/listinfo/devs Following a discussion with Vincent, I've
created the
feature-restimprovements feature branch on the xwiki xwiki-platform github
and passed it to fabio who will:
- integrate his own patches for wiki creation and xar upload
- move internal code to internal
I've create a new pull request for this branch
https://github.com/xwiki/xwiki-platform/pull/71
The older pull request (https://github.com/xwiki/xwiki-platform/pull/56)
has been closed.
I did quite a lot of work on this pull request with several
changes,
mostly related to keep things consistent and some bugfixes.
It seems to me that the pull request is ready to be merged. The code
is not complex, but since query building and option handling make it
quite complicated it would be good if somebody could have a look at it
before I merge it.
I also wrote some integration tests to check that things are working
fine: https://github.com/xwiki/xwiki-enterprise/pull/33
Thanks,
Fabio
> Ludovic
>
> 2012/10/8 Ludovic Dubost <ludovic(a)xwiki.com>
>
>> Hi,
>>
>> All votes told to move the code to internal packages.
>>
>> This is something I can do, however I'm not sure exactly which code
>> should go into the internal package and which one should stay where it
>> is.
>>
>> Right now here is the list of classes failing or not the CLIRR tests
>>
>> Not failing:
>>
>> org.xwiki.rest.ComponentsObjectFactory
>> org.xwiki.rest.Constants
>> org.xwiki.rest.RangeIterable
>> org.xwiki.rest.Relations
>> org.xwiki.rest.Utils
>> org.xwiki.rest.XWikiAuthentication
>> org.xwiki.rest.XWikiJaxRsApplication
>> org.xwiki.rest.XWikiResource
>> org.xwiki.rest.XWikiRestComponent
>> org.xwiki.rest.XWikiRestletJaxRsApplication
>> org.xwiki.rest.XWikiRestletServlet
>> org.xwiki.rest.XWikiSecretVerifier
>> org.xwiki.rest.XWikiSetupCleanupFilter
>> org.xwiki.rest.exceptions.QueryExceptionMapper
>> org.xwiki.rest.exceptions.XWikiExceptionMapper
>> org.xwiki.rest.representations.TextPlainReader
>> org.xwiki.rest.representations.comments.FormUrlEncodedCommentReader
>> org.xwiki.rest.representations.comments.TextPlainCommentReader
>> org.xwiki.rest.representations.objects.FormUrlEncodedObjectReader
>> org.xwiki.rest.representations.objects.FormUrlEncodedPropertyReader
>> org.xwiki.rest.representations.objects.TextPlainPropertyReader
>> org.xwiki.rest.representations.pages.FormUrlEncodedPageReader
>> org.xwiki.rest.representations.pages.TextPlainPageReader
>> org.xwiki.rest.representations.tags.FormUrlEncodedTagsReader
>> org.xwiki.rest.representations.tags.TextPlainTagsReader
>> org.xwiki.rest.resources.BrowserAuthenticationResource
>> org.xwiki.rest.resources.RootResource
>> org.xwiki.rest.resources.SyntaxesResource
>> org.xwiki.rest.resources.attachments.AttachmentAtPageVersionResource
>> org.xwiki.rest.resources.attachments.AttachmentHistoryResource
>> org.xwiki.rest.resources.attachments.AttachmentResource
>> org.xwiki.rest.resources.attachments.AttachmentVersionResource
>> org.xwiki.rest.resources.classes.ClassPropertiesResource
>> org.xwiki.rest.resources.classes.ClassPropertyResource
>> org.xwiki.rest.resources.classes.ClassResource
>> org.xwiki.rest.resources.classes.ClassesResource
>> org.xwiki.rest.resources.objects.BaseObjectsResource
>> org.xwiki.rest.resources.pages.ModifiablePageResource
>> org.xwiki.rest.resources.pages.PageTagsResource
>> org.xwiki.rest.resources.pages.PageTranslationsResource
>> org.xwiki.rest.resources.spaces.SpaceResource
>> org.xwiki.rest.resources.spaces.SpacesResource
>> org.xwiki.rest.resources.tags.TagsResource
>> org.xwiki.rest.resources.wikis.WikiPagesResource
>> org.xwiki.rest.resources.wikis.WikiSearchQueryResource
>> org.xwiki.rest.resources.wikis.WikisResource
>>
>> Failing:
>>
>> org.xwiki.rest.DomainObjectFactory
>> org.xwiki.rest.resources.BaseAttachmentsResource
>> org.xwiki.rest.resources.BaseSearchResult
>> org.xwiki.rest.resources.ModificationsResource
>> org.xwiki.rest.resources.attachments.AttachmentsAtPageVersionResource
>> org.xwiki.rest.resources.attachments.AttachmentsResource
>> org.xwiki.rest.resources.comments.CommentResource
>> org.xwiki.rest.resources.comments.CommentVersionResource
>> org.xwiki.rest.resources.comments.CommentsResource
>> org.xwiki.rest.resources.comments.CommentsVersionResource
>> org.xwiki.rest.resources.objects.AllObjectsForClassNameResource
>> org.xwiki.rest.resources.objects.ObjectAtPageVersionResource
>> org.xwiki.rest.resources.objects.ObjectPropertiesAtPageVersionResource
>> org.xwiki.rest.resources.objects.ObjectPropertiesResource
>> org.xwiki.rest.resources.objects.ObjectPropertyAtPageVersionResource
>> org.xwiki.rest.resources.objects.ObjectPropertyResource
>> org.xwiki.rest.resources.objects.ObjectResource
>> org.xwiki.rest.resources.objects.ObjectsAtPageVersionResource
>> org.xwiki.rest.resources.objects.ObjectsForClassNameResource
>> org.xwiki.rest.resources.objects.ObjectsResource
>> org.xwiki.rest.resources.pages.PageChildrenResource
>> org.xwiki.rest.resources.pages.PageHistoryResource
>> org.xwiki.rest.resources.pages.PageResource
>> org.xwiki.rest.resources.pages.PageTranslationHistoryResource
>> org.xwiki.rest.resources.pages.PageTranslationResource
>> org.xwiki.rest.resources.pages.PageTranslationVersionResource
>> org.xwiki.rest.resources.pages.PageVersionResource
>> org.xwiki.rest.resources.pages.PagesResource
>> org.xwiki.rest.resources.spaces.SpaceAttachmentsResource
>> org.xwiki.rest.resources.spaces.SpaceSearchResource
>> org.xwiki.rest.resources.tags.PagesForTagsResource
>> org.xwiki.rest.resources.wikis.WikiAttachmentsResource
>> org.xwiki.rest.resources.wikis.WikiSearchResource
>>
>>
>> So which one of these are not internal ?
>>
>> Ludovic
>>
>> 2012/8/25 Thomas Mortagne <thomas.mortagne(a)xwiki.com>om>:
>>> On Tue, Aug 21, 2012 at 10:18 PM, Vincent Massol <vincent(a)massol.net>
>> wrote:
>>>>
>>>> On Aug 21, 2012, at 2:18 PM, Fabio Mancinelli wrote:
>>>>
>>>>> On Fri, Jul 27, 2012 at 10:12 AM, Ludovic Dubost
<ludovic(a)xwiki.com>
>> wrote:
>>>>>> 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
>>>>> Yep, I think it's safe. We're adding stuff in a
representation (page
>>>>> summary) and keeping it also in the other, so API-wise it's ok.
>>>>
>>>> Note that CLIRR doesn't have false positives so if it complains it
>> means there's a breakage. The only decision to take is whether it's an
>> "acceptable" breakage, i.e. we voluntarily break assuming that nobody
was
>> using it and accept that a few users might get broken.
>>>>
>>>>>> 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
>>>>>
>>>>> The DomainObjectFactory is actually a utility class that is used to
>>>>> build REST-model objects from XWiki-model objects.
>>>>> It has been created just to prevent code duplication in resource
>>>>> implementations.
>>>>
>>>> The question is whether this is supposed to be a SPI or not.
>>>>
>>>>> Now I think it's unlikely that somebody uses it outside the REST
>>>>> module (a quick grep confirmed this for platform).
>>>>>
>>>>> The only use case for a developer of a module to use this class is
if
>>>>> she wants to return a REST-model object and build it using the
utility
>>>>> methods.
>>>>> I think this is quite unlikely.
>>>>>
>>>>> AFAIU all parameters additions are about "pretty names"
>>>>> (
>>
https://github.com/ldubost/xwiki-platform/compare/master...bd49bcc84e1dec3d…
>> )
>>>>>
>>>>> If we want to be conservative we might do the following: we can add
>>>>> the new methods and preserve the old ones making them call the new
>>>>> ones with default parameters.
>>>>>
>>>>> * false in methods like this
>>
https://github.com/ldubost/xwiki-platform/compare/master...bd49bcc84e1dec3d…
>>>>> * null, false in methods like this
>>
https://github.com/ldubost/xwiki-platform/compare/master...bd49bcc84e1dec3d…
>>>>> . This implies that in the new implementation the if statement
should
>>>>> also check for null values (like in this case:
>>
https://github.com/ldubost/xwiki-platform/compare/master...bd49bcc84e1dec3d…
>> )
>>>>>
>>>>> We could also think about whether continuing to keep this class in
the
>>>>> public API. It could make sense but I think that nobody will ever
use
>>>>> it so we can start to @deprecate it and eventually move it in
internal
>>>>> packages.
>>>>
>>>> Based on what you say I'd say that these classes/methods were put
>> public by mistake and should all be moved to the internal package without
>> going through deprecation.
>>>
>>> +1 for internal, if it's not supposed to be used outside of the module
>>> that's the definition of internal
>>>
>>>>
>>>> Of course this means no other other XWiki modules should use them
>> either since they're internal.
>>>>
>>>> Also this means that we don't provide any SPI either since SPI are
>> user-public. Is that what we want?
>>>>
>>>> Thanks
>>>> -Vincent
>>>> _______________________________________________
>>>> devs mailing list
>>>> devs(a)xwiki.org
>>>> http://lists.xwiki.org/mailman/listinfo/devs
>>>
>>>
>>>
>>> --
>>> Thomas Mortagne
>>> _______________________________________________
>>> devs mailing list
>>> devs(a)xwiki.org
>>> http://lists.xwiki.org/mailman/listinfo/devs
>>
>>
>>
>> --
>> Ludovic Dubost
>> Founder and CEO
>> Blog: http://blog.ludovic.org/
>> XWiki: http://www.xwiki.com
>> Skype: ldubost GTalk: ldubost
>
>
>
> --
> Ludovic Dubost
> Founder and CEO
> Blog: http://blog.ludovic.org/
> XWiki: http://www.xwiki.com
> Skype: ldubost GTalk: ldubost
> _______________________________________________
> devs mailing list
> devs(a)xwiki.org
> http://lists.xwiki.org/mailman/listinfo/devs
12 Oct
12 Oct
5:59 p.m.
On Mon, Oct 8, 2012 at 4:35 PM, Ludovic Dubost <ludovic(a)xwiki.com> wrote:
Hi,
All votes told to move the code to internal packages.
This is something I can do, however I'm not sure exactly which code
should go into the internal package and which one should stay where it
is.
Right now here is the list of classes failing or not the CLIRR tests
Not failing:
org.xwiki.rest.ComponentsObjectFactory
org.xwiki.rest.Constants
org.xwiki.rest.RangeIterable
org.xwiki.rest.Relations
org.xwiki.rest.Utils
org.xwiki.rest.XWikiAuthentication
org.xwiki.rest.XWikiJaxRsApplication
org.xwiki.rest.XWikiResource
org.xwiki.rest.XWikiRestComponent
org.xwiki.rest.XWikiRestletJaxRsApplication
org.xwiki.rest.XWikiRestletServlet
org.xwiki.rest.XWikiSecretVerifier
org.xwiki.rest.XWikiSetupCleanupFilter
org.xwiki.rest.exceptions.QueryExceptionMapper
org.xwiki.rest.exceptions.XWikiExceptionMapper
org.xwiki.rest.representations.TextPlainReader
org.xwiki.rest.representations.comments.FormUrlEncodedCommentReader
org.xwiki.rest.representations.comments.TextPlainCommentReader
org.xwiki.rest.representations.objects.FormUrlEncodedObjectReader
org.xwiki.rest.representations.objects.FormUrlEncodedPropertyReader
org.xwiki.rest.representations.objects.TextPlainPropertyReader
org.xwiki.rest.representations.pages.FormUrlEncodedPageReader
org.xwiki.rest.representations.pages.TextPlainPageReader
org.xwiki.rest.representations.tags.FormUrlEncodedTagsReader
org.xwiki.rest.representations.tags.TextPlainTagsReader
org.xwiki.rest.resources.BrowserAuthenticationResource
org.xwiki.rest.resources.RootResource
org.xwiki.rest.resources.SyntaxesResource
org.xwiki.rest.resources.attachments.AttachmentAtPageVersionResource
org.xwiki.rest.resources.attachments.AttachmentHistoryResource
org.xwiki.rest.resources.attachments.AttachmentResource
org.xwiki.rest.resources.attachments.AttachmentVersionResource
org.xwiki.rest.resources.classes.ClassPropertiesResource
org.xwiki.rest.resources.classes.ClassPropertyResource
org.xwiki.rest.resources.classes.ClassResource
org.xwiki.rest.resources.classes.ClassesResource
org.xwiki.rest.resources.objects.BaseObjectsResource
org.xwiki.rest.resources.pages.ModifiablePageResource
org.xwiki.rest.resources.pages.PageTagsResource
org.xwiki.rest.resources.pages.PageTranslationsResource
org.xwiki.rest.resources.spaces.SpaceResource
org.xwiki.rest.resources.spaces.SpacesResource
org.xwiki.rest.resources.tags.TagsResource
org.xwiki.rest.resources.wikis.WikiPagesResource
org.xwiki.rest.resources.wikis.WikiSearchQueryResource
org.xwiki.rest.resources.wikis.WikisResource
Failing:
org.xwiki.rest.DomainObjectFactory
org.xwiki.rest.resources.BaseAttachmentsResource
org.xwiki.rest.resources.BaseSearchResult
org.xwiki.rest.resources.ModificationsResource
org.xwiki.rest.resources.attachments.AttachmentsAtPageVersionResource
org.xwiki.rest.resources.attachments.AttachmentsResource
org.xwiki.rest.resources.comments.CommentResource
org.xwiki.rest.resources.comments.CommentVersionResource
org.xwiki.rest.resources.comments.CommentsResource
org.xwiki.rest.resources.comments.CommentsVersionResource
org.xwiki.rest.resources.objects.AllObjectsForClassNameResource
org.xwiki.rest.resources.objects.ObjectAtPageVersionResource
org.xwiki.rest.resources.objects.ObjectPropertiesAtPageVersionResource
org.xwiki.rest.resources.objects.ObjectPropertiesResource
org.xwiki.rest.resources.objects.ObjectPropertyAtPageVersionResource
org.xwiki.rest.resources.objects.ObjectPropertyResource
org.xwiki.rest.resources.objects.ObjectResource
org.xwiki.rest.resources.objects.ObjectsAtPageVersionResource
org.xwiki.rest.resources.objects.ObjectsForClassNameResource
org.xwiki.rest.resources.objects.ObjectsResource
org.xwiki.rest.resources.pages.PageChildrenResource
org.xwiki.rest.resources.pages.PageHistoryResource
org.xwiki.rest.resources.pages.PageResource
org.xwiki.rest.resources.pages.PageTranslationHistoryResource
org.xwiki.rest.resources.pages.PageTranslationResource
org.xwiki.rest.resources.pages.PageTranslationVersionResource
org.xwiki.rest.resources.pages.PageVersionResource
org.xwiki.rest.resources.pages.PagesResource
org.xwiki.rest.resources.spaces.SpaceAttachmentsResource
org.xwiki.rest.resources.spaces.SpaceSearchResource
org.xwiki.rest.resources.tags.PagesForTagsResource
org.xwiki.rest.resources.wikis.WikiAttachmentsResource
org.xwiki.rest.resources.wikis.WikiSearchResource
So which one of these are not internal ?
I think that everything except XWikiResource and Relations should be
moved to internal.
These are implementations of the HTTP actions on different resources
and the implementation of content-type conversions. Everything that is
actually internal.
Developers who wants to implement new resources only needs
XWikiRestComponent, XWikiResource (which provides an extensible class
with some utility methods) and XWikiRelations to have a list of the
relations that can be specified in <link>s
So I am going to move everything else in internal.
-Fabio
Ludovic
2012/8/25 Thomas Mortagne <thomas.mortagne(a)xwiki.com>om>:
On Tue, Aug 21, 2012 at 10:18 PM, Vincent Massol
<vincent(a)massol.net> wrote:
--
Ludovic Dubost
Founder and CEO
Blog: http://blog.ludovic.org/
XWiki: http://www.xwiki.com
Skype: ldubost GTalk: ldubost
_______________________________________________
devs mailing list
devs(a)xwiki.org
http://lists.xwiki.org/mailman/listinfo/devs
On Aug 21, 2012, at 2:18 PM, Fabio Mancinelli wrote:
+1 for internal, if it's not supposed to be used outside of the module
that's the definition of internal
On Fri, Jul 27, 2012 at 10:12 AM, Ludovic Dubost
<ludovic(a)xwiki.com> wrote:
> 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
>
Yep, I think it's safe. We're adding stuff in a representation (page
summary) and keeping it also in the other, so API-wise it's ok.
Note that CLIRR doesn't have false positives so if it complains it means there's
a breakage. The only decision to take is whether it's an "acceptable"
breakage, i.e. we voluntarily break assuming that nobody was using it and accept that a
few users might get broken.
> 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
The DomainObjectFactory is actually a utility class that is used to
build REST-model objects from XWiki-model objects.
It has been created just to prevent code duplication in resource
implementations.
The question is whether this is supposed to be a SPI or not.
Now I think it's unlikely that somebody uses
it outside the REST
module (a quick grep confirmed this for platform).
The only use case for a developer of a module to use this class is if
she wants to return a REST-model object and build it using the utility
methods.
I think this is quite unlikely.
AFAIU all parameters additions are about "pretty names"
(https://github.com/ldubost/xwiki-platform/compare/master...bd49bcc84e1dec3d…)
If we want to be conservative we might do the following: we can add
the new methods and preserve the old ones making them call the new
ones with default parameters.
* false in methods like this
https://github.com/ldubost/xwiki-platform/compare/master...bd49bcc84e1dec3d…
* null, false in methods like this
https://github.com/ldubost/xwiki-platform/compare/master...bd49bcc84e1dec3d…
. This implies that in the new implementation the if statement should
also check for null values (like in this case:
https://github.com/ldubost/xwiki-platform/compare/master...bd49bcc84e1dec3d…)
We could also think about whether continuing to keep this class in the
public API. It could make sense but I think that nobody will ever use
it so we can start to @deprecate it and eventually move it in internal
packages.
Based on what you say I'd say that these classes/methods were put public by mistake
and should all be moved to the internal package without going through deprecation.
Of course this means no other other XWiki modules should use them either since
they're internal.
Also this means that we don't provide any SPI either since SPI are user-public. Is
that what we want?
Thanks
-Vincent
_______________________________________________
devs mailing list
devs(a)xwiki.org
http://lists.xwiki.org/mailman/listinfo/devs
--
Thomas Mortagne
_______________________________________________
devs mailing list
devs(a)xwiki.org
http://lists.xwiki.org/mailman/listinfo/devs 
8:09 p.m.
New subject: [xwiki-devs] [VOTE] REST API Changes not passing CLIRR. Ignore errors
On 10/12/2012 05:59 PM, Fabio Mancinelli wrote:
On Mon, Oct 8, 2012 at 4:35 PM, Ludovic Dubost
<ludovic(a)xwiki.com> wrote:
Sounds good, +1
Jerome
Hi,
All votes told to move the code to internal packages.
This is something I can do, however I'm not sure exactly which code
should go into the internal package and which one should stay where it
is.
Right now here is the list of classes failing or not the CLIRR tests
Not failing:
org.xwiki.rest.ComponentsObjectFactory
org.xwiki.rest.Constants
org.xwiki.rest.RangeIterable
org.xwiki.rest.Relations
org.xwiki.rest.Utils
org.xwiki.rest.XWikiAuthentication
org.xwiki.rest.XWikiJaxRsApplication
org.xwiki.rest.XWikiResource
org.xwiki.rest.XWikiRestComponent
org.xwiki.rest.XWikiRestletJaxRsApplication
org.xwiki.rest.XWikiRestletServlet
org.xwiki.rest.XWikiSecretVerifier
org.xwiki.rest.XWikiSetupCleanupFilter
org.xwiki.rest.exceptions.QueryExceptionMapper
org.xwiki.rest.exceptions.XWikiExceptionMapper
org.xwiki.rest.representations.TextPlainReader
org.xwiki.rest.representations.comments.FormUrlEncodedCommentReader
org.xwiki.rest.representations.comments.TextPlainCommentReader
org.xwiki.rest.representations.objects.FormUrlEncodedObjectReader
org.xwiki.rest.representations.objects.FormUrlEncodedPropertyReader
org.xwiki.rest.representations.objects.TextPlainPropertyReader
org.xwiki.rest.representations.pages.FormUrlEncodedPageReader
org.xwiki.rest.representations.pages.TextPlainPageReader
org.xwiki.rest.representations.tags.FormUrlEncodedTagsReader
org.xwiki.rest.representations.tags.TextPlainTagsReader
org.xwiki.rest.resources.BrowserAuthenticationResource
org.xwiki.rest.resources.RootResource
org.xwiki.rest.resources.SyntaxesResource
org.xwiki.rest.resources.attachments.AttachmentAtPageVersionResource
org.xwiki.rest.resources.attachments.AttachmentHistoryResource
org.xwiki.rest.resources.attachments.AttachmentResource
org.xwiki.rest.resources.attachments.AttachmentVersionResource
org.xwiki.rest.resources.classes.ClassPropertiesResource
org.xwiki.rest.resources.classes.ClassPropertyResource
org.xwiki.rest.resources.classes.ClassResource
org.xwiki.rest.resources.classes.ClassesResource
org.xwiki.rest.resources.objects.BaseObjectsResource
org.xwiki.rest.resources.pages.ModifiablePageResource
org.xwiki.rest.resources.pages.PageTagsResource
org.xwiki.rest.resources.pages.PageTranslationsResource
org.xwiki.rest.resources.spaces.SpaceResource
org.xwiki.rest.resources.spaces.SpacesResource
org.xwiki.rest.resources.tags.TagsResource
org.xwiki.rest.resources.wikis.WikiPagesResource
org.xwiki.rest.resources.wikis.WikiSearchQueryResource
org.xwiki.rest.resources.wikis.WikisResource
Failing:
org.xwiki.rest.DomainObjectFactory
org.xwiki.rest.resources.BaseAttachmentsResource
org.xwiki.rest.resources.BaseSearchResult
org.xwiki.rest.resources.ModificationsResource
org.xwiki.rest.resources.attachments.AttachmentsAtPageVersionResource
org.xwiki.rest.resources.attachments.AttachmentsResource
org.xwiki.rest.resources.comments.CommentResource
org.xwiki.rest.resources.comments.CommentVersionResource
org.xwiki.rest.resources.comments.CommentsResource
org.xwiki.rest.resources.comments.CommentsVersionResource
org.xwiki.rest.resources.objects.AllObjectsForClassNameResource
org.xwiki.rest.resources.objects.ObjectAtPageVersionResource
org.xwiki.rest.resources.objects.ObjectPropertiesAtPageVersionResource
org.xwiki.rest.resources.objects.ObjectPropertiesResource
org.xwiki.rest.resources.objects.ObjectPropertyAtPageVersionResource
org.xwiki.rest.resources.objects.ObjectPropertyResource
org.xwiki.rest.resources.objects.ObjectResource
org.xwiki.rest.resources.objects.ObjectsAtPageVersionResource
org.xwiki.rest.resources.objects.ObjectsForClassNameResource
org.xwiki.rest.resources.objects.ObjectsResource
org.xwiki.rest.resources.pages.PageChildrenResource
org.xwiki.rest.resources.pages.PageHistoryResource
org.xwiki.rest.resources.pages.PageResource
org.xwiki.rest.resources.pages.PageTranslationHistoryResource
org.xwiki.rest.resources.pages.PageTranslationResource
org.xwiki.rest.resources.pages.PageTranslationVersionResource
org.xwiki.rest.resources.pages.PageVersionResource
org.xwiki.rest.resources.pages.PagesResource
org.xwiki.rest.resources.spaces.SpaceAttachmentsResource
org.xwiki.rest.resources.spaces.SpaceSearchResource
org.xwiki.rest.resources.tags.PagesForTagsResource
org.xwiki.rest.resources.wikis.WikiAttachmentsResource
org.xwiki.rest.resources.wikis.WikiSearchResource
So which one of these are not internal ?
I think that everything except XWikiResource and Relations should be
moved to internal.
These are implementations of the HTTP actions on different resources
and the implementation of content-type conversions. Everything that is
actually internal.
Developers who wants to implement new resources only needs
XWikiRestComponent, XWikiResource (which provides an extensible class
with some utility methods) and XWikiRelations to have a list of the
relations that can be specified in <link>s
So I am going to move everything else in internal.
-Fabio
Ludovic
2012/8/25 Thomas Mortagne <thomas.mortagne(a)xwiki.com>om>:
_______________________________________________
devs mailing list
devs(a)xwiki.org
http://lists.xwiki.org/mailman/listinfo/devs On Tue, Aug 21, 2012 at 10:18 PM, Vincent Massol
<vincent(a)massol.net> wrote:
--
Ludovic Dubost
Founder and CEO
Blog: http://blog.ludovic.org/
XWiki: http://www.xwiki.com
Skype: ldubost GTalk: ldubost
_______________________________________________
devs mailing list
devs(a)xwiki.org
http://lists.xwiki.org/mailman/listinfo/devs On Aug 21, 2012, at 2:18 PM, Fabio Mancinelli
wrote:
> On Fri, Jul 27, 2012 at 10:12 AM, Ludovic Dubost <ludovic(a)xwiki.com> wrote:
>> 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
>>
> Yep, I think it's safe. We're adding stuff in a representation (page
> summary) and keeping it also in the other, so API-wise it's ok.
Note that CLIRR doesn't have false positives so if it complains it means there's
a breakage. The only decision to take is whether it's an "acceptable"
breakage, i.e. we voluntarily break assuming that nobody was using it and accept that a
few users might get broken.
>> 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
> The DomainObjectFactory is actually a utility class that is used to
> build REST-model objects from XWiki-model objects.
> It has been created just to prevent code duplication in resource
> implementations.
The question is whether this is supposed to be a SPI or not.
> Now I think it's unlikely that somebody uses it outside the REST
> module (a quick grep confirmed this for platform).
>
> The only use case for a developer of a module to use this class is if
> she wants to return a REST-model object and build it using the utility
> methods.
> I think this is quite unlikely.
>
> AFAIU all parameters additions are about "pretty names"
>
(https://github.com/ldubost/xwiki-platform/compare/master...bd49bcc84e1dec3d…)
>
> If we want to be conservative we might do the following: we can add
> the new methods and preserve the old ones making them call the new
> ones with default parameters.
>
> * false in methods like this
>
https://github.com/ldubost/xwiki-platform/compare/master...bd49bcc84e1dec3d…
> * null, false in methods like this
>
https://github.com/ldubost/xwiki-platform/compare/master...bd49bcc84e1dec3d…
> . This implies that in the new implementation the if statement should
> also check for null values (like in this case:
>
https://github.com/ldubost/xwiki-platform/compare/master...bd49bcc84e1dec3d…)
>
> We could also think about whether continuing to keep this class in the
> public API. It could make sense but I think that nobody will ever use
> it so we can start to @deprecate it and eventually move it in internal
> packages.
Based on what you say I'd say that these classes/methods were put public by mistake
and should all be moved to the internal package without going through deprecation.
+1 for internal, if it's not supposed to be used outside of the module
that's the definition of internal
Of course this means no other other XWiki modules
should use them either since they're internal.
Also this means that we don't provide any SPI either since SPI are user-public. Is
that what we want?
Thanks
-Vincent
_______________________________________________
devs mailing list
devs(a)xwiki.org
http://lists.xwiki.org/mailman/listinfo/devs
--
Thomas Mortagne
_______________________________________________
devs mailing list
devs(a)xwiki.org
http://lists.xwiki.org/mailman/listinfo/devs
14 Oct
14 Oct
10:55 a.m.
On Fri, Oct 12, 2012 at 8:09 PM, Jerome Velociter <jerome(a)velociter.fr> wrote:
On 10/12/2012 05:59 PM, Fabio Mancinelli wrote:
+1 too
On Mon, Oct 8, 2012 at 4:35 PM, Ludovic Dubost <ludovic(a)xwiki.com> wrote:
Sounds good, +1
Hi,
All votes told to move the code to internal packages.
This is something I can do, however I'm not sure exactly which code
should go into the internal package and which one should stay where it
is.
Right now here is the list of classes failing or not the CLIRR tests
Not failing:
org.xwiki.rest.ComponentsObjectFactory
org.xwiki.rest.Constants
org.xwiki.rest.RangeIterable
org.xwiki.rest.Relations
org.xwiki.rest.Utils
org.xwiki.rest.XWikiAuthentication
org.xwiki.rest.XWikiJaxRsApplication
org.xwiki.rest.XWikiResource
org.xwiki.rest.XWikiRestComponent
org.xwiki.rest.XWikiRestletJaxRsApplication
org.xwiki.rest.XWikiRestletServlet
org.xwiki.rest.XWikiSecretVerifier
org.xwiki.rest.XWikiSetupCleanupFilter
org.xwiki.rest.exceptions.QueryExceptionMapper
org.xwiki.rest.exceptions.XWikiExceptionMapper
org.xwiki.rest.representations.TextPlainReader
org.xwiki.rest.representations.comments.FormUrlEncodedCommentReader
org.xwiki.rest.representations.comments.TextPlainCommentReader
org.xwiki.rest.representations.objects.FormUrlEncodedObjectReader
org.xwiki.rest.representations.objects.FormUrlEncodedPropertyReader
org.xwiki.rest.representations.objects.TextPlainPropertyReader
org.xwiki.rest.representations.pages.FormUrlEncodedPageReader
org.xwiki.rest.representations.pages.TextPlainPageReader
org.xwiki.rest.representations.tags.FormUrlEncodedTagsReader
org.xwiki.rest.representations.tags.TextPlainTagsReader
org.xwiki.rest.resources.BrowserAuthenticationResource
org.xwiki.rest.resources.RootResource
org.xwiki.rest.resources.SyntaxesResource
org.xwiki.rest.resources.attachments.AttachmentAtPageVersionResource
org.xwiki.rest.resources.attachments.AttachmentHistoryResource
org.xwiki.rest.resources.attachments.AttachmentResource
org.xwiki.rest.resources.attachments.AttachmentVersionResource
org.xwiki.rest.resources.classes.ClassPropertiesResource
org.xwiki.rest.resources.classes.ClassPropertyResource
org.xwiki.rest.resources.classes.ClassResource
org.xwiki.rest.resources.classes.ClassesResource
org.xwiki.rest.resources.objects.BaseObjectsResource
org.xwiki.rest.resources.pages.ModifiablePageResource
org.xwiki.rest.resources.pages.PageTagsResource
org.xwiki.rest.resources.pages.PageTranslationsResource
org.xwiki.rest.resources.spaces.SpaceResource
org.xwiki.rest.resources.spaces.SpacesResource
org.xwiki.rest.resources.tags.TagsResource
org.xwiki.rest.resources.wikis.WikiPagesResource
org.xwiki.rest.resources.wikis.WikiSearchQueryResource
org.xwiki.rest.resources.wikis.WikisResource
Failing:
org.xwiki.rest.DomainObjectFactory
org.xwiki.rest.resources.BaseAttachmentsResource
org.xwiki.rest.resources.BaseSearchResult
org.xwiki.rest.resources.ModificationsResource
org.xwiki.rest.resources.attachments.AttachmentsAtPageVersionResource
org.xwiki.rest.resources.attachments.AttachmentsResource
org.xwiki.rest.resources.comments.CommentResource
org.xwiki.rest.resources.comments.CommentVersionResource
org.xwiki.rest.resources.comments.CommentsResource
org.xwiki.rest.resources.comments.CommentsVersionResource
org.xwiki.rest.resources.objects.AllObjectsForClassNameResource
org.xwiki.rest.resources.objects.ObjectAtPageVersionResource
org.xwiki.rest.resources.objects.ObjectPropertiesAtPageVersionResource
org.xwiki.rest.resources.objects.ObjectPropertiesResource
org.xwiki.rest.resources.objects.ObjectPropertyAtPageVersionResource
org.xwiki.rest.resources.objects.ObjectPropertyResource
org.xwiki.rest.resources.objects.ObjectResource
org.xwiki.rest.resources.objects.ObjectsAtPageVersionResource
org.xwiki.rest.resources.objects.ObjectsForClassNameResource
org.xwiki.rest.resources.objects.ObjectsResource
org.xwiki.rest.resources.pages.PageChildrenResource
org.xwiki.rest.resources.pages.PageHistoryResource
org.xwiki.rest.resources.pages.PageResource
org.xwiki.rest.resources.pages.PageTranslationHistoryResource
org.xwiki.rest.resources.pages.PageTranslationResource
org.xwiki.rest.resources.pages.PageTranslationVersionResource
org.xwiki.rest.resources.pages.PageVersionResource
org.xwiki.rest.resources.pages.PagesResource
org.xwiki.rest.resources.spaces.SpaceAttachmentsResource
org.xwiki.rest.resources.spaces.SpaceSearchResource
org.xwiki.rest.resources.tags.PagesForTagsResource
org.xwiki.rest.resources.wikis.WikiAttachmentsResource
org.xwiki.rest.resources.wikis.WikiSearchResource
So which one of these are not internal ?
I think that everything except XWikiResource and Relations should be
moved to internal.
These are implementations of the HTTP actions on different resources
and the implementation of content-type conversions. Everything that is
actually internal.
Developers who wants to implement new resources only needs
XWikiRestComponent, XWikiResource (which provides an extensible class
with some utility methods) and XWikiRelations to have a list of the
relations that can be specified in <link>s
So I am going to move everything else in internal.
Jerome
--
Thomas Mortagne
-Fabio
_______________________________________________
devs mailing list
devs(a)xwiki.org
http://lists.xwiki.org/mailman/listinfo/devs Ludovic
2012/8/25 Thomas Mortagne <thomas.mortagne(a)xwiki.com>om>:
_______________________________________________
devs mailing list
devs(a)xwiki.org
http://lists.xwiki.org/mailman/listinfo/devs
On Tue, Aug 21, 2012 at 10:18 PM, Vincent Massol <vincent(a)massol.net>
wrote:
>
> On Aug 21, 2012, at 2:18 PM, Fabio Mancinelli wrote:
>
>> On Fri, Jul 27, 2012 at 10:12 AM, Ludovic Dubost <ludovic(a)xwiki.com>
>> wrote:
>>>
>>> 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
>>>
>> Yep, I think it's safe. We're adding stuff in a representation (page
>> summary) and keeping it also in the other, so API-wise it's ok.
>
> Note that CLIRR doesn't have false positives so if it complains it
> means there's a breakage. The only decision to take is whether it's an
> "acceptable" breakage, i.e. we voluntarily break assuming that nobody was
> using it and accept that a few users might get broken.
>
>>> 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
>>
>> The DomainObjectFactory is actually a utility class that is used to
>> build REST-model objects from XWiki-model objects.
>> It has been created just to prevent code duplication in resource
>> implementations.
>
> The question is whether this is supposed to be a SPI or not.
>
>> Now I think it's unlikely that somebody uses it outside the REST
>> module (a quick grep confirmed this for platform).
>>
>> The only use case for a developer of a module to use this class is if
>> she wants to return a REST-model object and build it using the utility
>> methods.
>> I think this is quite unlikely.
>>
>> AFAIU all parameters additions are about "pretty names"
>>
>>
(https://github.com/ldubost/xwiki-platform/compare/master...bd49bcc84e1dec3d…)
>>
>> If we want to be conservative we might do the following: we can add
>> the new methods and preserve the old ones making them call the new
>> ones with default parameters.
>>
>> * false in methods like this
>>
>>
https://github.com/ldubost/xwiki-platform/compare/master...bd49bcc84e1dec3d…
>> * null, false in methods like this
>>
>>
https://github.com/ldubost/xwiki-platform/compare/master...bd49bcc84e1dec3d…
>> . This implies that in the new implementation the if statement should
>> also check for null values (like in this case:
>>
>>
https://github.com/ldubost/xwiki-platform/compare/master...bd49bcc84e1dec3d…)
>>
>> We could also think about whether continuing to keep this class in the
>> public API. It could make sense but I think that nobody will ever use
>> it so we can start to @deprecate it and eventually move it in internal
>> packages.
>
> Based on what you say I'd say that these classes/methods were put
> public by mistake and should all be moved to the internal package without
> going through deprecation.
+1 for internal, if it's not supposed to be used outside of the module
that's the definition of internal
> Of course this means no other other XWiki modules should use them
> either since they're internal.
>
> Also this means that we don't provide any SPI either since SPI are
> user-public. Is that what we want?
>
> Thanks
> -Vincent
> _______________________________________________
> devs mailing list
> devs(a)xwiki.org
> http://lists.xwiki.org/mailman/listinfo/devs
--
Thomas Mortagne
_______________________________________________
devs mailing list
devs(a)xwiki.org
http://lists.xwiki.org/mailman/listinfo/devs
--
Ludovic Dubost
Founder and CEO
Blog: http://blog.ludovic.org/
XWiki: http://www.xwiki.com
Skype: ldubost GTalk: ldubost
_______________________________________________
devs mailing list
devs(a)xwiki.org
http://lists.xwiki.org/mailman/listinfo/devs
4403
days inactive
4487
days old
18 comments
6 participants
participants (6)
-
Fabio Mancinelli -
Jerome Velociter -
Ludovic Dubost -
Sergiu Dumitriu -
Thomas Mortagne -
Vincent Massol