https://github.com/jdcasey/monolith-maven-plugin

Apache Maven plugin that creates essentially self-contained versions of existing dependencies and plugins using specifications in dependencyManagement and pluginManagement of another POM
https://github.com/jdcasey/monolith-maven-plugin

Last synced: about 1 year ago
JSON representation

Apache Maven plugin that creates essentially self-contained versions of existing dependencies and plugins using specifications in dependencyManagement and pluginManagement of another POM

• Host: GitHub
• URL: https://github.com/jdcasey/monolith-maven-plugin
• Owner: jdcasey
• Created: 2013-07-13T07:07:08.000Z (about 13 years ago)
• Default Branch: master
• Last Pushed: 2013-08-07T15:26:45.000Z (almost 13 years ago)
• Last Synced: 2025-07-13T10:49:06.270Z (about 1 year ago)
• Language: Java
• Size: 180 KB
• Stars: 1
• Watchers: 2
• Forks: 0
• Open Issues: 0
• Metadata Files:
  • Readme: README.md

Awesome Lists containing this project

README

          
# Monolith Plugin for Apache Maven

This plugin reads the entries in your POM's `dependencyManagement` and `pluginManagement` sections, and generates monolithic, self-contained assemblies for each. That is, self-contained EXCEPT when they reference other monoliths declared in the current project. In the case of plugins, these assemblies are usable as drop-in replacements for the original plugin...just adjust the version to the new, qualified version, and away you go.

## Why??

In cleanroom environments, it's often desirable to avoid mixing built-time / toolchain libraries with the libraries you're building. When you're doing Maven builds, it's not enough to simply keep track of the plugins you're using. Each plugin has its own dependency graph, and if that graph overlaps with something you're trying to build and ship, it can cause a chicken-and-egg scenario that makes it hard to guarantee that what you're shipping is actually the code that you built, and not something you imported for the sake of supporting a plugin.

This is where monoliths come in handy. By creating self-contained plugins (and other libraries used during a Maven build), you avoid questions of dependency-graph overlap.

## How To Use

Imagine you want to create a self-contained version of the Maven Archetype Plugin. However, since you want to manage the archetypes you're planning on shipping, you actually need a self-contained version of the `archetype-packaging` artifact. It's possible this artifact is already self-contained...for the purposes of this example, assume it's not.

Simply create a new Maven project, and in the pom.xml add this:

    

      

        

          org.apache.maven.archetype

          archetype-packaging

          2.2

        

      

    

    

      

        

          

            maven-archetype-plugin

            2.2

          

        

      

    

Then, issue the following:

    mvn org.commonjava.maven.plugins:monolith-maven-plugin:create

When Maven finishes, the basic output (i.e. monolithic artifacts + poms) will be in the `target/monoliths` directory. Additionally, the plugin generates a partial local repository (by `install`ing these artifacts and POMs) in `target/installed`. It also generates a partial remote repository (by `deploy`'ing these artifacts and POMs) in `target/deployed`.

## Making That Last Call Simpler

If you want to simplify the Maven command line you must run, try adding the following to your `settings.xml`:

    

      org.commonjava.maven.plugins

    

Then, the command you must issue becomes:

    mvn monolith:create