On Feb 4, 2008, at 10:41 AM, Sergiu Dumitriu wrote:

+5

Also, in the deprecated methods we should log the calls, if possible capturing where exactly that code is used. This will ease the code upgrade, as velocity is not that easy to refactor when you don't get compilation errors.

yes, very good idea. -Vincent

Vincent Massol wrote:

...

Hi,

I'd like us to agree on using the strategy described here: http://blogs.sonatype.com/john/2007/11/09/1194630418546.html

This has several advantages:

1) Keeps our code clean 2) Put all backward compatibility code in a single place which makes it easy too to remove when the time has come

Here's my +1

If we agree I'll do a try of using this approach for moving out the deprecated methods in the XWiki class into an aspect. It should be a piece of cake since we already have the aspectj plugin in place for the core build.

Thanks -Vincent

For everyone's information I have added this strategy to our development practices guide at: http://dev.xwiki.org/xwiki/bin/view/Community/DevelopmentPractices#HBackward... Thanks -Vincent On Feb 4, 2008, at 2:40 PM, Vincent Massol wrote:

Done: http://jira.xwiki.org/jira/browse/XWIKI-2059

The mechanism is now in place. See the aspect here: http://tinyurl.com/2bgrxj

Thanks -Vincent

On Feb 4, 2008, at 9:44 AM, Vincent Massol wrote:

...

Hi,

I'd like us to agree on using the strategy described here: http://blogs.sonatype.com/john/2007/11/09/1194630418546.html

This has several advantages:

1) Keeps our code clean 2) Put all backward compatibility code in a single place which makes it easy too to remove when the time has come

Here's my +1

If we agree I'll do a try of using this approach for moving out the deprecated methods in the XWiki class into an aspect. It should be a piece of cake since we already have the aspectj plugin in place for the core build.

Thanks -Vincent

On Feb 4, 2008, at 10:39 PM, Jerome Velociter wrote:

I think we also have to advertise this when releasing, otherwise it might be unclear that some deprecated methods still works while not being "in the code" (for example I don't have that reflex yet to lookup the aspects when reading code)

This is exactly another benefit of the aspects! You won't see the deprecated methods in the Javadoc so you won't be tempted to use them... ;) However you're right if you want to see what you should use instead you'll need that doc. The aspectj plugin has a mojo to generate javadoc: http://mojo.codehaus.org/aspectj-maven-plugin/aspectj-report-mojo.html so we could replace the current javadoc generation by this one. -Vincent

...

For everyone's information I have added this strategy to our development practices guide at: http://dev.xwiki.org/xwiki/bin/view/Community/DevelopmentPractices#HBackward...

Thanks -Vincent

On Feb 4, 2008, at 2:40 PM, Vincent Massol wrote:

...

Done: http://jira.xwiki.org/jira/browse/XWIKI-2059

The mechanism is now in place. See the aspect here: http://tinyurl.com/2bgrxj

Thanks -Vincent

On Feb 4, 2008, at 9:44 AM, Vincent Massol wrote:

...

Hi,

I'd like us to agree on using the strategy described here: http://blogs.sonatype.com/john/2007/11/09/1194630418546.html

This has several advantages:

1) Keeps our code clean 2) Put all backward compatibility code in a single place which makes it easy too to remove when the time has come

Here's my +1

If we agree I'll do a try of using this approach for moving out the deprecated methods in the XWiki class into an aspect. It should be a piece of cake since we already have the aspectj plugin in place for the core build.

Thanks -Vincent

_______________________________________________ devs mailing list [email protected] http://lists.xwiki.org/mailman/listinfo/devs

_______________________________________________ devs mailing list [email protected] http://lists.xwiki.org/mailman/listinfo/devs