XDoclet operation Figure 1 shows the input and generated output of the xDoclet.
Figure 1. xdoclet black box
You can see that Java source code containing embedded xdoclet tags is the input of the system. Under the drive of Apache Ant, the XDoclet handles the input code, the generated output text file can be a Java source code, HTML page, XML file, etc. To handle input, xDoclets need to use templates (saved in .xdt files) and label processors (encoded with Java). XDoclet packs templates and tag processors into "modules", different "modules" processing different problem domains.
The XDoclet generated structural model XDoclet parsed the input Java source code containing the embedded xdoclet tag, and establishes a very detailed structure model for the code. Each element in the structural model represents a Java structure in the source code. The structural model shown in Figure 2 reveals the XDoclet tracked code constructors and relationships.
Figure 2. Internal structural model of XDoclet analysis of Java source code
The structural model of Figure 2 tracks the class, the interface, and the model element, and the model element. The model also tracks the relationship between elements, such as inheritance and interface implementation. Embedding the xdoclet tag in the source code in the form of the inline note is parsed to the properties of the model element, and is tracked
In-depth XDoclet FIG. 3 shows the internal structure of the XDoclet reveals the function block that operates.
Figure 3. Dunctional block inside the xdoclet
As shown in Figure 3, the Apache Ant controls the configuration and operation of XDoclet when running. XDoclet parses the input Java source code and generates a structural model in memory. The template engine generates an output file by processing a set of templates and label processors. The template and label processor can be built-in or custom. During the code generation, the template and label processor has full access to the structural model.
XDoclet fake complexity XDoclet is essentially a universal Javadoc engine (see the sidebar, the General Javadoc Engine). So, what makes it look so complicated? The answer is that xDoclets have never been discussed separately, but always hidden in many other complex technologies. Figure 4 shows the complex fog surrounding XDoclet (see why xDoclets look much more complicated than actual).
Why xDoclet looks more than the actual multi-apache Ant automatically performs Java software generation process. Building management processes are usually part of more complex process in production projects. The terminology and concept of building management are integrated into the APCHE ANT and is a prerequisite for understanding its operation. Mature Ant scripts may be very complicated. Every new version of Ant will introduce some new features, which further adds complexity. This forms the complexity of the XDoclet surface because the xdoclet needs ANT to execute. The problem of xDoclet processing is another source of complexity. When publishing XDoclets, XDoclets have been integrated with EJB components, J2EE Web container integration, Hibernate persistence, Struts framework, Java management extension (JMX), etc. generate code. Each area in these issues has a large set of deli and concepts in this field. From these complex problems, there is often a discussion of xdoclets, which also increases the complexity of the XDoclet surface. It may be "I only see the forest, don't see the trees".
Figure 4. Complex coupled coupling of xdoclet
In Figure 4, you can see XDoclets are closely related to the following:
