No I'm talking about all the markup that appears in the output. What I
pasted is not the source, it's the output you get in your Javadoc (with the
<li>, the <p/> and so on).
The cross references are indeed OK.
On Sun, Jul 15, 2018 at 3:06 PM Steve Ebersole <st...@hibernate.org> wrote:
> You mean the lack of rendering Javdoc cross-references ({@link ...})?
> Otherwise, I am not sure what exactly you are getting at.
>
> Asciidoclet is supposed to handle Javdoc cross-references - if it is not,
> that would be a bug in asciidoclet
>
> On Sun, Jul 15, 2018 at 7:58 AM Guillaume Smet <guillaume.s...@gmail.com>
> wrote:
>
>> On Sun, Jul 15, 2018 at 2:13 AM Steve Ebersole <st...@hibernate.org>
>> wrote:
>>
>>> We have ported things from 6 back to 5.3 so I cannot say definitively
>>> that absolutely no javadoc in 5.3 uses asciidoc(tor).
>>>
>>> But feel free to disable it.
>>>
>>
>> I just tried the opposite and enable Asciidoclet for the aggregated
>> javadoc to be consistent and it leads to malformed Javadoc containing HTML
>> markups when our Javadoc is using HTML.
>>
>> I think you either have all your Javadoc using Asciidoctor or you end up
>> with some bad output.
>>
>> A good example is the Javadoc of CompositeNestedGeneratedValueGenerator
>> which, with Asciidoclet enabled, looks like:
>>
>> For composite identifiers, defines a number of "nested" generations that
>> need to happen to "fill" the identifier property(s). <p/> This generator is
>> used implicitly for all composite identifier scenarios if an explicit
>> generator is not in place. So it make sense to discuss the various
>> potential scenarios:<ul> <li> <i>"embedded" composite identifier</i> - this
>> is possible only in HBM mappings as <composite-id/> (notice the
>> lack of both a name and class attribute declarations). The term
>> "embedded"
>> <http://../../../org/hibernate/mapping/Component.html#isEmbedded--> here
>> refers to the Hibernate usage which is actually the exact opposite of the
>> JPA meaning of "embedded". Essentially this means that the entity class
>> itself holds the named composite pk properties. This is very similar to the
>> JPA @IdClass usage, though without a separate pk-class for loading.
>> </li> <li> <i>pk-class as entity attribute</i> - this is possible in both
>> annotations (@EmbeddedId) and HBM mappings (<composite-id
>> name="idAttributeName" class="PkClassName"/>) </li> <li>
>> <i>"embedded" composite identifier with a pk-class</i> - this is the JPA
>> @IdClass use case and is only possible in annotations </li> </ul> <p/>
>> Most of the grunt work is done in Component
>> <http://../../../org/hibernate/mapping/Component.html>.
>>
>> Did I miss something?
>>
>> --
>> Guillaume
>>
>
_______________________________________________
hibernate-dev mailing list
hibernate-dev@lists.jboss.org
https://lists.jboss.org/mailman/listinfo/hibernate-dev
