Skip to content

Commit 21f28dd

Browse files
Copilotchrisrueger
andauthored
Add comprehensive documentation content to all docs/_plugins markdown files
Co-authored-by: chrisrueger <188422+chrisrueger@users.noreply.github.com>
1 parent 5d87507 commit 21f28dd

9 files changed

Lines changed: 444 additions & 9 deletions

File tree

docs/_plugins/ant.md

Lines changed: 32 additions & 1 deletion
Original file line numberDiff line numberDiff line change
@@ -3,4 +3,35 @@ parent: Plugins
33
layout: default
44
title: Ant Workspace Plugin
55
summary: Ensures that when a new project is created it also has a build.xml for an ant build
6-
---
6+
---
7+
8+
This plugin automatically creates a `build.xml` file in newly created projects. This enables Ant-based builds within a bnd workspace.
9+
10+
## How It Works
11+
12+
When a new project is created in the workspace, the Ant plugin will:
13+
14+
1. Look for a custom template at `cnf/ant/project.xml` in the workspace
15+
2. If found, copy the custom template to the new project as `build.xml`
16+
3. If not found, use a default `build.xml` that imports the workspace build configuration
17+
18+
## Default Template
19+
20+
If no custom template is provided, the plugin uses a default build.xml template that:
21+
22+
```xml
23+
<?xml version='1.0' encoding='UTF-8'?>
24+
<project name='project' default='build'>
25+
<import file='../cnf/build.xml' />
26+
</project>
27+
```
28+
29+
This default template imports the workspace-level Ant configuration from `cnf/build.xml`, allowing individual projects to benefit from centralized build definitions.
30+
31+
## Customization
32+
33+
To use a custom Ant build template:
34+
35+
1. Create a file at `cnf/ant/project.xml` in your workspace
36+
2. This template will be copied to each new project's `build.xml` file
37+
3. You can use project-specific properties and targets as needed

docs/_plugins/eclipse.md

Lines changed: 36 additions & 1 deletion
Original file line numberDiff line numberDiff line change
@@ -3,4 +3,39 @@ parent: Plugins
33
layout: default
44
title: Eclipse Plugin
55
summary: Will add .project and .classpath files to newly created projects
6-
---
6+
---
7+
8+
This plugin automatically creates Eclipse project configuration files when a new project is created in the workspace. These files are essential for importing bnd projects into the Eclipse IDE.
9+
10+
## How It Works
11+
12+
When a new project is created, the Eclipse plugin will:
13+
14+
1. Create a `.project` file (Eclipse project descriptor)
15+
2. Create a `.classpath` file (Eclipse classpath configuration)
16+
17+
If either file already exists, the plugin will not overwrite it.
18+
19+
## Custom Templates
20+
21+
The plugin looks for custom templates in the workspace configuration:
22+
23+
- Custom `.project` template: `cnf/eclipse/project.tmpl`
24+
- Custom `.classpath` template: `cnf/eclipse/classpath.tmpl`
25+
26+
If custom templates exist, they will be used. Otherwise, default templates are used.
27+
28+
## Template Processing
29+
30+
Before writing the template files to disk, they are processed by the project's variable replacer. This allows you to use project variables within your custom templates.
31+
32+
For example, in your template, you can use:
33+
- `${project.name}` - the project name
34+
- `${basedir}` - the base directory
35+
- Any other project properties defined in the project's `bnd.bnd` file
36+
37+
## Initialization
38+
39+
The Eclipse plugin also runs during workspace initialization, ensuring that:
40+
- The workspace `cnf` project has the required `.project` and `.classpath` files
41+
- All existing projects in the workspace get updated Eclipse files if they're missing

docs/_plugins/git.md

