thank you Jason
Regards,
Hervé
Le samedi 5 juillet 2014 15:59:31 Jason van Zyl a écrit :
> On Jul 5, 2014, at 3:16 PM, Jeff Jensen
wrote:
> > Jason, for:
> >> 1) Include a "since" statement indicating at point the API was deprecated
> >
> > You didn't mention if you are against doing so or no
On Jul 5, 2014, at 3:16 PM, Jeff Jensen
wrote:
> Jason, for:
>
>> 1) Include a "since" statement indicating at point the API was deprecated
>
> You didn't mention if you are against doing so or not. Do you find it of
> value for yourself and others?
>
Certainly can't hurt, so I added a com
Jason, for:
> 1) Include a "since" statement indicating at point the API was deprecated
You didn't mention if you are against doing so or not. Do you find it of
value for yourself and others?
> 2) include a statement pointing to the replacement API (or non-replacement
> and reason for same).
Generally when I use @Deprecate alone it means there is no replacement. But I
marked this change with that sentiment.
Right now I consider Maven to be and end user tool. The jumble of components we
have let leak to confuse most integrators I would not consider much of an API
or SPI. With 4.0.0
Ok, will do
On Saturday, 5 July 2014, Robert Scholte wrote:
> Op Sat, 05 Jul 2014 18:11:43 +0200 schreef Stephen Connolly <
> stephen.alan.conno...@gmail.com>:
>
> I'm confused as to what the ask is!
>>
>> Are the windows tests now working and you want me to create the job for
>> checking the w
Op Sat, 05 Jul 2014 18:11:43 +0200 schreef Stephen Connolly
:
I'm confused as to what the ask is!
Are the windows tests now working and you want me to create the job for
checking the windows results?
yes, see https://builds.apache.org/job/core-it-maven-3-win/
Robert
On Saturday, 5 July
I'm confused as to what the ask is!
Are the windows tests now working and you want me to create the job for
checking the windows results?
On Saturday, 5 July 2014, Robert Scholte wrote:
> I have to admit that it's a weird fix, but it seems to work.
> In the end it's a JDK problem which can't be
I have to admit that it's a weird fix, but it seems to work.
In the end it's a JDK problem which can't be fixed there, developers need
to add workarounds in their code.
So Stephen, could you add this one as well?
thanks,
Robert
Op Sun, 22 Jun 2014 12:02:50 +0200 schreef Robert Scholte
:
I
The original Java deprecation guidelines were to
1) Include a "since" statement indicating at point the API was deprecated
2) include a statement pointing to the replacement API (or non-replacement
and reason for same).
On Sat, Jul 5, 2014 at 10:34 PM, Robert Scholte
wrote:
> +1, I often hit de
+1, I often hit deprecated code without knowing what to use instead. A
hint would certainly help.
Robert
Op Sat, 05 Jul 2014 14:32:14 +0200 schreef Hervé BOUTEMY
:
when we deprecate somthing like this, we should add a hint on what to do
instead: we have a bunch of deprecated things withou
when we deprecate somthing like this, we should add a hint on what to do
instead: we have a bunch of deprecated things without any idea on what to do
I don't know how we can fix the existing deprecations, but at least I'd like to
avoid adding more such "dead-end" deprecations
Regards,
Hervé
Le
Le samedi 5 juillet 2014 13:30:13 Robert Scholte a écrit :
> Op Sat, 05 Jul 2014 10:38:29 +0200 schreef Tamás Cservenák
>
> :
> > Yes. But repo IDs are meaningless imo, urls are a bit better (as Igor
> > mentioned, could be used as uris, sorta).
>
> Exactly. *If* this is solved in the pom, you ha
Op Sat, 05 Jul 2014 10:38:29 +0200 schreef Tamás Cservenák
:
Yes. But repo IDs are meaningless imo, urls are a bit better (as Igor
mentioned, could be used as uris, sorta).
Exactly. *If* this is solved in the pom, you have to pass the original
repositoryUrl as an extra argument to the repo
I missed on to ask for:
@Component
private RepositorySystem repository;
can't find an equivalent in the evaluation area?
Kind regards
Karl-Heinz Marbaise
-
To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org
For a
Hi Jason,
> Easiest way I know of is using Aether directly:
https://github.com/eclipse/aether-demo/blob/master/aether-demo-snippets/src/main/java/org/eclipse/aether/examples/FindAvailableVersions.java
This is predicated on their being intact Maven metadata for that
particular artifact, which
Yes. But repo IDs are meaningless imo, urls are a bit better (as Igor
mentioned, could be used as uris, sorta).
Nx even today stores all the urls a cached artifact was downloaded in its
own attributes (you can check it with ?describe request). The only problem
currently is that if you access repo
16 matches
Mail list logo
