Re: [xwiki-devs] [VOTE] Rename xwiki-bridge in xwiki-model (NEW)
Hi, New proposal: Create a new xwiki-model and move "clean" classes from xwiki-bridge into it. These are: - *AttachmentName* - *DocumentName* Here's my +1 Thanks -Vincent On Wed, Sep 2, 2009 at 1:12 PM, Thomas Mortagne <[email protected]> wrote:
On Wed, Aug 26, 2009 at 18:00, Vincent Massol<[email protected]> wrote:
Hi,
Since we have some final classes (final in the sense with a good architecture) in xwiki-bridge I'd like to rename it into xwiki-model so that we can start this model module.
Note: We'd still have a org.xwiki.model.bridge package for the time being in that xwiki-model module.
Here's my +1
I would prefer to create a new xwiki-model with only the clean apis instead of having clean and bridge in the same project.
Thanks -Vincent
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? Thanks -Vincent On Dec 13, 2009, at 10:35 AM, Vincent Massol wrote:
Hi,
New proposal: Create a new xwiki-model and move "clean" classes from xwiki-bridge into it. These are: - *AttachmentName* - *DocumentName*
Here's my +1
Thanks -Vincent
On Wed, Sep 2, 2009 at 1:12 PM, Thomas Mortagne <[email protected]> wrote:
On Wed, Aug 26, 2009 at 18:00, Vincent Massol<[email protected]> wrote:
Hi,
Since we have some final classes (final in the sense with a good architecture) in xwiki-bridge I'd like to rename it into xwiki-model so that we can start this model module.
Note: We'd still have a org.xwiki.model.bridge package for the time being in that xwiki-model module.
Here's my +1
I would prefer to create a new xwiki-model with only the clean apis instead of having clean and bridge in the same project.
Thanks -Vincent
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?
hmm I guess we could add them as backward-compat aspects. Thanks -Vincent
Thanks -Vincent
On Dec 13, 2009, at 10:35 AM, Vincent Massol wrote:
Hi,
New proposal: Create a new xwiki-model and move "clean" classes from xwiki-bridge into it. These are: - *AttachmentName* - *DocumentName*
Here's my +1
Thanks -Vincent
On Wed, Sep 2, 2009 at 1:12 PM, Thomas Mortagne <[email protected]> wrote:
On Wed, Aug 26, 2009 at 18:00, Vincent Massol<[email protected]> wrote:
Hi,
Since we have some final classes (final in the sense with a good architecture) in xwiki-bridge I'd like to rename it into xwiki- model so that we can start this model module.
Note: We'd still have a org.xwiki.model.bridge package for the time being in that xwiki-model module.
Here's my +1
I would prefer to create a new xwiki-model with only the clean apis instead of having clean and bridge in the same project.
Thanks -Vincent
On Dec 13, 2009, at 1:43 PM, Vincent Massol 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?
hmm I guess we could add them as backward-compat aspects.
That won't work in the following case: - some custom user code uses bridge.DocumentName as tries to pass it to other core module's APIs. Or we'd need to keep backward compat for all existing modules. That's a lot. I've started making changes in my local workspace and that means changes in: - office importer - classloader - macro html - macro script - wikibridge - url - chart and quite a few more. Thanks -Vincent
Thanks -Vincent
Thanks -Vincent
On Dec 13, 2009, at 10:35 AM, Vincent Massol wrote:
Hi,
New proposal: Create a new xwiki-model and move "clean" classes from xwiki-bridge into it. These are: - *AttachmentName* - *DocumentName*
Here's my +1
Thanks -Vincent
On Wed, Sep 2, 2009 at 1:12 PM, Thomas Mortagne <[email protected]> wrote:
On Wed, Aug 26, 2009 at 18:00, Vincent Massol<[email protected]> wrote:
Hi,
Since we have some final classes (final in the sense with a good architecture) in xwiki-bridge I'd like to rename it into xwiki- model so that we can start this model module.
Note: We'd still have a org.xwiki.model.bridge package for the time being in that xwiki-model module.
Here's my +1
I would prefer to create a new xwiki-model with only the clean apis instead of having clean and bridge in the same project.
Thanks -Vincent
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). Thanks -Vincent
On Dec 13, 2009, at 10:35 AM, Vincent Massol wrote:
Hi,
New proposal: Create a new xwiki-model and move "clean" classes from xwiki-bridge into it. These are: - *AttachmentName* - *DocumentName*
Here's my +1
Thanks -Vincent
On Wed, Sep 2, 2009 at 1:12 PM, Thomas Mortagne <[email protected]> wrote:
On Wed, Aug 26, 2009 at 18:00, Vincent Massol<[email protected]> wrote:
Hi,
Since we have some final classes (final in the sense with a good architecture) in xwiki-bridge I'd like to rename it into xwiki- model so that we can start this model module.
Note: We'd still have a org.xwiki.model.bridge package for the time being in that xwiki-model module.
Here's my +1
I would prefer to create a new xwiki-model with only the clean apis instead of having clean and bridge in the same project.
Thanks -Vincent
On 12/14/09 9:19 AM, Vincent Massol 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).
+1 to go ahead as well. Jerome.
Thanks -Vincent
On Dec 13, 2009, at 10:35 AM, Vincent Massol wrote:
Hi,
New proposal: Create a new xwiki-model and move "clean" classes from xwiki-bridge into it. These are: - *AttachmentName* - *DocumentName*
Here's my +1
Thanks -Vincent
On Wed, Sep 2, 2009 at 1:12 PM, Thomas Mortagne <[email protected]> wrote:
On Wed, Aug 26, 2009 at 18:00, Vincent Massol<[email protected]> wrote:
Hi,
Since we have some final classes (final in the sense with a good architecture) in xwiki-bridge I'd like to rename it into xwiki- model so that we can start this model module.
Note: We'd still have a org.xwiki.model.bridge package for the time being in that xwiki-model module.
Here's my +1
I would prefer to create a new xwiki-model with only the clean apis instead of having clean and bridge in the same project.
Thanks -Vincent
_______________________________________________ devs mailing list [email protected] http://lists.xwiki.org/mailman/listinfo/devs
Vincent Massol 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).
+1 Thanks, Marius
Thanks -Vincent
On Dec 13, 2009, at 10:35 AM, Vincent Massol wrote:
Hi,
New proposal: Create a new xwiki-model and move "clean" classes from xwiki-bridge into it. These are: - *AttachmentName* - *DocumentName*
Here's my +1
Thanks -Vincent
On Wed, Sep 2, 2009 at 1:12 PM, Thomas Mortagne <[email protected]> wrote:
On Wed, Aug 26, 2009 at 18:00, Vincent Massol<[email protected]> wrote:
Hi,
Since we have some final classes (final in the sense with a good architecture) in xwiki-bridge I'd like to rename it into xwiki- model so that we can start this model module.
Note: We'd still have a org.xwiki.model.bridge package for the time being in that xwiki-model module.
Here's my +1 I would prefer to create a new xwiki-model with only the clean apis instead of having clean and bridge in the same project.
Thanks -Vincent
_______________________________________________ devs mailing list [email protected] http://lists.xwiki.org/mailman/listinfo/devs
On Mon, Dec 14, 2009 at 09:19, Vincent Massol <[email protected]> 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.
Thanks -Vincent
On Dec 13, 2009, at 10:35 AM, Vincent Massol wrote:
Hi,
New proposal: Create a new xwiki-model and move "clean" classes from xwiki-bridge into it. These are: - *AttachmentName* - *DocumentName*
Here's my +1
Thanks -Vincent
On Wed, Sep 2, 2009 at 1:12 PM, Thomas Mortagne <[email protected]> wrote:
On Wed, Aug 26, 2009 at 18:00, Vincent Massol<[email protected]> wrote:
Hi,
Since we have some final classes (final in the sense with a good architecture) in xwiki-bridge I'd like to rename it into xwiki- model so that we can start this model module.
Note: We'd still have a org.xwiki.model.bridge package for the time being in that xwiki-model module.
Here's my +1
I would prefer to create a new xwiki-model with only the clean apis instead of having clean and bridge in the same project.
Thanks -Vincent
_______________________________________________ devs mailing list [email protected] http://lists.xwiki.org/mailman/listinfo/devs
-- Thomas Mortagne
On Dec 14, 2009, at 10:57 AM, Thomas Mortagne wrote:
On Mon, Dec 14, 2009 at 09:19, Vincent Massol <[email protected]> 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 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) - 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) - 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. - 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? WDYT? Thanks -Vincent
On Dec 13, 2009, at 10:35 AM, Vincent Massol wrote:
Hi,
New proposal: Create a new xwiki-model and move "clean" classes from xwiki-bridge into it. These are: - *AttachmentName* - *DocumentName*
Here's my +1
Thanks -Vincent
On Wed, Sep 2, 2009 at 1:12 PM, Thomas Mortagne <[email protected]> wrote:
On Wed, Aug 26, 2009 at 18:00, Vincent Massol<[email protected]> wrote:
Hi,
Since we have some final classes (final in the sense with a good architecture) in xwiki-bridge I'd like to rename it into xwiki- model so that we can start this model module.
Note: We'd still have a org.xwiki.model.bridge package for the time being in that xwiki-model module.
Here's my +1
I would prefer to create a new xwiki-model with only the clean apis instead of having clean and bridge in the same project.
Thanks -Vincent
On Mon, Dec 14, 2009 at 11:45, Vincent Massol <[email protected]> wrote:
On Dec 14, 2009, at 10:57 AM, Thomas Mortagne wrote:
On Mon, Dec 14, 2009 at 09:19, Vincent Massol <[email protected]> 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() ?
WDYT?
Thanks -Vincent
On Dec 13, 2009, at 10:35 AM, Vincent Massol wrote:
Hi,
New proposal: Create a new xwiki-model and move "clean" classes from xwiki-bridge into it. These are: - *AttachmentName* - *DocumentName*
Here's my +1
Thanks -Vincent
On Wed, Sep 2, 2009 at 1:12 PM, Thomas Mortagne <[email protected]> wrote:
On Wed, Aug 26, 2009 at 18:00, Vincent Massol<[email protected]> wrote: > Hi, > > Since we have some final classes (final in the sense with a good > architecture) in xwiki-bridge I'd like to rename it into xwiki- > model > so that we can start this model module. > > Note: We'd still have a org.xwiki.model.bridge package for the > time > being in that xwiki-model module. > > Here's my +1
I would prefer to create a new xwiki-model with only the clean apis instead of having clean and bridge in the same project.
> > Thanks > -Vincent
devs mailing list [email protected] http://lists.xwiki.org/mailman/listinfo/devs
-- Thomas Mortagne
On Dec 14, 2009, at 12:23 PM, Thomas Mortagne wrote:
On Mon, Dec 14, 2009 at 11:45, Vincent Massol <[email protected]> wrote:
On Dec 14, 2009, at 10:57 AM, Thomas Mortagne wrote:
On Mon, Dec 14, 2009 at 09:19, Vincent Massol <[email protected]> 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(); WDYT? Thanks -Vincent
WDYT?
Thanks -Vincent
On Dec 13, 2009, at 10:35 AM, Vincent Massol wrote:
Hi,
New proposal: Create a new xwiki-model and move "clean" classes from xwiki- bridge into it. These are: - *AttachmentName* - *DocumentName*
Here's my +1
Thanks -Vincent
On Wed, Sep 2, 2009 at 1:12 PM, Thomas Mortagne <[email protected]> wrote: > On Wed, Aug 26, 2009 at 18:00, Vincent > Massol<[email protected]> > wrote: >> Hi, >> >> Since we have some final classes (final in the sense with a >> good >> architecture) in xwiki-bridge I'd like to rename it into xwiki- >> model >> so that we can start this model module. >> >> Note: We'd still have a org.xwiki.model.bridge package for the >> time >> being in that xwiki-model module. >> >> Here's my +1 > > I would prefer to create a new xwiki-model with only the clean > apis > instead of having clean and bridge in the same project. > >> >> Thanks >> -Vincent
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 <[email protected]> wrote:
On Dec 14, 2009, at 10:57 AM, Thomas Mortagne wrote:
On Mon, Dec 14, 2009 at 09:19, Vincent Massol <[email protected]> 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
WDYT?
Thanks -Vincent
WDYT?
Thanks -Vincent
On Dec 13, 2009, at 10:35 AM, Vincent Massol wrote:
> Hi, > > New proposal: > Create a new xwiki-model and move "clean" classes from xwiki- > bridge > into it. These are: > - *AttachmentName* > - *DocumentName* > > Here's my +1 > > Thanks > -Vincent > > On Wed, Sep 2, 2009 at 1:12 PM, Thomas Mortagne > <[email protected]> wrote: >> On Wed, Aug 26, 2009 at 18:00, Vincent Massol<[email protected] >> > >> wrote: >>> Hi, >>> >>> Since we have some final classes (final in the sense with a >>> good >>> architecture) in xwiki-bridge I'd like to rename it into >>> xwiki- >>> model >>> so that we can start this model module. >>> >>> Note: We'd still have a org.xwiki.model.bridge package for the >>> time >>> being in that xwiki-model module. >>> >>> Here's my +1 >> >> I would prefer to create a new xwiki-model with only the clean >> apis >> instead of having clean and bridge in the same project. >> >>> >>> Thanks >>> -Vincent
On Mon, Dec 14, 2009 at 13:24, Vincent Massol <[email protected]> wrote:
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 <[email protected]> wrote:
On Dec 14, 2009, at 10:57 AM, Thomas Mortagne wrote:
On Mon, Dec 14, 2009 at 09:19, Vincent Massol <[email protected]> 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
Well here you can "fix" the method name with getAttachmentsNames or something since it does not return attachments actually
WDYT?
-Vincent
WDYT?
Thanks -Vincent
WDYT?
Thanks -Vincent
> On Dec 13, 2009, at 10:35 AM, Vincent Massol wrote: > >> Hi, >> >> New proposal: >> Create a new xwiki-model and move "clean" classes from xwiki- >> bridge >> into it. These are: >> - *AttachmentName* >> - *DocumentName* >> >> Here's my +1 >> >> Thanks >> -Vincent >> >> On Wed, Sep 2, 2009 at 1:12 PM, Thomas Mortagne >> <[email protected]> wrote: >>> On Wed, Aug 26, 2009 at 18:00, Vincent Massol<[email protected] >>> > >>> wrote: >>>> Hi, >>>> >>>> Since we have some final classes (final in the sense with a >>>> good >>>> architecture) in xwiki-bridge I'd like to rename it into >>>> xwiki- >>>> model >>>> so that we can start this model module. >>>> >>>> Note: We'd still have a org.xwiki.model.bridge package for the >>>> time >>>> being in that xwiki-model module. >>>> >>>> Here's my +1 >>> >>> I would prefer to create a new xwiki-model with only the clean >>> apis >>> instead of having clean and bridge in the same project. >>> >>>> >>>> Thanks >>>> -Vincent
_______________________________________________ devs mailing list [email protected] http://lists.xwiki.org/mailman/listinfo/devs
-- Thomas Mortagne
On Dec 14, 2009, at 1:24 PM, Vincent Massol wrote:
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 <[email protected]> wrote:
On Dec 14, 2009, at 10:57 AM, Thomas Mortagne wrote:
On Mon, Dec 14, 2009 at 09:19, Vincent Massol <[email protected]> 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();
Actually I'd like to replace this one with Model.getCurrentDocumentName() instead (see other vote thread on model). Thanks -Vincent
^^^^^ getCurrentModelDocumentName()
Also I missed this one:
List<AttachmentName> getAttachments(DocumentName documentName) throws Exception;
==> getModelAttachments
WDYT?
-Vincent
WDYT?
Thanks -Vincent
WDYT?
Thanks -Vincent
> On Dec 13, 2009, at 10:35 AM, Vincent Massol wrote: > >> Hi, >> >> New proposal: >> Create a new xwiki-model and move "clean" classes from xwiki- >> bridge >> into it. These are: >> - *AttachmentName* >> - *DocumentName* >> >> Here's my +1 >> >> Thanks >> -Vincent >> >> On Wed, Sep 2, 2009 at 1:12 PM, Thomas Mortagne >> <[email protected]> wrote: >>> On Wed, Aug 26, 2009 at 18:00, Vincent Massol<[email protected] >>> > >>> wrote: >>>> Hi, >>>> >>>> Since we have some final classes (final in the sense with a >>>> good >>>> architecture) in xwiki-bridge I'd like to rename it into >>>> xwiki- >>>> model >>>> so that we can start this model module. >>>> >>>> Note: We'd still have a org.xwiki.model.bridge package for >>>> the >>>> time >>>> being in that xwiki-model module. >>>> >>>> Here's my +1 >>> >>> I would prefer to create a new xwiki-model with only the clean >>> apis >>> instead of having clean and bridge in the same project. >>> >>>> >>>> Thanks >>>> -Vincent
On Mon, Dec 14, 2009 at 13:11, Vincent Massol <[email protected]> wrote:
On Dec 14, 2009, at 12:23 PM, Thomas Mortagne wrote:
On Mon, Dec 14, 2009 at 11:45, Vincent Massol <[email protected]> wrote:
On Dec 14, 2009, at 10:57 AM, Thomas Mortagne wrote:
On Mon, Dec 14, 2009 at 09:19, Vincent Massol <[email protected]> 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 ?
WDYT?
Thanks -Vincent
WDYT?
Thanks -Vincent
On Dec 13, 2009, at 10:35 AM, Vincent Massol wrote:
> Hi, > > New proposal: > Create a new xwiki-model and move "clean" classes from xwiki- > bridge > into it. These are: > - *AttachmentName* > - *DocumentName* > > Here's my +1 > > Thanks > -Vincent > > On Wed, Sep 2, 2009 at 1:12 PM, Thomas Mortagne > <[email protected]> wrote: >> On Wed, Aug 26, 2009 at 18:00, Vincent >> Massol<[email protected]> >> wrote: >>> Hi, >>> >>> Since we have some final classes (final in the sense with a >>> good >>> architecture) in xwiki-bridge I'd like to rename it into xwiki- >>> model >>> so that we can start this model module. >>> >>> Note: We'd still have a org.xwiki.model.bridge package for the >>> time >>> being in that xwiki-model module. >>> >>> Here's my +1 >> >> I would prefer to create a new xwiki-model with only the clean >> apis >> instead of having clean and bridge in the same project. >> >>> >>> Thanks >>> -Vincent
devs mailing list [email protected] http://lists.xwiki.org/mailman/listinfo/devs
-- Thomas Mortagne
Hi, 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
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)
- 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) - 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.
- 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?
WDYT?
+1 - Asiri
I am in favor of moving toward the new core api, I also would like to preserve backward compatibility as much as possible through a deprecation stage. Thanks Caleb James DeLisle Vincent Massol 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).
Thanks -Vincent
On Dec 13, 2009, at 10:35 AM, Vincent Massol wrote:
Hi,
New proposal: Create a new xwiki-model and move "clean" classes from xwiki-bridge into it. These are: - *AttachmentName* - *DocumentName*
Here's my +1
Thanks -Vincent
On Wed, Sep 2, 2009 at 1:12 PM, Thomas Mortagne <[email protected]> wrote:
On Wed, Aug 26, 2009 at 18:00, Vincent Massol<[email protected]> wrote:
Hi,
Since we have some final classes (final in the sense with a good architecture) in xwiki-bridge I'd like to rename it into xwiki- model so that we can start this model module.
Note: We'd still have a org.xwiki.model.bridge package for the time being in that xwiki-model module.
Here's my +1 I would prefer to create a new xwiki-model with only the clean apis instead of having clean and bridge in the same project.
Thanks -Vincent
_______________________________________________ devs mailing list [email protected] http://lists.xwiki.org/mailman/listinfo/devs
On Dec 13, 2009, at 10:35 AM, Vincent Massol wrote:
Hi,
New proposal: Create a new xwiki-model and move "clean" classes from xwiki-bridge into it. These are: - *AttachmentName* - *DocumentName*
Here's my +1
I vote +0 because I don't have any code concerned but I think it's a good idea to start to go ahead towards a new model. -Fabio
Hi Vincent, On 12/13/2009 11:35 AM, Vincent Massol wrote:
Hi,
New proposal: Create a new xwiki-model and move "clean" classes from xwiki-bridge into it. These are: - *AttachmentName* - *DocumentName*
Here's my +1
It's gonna be a bit uncomfortable for making annotations work on both 2.1 & higher but it's gonna be uncomfortable for someone at some point anyway. Normally +1 but is there any chance we could create this situation just once? Right now I see at least 2 cases: one now and one when the bridge will be completely replaced by the xwiki-model. Otherwise put, is there any chance we could postpone this? Thanks, Anca
Thanks -Vincent
On Wed, Sep 2, 2009 at 1:12 PM, Thomas Mortagne <[email protected]> wrote:
On Wed, Aug 26, 2009 at 18:00, Vincent Massol<[email protected]> wrote:
Hi,
Since we have some final classes (final in the sense with a good architecture) in xwiki-bridge I'd like to rename it into xwiki-model so that we can start this model module.
Note: We'd still have a org.xwiki.model.bridge package for the time being in that xwiki-model module.
Here's my +1
I would prefer to create a new xwiki-model with only the clean apis instead of having clean and bridge in the same project.
Thanks -Vincent
devs mailing list [email protected] http://lists.xwiki.org/mailman/listinfo/devs
On Dec 14, 2009, at 10:33 AM, Anca Luca wrote:
Hi Vincent,
On 12/13/2009 11:35 AM, Vincent Massol wrote:
Hi,
New proposal: Create a new xwiki-model and move "clean" classes from xwiki-bridge into it. These are: - *AttachmentName* - *DocumentName*
Here's my +1
It's gonna be a bit uncomfortable for making annotations work on both 2.1 & higher but it's gonna be uncomfortable for someone at some point anyway.
Normally +1
but is there any chance we could create this situation just once? Right now I see at least 2 cases: one now and one when the bridge will be completely replaced by the xwiki-model. Otherwise put, is there any chance we could postpone this?
I think it's going to be hard to commit to remove the bridge completely by 2.2 end. I'd love to do this though and if we succeed I'm all for it. As I said in my email I'd like to push to the max for the new model in 2.2 but I have no idea how far we will get. One solution would be to use a branch but that would be a major PITA since this code affects virtually everything else so merge will just be impossible. Hence my strategy to commit small stuff at a time. This also makes it much easier for everyone to participate to the new model. Thanks -Vincent
Thanks, Anca
Thanks -Vincent
On Wed, Sep 2, 2009 at 1:12 PM, Thomas Mortagne <[email protected]> wrote:
On Wed, Aug 26, 2009 at 18:00, Vincent Massol<[email protected]> wrote:
Hi,
Since we have some final classes (final in the sense with a good architecture) in xwiki-bridge I'd like to rename it into xwiki- model so that we can start this model module.
Note: We'd still have a org.xwiki.model.bridge package for the time being in that xwiki-model module.
Here's my +1
I would prefer to create a new xwiki-model with only the clean apis instead of having clean and bridge in the same project.
Thanks -Vincent
On Dec 14, 2009, at 10:39 AM, Vincent Massol wrote:
On Dec 14, 2009, at 10:33 AM, Anca Luca wrote:
Hi Vincent,
On 12/13/2009 11:35 AM, Vincent Massol wrote:
Hi,
New proposal: Create a new xwiki-model and move "clean" classes from xwiki-bridge into it. These are: - *AttachmentName* - *DocumentName*
Here's my +1
It's gonna be a bit uncomfortable for making annotations work on both 2.1 & higher but it's gonna be uncomfortable for someone at some point anyway.
Normally +1
but is there any chance we could create this situation just once? Right now I see at least 2 cases: one now and one when the bridge will be completely replaced by the xwiki-model. Otherwise put, is there any chance we could postpone this?
I think it's going to be hard to commit to remove the bridge completely by 2.2 end. I'd love to do this though and if we succeed I'm all for it. As I said in my email I'd like to push to the max for the new model in 2.2 but I have no idea how far we will get.
One solution would be to use a branch but that would be a major PITA since this code affects virtually everything else so merge will just be impossible. Hence my strategy to commit small stuff at a time. This also makes it much easier for everyone to participate to the new model.
Just one remark: this is not about changing the model implementation but about defining interfaces to access the model in "clean" code (ie component-based code, new architecture). So it's not revolutionary changes either. Another remark: the more we wait the more code we have to change later on, the more APIs we will break. Thanks -Vincent
On Wed, Sep 2, 2009 at 1:12 PM, Thomas Mortagne <[email protected]> wrote:
On Wed, Aug 26, 2009 at 18:00, Vincent Massol<[email protected]> wrote:
Hi,
Since we have some final classes (final in the sense with a good architecture) in xwiki-bridge I'd like to rename it into xwiki- model so that we can start this model module.
Note: We'd still have a org.xwiki.model.bridge package for the time being in that xwiki-model module.
Here's my +1
I would prefer to create a new xwiki-model with only the clean apis instead of having clean and bridge in the same project.
Thanks -Vincent
+1, JV. On Sun, Dec 13, 2009 at 10:35 AM, Vincent Massol <[email protected]> wrote:
Hi,
New proposal: Create a new xwiki-model and move "clean" classes from xwiki-bridge into it. These are: - *AttachmentName* - *DocumentName*
Here's my +1
Thanks -Vincent
On Wed, Sep 2, 2009 at 1:12 PM, Thomas Mortagne <[email protected]> wrote:
On Wed, Aug 26, 2009 at 18:00, Vincent Massol<[email protected]> wrote:
Hi,
Since we have some final classes (final in the sense with a good architecture) in xwiki-bridge I'd like to rename it into xwiki-model so that we can start this model module.
Note: We'd still have a org.xwiki.model.bridge package for the time being in that xwiki-model module.
Here's my +1
I would prefer to create a new xwiki-model with only the clean apis instead of having clean and bridge in the same project.
Thanks -Vincent
devs mailing list [email protected] http://lists.xwiki.org/mailman/listinfo/devs
participants (9)
-
Anca Luca -
Asiri Rathnayake -
Caleb James DeLisle -
Fabio Mancinelli -
Jean-Vincent Drean -
Jerome Velociter -
Marius Dumitru Florea -
Thomas Mortagne -
Vincent Massol