Hi Konstantin Boudnik
Are the things on groovy-lang not considered originating from Apache
premises? The repository for the same is licensed to Apache and is in
Apache's git repository. Am I missing something here?
On Fri, Feb 26, 2016 at 9:20 PM, Konstantin Boudnik wrote:
> There's another con
I side with Cédric here. The Java/Groovy docs should only link to other parts
of the official documentation, or at least to endpoints the Groovy team
controls. I don’t have to go online to read the docs or root around in my
~/.m2 repo to find them, they are displayed automagically by my IDE an
Well it's not really hidden, as the groovy/javadoc is published on the
web and quite high in the google search results (at least for me).
Also you can configure e.g. Eclipse to automatically download sources
and javadocs for all dependencies, so it's directly visible in the IDE.
Cheers,
Pasca
Hi Konstantin,
yes, that is a test which is part of the asciidoc documentation and it
downloads jars. These tests are a bit fragile.
Thanks for checking. :)
Cheers,
Pascal
Am 26.02.2016 um 02:35 schrieb Konstantin Boudnik:
Ok, here it's I ran the tests a few times and only once I have gotte
There's another concern: docs of an Apache project has to originate, as the
source code, from Apache premises (Infra, etc.) While linking doesn't exactly
violates this, it is still looks like "Ok, here's our documentation, but for
this little piece you'd need to go and check somewhere else". There'
Hi
Rather than linking to Mr. Haki or improving this particular Java why not
link to http://groovy-lang.org/metaprogramming.html#xform-TupleConstructor?
IMO that is better than either of the 2 suggestions. The meta programming
doc is community driven and already present.
On Fri, Feb 26, 2016 at 3
> Do you have an idea for a GSOC project in Groovy?
Can it be a project not related to the development of Groovy itself? If yes,
I've been developing a music player for Android in Groovy
(https://github.com/AugierLe42e/Phoebius) fir a few months now. It started as a
school project and I continu
On 26.02.2016 13:09, CH wrote:
There hasn't been much discussions on this thread. If Groovy is planning
to apply as organisation, I'd like to apply as student to work on Groovy
stuff. This year will be the last where I'm able to participate. That's
why I reopen the discussion.
if we would att
There hasn't been much discussions on this thread. If Groovy is planning to
apply as organisation, I'd like to apply as student to work on Groovy stuff.
This year will be the last where I'm able to participate. That's why I reopen
the discussion.
Regards,
Christophe Henry.
Le 12 février 201
I too agree with Cédric, that they should be in the documentation. I don't know
how MrHaKi's work is licensed, but if it's open, the documentation could use
his work with attributions to him.
Best regards,
Søren Berg Glasius
Hedevej 1, Gl. Rye, 8680 Ry, Denmark
Mobile: +45 40 44 91 88, Skype: s
I agree with Cédric.
It'd be better to integrate the actual tips in the JavaDocs per se.
Furthermore, the Groovy's GroovyDoc can also contain code samples that are
actually tested, with assertions.
So not only would that improve the documentation itself, without going
through another hoop to visit
If you're ready to introduce a link to an external resource in a Javadoc, I
think you should instead make an effort to improve this particular Javadoc.
I'm strongly against promoting blogs, tutorials, ... that are by nature
individual rather than community driven. That, independently of the quality
Also, people these days would usually consult documentation online sources than bother with locating any local javadoc/groovydoc documentation sources, hidden away in some local m2 repo cache (or is that just me?). That’d make a stale link somewhat less likely, outweighed by the goodness of Groovy
13 matches
Mail list logo
