+1
Am 02/05/17 um 21:57 schrieb Michael Osipov:
> Am 2017-02-04 um 23:31 schrieb Christian Schulte:
>> I added a comment below
>>
>>> http://git-wip-us.apache.org/repos/asf/maven/blob/87c6346a/maven-compat/src/main/java/org/apache/maven/repository/MetadataResolutionRequest.java
>>> --
Am 2017-02-04 um 23:31 schrieb Christian Schulte:
I added a comment below
http://git-wip-us.apache.org/repos/asf/maven/blob/87c6346a/maven-compat/src/main/java/org/apache/maven/repository/MetadataResolutionRequest.java
--
diff
Am 2017-02-04 um 23:31 schrieb Christian Schulte:
I added a comment below
http://git-wip-us.apache.org/repos/asf/maven/blob/87c6346a/maven-compat/src/main/java/org/apache/maven/repository/MetadataResolutionRequest.java
--
diff
Am 02/04/17 um 23:31 schrieb Michael Osipov:
> Am 2017-02-04 um 23:26 schrieb Christian Schulte:
>> Am 02/04/17 um 13:19 schrieb Michael Osipov:
>>> I will merge as-is without further modifiers.
>>
>> Please watch out for this:
>>
>> class A {
>>
>> @Deprecated
>> void methodWithTypo()
>> {
>
Am 2017-02-04 um 23:26 schrieb Christian Schulte:
Am 02/04/17 um 13:19 schrieb Michael Osipov:
I will merge as-is without further modifiers.
Please watch out for this:
class A {
@Deprecated
void methodWithTypo()
{
this.methodWithoutTypo();
}
void methodWithoutType()
{
//
I added a comment below
> http://git-wip-us.apache.org/repos/asf/maven/blob/87c6346a/maven-compat/src/main/java/org/apache/maven/repository/MetadataResolutionRequest.java
> --
> diff --git
> a/maven-compat/src/main/java/org/apach
Am 02/04/17 um 13:19 schrieb Michael Osipov:
> I will merge as-is without further modifiers.
Please watch out for this:
class A {
@Deprecated
void methodWithTypo()
{
this.methodWithoutTypo();
}
void methodWithoutType()
{
// do what the old method did
}
}
External usage:
Am 02/04/17 um 11:33 schrieb Stephen Connolly:
> Yep I don't think it is a good idea to make them final
>
> We could add some tooling to the Maven-plugin-plugin to scan for annotated
> method (would need a new annotation) so that plugins using or overriding
> would get a hard error (similar to @Re
Am 02/04/17 um 10:12 schrieb Stuart McCulloch:
> Note making a method final will break binary compatibility if someone has
> previously overridden that method - in such cases they'd get a verify error
> running with the new binary:
>
> https://docs.oracle.com/javase/specs/jls/se7/html/jls-13.html#
I will merge as-is without further modifiers.
Am 2017-02-04 um 11:33 schrieb Stephen Connolly:
Yep I don't think it is a good idea to make them final
We could add some tooling to the Maven-plugin-plugin to scan for annotated
method (would need a new annotation) so that plugins using or overridi
Yep I don't think it is a good idea to make them final
We could add some tooling to the Maven-plugin-plugin to scan for annotated
method (would need a new annotation) so that plugins using or overriding
would get a hard error (similar to @Restricted(NoExternalUse) in Jenkins
That would allow to r
Note making a method final will break binary compatibility if someone has
previously overridden that method - in such cases they'd get a verify error
running with the new binary:
https://docs.oracle.com/javase/specs/jls/se7/html/jls-13.html#jls-13.4.17
On 4 Feb 2017 01:59, "Christian Schulte" w
Can we make the deprecated methods final, please? It's still binary
compatible when final. If someone has overridden such a deprecated
method, he will get a compile time error and will notice he needs to
override the new method instead.
Am 02/04/17 um 00:21 schrieb micha...@apache.org:
> Repositor
13 matches
Mail list logo