microprofile-server

Name: microprofile-server
Author: AdamBien

40stars10forks

How to install microprofile-server?

adambien/airails/microprofile-server

$npx -y skills add AdamBien/airails --skill microprofile-server

Installs into the current project.

Summary

Architecture and coding rules for long-running Java MicroProfile / Jakarta EE server applications — BCE layering, business components (BC), JAX-RS resources, CDI, JSON-P, testing (unit/integration/system), and Maven project structure. Use when creating, generating, scaffolding, w

Files · 1

View on GitHub

SKILL.md

1	## Composition
2	- compose with `java-conventions` for all language-level Java rules (syntax, style, naming, visibility, interfaces/classes, methods/lambdas, streams/collections, exceptions, comments/JavaDoc)
3	- this skill specializes only the MicroProfile / Jakarta EE server context — it does not restate language-level rules
4
5	## Dependencies
6	- prefer dependencies in this order: Java SE, MicroProfile, Jakarta EE
7
8	## Exceptions (JAX-RS)
9	- in JAX-RS projects, inherit from WebApplicationException for custom exceptions
10	- use explicit exceptions like BadRequestException for Response.Status.BAD_REQUEST
11	- throw explicit WebApplicationException subclasses (e.g. BadRequestException, NotFoundException) rather than constructing Response objects inline — they are automatically mapped to the correct HTTP status by the JAX-RS runtime
12
13	## BCE/ECB Architecture
14	- structure code using the Boundary Control Entity (BCE/ECB) pattern
15	- package structure: [ORGANIZATION_NAME].[PROJECT_NAME].[COMPONENT_NAME].[boundary\|control\|entity]
16	- top level package reflects the application responsibility or name
17	- suggest renaming the top level [PROJECT_NAME] package when it does not reflect the project's name or responsibility
18	- business components are children of top level package, named after their responsibilities
19	- a BC may represent a domain concept or a shared concern; both are valid when the responsibility has a name and is reused across the application
20	- boundary, control, entity packages are only allowed in business components
21	- a BC does not need every layer; a BC may consist of only a control layer when its responsibility is procedural and consumed by other BCs
22	- not every BCE component needs a dedicated boundary package; control package contents can be accessed directly
23	- prefer a dedicated BC over the root application package when a shared concern carries domain or protocol semantics, exposes more than one operation, or is expected to grow
24	- reserve the root application package for trivial single-class plumbing with no business semantics and no protocol coupling
25	- do not explain the BCE pattern in documentation
26
27	## Boundary Layer
28	- keep coarse-grained classes in the boundary package
29	- place facades in the boundary package
30	- health checks must be placed in the boundary package
31	- @Transactional is only allowed in boundary layer
32	- if there is no Boundary stereotype, use ApplicationScope instead
33
34	## Control Layer
35	- implement procedural business logic in the control package
36
37	## Entity Layer
38	- maintain domain objects, data classes, and entities in the entity package
39	- entities maintain state and corresponding behavior
40	- model value objects as enums
41	- direct references between entities from independent BCs are allowed, but always aim for Maximal Cohesion and Minimal Coupling between BCs
42	- if a relation exists in the database (e.g. JPA foreign key), the entities must carry a corresponding reference (id field or association); the DB schema is the source of truth
43	- excessive cross-BC references or shared configuration is a refactoring signal — split, merge, or rebalance the BCs to restore cohesion
44
45	## Components
46	- create new components with minimal business logic and essential fields only
47
48	## JavaDoc (MicroProfile/Jakarta EE)
49	- follow links in JavaDoc to external specifications and use them for code generation
50	- use popular, also funny, technical terms from the Java SE, MicroProfile and Jakarta EE ecosystems as examples in unit tests and javadoc
51
52	## README Guidelines
53	- write brief, 'to the point' README.md files for advanced developers
54	- use precise and concise language; avoid generic adjectives like "simple", "lightweight"
55	- do not include detailed project structure (file/folder listings); high-level module descriptions are acceptable
56	- never list REST resources in READMEs
57	- if modules are listed, provide links
58	- do not use "Orchestrates" term; use more specific alternatives
59
60	## Integration Tests
61	- integration tests end with IT suffix and are executed by the failsafe maven plugin (no configuration necessary)
62
63	## System Tests (ST)
64	- system tests are created in a dedicated Maven module ending with "-st"
65	- use microprofile-rest-client for testing JAX-RS resources
66	- REST client interfaces: src/main/java of the -st module
67	- test classes: src/test/java of the -st module
68	- name client interfaces after the resource with "Client" suffix (e.g., GreetingsResource -> GreetingsResourceClient)
69	- RegisterRestClient configKey: "service_uri"
70	- STs end with "IT" suffix
71	- do not use RestAssure

