<div dir="ltr"><br><div class="gmail_extra"><br><br><div class="gmail_quote">On Wed, Feb 26, 2014 at 4:24 PM, Tristan Tarrant <span dir="ltr"><<a href="mailto:ttarrant@redhat.com" target="_blank">ttarrant@redhat.com</a>></span> wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div class="">On 26/02/2014 15:02, Mircea Markus wrote:<br>
> On Feb 26, 2014, at 1:05 PM, Tristan Tarrant <<a href="mailto:ttarrant@redhat.com">ttarrant@redhat.com</a>> wrote:<br>
><br>
>> Dear all,<br>
>><br>
>> our JavaDocs currently encompass all of our classes, interfaces, etc<br>
>> with no clear distinction between public and private API/SPI. I would<br>
>> like to clearly mark which of our classes/interfaces are public API.<br>
>> Should we:<br>
>><br>
>> - add some decoration / visual cue to such elements to distinguish them<br>
>> from the internal stuff<br>
> I think Sanne mentioned and i think it was Hibernate that has impl sub-packages for all the non-public API.<br>
> Sounds sensible to me, as people will see the impl in the class name when importing it, and that should raise question marks. shall we adopt that?<br>
</div>That would help, but we would still end up with a lot of noise in the<br>
javadocs, for example the list of classes on the left has no separation<br>
by package.<br><br></blockquote><div><br></div><div>If we move all internal classes to .impl sub-packages, it will be quite easy to exclude the .impl packages from javadocs with a bit of maven-javadoc-plugin configuration. I don't think we need to generate javadocs for the internal classes at all, as the sources are easily accessible from any IDE.<br>
<br></div><div>Cheers<br></div><div>Dan<br><br></div></div></div></div>