2013/7/11 Hardy Ferentschik
>
> On 11 Jan 2013, at 12:30 PM, Gunnar Morling wrote:
>
> > I think hovering over a method I want to use in my IDE and seeing it is
> annotated with @Incubating gives me that information much faster than going
> to a wiki or online docs.
>
> would you get that out of
On Thu 2013-07-11 14:37, Hardy Ferentschik wrote:
>
> On 11 Jan 2013, at 12:18 PM, Gunnar Morling wrote:
>
> > Here is the thing, we need to also need to start talking retention setting
> > of the annotation.
> > I think you were suggesting source retention. This means that the
> > annotation
On 11 Jan 2013, at 12:30 PM, Gunnar Morling wrote:
> I think hovering over a method I want to use in my IDE and seeing it is
> annotated with @Incubating gives me that information much faster than going
> to a wiki or online docs.
would you get that out of the box?
> The latter also doesn't
On 11 Jan 2013, at 12:18 PM, Gunnar Morling wrote:
> Here is the thing, we need to also need to start talking retention setting of
> the annotation.
> I think you were suggesting source retention. This means that the annotation
> is only in the
> source. That means the IDE needs to be linked t
2013/7/11 Hardy Ferentschik
>
> On 10 Jan 2013, at 11:07 PM, Gunnar Morling wrote:
>
> > 2013/7/10 Steve Ebersole
> >
> >> http://www.gradle.org/docs/current/userguide/feature_lifecycle.html
> >
> >
> > Thanks for the link. I like their approach of explicitly documenting this
> > kind of thing.
2013/7/11 Sanne Grinovero
> Indeed in my previous comment about bundling it in a common jar I was
> assuming the retention would have been at source level.
>
> Hardy suggested we could keep it even at runtime.. indeed that could
> open the path for several kinds of diagnostics and reporting. I gu
2013/7/11 Hardy Ferentschik
>
> On 10 Jan 2013, at 5:48 PM, Gunnar Morling wrote:
>
> > So basically we're looking for a way to inform the user and say "it's ok
> to
> > use this API, but be prepared to changes in the future". One way to do
> this
> > is documentation, i.e. prose or a custom Jav
Indeed in my previous comment about bundling it in a common jar I was
assuming the retention would have been at source level.
Hardy suggested we could keep it even at runtime.. indeed that could
open the path for several kinds of diagnostics and reporting. I guess
there is no downside? I don't exp
On 10 Jan 2013, at 11:07 PM, Gunnar Morling wrote:
> 2013/7/10 Steve Ebersole
>
>> http://www.gradle.org/docs/current/userguide/feature_lifecycle.html
>
>
> Thanks for the link. I like their approach of explicitly documenting this
> kind of thing.
I think we might have to differentiate here
On 10 Jan 2013, at 6:13 PM, Emmanuel Bernard wrote:
> I remember a few discussion where something like that has been
> contemplated. One thing that made us not do it AFAIR is that we would
> need some kind of shared project to host this across ORM, OGM, SEARCH
> etc. In the past we have deemed i
On 10 Jan 2013, at 5:48 PM, Gunnar Morling wrote:
> So basically we're looking for a way to inform the user and say "it's ok to
> use this API, but be prepared to changes in the future". One way to do this
> is documentation, i.e. prose or a custom JavaDoc tag such as @experimental.
> This has b
On Wed 10 Jul 2013 04:07:33 PM CDT, Gunnar Morling wrote:
> I sometimes think about a similar approach (in terms of using
> annotations) to marking the API/SPI/INTERNAL split.
>
>
> An interesting idea. Would this mean to add annotations to every type?
> If so, I'm not sure though how well
2013/7/10 Steve Ebersole
> http://www.gradle.org/docs/current/userguide/feature_lifecycle.html
Thanks for the link. I like their approach of explicitly documenting this
kind of thing.
>
> I sometimes think about a similar approach (in terms of using
> annotations) to marking the API/SPI/INTERN
2013/7/10 Sanne Grinovero
> To share the annotation?
> We where contemplating a shared jar anyway to maintain the checkstyle
> rules. I guess this could also contain some other shared stuff, like
> the CSS extensions to the javadoc, etc..
>
But isn't there a difference between shared resources s
http://www.gradle.org/docs/current/userguide/feature_lifecycle.html
I sometimes think about a similar approach (in terms of using
annotations) to marking the API/SPI/INTERNAL split.
On 07/10/2013 11:23 AM, Sanne Grinovero wrote:
> To share the annotation?
> We where contemplating a shared jar an
To share the annotation?
We where contemplating a shared jar anyway to maintain the checkstyle
rules. I guess this could also contain some other shared stuff, like
the CSS extensions to the javadoc, etc..
On 10 July 2013 17:13, Emmanuel Bernard wrote:
> I remember a few discussion where something
I remember a few discussion where something like that has been
contemplated. One thing that made us not do it AFAIR is that we would
need some kind of shared project to host this across ORM, OGM, SEARCH
etc. In the past we have deemed it not worth it.
Emmanuel
On Wed 2013-07-10 17:48, Gunnar Morl
The Gradle team do this exact thing as well. They have been doing that
for over a year. You might want to ask them about their experiences.
On 07/10/2013 10:48 AM, Gunnar Morling wrote:
> Hi,
>
> Hardy and I have been musing about how to mark new API members (methods,
> classes etc.) which are
18 matches
Mail list logo