People who liked this also viewed

6 picks

Type

microprofile-server

40stars10forks

View on GitHub

How to install microprofile-server?

adambien/airails/microprofile-server

$npx -y skills add AdamBien/airails --skill microprofile-server

Installs into the current project.

Summary

Files · 1

View on GitHub

SKILL.md

1	## Composition
2	- compose with `java-conventions` for all language-level Java rules (syntax, style, naming, visibility, interfaces/classes, methods/lambdas, streams/collections, exceptions, comments/JavaDoc)
3	- this skill specializes only the MicroProfile / Jakarta EE server context — it does not restate language-level rules
4
5	## Dependencies
6	- prefer dependencies in this order: Java SE, MicroProfile, Jakarta EE
7
8	## Exceptions (JAX-RS)
9	- in JAX-RS projects, inherit from WebApplicationException for custom exceptions
10	- use explicit exceptions like BadRequestException for Response.Status.BAD_REQUEST
11	- throw explicit WebApplicationException subclasses (e.g. BadRequestException, NotFoundException) rather than constructing Response objects inline — they are automatically mapped to the correct HTTP status by the JAX-RS runtime
12
13	## BCE/ECB Architecture
14	- structure code using the Boundary Control Entity (BCE/ECB) pattern
15	- package structure: [ORGANIZATION_NAME].[PROJECT_NAME].[COMPONENT_NAME].[boundary\|control\|entity]
16	- top level package reflects the application responsibility or name
17	- suggest renaming the top level [PROJECT_NAME] package when it does not reflect the project's name or responsibility
18	- business components are children of top level package, named after their responsibilities
19	- a BC may represent a domain concept or a shared concern; both are valid when the responsibility has a name and is reused across the application
20	- boundary, control, entity packages are only allowed in business components
21	- a BC does not need every layer; a BC may consist of only a control layer when its responsibility is procedural and consumed by other BCs
22	- not every BCE component needs a dedicated boundary package; control package contents can be accessed directly
23	- prefer a dedicated BC over the root application package when a shared concern carries domain or protocol semantics, exposes more than one operation, or is expected to grow
24	- reserve the root application package for trivial single-class plumbing with no business semantics and no protocol coupling
25	- do not explain the BCE pattern in documentation
26
27	## Boundary Layer
28	- keep coarse-grained classes in the boundary package
29	- place facades in the boundary package
30	- health checks must be placed in the boundary package
31	- @Transactional is only allowed in boundary layer
32	- if there is no Boundary stereotype, use ApplicationScope instead
33
34	## Control Layer
35	- implement procedural business logic in the control package
36
37	## Entity Layer
38	- maintain domain objects, data classes, and entities in the entity package
39	- entities maintain state and corresponding behavior
40	- model value objects as enums
41	- direct references between entities from independent BCs are allowed, but always aim for Maximal Cohesion and Minimal Coupling between BCs
42	- if a relation exists in the database (e.g. JPA foreign key), the entities must carry a corresponding reference (id field or association); the DB schema is the source of truth
43	- excessive cross-BC references or shared configuration is a refactoring signal — split, merge, or rebalance the BCs to restore cohesion
44
45	## Components
46	- create new components with minimal business logic and essential fields only
47
48	## JavaDoc (MicroProfile/Jakarta EE)
49	- follow links in JavaDoc to external specifications and use them for code generation
50	- use popular, also funny, technical terms from the Java SE, MicroProfile and Jakarta EE ecosystems as examples in unit tests and javadoc
51
52	## README Guidelines
53	- write brief, 'to the point' README.md files for advanced developers
54	- use precise and concise language; avoid generic adjectives like "simple", "lightweight"
55	- do not include detailed project structure (file/folder listings); high-level module descriptions are acceptable
56	- never list REST resources in READMEs
57	- if modules are listed, provide links
58	- do not use "Orchestrates" term; use more specific alternatives
59
60	## Integration Tests
61	- integration tests end with IT suffix and are executed by the failsafe maven plugin (no configuration necessary)
62
63	## System Tests (ST)
64	- system tests are created in a dedicated Maven module ending with "-st"
65	- use microprofile-rest-client for testing JAX-RS resources
66	- REST client interfaces: src/main/java of the -st module
67	- test classes: src/test/java of the -st module
68	- name client interfaces after the resource with "Client" suffix (e.g., GreetingsResource -> GreetingsResourceClient)
69	- RegisterRestClient configKey: "service_uri"
70	- STs end with "IT" suffix
71	- do not use RestAssure

People who liked this also viewed

6 picks

Type