You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
The <b>Pico Builder</b> provides compile-time code generation for fluent builders. It was inspired by [Lombok]([https://projectlombok.org/), but the implementation here in Helidon is different in a few ways:
3
+
The <b>Helidon Pico Builder</b> provides compile-time code generation for fluent builders. It was inspired by [Lombok]([https://projectlombok.org/), but the implementation here in Helidon is different in a few ways:
4
4
<ol>
5
-
<li>Pico Builders target interface or annotation types only.</li>
6
-
<li>Generated classes implement the target interface (or annotation) and provide a fluent builder that will always have an implementation of <i>toString(), hashCode(), and equals().</i></li>
5
+
<li>The <i>Builder</i> annotation targets interface or annotation types only. Your interface effectively contains the attributes of your getter as well as serving as the contract for your getter methods.</li>
6
+
<li>Generated classes implement your target interface (or annotation) and provide a fluent builder that will always have an implementation of <i>toString(), hashCode(), and equals().</i> implemented</li>
7
7
<li>Generated classes always behave like a <i>SuperBuilder</i> from Lombok. Basically this means that builders can form
8
8
a hierarchy on the types they target (e.g., Level2 derives from Level1 derives from Level0, etc.).</li>
9
-
<li>Lombok uses AOP while the Pico Builder generates source code (in conjunction with the proper Builder annotation processor).</li>
10
-
<li>Pico Builders are extensible - you can provide your own implementation of the SPI to customize the generated classes.</li>
9
+
<li>Lombok uses AOP while the Pico Builder generates source code. You can use the <i>Builder</i> annotation (as well as other annotations in the package and <i>ConfiguredOption</i>) to control the naming and other features of what and how the implementation classes are generated and behave.</li>
10
+
<li>Pico Builders are extensible - you can provide your own implementation of the <b>Builder Processor SPI</b> to customize the generated classes for your situation.</li>
11
11
</ol>
12
12
13
-
Supported annotation types (see [api](./api/src/main/java/io/helidon/pico/builder/api) for further details):
13
+
Supported annotation types (see [builder](./builder/src/main/java/io/helidon/pico/builder) for further details):
14
14
* Builder - similar to Lombok's SuperBuilder.
15
15
* Singular - similar to Lombok's Singular.
16
16
@@ -20,9 +20,9 @@ are ignored on the target being processed.
20
20
21
21
The Helidon Pico Builder is completely independent of other parts of Pico. It can therefore be used in a standalone manner. The
22
22
generated implementation class will not require any special module to support those classes - just the types from your interface
23
-
and standard JRE types are used.
23
+
and standard JRE types are used. This is made possible when your <i>Builder</i> has the <i>requireBuilderLibrary=false</i>. See the javadoc for details.
24
24
25
-
## Usage
25
+
## Getting Started
26
26
1. Write your interface that you want to have a builder for.
27
27
```java
28
28
publicinterfaceMyConfigBean {
@@ -31,28 +31,30 @@ public interface MyConfigBean {
31
31
intgetPort();
32
32
}
33
33
```
34
-
2. Annotate your interface definition with <i>Builder</i>, and optionally use <i>ConfiguredOption</i>, <i>Singular</i>, etc.
34
+
2. Annotate your interface definition with <i>Builder</i>, and optionally use <i>ConfiguredOption</i>, <i>Singular</i>, etc. Remember to review the annotation attributes javadoc for any customizations.
35
35
3. Compile (using the <i>pico-builder-processor</i> in your annotation classpath).
36
36
37
-
The result of this will create (under ./target/generated-sources):
37
+
The result of this will create (under ./target/generated-sources/annotations):
38
38
* MyConfigBeanImpl (in the same package as MyConfigBean) that will support multi-inheritance builders named MyConfigBeanImpl.Builder.
39
39
* Support for toString(), hashCode(), and equals() are always included.
40
40
* Support for toBuilder().
41
-
* Support for streams (see javadoc for [Builder](./api/src/main/java/io/helidon/pico/builder/Builder.java)).
41
+
* Support for streams (see javadoc for [Builder](./builder/src/main/java/io/helidon/pico/builder/Builder.java)).
42
+
* Support for attribute visitors (see [test-builder](./tests/builder/src/main/java/io/helidon/pico/builder/test/testsubjects/package-info.java)).
43
+
* Support for attribute validation (see ConfiguredOption#required() and [builder](./tests/builder/src/main/java/io/helidon/pico/builder/test/testsubjects/package-info.java)).
42
44
43
45
The implementation of the processor also allows for a provider-based extensibility mechanism.
44
46
45
-
## modules
46
-
*[api](./api) - defines the compile-time annotations. Typically this module is only needed at compile time.
47
-
*[spi](./spi) - defines the SPI runtime definitions used by builder tooling. Only needed at compile time.
48
-
*[tools](./tools) - provides the creators / code generators. Only needed at compile time.
49
-
*[runtime-tools](./runtime-tools) - provides optional runtime utility classes the can helpful at compile time as well as runtime.
50
-
*[processor](./processor) - the annotation processor which delegates to the tools module for processing. Only needed at compile time.
51
-
*[test-builder](./test-builder) - internal tests that can also serve as examples for usage.
52
-
53
-
## provider
54
-
To implement your own provider:
55
-
* Write an implementation for <i>BuilderCreator</i> having a higher-than-default <i>Weighted</i> value as compared to <i>DefaultBuilderCreator</i>.
47
+
## Modules
48
+
*[builder](./builder) - provides the compile-time annotations, as well as optional runtime supporting types.
49
+
*[processor-spi](./processor-spi) - defines the Builder Processor SPI runtime definitions used by builder tooling. This module is only needed at compile time.
50
+
*[processor-tools](./processor-tools) - provides the concrete creators & code generators. This module is only needed at compile time.
51
+
*[processor](./processor) - the annotation processor which delegates to the processor-tools module for the main processing logic. This module is only needed at compile time.
52
+
*[tests/builder](./tests/builder) - internal tests that can also serve as examples on usage.
53
+
54
+
## Customizations
55
+
To implement your own custom <i>Builder</i>:
56
+
* Write an implementation of <i>BuilderCreator</i> having a higher-than-default <i>Weighted</i> value as compared to <i>DefaultBuilderCreator</i>.
56
57
* Include your module with this creator in your annotation processing path.
57
58
58
-
See [test-builder](./test-builder) for usage examples.
59
+
## Usage
60
+
See [tests/builder](./tests/builder) for usage examples.
0 commit comments