forked from takari/io.takari.incrementalbuild
-
Notifications
You must be signed in to change notification settings - Fork 0
Commit
This commit does not belong to any branch on this repository, and may belong to a fork outside of the repository.
moved takari-builder into incrementalbuild
- Loading branch information
Jaime
committed
May 11, 2017
1 parent
28a6b40
commit 96519f8
Showing
270 changed files
with
26,775 additions
and
273 deletions.
There are no files selected for viewing
Large diffs are not rendered by default.
Oops, something went wrong.
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Original file line number | Diff line number | Diff line change |
---|---|---|
@@ -0,0 +1,39 @@ | ||
## Builder Classloading | ||
|
||
[Takari Maven Classloading](http://takari.io/book/91-maven-classloading.html) document provides an overview of classloaders created during Maven build and how these classloaders are wired together. | ||
|
||
|
||
### The Pieces Of The Puzzle | ||
|
||
Java SecurityManager extension/composition API must be shared by all Build Extensions and Maven Plugins used in the same JVM. | ||
|
||
Modularity Enforcer must be able to "wrap" individual subproject builds, which implies it must be loaded either as Maven Core Extension or Build Extension. Modularity Enforcer depends on the composable security manager. | ||
|
||
Although not a hard requirement, it is desired to use shared Builder Framework classes. Shared classes will make overall build analysis and enforment (e.g., input-output cycle detection) easier to implement. It is also better aligned with "builder runtime" vision (as opposed to "builder library") and will force us to provide strong API and runtime compatibility from the get-go. Builder Framework depends on the composable security manager. | ||
|
||
Maven Plugins are loaded in separate classloaders. The plugins depend on Builder Framework. | ||
|
||
exec-maven-plugin needs to access Modularity Enforcer classes. The plan is to remove the plugin after everything is converted to the Builder Framework, but this is not a hard requirement. | ||
|
||
Although not immediately needed, surefire-maven-plugin support will require Builder Framework support external JVM fork. This will require surefire plugin access to Builder Framework classes. | ||
|
||
### Proposed classloader configuration | ||
|
||
Load SecurityManager, Modularity Enforcer and Builder Framework as single Maven Build Extension. In practical terms, this means that **all** Maven projects that use the Builder Framework will need to add the following `<plugin>` element in their parent pom: | ||
|
||
```xml | ||
<plugin> | ||
<groupId>io.takari.builder</groupId> | ||
<artifactId>takari-builder</artifactId> | ||
<version>${takari-builder.version}</version> | ||
<extensions>true</extensions> | ||
</plugin> | ||
``` | ||
|
||
The build extension will export SecurityManager, Modularity Enforcer and Builder Framework API packages and artifacts. This will ensure that all plugins used by the build will use the same classes from the build extension. | ||
|
||
|
||
|
||
### Eclipse complicates things... or maybe not | ||
|
||
As of version 1.7, Eclipse/m2e does not have concept of "reactor build" and all workspace projects are treated independently. There are still workspace-level plugin and extension realm caches, so "equal" build extensions are only loaded by single shared classloader. There are no reactor-build callbacks, but this will be a problem regardless of classloader arrangement. |
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Original file line number | Diff line number | Diff line change |
---|---|---|
@@ -0,0 +1,10 @@ | ||
[![Build Status](https://drone-butc.dci.sfdc.net/api/badges/modularization-team/io.takari.incrementalbuild/status.svg)](https://drone-butc.dci.sfdc.net/modularization-team/io.takari.incrementalbuild) | ||
|
||
## Documentation | ||
|
||
Click [here](DOCUMENTATION.md) for our user documentation. | ||
|
||
## Release Instructions | ||
|
||
mvn release:prepare release:perform | ||
|
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Oops, something went wrong.