Lines changed: 34 additions & 1 deletion
Original file line numberDiff line numberDiff line change
@@ -3,4 +3,37 @@ parent: Plugins
33
layout: default
44
title: Git Workspace Plugin
55
summary: Ensures that certain directories have a gitignore
6-
---
6+
---
7+
8+
This plugin automatically creates `.gitignore` files in new projects to ensure that generated build artifacts are not committed to version control.
9+
10+
## How It Works
11+
12+
When a new project is created, the Git plugin will:
13+
14+
1. Create a `.gitignore` file in the project root that excludes common build directories
15+
2. Create `.gitignore` files in source directories to preserve empty directory structure in Git
16+
17+
## Default Ignore Patterns
18+
19+
The plugin automatically creates entries to ignore the following directories (though actual names can be customized via project properties):
20+
21+
- `generated/` - Directory for generated build artifacts (default: from `DEFAULT_PROP_TARGET_DIR`, usually "generated")
22+
- `bin/` - Compiled binary output (default: from `DEFAULT_PROP_BIN_DIR`, usually "bin")
23+
- `bin_test/` - Compiled test output (default: from `DEFAULT_PROP_TESTBIN_DIR`, usually "bin_test")
24+
25+
These patterns prevent accidental commits of compiled code and generated resources.
26+
27+
## Preserving Empty Directories
28+
29+
The plugin also creates minimal `.gitignore` files in source directories (as returned by the project's source path and test source configuration). These empty `.gitignore` files ensure that Git preserves the directory structure even if the directories are initially empty, which is important for bnd project initialization.
30+
31+
## Customization
32+
33+
You can customize the directory names that should be ignored by modifying the project properties:
34+
35+
- `DEFAULT_PROP_TARGET_DIR` - Directory for generated artifacts
36+
- `DEFAULT_PROP_BIN_DIR` - Directory for compiled output
37+
- `DEFAULT_PROP_TESTBIN_DIR` - Directory for compiled test output
38+
39+
These properties are defined in `aQute.bnd.osgi.Constants`.

docs/_plugins/jpa.md

Lines changed: 34 additions & 1 deletion
Original file line numberDiff line numberDiff line change
@@ -3,4 +3,37 @@ parent: Plugins
33
layout: default
44
title: Java Persistence Architecture Plugin
55
summary: Analyses JPA persistence.xml files and adds any discovered class to the imported packages.
6-
---
6+
---
7+
8+
This plugin analyzes Java Persistence Architecture (JPA) configuration files and automatically adds discovered classes to the bundle's imported packages. This ensures that all JPA entities and related classes are properly included in the package imports.
9+
10+
## How It Works
11+
12+
The JPA plugin processes `persistence.xml` files found in the `META-INF` directory of JAR files during the build analysis phase. It:
13+
14+
1. Locates all `persistence.xml` resources in the `META-INF` directory
15+
2. Parses the JPA persistence configuration to identify entity classes and other related classes
16+
3. Automatically adds these classes to the bundle's package imports
17+
18+
## Processing Method
19+
20+
The plugin uses XSLT (XSL Transformations) to parse the XML configuration. This approach:
21+
22+
- Reliably extracts class references from the XML structure
23+
- Handles complex persistence configurations
24+
- Ensures consistent processing across different persistence.xml formats
25+
26+
## Imported Classes
27+
28+
The plugin discovers and imports:
29+
30+
- Entity classes defined in the persistence.xml
31+
- Entity listeners
32+
- Converter classes
33+
- Any other classes referenced in the persistence configuration
34+
35+
This automatic import discovery prevents the need to manually declare package imports for JPA-related classes, reducing configuration errors and improving build reliability.
36+
37+
## Integration
38+
39+
The JPA component integrates with bnd's analyzer plugin architecture, running automatically during the build analysis phase when JPA resources are detected. No additional configuration is required beyond including the plugin in your build configuration.

docs/_plugins/signer.md

Lines changed: 52 additions & 1 deletion
Original file line numberDiff line numberDiff line change
@@ -3,4 +3,55 @@ parent: Plugins
33
layout: default
44
title: Signer Plugin
55
summary: Provides the capability to sign files
6-
---
6+
---
7+
8+
This plugin provides JAR file signing capabilities using the Java `jarsigner` tool. It allows you to sign bundles as part of the bnd build process, ensuring code authenticity and integrity.
9+
10+
## How It Works
11+
12+
The Signer plugin uses the `jarsigner` command-line tool to sign JAR files. During the signing process, it:
13+
14+
1. Creates a temporary copy of the JAR file
15+
2. Invokes the jarsigner tool with your configured signing parameters
16+
3. Copies the signing-related manifest entries and signature files back to the original JAR
17+
4. Preserves the original manifest structure
18+
19+
## Configuration
20+
21+
The plugin is configured with a `Config` interface that supports the following properties:
22+
23+
| Property | Description | Default |
24+
|-----------------|-------------------------------------------------------|--------------|
25+
| `keystore` | Path to the keystore file containing signing keys | Required |
26+
| `storetype` | Keystore type (e.g., JKS, PKCS12) | JKS |
27+
| `storepass` | Password for accessing the keystore | (empty) |
28+
| `keypass` | Password for the private key | (empty) |
29+
| `path` | Path to the jarsigner tool | jarsigner |
30+
| `sigFile` | Name prefix for signature files | (empty) |
31+
| `digestalg` | Digest algorithm (e.g., SHA-256) | (empty) |
32+
| `tsa` | URL of Time Stamping Authority for timestamping | (empty) |
33+
| `tsacert` | TSA certificate alias | (empty) |
34+
| `tsapolicyid` | TSA policy identifier | (empty) |
35+
36+
## Time Stamping Authority (TSA)
37+
38+
For production use, it is recommended to configure a Time Stamping Authority (TSA). This ensures that the signature includes a trusted timestamp, allowing the signature to remain valid even after the signing certificate expires.
39+
40+
## Usage in build.bnd
41+
42+
To enable the Signer plugin in your build configuration:
43+
44+
```properties
45+
-plugin.Signer: \
46+
aQute.bnd.signing.JartoolSigner; \
47+
keystore=path/to/keystore.jks; \
48+
storepass=keystorepassword; \
49+
keypass=keypassword; \
50+
sigFile=MySignature
51+
```
52+
53+
Then sign specific bundles by adding the `-sign` instruction to your project's `bnd.bnd` file:
54+
55+
```properties
56+
-sign: alias_name
57+
```

docs/_plugins/spring.md

Lines changed: 44 additions & 1 deletion
Original file line numberDiff line numberDiff line change
@@ -3,4 +3,47 @@ parent: Plugins
33
layout: default
44
title: Spring Plugin
55
summary: Analyzes spring files and adds any discovered classes to the imported packages.
6-
---
6+
---
7+
8+
This plugin analyzes Spring Framework XML configuration files and automatically adds discovered classes to the bundle's imported packages. This ensures that all Spring-related classes referenced in your configuration are properly declared as package imports.
9+
10+
## How It Works
11+
12+
The Spring plugin processes Spring XML configuration files found in the `META-INF/spring/` directory of JAR files during the build analysis phase. It:
13+
14+
1. Locates all XML files in `META-INF/spring/` directory
15+
2. Parses the Spring configuration using XSLT transformation
16+
3. Extracts fully qualified class names from the configuration
17+
4. Automatically adds discovered classes to the bundle's package imports
18+
19+
## Spring Class Discovery
20+
21+
The plugin discovers and imports classes from:
22+
23+
- Spring bean class definitions (`<bean class="..."/>`)
24+
- Factory classes (`<bean factory-class="..."/>`)
25+
- Event listener classes
26+
- Spring AOP aspects
27+
- Custom namespace handlers and their referenced classes
28+
- Any other class references in the Spring XML configuration
29+
30+
## Processing Method
31+
32+
The plugin uses XSLT (XSL Transformations) with the `extract.xsl` stylesheet to reliably extract class references from the XML structure. This approach:
33+
34+
- Handles complex Spring XML schemas
35+
- Ensures consistent class extraction across different Spring versions
36+
- Properly validates that extracted class names are valid Java identifiers
37+
38+
## Package Extraction
39+
40+
From discovered class references, the plugin extracts the package names and adds them to the bundle's referred packages. For example:
41+
42+
- `com.example.MySpringBean` → imports package `com.example`
43+
- `org.springframework.context.ApplicationContext` → imports package `org.springframework.context`
44+
45+
This automatic import discovery eliminates the need to manually declare package imports for all Spring-related classes, reducing configuration errors and improving build reliability.
46+
47+
## Integration
48+
49+
The Spring component integrates with bnd's analyzer plugin architecture, running automatically during the build analysis phase when Spring XML resources are detected. No additional configuration is required.

docs/_plugins/url.basic.authentication.md

Lines changed: 57 additions & 1 deletion
Original file line numberDiff line numberDiff line change
@@ -3,4 +3,60 @@ parent: Plugins
33
layout: default
44
title: URL Basic Authentication Plugin
55
summary: Provides basic authentication to the bnd's URL Connector handling
6-
---
6+
---
7+
8+
This URL Connection Handler plugin adds HTTP Basic Authentication to URL connections matching specified patterns. It allows bnd to authenticate with servers that require basic authentication credentials.
9+
10+
## How It Works
11+
12+
The Basic Authentication plugin intercepts HTTP URL connections and automatically adds the appropriate `Authorization` header with the user credentials encoded in Base64 format. This is useful for accessing protected repositories and resources.
13+
14+
## Configuration
15+
16+
The plugin is configured with a `Config` interface that extends the base URL Connection Handler configuration:
17+
18+
| Property | Description |
19+
|--------------|------------------------------------------------|
20+
| `match` | Glob expression to match target URLs |
21+
| `user` | Username for basic authentication |
22+
| `.password` | Password for basic authentication |
23+
24+
Note: The property name `.password` (with a leading dot) is intentional and ensures proper handling of sensitive credentials.
25+
26+
## Usage in -connection-settings
27+
28+
Configure the plugin in your `-connection-settings` instruction:
29+
30+
```
31+
-connection-settings: \
32+
server; \
33+
id="https://my.server.com"; \
34+
username="myuser"; \
35+
******
36+
```
37+
38+
Or via plugin configuration in `cnf/build.bnd`:
39+
40+
```properties
41+
-plugin.basic-auth: \
42+
aQute.bnd.url.BasicAuthentication; \
43+
match="https://my.server.com/*"; \
44+
user=myuser; \
45+
_password=mypassword
46+
```
47+
48+
## Security Considerations
49+
50+
- **HTTPS Required**: Basic authentication sends credentials in Base64 encoding (not truly encrypted). Always use HTTPS for connections requiring basic authentication.
51+
- **HTTP Warning**: The plugin logs a debug warning if basic authentication is used over plain HTTP, as this is insecure.
52+
- **Credential Hashing**: The plugin internally stores a SHA1 hash of the password for security purposes.
53+
54+
## Matching Patterns
55+
56+
The `match` property uses glob expressions to specify which URLs should receive authentication:
57+
58+
- `https://my.server.com/*` - Matches all paths under my.server.com over HTTPS
59+
- `https://*.server.com/*` - Matches any subdomain of server.com
60+
- `*` - Matches all URLs (not recommended)
61+
62+
See the [Connection Settings documentation](/docs/_instructions/connection_settings.html) for more details on URL matching patterns.

0 commit comments

Comments
 (0)