Re: [xwiki-devs] [VOTE] Rename xwiki-bridge in xwiki-model (NEW)

On Dec 14, 2009, at 1:11 PM, Vincent Massol wrote: > > On Dec 14, 2009, at 12:23 PM, Thomas Mortagne wrote: > >> On Mon, Dec 14, 2009 at 11:45, Vincent Massol <vincent(a)massol.net> >> wrote: >>> >>> On Dec 14, 2009, at 10:57 AM, Thomas Mortagne wrote: >>> >>>> On Mon, Dec 14, 2009 at 09:19, Vincent Massol <vincent(a)massol.net> >>>> wrote: >>>>> >>>>> On Dec 13, 2009, at 1:36 PM, Vincent Massol wrote: >>>>> >>>>>> Before voting please consider that this will break a lot of >>>>>> existing >>>>>> code which is currently using org.xwiki.bridge.DocumentName >>>>>> (since >>>>>> it would now be named org.xwiki.model.DocumentName). >>>>>> >>>>>> Do we want to keep org.xwiki.bridge.DocumentName (and all the >>>>>> others >>>>>> too) and deprecate them? >>>>>> >>>>>> IMO it depends if we agree that 2.2 will introduce the new >>>>>> model or >>>>>> not. >>>>>> >>>>>> WDYT? >>>>> >>>>> Note that I have now finished the refactoring locally and I'm >>>>> waiting >>>>> for a decision. FYI there are 93 files impacted but most are >>>>> tests or >>>>> files which don't expose APIs. In term of APIs there are probably >>>>> something like 20 methods whose signature have changed (mostly >>>>> from >>>>> org.xwiki.bridge.DocumentName to org.xwiki.model.DocumentName). >>>>> >>>>> For developers it means replace "bridge" by "model" in imports. >>>>> This >>>>> is not a big change but it means they need to re-release whatever >>>>> "extensions" they have done (if they used the bridge) when they >>>>> move >>>>> to XE 2.2. >>>>> >>>>> Personally I don't see any way of moving forward for the new >>>>> model >>>>> without breaking some backward compat and the bridge was always >>>>> flagged as being temporary so I'm +1 to go ahead. I'd also like >>>>> to >>>>> continue working on the model in the 2.2 timeframe to ensure that >>>>> what >>>>> we release for 2.2 final will be stable (for example by >>>>> introducing >>>>> the WikiResourceName discussed in the other mail thread on the >>>>> new >>>>> model). >>>> >>>> I really don't like breaking API if it's not absolutely >>>> necessary and >>>> temporary or not bridge is public API, temporary does not mean >>>> suddenly vanish for no reason... I don't see why adding the new >>>> model >>>> would have to break the bridge, that's two different things for >>>> me and >>>> bridge should not be broken if there is not technical issue to >>>> keep it >>>> working. For things other than the bridge it's ok for me since >>>> it's >>>> more SPIs than APIs and i doubt anyone except us (or even any of >>>> our >>>> plugins) are using it. >>>> >>>> For example there is not reason to delete >>>> org.xwiki.bridge.AttachmentNameSerializer, >>>> org.xwiki.bridge.AttachmentNameFactory, >>>> org.xwiki.bridge.DocumentNameFactory, >>>> org.xwiki.bridge.DocumentNameFactory, ... And we just need to >>>> double >>>> methods in DocumentAccessBridge dealing with DocumentName to add >>>> methods using the new model.DocumentName if we need some. >>>> >>>> +1 for the new model but -1 to break anything in the bridge >>>> public API >>>> since it's very easy to not break it. >>> >>> ok I've checked more precisely what were the APIs that are broken >>> and >>> for which we could want to maintain backward compat (I have not >>> listed >>> internal implementation classes): >>> >>> 1) xwiki-bridge: >>> - DocumentAccesssBridge >>> - DocumentModelBridge >>> - DocumentNameFactory >>> - DocumentNameSerializer >> >> - AttachmentNameSerializer >> - AttachmentNameFactory >> >>> >>> 2) xwiki-core: >>> - XWikiDocument (for getDocumentName()) >>> >>> 3) xwiki-openoffice: >>> - XDOMOfficeDocumentBuilder >>> - XHTMLOfficeDocumentBuilder >>> - TargetPageDescriptor >>> - XDOMOfficeDocumentSplitter >>> >>> 4) xwiki-macro-wikibridge >>> - WikiMacroManager >>> - WikiMacroFactory >>> >>> 5) xwiki-url >>> - XWikiAttachmentURL >>> - XWikiDocumentURL >>> >>> So here's what I propose: >>> - We keep backward compat for 1) and 2) >> >> +1 for backward compatibility here, not sure we need aspects here >> since it basically mean put almost the whole module in aspects >> >>> - We don't keep backward compat for 4) (I doubt it's used by anyone >>> else and the backward compat has already been broken for that >>> module a >>> week ago) and for 5) (it's not used yet) >> >> +0.5 for no backward compatibility here >> >>> - I'm hesitating for 3). We could keep backward compat to make it >>> easier for some projects. Thus I'm slighty in favor of keeping >>> backward compat for it. >> >> Not sure either. I would be more in favor of keeping backward >> compatibility as a general good rule when possible. >> >>> - We use aspects whenever we want to keep backward compat >>> - We need a new method name in DocumentModelBridge to add in >>> addition >>> of getCurrentDocumentName(). I don't have a good idea: >>> getDocumentName2(), getNewDocumentName(), getDocumentNameModel(), >>> getDocumentNameFromModel(), etc. Any idea? >> >> getModelDocumentName() ? > > We also have in DAB: > > DocumentName getDocumentName(String documentName); > DocumentName getCurrentDocumentName(); > > So I'd also propose: > > DocumentName getModelDocumentName(String documentName); > DocumentName getModelCurrentDocumentName();

^^^^^ getCurrentModelDocumentName() Also I missed this one: List<AttachmentName> getAttachments(DocumentName documentName) throws Exception; ==> getModelAttachments WDYT? -Vincent